Fuel Cell Integration for Electrified Propulsion

This is a two-part webinar series where we cover two topics. And today's topic is fuel cell integration for electrified propulsion. Here's the agenda for today. And we would like to introduce our speaker, Rahul Choudhary.

Rahul is a senior application engineer at MathWorks India, and he specializes in the field of system modeling and control design. He has over 10 years of experience in power electronics control, motor control, multi-domain modeling, and real-time simulation.

Before joining MathWorks, Rahul worked with an Eaton India Engineering Center as a control engineer, where he was involved in developing prognostic and health monitoring algorithms for proof-of-concept projects for their electrical business using MATLAB and Simulink.

Rahul holds a master's degree in system and control engineering from Indian Institute of Technology Bombay and a bachelor's degree in electronics and instrumentation engineer from Institute of Engineering and Technology, Lucknow. Over to you, Rahul.

Thank you, Pooja. Let me quickly share my screen. Is it visible?

Thank you. So yesterday, we covered first part of this webinar series, where my colleague, Ramanuja and Dr. Chandrashekhar spoke about green hydrogen production, importance of green hydrogen, and how we can solve certain challenges with the help of simulation. Today, I am going to talk about fuel cell integration for electrified propulsion, where mainly, we are going to see the application of hydrogen fuel cell in various applications.

So I have divided my talk into three categories, the first one where we are going to focus on how we can leverage modeling and simulation capabilities to develop these systems, which includes fuel cell, the battery, and other components. Then we'll speak about how we can develop some kind of control algorithm or supervisory control logic, validate its performance, and then code generation for deployment on the hardware.

And finally, we'll cover real-time testing and prototyping. So before connecting your control algorithm or control hardware to final prototype, how can you make sure that it is working the way it should be? By doing something called real-time testing and prototyping. So these three things we are going to cover in today's session.

Why it is important-- so climate change, it's talk of the day. So everybody is talking about and concerned about the climate changes. And if we talk about transportation, whether it is goods or people transportation, the contribution is significant towards this climate change. That's when we can reduce some of these carbon footprints by moving to more sustainable solutions, such as batteries or fuel cell.

Batteries are very good for, maybe, small vehicles. But as we increase the size of the vehicle-- maybe a truck or buses are maybe electrical. Maybe ships or airplanes, their battery is not only going to take a lot of time to charge but also, they are going to put extra burden in terms of weight, basically, for doing the transportation, or taking goods from one place to other place.

One user story where Nuvera, they developed hydrogen fuel cell, our primary aim was to reduce CO2 emission. And they used the hybrid approach where both fuel cell and battery was used. And the battery was mainly there to handle, or provide excess load-- or provide charge when there is an additional load or if there is some amount of energy which is being generated because of regenerative braking, then that energy can be quickly absorbed into the battery pack.

In their own words, you can see that "Fuel cells are better than batteries whenever the long range is required or when the battery charging is taking too much time, making them an ideal candidate for boats, planes, trucks, and buses, and for emergency response vehicles." So with this, let's dive into the first part of today's presentation, how we can leverage system simulation to develop multi-stack fuel cells and battery propulsion system.

So why we need to model anything? The motivation for modeling any system is if you have access to system-level model, then we can validate its behavior against the requirement. We can make sure that the system which we are trying to design is as per the requirement.

Once your model is ready, you can use that model to optimize system parameters and also control design. So it can be used for rate of analysis, design space exploration. And eventually, not only just the plant model but you can have a system-level model where you have both your plant, as well as the controller.

And everything can be tested in one single environment. So you don't have to rely on multiple tools and working simulation based approach where it can be, sometimes, tricky. Everything can be one environment where you can optimize system performance, as well as your controller's performance.

When we have to create a system-level model, there are various tools which are available. So for control design, which typically consists of some kind of logic or mathematical expression, and those logics or expressions can be modeled with the help of Simulink blocks, there is another tool called Stateflow, which sits on top of Simulink.

And Stateflow is a very useful tool when it comes to modeling logical systems with the help of state machine or flowchart. So that's how you can quickly model your logical algorithm or system.

The other part is plant. Typically, this plant consists of a multi-domain system where you have the mechanical part, electrical part, pneumatic and hydraulic parts, and they interact with each other. You can use Simulink to model your plant. But the only thing is, first, you have to represent those plant dynamics in the form of mathematical equation. And then you can model it using blocks, which are available in Simulink.

There is another tool which sits on top of Simulink-- we call it Simscape-- which is our physical modeling tool. So instead of modeling your system based on its mathematical implementation, you can model it based on its physical appearance.

So we provide components such as resistance, inductance, capacitance from electrical domain or, if you talk about mechanical, then components related to the drive train, vehicle dynamics. All those blocks are readily available. And you can use those blocks to quickly assemble your plant and then do a closed-loop simulation.

So once the system-level model is ready, you can just click on this Play button, and then you can see different types of behavior of your plan. In today's context, or for today's webinar, this is the system which you are trying to model. And it has two major components.

One is the control algorithm. In this case, it's a supervisory controller. And the job of the supervisory controller to make sure that there is efficient power transfer between the source, which is battery, and fuel cell and also to the load. And it is also going to regulate the amount of cooling which is going to flow through these components so that we can maintain the temperature within the specified limit.

Once the model is ready, we can click on this Play button. And then we can analyze different parameters, such as the energy consumption from the system, how much current battery and fuel cell are producing or drawing, the heat flow, hydrogen consumption, the overall bus voltage, and how much power this particular system is generating, or producing.

This is just a beginning. When you have a system-level model, you can do various what-if scenario simulation. You can use this model for design space exploration. So for example, I can quickly test which configuration is going to suit my requirements, whether three battery and two fuel cell stacks or two battery modules and three fuel cell stacks, which one is going to be better for me, in a click of a button.

We can also use it for controller calibration. So I can play with a hysteresis component of my temperature controller and see its impact on overall systems. So on the left-hand side and the right-hand side, we are comparing the energy produced and then the overall temperature. And you can see when we change the hysteresis, it is going to impact the way fuel cell and battery, they are going to produce the energy.

So here, I'm doing things in a ad hoc manner. But if you want to truly utilize the capability of simulation, then all these things can be automated. And it is not restricted only to changing one or two parameters, but you can change number of parameters by automating the task by creating a MATLAB script. You can also take advantage of built-in optimization algorithm to take more informed decisions instead of trying trial and error-based approach.

OK, let's talk about the plant. In plant, we have that the major components are fuel cell. And if I go inside the fuel cell, this is being created using the block which is available in Simscape Electrical library. If I double-click on this block, it asks for various parameters, such as what is the open-circuit voltage for your fuels and how many cells are connected in how many units are there, and are there different parameters.

If you notice, we also have a hyperlink for source code. If I click on the Source Code, it is going to open the source code, which is how this component is being developed. The source code is nothing but a Simscape language, which our developers, they use to create all the blocks which you find in Simscape library. And it is also open to users. So if you want to create your own custom component, you can do that.

However, we have not created any custom component for this fuel cell stack, but we are using the existing fuel cell block, and we are arranging them, or connecting them, in parallel to make a stack. So you can see there are two major components in this Simscape script.

One is the component, the component which you want to use, from the existing library and then the connection-- how I want to connect if I have multiple such components. So we are using this variable called Nr.

So that basically dictates how many components are there which we want to connect in parallel. So once you specify this Nr, then this script, what it is doing, it is replicating these components Nr times and connecting them in and essentially making the entire fuel cell stack.

The other component in this model is the battery unit. And we are using same approach for battery, where we are replicating this battery block multiple times based on the number of stacks, number of cells that are available in that particular stack.

For battery modeling, we are relying on something called electrical equivalent models and start modeling the chemical aspect or chemistry of the battery. We are trying to capture its electrothermal behavior. Battery provides a lot more details.

So, for example, you can also model the aging of the battery, so how battery performance is going to deteriorate over a period of time based on the number of charge and discharge cycle; some other capabilities, such as setting the current direction, so depending upon whether it is connected to the load or connected to the charger, the internal resistance parameter is going to be different.

Since our battery block is based on electrical equivalent parameter, getting these electrical equivalent parameters from manufacture is sometimes difficult. Because they're not going to give you how your open-circuit voltage or thermal resistance is going to change as a function of state of charge and temperature. But instead, they are only going to provide you charge and discharge profiles.

What we have done, we have created something called preparameterized block where, if you click on this option, you'll find battery from different manufacturer. And if you find your manufacturer in that dropdown menu, you can go and select that, and it is automatically going to populate all the necessary electrical equivalent parameters into that battery.

Other than the battery, we also have drive. And here, we are using a very interesting construct from Simulink called Variant Subsystem, where we are implementing three implementation of the same motor where we have single-motor drive, dual-motor drive, and triple-motor drive. And instead of having three different models to accommodate these variants, we are using this variant subsystem.

And quickly, we can switch between one or other variant by either going and manually selecting it or defining some kind of constant, which is going to pick the right variant for the simulation. The advantage of having Variant Subsystem is you don't have to maintain multiple models if you want to try out different configuration in your model. You can keep everything under one model, and then you can switch between one variant or other based on your requirement.

The other component is power converter. So here, we have taken blocks from, again, Simulink Electrical library. These are low-fidelity DC converter, which means we are trying to simulate its behavior, and we are not going into details of switchings and all those things. That makes this model run very fast. But if you are interested in simulating the switching dialings as well, then, in that case, you can choose a different variant or variation of it.

The last component is the cooling system, where we have taken blocks from Simscape Fluids library to model this cooling system. You can see there are two motors to cool battery and fuel cell. And the coolant is passing through a heat exchanger where the heat is getting dissipated to the environment.

In terms of control system, we have implemented a supervisory logic with the tool called Stateflow where we have multiple states-- the main state, which is going to control how the system is going to operate, whether it is going to operate in battery-only mode or dual mode or the standby. The bottom two states are going to specify, or are going to control, the amount of coolant that's going to flow from the cooling network, one for battery and one for the fuel cell.

So with that, we covered the modeling and simulation part. And now it's time for a poll question. So poll must be appearing on your window. So the question is, why system modeling is important to you. Why would you like to do system modeling?

And you can select the appropriate option, whether you want to do some design, trade-off analysis, or want to use that plant model to design your control algorithm, explore design space, or, eventually, you want to use that model to perform hardware-in-the-loop testing. Or if any of these options does not make sense to you or if you have something else in mind, please specify your answer in the chat window.

So I'll keep this poll question open for some time, and then we'll move to the next section of today's presentation. OK, so let's move on.

The next part is how we can develop supervisory logic and then verify that logic and, once we are happy with the overall closed-loop simulation, then how we can take the algorithm and deploy it to the target hardware. So the complexity of the system is increasing day by day. And we want to approach to this problem in a different way.

So we want to make the solution, or we expect the solution, to be more modular and reusable. So whenever a new problem comes to us, we don't want to start from scratch. We want to reuse all the learnings, what we had earlier from the earlier project.

And because of that, we have more and more involvement of the software in the system. So nowadays, most of the things are controlled via software rather than using some mechanical or mechatronics component.

Now, if you don't test these algorithms in detail, then there is a risk of finding some error when you are doing the commissioning. And if you identify those bugs while commissioning the product, then you can make a lot of people angry because you'd be wasting expensive hydrogen, which is very difficult to produce.

So why we need to basically develop, verify the logic? So first of all, everybody has a different coding style. And it's very difficult to understand anybody's code and update and modify it. So use model as your ultimate truth. Because it is easy. And it's easy to understand, easy to update, compared to any low-level code.

You can also test your model to make sure that it is meeting your requirement, the model is as per your requirement, and then control is performing the way it should so you can do proper testing on your model. And once you're happy with the model's performance in desktop environment, you can move to the code by using a feature called automatic code generation.

So let's go back to our model again. Let's go into the Supervisory Logic. Let's double-click on it. And inside the Supervisory Logic, you can see we have implemented things using a Stateflow machine where we are taking afferent inputs from the system, and then it is producing some output based on those inputs.

If I go inside it, you can see, so the states are highlighted in yellow color. Why? Because it is saying that this state is unreachable. So there is no incoming transition to this state.

I can quickly draw a transition from a default state to this dual-mode state and put some condition, like when it should go to this dual-mode controller. So basically, when the charge and the battery is less than some threshold, then it should go to the dual mode.

What is Qlow? Qlow is nothing but a parameter which we can control from our workspace. And based on the threshold value, it is going to move from battery-only to dual mode, where it is able to utilize the battery and field set.

Now I can run the simulation. Another advantage of Stateflow is it will give you a visual cue, so you can see how logic is going to execute through Stateflow animation. That way, it becomes very, very easy to debug any error, or any problem, in your code. And you can quickly understand whether it is going to the right states and producing the right output or not.

If you want to learn more about Stateflow, then we have our Stateflow Onramp, which gives you some hands-on experience, and then a short tutorial to define the problem statement. And it's very interactive, with automated assessment and immediate feedback. So if you're trying to do such an exercise, it will immediately give you a feedback, whether you are doing or if you want to make any changes.

And the good thing about the Stateflow Onramp is it's freely available, along with the tool. So I would highly recommend you to go through the Stateflow Onramp if you are working on any kind of complex logical system modeling using MATLAB and Simulink.

Moving forward, so let's talk about model-based design verification workflow. There are two things about model-based design verification workflow. One is model verification and the code verification.

If you go deeper into the model verification, there are certain questions we want to answer. So first of all, whatever requirement I have for my system, does my model meet all the requirements? How we can check that, so we have a tool called Requirement Toolbox, which can be interfaced with the various requirement management tool, or you can also alter your requirements directly into this particular tool.

And then you'll get a visual like this where, for each requirement, you can check whether the requirement is being implemented or it is not being implemented. Later, we'll see, but you can also check, or verify, whether the component which is being implemented is as per the requirement or not.

So you can see here if it is green, it means whatever requirement we have implemented, it is behaving as it should. If it is yellow, it means we did not test. Or if it is red, it means it is not meeting the requirement. So definitely, with the help of this Requirement Toolbox, you can quickly understand whether the model is as per the requirement or not.

Now, second point is once a model is developed and it is meeting all your requirement, next question we would like to ask whether it is functioning correctly, whether it is producing the output it's supposed to produce. How we can test that, so for that, in this particular supervisory controller, at the bottom side, you can see these three options.

By clicking on that, we can create a harness model to quickly test this particular unit. When I click on this harness model, it produces the component under test and, also, a couple of inputs, which we can vary.

Just to remind you here, we are doing unit-level testing. So we have not connected this logic to the plant. But instead, we are just going to test the functionality of this supervisory controller by giving various kind of inputs.

Now, in this model, what I'm going to do, I'm going to enable something called coverage analysis. What coverage analysis is, we'll discuss that later. But as of now, I'm going to enable that option.

And you can see here the coverage analysis is on. And then I'm going to run the model. And from these dashboard icons, I'm going to vary different inputs and basically going to observe how my supervisory logic is going to react to those changes.

So you can see the moment I move something on the slider, it is moving from one state to other state. I can quickly change the temperature profile for the battery, temperature profile for the fuel cell, maybe play with different options. So basically, we are running the system in open loop, and we are changing different inputs. Then we are just observing how my supervisory logic is going to behave.

Let's stop the simulation and go back to our coverage analysis part. And if I click on this, highlight the coverage. So when I was playing with the model, you can see the certain parts which are highlighted in green, which means these parts were thoroughly tested. So I was able to execute these conditions. But there are certain parts in this model which was not executed. So for example, in this case, the dual-mode operation was never tested.

So when I'm going to take this logic and put it on the actual hardware, we never know what kind of error we might face, whether there could be possibility of divide by 0 error or integer overflow. Those things we don't know because we have not tested this part of the code. So testing each and every part of the code is very, very important. And that's when the coverage analysis comes very, very handy.

So the next part which I'm going to address is, is it completely tested? Did we verify all possibilities into our model? How we can do that, so what we can do-- now, let me go back to the model again. And this time, I'm going to open a different harness model where we are going to use two special blocks. One is test assessment block and test sequence block.

This test assessment block can test a particular scenario. So for example, I want to understand, when the battery is lower than the threshold, or the charge of the battery is lower than the threshold, then the fuel cell must be on. So in this particular test assessment block, I have put this condition, and then I'm going to verify when this condition is true, whether the fuel cell is on or not.

Similarly, we also have a test sequence block. So if you want to test multiple scenarios-- so, for example, starting with some initial condition and then when some condition occurs, then it should move to the next step, not only based on certain condition but we can also provide a temporal logic.

So after this condition happens, wait for one tick. One tick is nothing but one step time. We can also give something like after five seconds or five ticks or 10 ticks. So that way, by using this test sequence block, we can test different scenarios without even writing multiple test cases. So either we can run the model and see how it is behaving or we can use another construct called Simulink Test, where we can incorporate all these tests and automate it.

So the Simulink Test Manager can incorporate various test cases, and you can define different conditions. So there are multiple parameters to change. We can override the simulation parameters, inputs. And then, in one single click, it is going to run all those test cases.

Currently, you have only one test case. But if you have hundreds and thousands of test cases can run one by one. And then it is going to give you a result, whether it has been passed or fail. In our case, it is being failed because it is not able to meet the condition at one particular instance.

We can also generate a report out of it. And we can capture all the details about what kind of test we ran and whether the test was passed or failed, if it failed, then why it is failed. So these kind of artifacts, we can be produce.

Now, another thing what you would notice in this particular Test Manager that if I scroll down, you see that we have this 35% coverage analysis, which means that whatever test cases we ran, it was only able to excite the 30% logics into the model.

If you want to make this 100%, you want to thoroughly test each and every part of your algorithm, then you can quickly click on this button, which is Add Test Cases for Missing Coverage. And with the help of tool called Simulink Design Verifier, you can basically generate test cases for missing coverage. So that's how, with the help of dual Simulink Design Verifier, we can totally test our algorithm.

Now once algorithm is properly tested, we can generate code out of it. And our code generation process is independent of-- it is hardware agnostic, which means when you are in the development process or development phase, you don't have to worry about what end hardware you are going to use. You focus on improving your design, making sure that it is as per the requirement, there is no unwanted output or any bugs in your model.

Once you are happy with your desktop-level simulation, then you can generate code from your algorithm. And it could be a C code, which you can take to any embedded processor or HDL code, which you can take FPGAs or even PLC code.

And we support multiple hardwares. Even if your hardware is not supported, so either you can write your own custom code for that or you can also leverage our consulting services, and they will help you to deploy your code to your particular target.

Let's try to understand the coordination workflow for the same supervisory logic. So what we can do when we have the supervisory logic, we can go to this Apps tab and open this app called Embedded Coder.

This Embedded Coder, if you're new to Embedded Coder, we have something called Quick Start. This we introduced a couple of releases back. And in this Quick Start, it is going to ask certain questions related to the model and the kind of code you want to generate.

And then it is going to analyze your model for multiple time rates and states and all those things. And you can also specify what kind of hardware you want to use for deploying this code. And based on that, it is going to make some appropriate changes into the data type.

So in this case, I'm going to select a C2000 from Texas Instrument. You can also specify whether you want to generate code for execution efficiency or RAM efficiency. And based on your selection, it is going to update certain settings in your code generation window. And then it is going to generate the code.

Once the code is generated, you can see here, on the left-hand side, you have the Stateflow logic, and the right-hand side, we have the generated code. And here, Embedded Coder is going to establish a bidirectional traceability, which means you can quickly navigate from your Stateflow chart to the generated code and also from the generated code to the Stateflow chart. This bidirectional traceability will allow you to quickly understand how the code is being generated and make sense out of it.

If you want to automate this task, then we also support CI/CD workflow, which is nothing but continuous integration and continuous deployment, or deliver. If you want to know more about this CI/CD workflow, then I would highly recommend you to go through our MathWorks website and try to learn about this particular workflow.

In terms of standards, or in terms of certification, we do support multiple workflows from various industries. What MathWorks tools is going to offer here, it is going to reduce the amount of effort you need to put for any certification by generating appropriate artifacts which are required for different certification and by different certification agencies.

With that-- in the certification, by the way, the hardware-in-the-loop validation is one of the important aspects. And in the next section, we are going to talk about real-time testing for virtual prototyping, which is third and final topic for today's presentation.

So then how do we move from concept to product? So we do desktop simulation. We verify the control algorithm. And then we deploy the control algorithm to our hardware controller.

How do we make sure that there are no surprises when we deploy the control algorithm to the hardware? Maybe we can test it against the simulated model and by performing processor-in-the-loop simulation.

However, there is one important piece which is missing is the real-time testing. Because in processor-in-the-loop, the model is able to generate the output, but the output is not generated in real time, which means, unlike a real plant, where it is not going to wait for controller input, the simulated one is going to do that. So it is not a very realistic scenario simulation.

So that's why we need to do real-time testing where we are going to put this model on some kind of hardware emulator. And then we are going to connect our controller directly to this hardware emulator, and it is going to exchange signals in real time.

So for this hardware controller, it won't be able to differentiate whether it is talking to your actual plant or it is talking to a hardware emulator. Once you verify the performance in hardware-in-the-loop simulation, then you have a good amount of confidence that, OK, this controller can be connected to your actual physical prototype or expensive hardware.

So why we need to perform real-time testing? So if you want to try out different concepts, different ideas, and you don't want to use your expensive physical prototype to test those ideas, definitely, real-time testing is going to help you with that.

There are certain scenarios which are very difficult to test on actual hardware, so, for example, if you want to inject some fault or you want to create a harsh environment and verify your controls performance. One good example could be doing thermal runaway for your batteries. So doing thermal runaway on actual battery pack is going to be very, very dangerous. So it's always better to do it in simulation environment or in virtual environment.

Third thing is it is flexible. It is less expensive. You can do all those testing without creating expensive prototypes, and it is flexible. So today, if you are working on, let's say, a hydrogen fuel cell or e-mobility, tomorrow, you are working on a solar inverter, the same setup can be used for multiple applications. So that way, it is really, really flexible.

What MathWorks has to offer-- so we have our real-time target partner called Speedgoat. And then so MathWorks provides all the necessary softwares which are needed, both in terms of model, the controller, toolboxes, real-time operating system, device drivers.

And then Speedgoat, they provide these configurable real-time target machines, which you can customize based on your application. And they are tightly integrated and give you a turnkey solution, in some sense. The value of turnkey solution is, so, first of all, it's one team, so you don't have to talk to 10 different vendors for plant modeling, controller design, and implementation side.

Another advantage is Speedgoat is always going to support the latest release of MATLAB, since they are partners. So whenever you are going to upgrade your MATLAB version, you don't have to think twice whether the Speedgoat is going to support that upgraded version or not. Third thing is smooth onramping to MathWorks training and consulting services.

About Speedgoat-- so if you're working on a general-purpose application-- maybe some kind of mechatronic system, energy management system, where the sample time or the rate at which the model is going to get executed is typically higher than several microseconds-- then in that case, you can use CPU-based solution.

But if you're working on, let's say, power electronics components and you want to do a harmonic analysis-- and these power electronic switches, they typically operate in the order of hundreds of kilohertz than in gigahertz-- so if your sample time requirement is going to be less than 5 microsecond, then Speedgoat, also offers a FPGA-based solution where you can accelerate the whole process and achieve real-time performance.

So when we are learning the model, we can open the Solver Profiler and try to look at some of the key parameters here. So when you open Solver Profiler, there's one key parameter to look at is basically run per simulation ratio. If run per simulation ratio is less than 1, it means your model runs faster than the real time.

What do I mean by that? So if my simulation stop time is 80 seconds, model will be able to compute the output well before 80 seconds. If my run per simulation ratio is more than 1, it means my model runs slower than the real time. So the same 80 seconds of simulation will take more than 80 seconds.

How do we prepare the model for real-time testing? So if you go back to the same example, so what we can do, we can use the Solver Profiler. So in this case, we are getting the controller as a discrete system. And then the rest of the plant model, we are solving with the help of a variable-step solver. And this combination gives us a most accurate result. And we can also consider that as our golden reference.

Now, in order to basically prepare the model for HIL simulation, we have to go and discretize the model. So either we can do it from the Solver configuration from the Simulink, or we can take advantage of this local Solver, which is available with every Simscape network. It gives us a little bit more flexibility in terms of discretizing the Euler solver.

And then we can run the model and compare the output, whether it is comparable to the golden reference or not. If it is not, then, probably, we have to tweak certain parameters into the model and make it acceptable in terms of accuracy.

Once we specify the fixed-step solver and all the parameters, we would also like to update certain parameters, which we would like to change during the runtime, so, for example, parameters which are there on the battery and then, also, the parameters which are there on the fuel cell. The idea here is I want to keep all these parameters as the runtime parameter. Because every time when I make changes to these parameters, I do not want to recompile the model again.

Same thing you can see in the generated code, as well. So all those runtime parameters would appear as your interface where you can directly change these parameters without recompiling the model.

So once your model is ready for real-time implementation, you can take this model, put it on Speedgoat hardware. The additional thing what you need to do is you need to add your device drivers, both for input and output.

Device drivers are nothing but how you are going to take the physical input to your model, so if your controller is connected via some kind of I/O or some kind of communication protocols, how those physical signals are going to come to your simulated model. That can be done with the help of device drivers. And typically, device drivers are provided along with the Speedgoat hardware.

Once you configure your model, you can generate a code using this TLC file-- slrt.tlc-- which is going to convert this whole application into a real-time application, which you can then, on Speedgoat, in real time. So that was from the third part of today's presentation.

Before we move to the final section, I would like to pause for a moment and ask you another poll question. So based on today's discussion, what next step would you like to take?

Would you be interested in trying MATLAB and various toolboxes for your project; or you'd be interested in upskilling your team's competency by talking to MathWorks trainers; whether you are interested in talking to technical expert from MathWorks; or, as of now, you're not interested in any of the above options, and you don't want to do anything for now.

So please select appropriate option from the poll. I'll keep this poll open for a few seconds, and then we'll move to the next part.

OK. So as a summary, we saw a couple of things, the first how system-level simulation and multi-domain simulation environment is going to help us perform trade-off analysis, controller calibration, and all those things. The second part of presentation, we saw how we can develop supervisory logic with the help of we can call Stateflow, how we can verify the supervisory logic, and then, finally, generate code out of it and do systematic validation.

And, finally, real-time testing and prototyping, how we can use the same model which we use in the design phase to design our control algorithm for agile testing or virtual testing and how we can reduce our dependency on expensive physical prototypes by taking advantage of real-time simulation.

There are certain resources which are available if you are more interested in a better solution for physical modeling or power electronics controls. If you are interested in trainings other than our instructor-led trainings, we have a couple of Onramps. We spoke about Stateflow Onramp, but there are other Onramps, like Simscape, Control System Design, Circuit Simulation.

If you want to understand more about how other companies' organizations, they are leveraging MathWorks solution to basically reduce their development time, make product which is more reliable, then you can also go through some of these testimonials.

The bottom line is model-based design is strong ROI. And there are multiple user stories, which are available at MathWorks website, from various industries, from various domains. And they all list out the benefits or ROI they got from model-based design workflow.

With that, I would like to thank you all for your attention. And if you have any follow-up questions, please feel free to put it in the Q&A panel, and then I'll try to answer these questions one by one.

And the final point, we have MATLAB EXPO coming up. It's a online version starting from May 10. I would highly recommend you to just go through the website and then identify such sessions which are relevant to you, do your application, and register for those sessions.

I would also like to thank our partner, IESA and IGHC. And as I said earlier, please revisit the registration page in a week's time to have access to the recording, not only for today's session but also for yesterday's session. Thank you, everyone. Thank you.

Thank you all for joining us today and taking time out, and I hope you found the session truly insightful. Again, we'd like to thank Veena and IESA and IGHC partnering with us for this event.

You can reach out to our speaker, Rahul, or Rahul Choudhary. We have posted his email ID on chat, as well. So please do reach out to us.

I know there were a few questions which we couldn't answer today, considering the time limitation. But please, do reach out to us over email, and we'll definitely try to revert back with your queries as soon as possible. Thank you so much.