Fuel Cell Integration for Electrified Propulsion - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 44:54
Loaded: 0.09%
Stream Type LIVE
Remaining Time 44:54
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 44:54

      Fuel Cell Integration for Electrified Propulsion

      Overview

      Hydrogen Fuel Cells appear as an attractive alternative to traditional fossil fuel engines in freight and passenger transport systems (marine, heavy-duty, railroad, off-road, aerospace) thanks to their high energy density. However, fuel cells are a part of a complex system including batteries, power converters, electrical machinery, and cooling equipment. Join this MathWorks presentation to uncover how Model-Based Design helps to solve challenges such as system sizing, performance trade-off analysis and concept development while ensuring lowest time-to-market and product safety.

      Highlights

      • Multi-stack fuel cells and battery propulsion system
      • Energy management design
      • Supervisory logic and state machine development
      • Embedded code generation
      • Real-time testing and prototyping

      About the Presenters

      Juan Sagarduyis a senior application engineer in the control design and automation field. His specific focus is physical multidomain modeling and simulation. In his role, Juan provides technical expertise for successful adoption of plant modeling tools (Simscape™ platform) for model-based development. In recent years, he has led several initiatives within Electrification for the Nordic region. Before joining MathWorks in 2011, Juan worked at the ABB Corporate Research Centre (Västerås, Sweden) in electrical machines and motion control projects. Juan holds an M.S. degree in industrial engineering (Bilbao, Spain) and a Ph.D. in electrical engineering from Cardiff University in the UK.

      Vasco Lenzi is a senior application engineer at MathWorks Switzerland. He specializes in design automation with emphasis on multidomain modelling, control design, verification, and deployment. Prior to joining MathWorks in 2016, Vasco worked as a development engineer on the modelling and simulation of engines and hydraulic systems at Liebherr Machines Bulle. Vasco also worked as a control software developer at the Institute of Dynamic Systems and Control, ETH, with active participation in Formula Student competitions. He holds a B.S. in mechanical engineering and an M.S. in Energy Sciences from ETH Zurich.

      Romain Lachauxis an application engineer at MathWorks with a focus on simulation tools. Before joining MathWorks, he spent 6 years of his career at Renault F1 Team where he gained significant experience in high-efficiency ICE, hybrid systems, energy management and dyno operation, applying some of the core model-based design principles. His broad automotive background is consolidated by a prior experience on engine calibration at Delphi after graduating from both ESTACA and IFP School.

      Recorded: 26 Apr 2022

      Hello, everyone. And welcome to this webinar dedicated to fuel cell integration for electrified propulsion. My name is Romain. And I'm an application engineer at MathWorks in France. And today, we have Vasco and Juan, application engineers too in Switzerland and Sweden. This webinar is the first and the last one of our webinar series about hydrogen production and fuel cells. Today, we will focus on future applications and, more precisely, their integration into electrified propulsion system.

      In this webinar, first, we will see how you can model such a system such as the fuel cells and every component needed, like power converters, electric motors, or cooling system. We will also highlight how you can design and verify the supervisory logic needed for this system using simulations and verification and validation capabilities. We will show how to generate and navigate between model and code. And as a last step of your design workflow, we will discover real-time tests, activities applied to fuel cell systems to guarantee quality and robustness of your design.

      As you may know, climate change is a global concern for everyone. We have a lot of thinking to decrease our impact on the environment and achieve a sustainable future. Transport of people and goods is a significant part of global CO2 emissions. And that's why all this industry is committed to make significant progress toward reducing carbon footprint.

      For light vehicles like passenger cars, the electric solution based only on batteries is the most popular one for now with a mature technology based on lithium-ion. But for other applications like trucks, commercial airplanes, or ships, for example, this solution may not be adopted because of the amount of batteries needed to perform long travels with heavy loads. And that's why future solutions is very interesting. They don't produce harmful emissions over the long range and the quick refueling type. To sum up, fuel cell with green hydrogen is a credible technology for this application.

      To illustrate this, we can mention Nuvera. Nuvera has developed fuel cells with the aim to reduce CO2 emissions caused by commercial diesel engines at seaports. In this application, batteries are also used to accept power regeneration from braking in a fuel cell electric vehicle or from lowering the load of a forklift.

      You will use this model-based design to simulate and optimize the control algorithm's behavior against a model of the fuel cell engine. And it additionally uses hardware in the loop testing to add rigor to the embedded computer's performance verification to fully test capabilities.

      So let's see how you can develop this fuel cell and battery propulsion system efficiently thanks to model-based design. And the first step is the building of a system-level model. When I speak about system-level model, I mean a model in which you will find both control algorithms and also plant model.

      Thanks to this model, you can quickly evaluate the behavior of your design against requirements. You don't need to wait for a physical prototype to do this. You can also use this model to optimize your design and associated calibrations in order to improve multiple parameters like sizing, energy flows, et cetera. And also, because we are able to model both control and plant path in the same simulation platform, you don't have to deal with co-simulation.

      So concretely, for the control part, we have Simulink. Simulink is a simulation platform that will allow you to create a model of your system like control, signal processing, communications, or other dynamic system and simulate it. In the same time, within your Simulink model, you can also build state diagrams thanks to Stateflow, which is an additional toolbox working in the Simulink platform.

      With it, you create state machine to respond to instantaneous changes in a dynamic system. It's generally used in modern management or for safety purposes in different systems like battery management. For the plant, this is generally an assembly of multiple components that can have different properties like mechanical parts, electrical systems, or fluid circuits.

      To model all these components, you can for sure use Simulink. Indeed, physical systems are defined by physical equations. And you can translate this physical equation system into a Simulink model thanks to mathematical blocks. But clearly, it will quickly become too complex to create, to read, and to update this type of model. And that's why there is also Simscape, which is a dedicated toolbox for physical modeling tasks into the Simulink platform.

      Thanks to Simscape, you will be able to easily create multi physical systems with, for example, electrical, thermal, and mechanical parts. And so you see that you can model your complete system with Simulink, which means that you are able to use the system-level model and simulate it very early in your design process to perform closed loop testing and ensure that its behavior complies with your requirements. The Play button in Simulink is, I think, the most important button that you can find in this tool.

      So if we come back to our topic, here is the model of a multi-stack fuel cell and battery propulsion system in Simulink. In this model, we can find the two main parts that we mentioned before. First, we can see the control part, which will manage the energy through our system and also the cooling system for both batteries and fuel cell stacks.

      And then, we have also the plant part, the assembly of multiple physical components of our system like batteries, fuel cell stacks, electric motors, power converters, and cooling system. Again, the main interest of this system-level model is that everything is modeled in the same simulation platform. So you can perform closed loop testing very easily without co-simulation concerns.

      So here is, typically, the results that you can get from these simulations. You can observe and evaluate each quantity at each node of your physical network, such as the power, the voltage, or the current in your battery or fuel cell stacks. This is a good first step to analyze the behavior of your design. But this is just the beginning of the journey.

      Indeed, based on this model, you can perform several design activities. For example, you can evaluate multiple architectures of your system. In this case, I compared an architecture with three battery modules and two fuel cell stacks versus an architecture with two battery modules and three fuel cell stacks. Then I can build multiple figures to easily compare energy flows or temperature in each component. And depending on my initial requirements and these results, I can choose which architecture is the best for my application.

      You can also use simulation to evaluate the calibration of your controller. Here, I just tested a decrease of the hysteresis on the temperature that controlled the cooling system. And we can see that this modification has an impact on the distribution of the energy flow between fuel cell and battery. Moreover, here, I compare just two possibilities manually. But you can, of course, use MATLAB script to automate parameter sweep, execute Monte Carlo simulations or cross-function optimization.

      Now let's have a look on how we built this model. For the plant, the most significant parts of our system are, of course, the fuel cell stacks and the battery modules. About the fuel cell unit, if I double-click on the components, I will see the Settings window in which I can change several parameters like the number of units, the internal resistance, or the thermal mass.

      But in this Setting window, you can also see hyperlink called Source code. Indeed, this fuel cell block is a composite component built thanks to Simscape Language, as you can see here on the right. Simscape Language is the foundation of Simscape. It is used by MathWorks developer to create a prebuilt component that you will find in the Simscape Library. But this language is also available to each user. So you can use it to modify an existing component or to create a brand new component with a specific behavior.

      In our case, we used Simscape Language to create a new component, but mainly based on that existing one. Indeed, the basis of our components is the fuel cell block available in Simscape Electrical Library. Associated to this block, you have documentation to learn more about physical equations or parameters implemented in this block.

      Then we create texture file based on Simscape Language to create an array with multiple fuel cell blocks. Specific syntax is available to perform this activity. First, we have two keyword components to indicate which block we want to add in our composite components. And then, we have the connection words.

      In this section, we indicate which part of a block is connected to which part of the other blocks. And to be able to change the number of fuel cell blocks connected in our composite components, we create a variable, Nr, and a for loop to perform all these integration and connection activities. In the end, our component is equivalent to the little diagram on the right with multiple fuel cell blocks connected in parallel.

      Let's have a look now to the battery units. For the battery unit, we used quite the same process. Indeed, we used Simscape Language to create a composite component of battery blocks from the Simscape Electrical Library. This battery block is based on an equivalent model, as explained above, for which you can choose the number of type constants, I mean, the number of dynamic loads modeled by RC components.

      In addition, you can choose the abstract level of your component. I mean that you can, for example, take into account several behaviors such as modeling the fading of your battery, also, directionality of the current in the battery. Moreover, if you already know exactly which cell manufacturer and which reference of cell you will use, you may find it in the built-in parameterization for the battery block. Display parameterization data allows you to set up the block to represent components by specific suppliers. The parameterizations of these batteries match the manufacturer data sheets.

      Then we have added electric motors from the Simscape Library in our model and thought that we used a very smart feature. Indeed, in our case, we wanted to test our design with one, two, or three models from the Simscape Library. Instead of creating three different models, we use the variant subsystem, which means that in my model, I have three different architectures of my drive time, the first variant with one motor, the second with two motors, and the third with three electric motors.

      And I can switch easily between each solution based on the parameter value or based on the manual choice. Or this can be set up thanks to the Variant Manager. This solution will simplify your daily work by managing only one model instead of creating a new specific model each time you want to investigate a new solution.

      And to finish with the plot, we have also two DC-DC converters directly available in the Simscape Electrical Library. This specific block represents a behavioral model of a power converter that regulates voltage on the load side. And to balance input power, output power, and losses, the required amount of power is drawn from the supply side Alternatively, the converter can support regenerative power flow from load to supply.

      And finally, we have also our cooling system based on multiple components from Simscape Fluids. In this cooling subsystem, you will find two branches, one for the battery modules and the other for fuel cell stacks. Only one exchanger is used to cool the fluid in the circuit with the external airflow. And as you can see, we have two pumps that command the liquid flow in each branch of the cooling system. These two pumps are controlled thanks to the supervisor logic of our model.

      In this supervisory logic, we can find a state machine built with state flow and have three main functions. The first one is to switch between different propulsion systems like battery-only, dual mode, or standby. We have also two other functions related to cooling, one dedicated to the battery and the other to the fuel cell.

      Here, based on the top right, it shows that it's observed in the physical system. And the limits that we define will activate cooling pump on it. Note that you have a pretty good overview of the model and how you can use it. I'll let Vasco give you more details about how you can use it efficiently to test your design and generate code automatically.

      Thanks, Romain, for a very insightful session on physical modeling for fuel cell system. In your model, you captured as well supervisory logic as software component. And once you have software captured in a model, what can you do with it? Well, let's discover it together in my section, supervisory logic development, verification, and code generation. This is the second section in today's webinar, right before one section on real-time testing.

      Today's world of mecatronic system is experiencing an increasing complexity of the embedded software. This is driven by many factors and trends, such as an impending need for modularity and reusability. For a fuel cell system, we can imagine an electrified powertrain used for a delivery van or maybe something larger like a delivery truck. And so you would like to reuse software as much as possible between just different product lines.

      This leads to more embedded software because a lot of challenges are maybe solved by a software behavior and not by a mechanical behavior. This brings the risk of coming to the commissioning phase, the physical prototype phase, with that big software which is not being fully tested. And particularly for fuel cell system, this could lead to a waste of hydrogen during this long commissioning campaign.

      So the motivation for today's section, my section here, is to talk about, how can a model be used as executable specification so that you can convey intent of your software behavior and not base what you're doing on ambiguous written specification? Additionally, we can actually use technology to measure the quality of your software and of your testing of the software. This makes it so that you have a good model in the end for which you can generate, automatically, code for different hardwares and language systems.

      Now let's see now how we test or develop supervisory logic. As Romain already mentioned and explained, we have a state machine developed with Stateflow, which takes care of different states and routines in the model of the logic. We provide inputs, such as the temperature of the batteries, the energy of the batteries. And we provide output, such as the desired voltage for my DC-DC system.

      We already saw the different three state machines. But in this case, we saw that one of our states is incomplete. It's yellow. It cannot be reached. So I need to design a transition from my initial state to my dual mode state. In this case, I would like to power on my fuel cell when the quantity in the battery is lower than my threshold value, Qlow.

      If I'm wondering what is exactly Qlow, I can always looks at my Symbols panel, where I see that Qlow has been defined as constant data of my state machine chart and is linked to a value in the workspace of the controller struct. So I can simply, by drag and dropping, create a transition based on Boolean condition or others.

      And when I click Play, I have a visual cue, provided by Stateflow, in what is going on. In this case, I am testing closed loop simulation with the physical model that Romain presented. And I can now see if everything is behaving like I expect by comparing the transition values with what it was set up to do and see if the different state machines are acting as I desire.

      If you want to know more how to develop supervisory logic with Stateflow, please feel free to perform the Stateflow Onramp. It's a free, short course on the basic of using Stateflow. It's great. It has hands-on exercises with automatic assessment. There's short video.

      It gives you immediate feedback. So I didn't want to make this a Stateflow lesson. It would take too much time, not when we have something like the Onramp. Take a look at links if you want to get the basics. It's free. It's a great way to learn how to develop supervisor logic in our tools.

      We are talking then about model-based design. In this workflow, we would like to use models to be connected to requirements, then refine the models in order to use it for code generation, and finally integrate the source code. It may be handwritten code for device drivers in real-time operating system to run on the final embedded control unit.

      We have two different verifications that we should do during this process. One is at the model level, in which we discovered design errors at the design time. We'll check that the requirements are implemented, they are still making sense. We check if the models that we are doing are still respecting the proper guideline.

      And we can, as well, perform what we call code verification, particularly for safety critical system, which we make sure that what is running on the ECU of the control unit then is doing exactly the same as my model, for instance, with equivalence testing. In today's webinar, we're going to focus on some model verification techniques.

      One aspect, of course, is the link to the requirements. So if my design, what I'm doing, really meets all the requirements, how do we know? And do the requirements need to be updated? For this, I don't have a live example. But I just want to quickly do mentioning of our Requirements management Toolbox, which allows you to get this view, in which you can see a list of requirements that have been imported or connected with an external requirement management tool.

      And you can then link this requirement to component of your models and so get this nice view with what is being implemented. You can connect, as well, test cases associated to a requirement so that you can make sure that for each requirement, there is associated test cases that can be run and you have either passed or failed results. If you want to learn more, click in the link on this slide.

      Another question that we can ask ourselves, is this functioning correctly? Well, we can do that for once with what we call ad hoc testing. We have designed our model. And thanks to Simulink Test, I create a unit test for the supervisory logic. We can see a new icon on that bottom right corner. If I click on it, I access all the unit tests for this specific subsystem so that I can perform unit testing.

      In this case, my test harness is an open loop test harness. I simply change the value of the input and see how my supervisor logic behaves. On the left, you can see I've added some dashboard blocks from the Simulink Library, in which I can use to connect to constants and change the value in an interactive session.

      I may be at the beginning. I'm just designing my control logic. And I want to know if I'm executing and if I have error in my system. I can measure how much I'm testing using COVERAGE analyzer from Simulink Coverage. I see that this is activated. I'm tracking coverage. And let's see. What does that mean?

      I start simulation with coverage enabled. And then, I simply change things around to make sure that I'm going through all my different states that I want to test. For instance, I can change the quantity of the battery. As I said, this is purely open loop testing. There is no notion of physical plant model or closed loop. I'm just changing numbers using sliders and other things. And I get an immediate feedback from Stateflow.

      And I want to say, OK, am I doing right? Are there things changing when I wanted them to change? Can I see immediately some error? They changed the load. Maybe I want a higher load. And things are behaving as it should. Then I stop the simulation. And I activated the coverage highlighting on my model so that I can immediately see, how much did I actually test?

      So I was playing around. I thought I did a good job. But in reality, I see that, OK, for both the thermal cooling circuit, everything is green. That means I tested every condition and combination of condition. On the other end, for the propulsion system, there are even if else statement within the state chart that I didn't properly test. I never went through that decision.

      And this can be critical, because what happens if I have an integer saturation or our division by zero in that statement? What happens is that maybe this condition will replicate during commissioning. And my system gets stuck with a division by zero or some other error, runtime error, that makes my system fail.

      And people then, of course, get angry because everything is taking much longer than expected. So what do you want to do as design developer, be able to say, look, I tested this 100%. And I didn't find any error. It will give you a lot more confidence about your design.

      Finally, how do we make sure that we are completely testing our system? Is there a way that we can reach 100% coverage? In this case, one thing that is very important, that it's enabled by Simulink Test, is to prepare test harnesses which code the requirement with specific verify and assert statements. We take a look at the second unit test. And we see that this time, we would like to check that the fuel cell output should always be enabled when the total capacity of the battery is under a certain threshold.

      So we get inside the test assessment block. We have started the run. And we transition to a verify statement when the battery is lower than a threshold. That means that every time that there is this condition with the battery charge lower, we would like to verify that the fuel cell is actually one, that the signal is one. So we code the requirement as a test assessment using this new test assessment block.

      We can use a similar approach by creating test sequences. So we can determine input-output. In this case, we would like to do some output and perform a step-by-step test case. If the first transition is based on the desired voltage for the DC-DC converter, then I set the value to a certain value. Then I decided to wait for one sample time of my supervisor logic to change, again, the parameters, the input in my supervisory logic. And so I can have both transition based on values, transition based off time. And this gives me great flexibility.

      Instead of simulating by clicking Play, I would like to perform this from the Test Manager, which comes with Simulink Test. And you can see on the left, I have highlighted a test suite that I have already prepared where I can put the new test. But I already have this low-charge test based on this model, based on this harness. I have many different options to change parameters, perform callbacks.

      And in the end, I can simply decide to run the suite. In this case, the suite is composed by one test. But it can have multiple tests, one after the other. The simulation is running in the background. And I get immediate feedback. If my verify statement has been passed within the second iteration, second time step, there is a fail.

      I can, of course, generate report so that I can document my progress, making sure that I always can showcase that I actually tested, and how much I am testing, and what I'm getting out of my test. We can see that the second, there is a failed statement, all, kind of, options and configurations I've used, which, kind of, computer architecture and so on.

      One thing that we can get together in this test report is the coverage. So my test sequence vector actually tested only 35% of my system. And what is really neat here is that by clicking on this plus button on that bottom right, we can automatically generate test cases that fill, fulfill the other 65% if possible. So the model is going to be analyzed. And test vectors are generated automatically. And test harness is created automatically so that we get to 100% coverage. This is performed thanks to Simulink Design Verifier technology.

      Systematic simulation testing is a powerful way for you as a design developer, an algorithm developer, to make sure that what you're doing at the model-level is fully tested, is functioning correctly. There are no design errors. You can prove the requirements are implemented correctly. And so if you want to know more about how you can perform this validation, follow-up with the link below for our Solution page.

      Once the model is fully tested, I am happy. It comes the moment to generate, automatically, code. As I said, this reduced coding time and errors, it provides you hardware-independent source code based on one model. And the know-how is captured in the model. This helps against fluctuation in the workplace.

      Many engineers come and go. When everyone is writing their own handwritten logic, this is always sometimes very difficult to understand. While it's on the model-level, things stay at the team-level and are much clearer, clearly more expressed in a model than as handwritten solution. You can generate both structural text or C code, HTML, and others. But we are focusing in particular on structured text and C code.

      We integrated in your IDEs either for your control unit, your custom hardware unit. They are very flexible. We support all the relevant PLCs worldwide. And even custom hardware is not a problem. This is one of our most used consulting packages to help with the integration of generated code into your current hardware. So don't hesitate to reach out to consulting. It's really a great implementation project that they can help you with.

      Let's see code generation in action then. This case, what I'm doing is I'm opening up the Embedded Coder app, which provides me with the first entry point in code generation. We included a quick start since a couple of releases, in which a tutorial step-by-step is going to ask you some questions from what you want to generate code, which kind of sort with many instances.

      It's going to analyze it and see, how is your system? What is the sampling rate or the continuous state? And then it asks you, OK, for which processor and device would you like to generate so that we can map the appropriate data type, for instance? I pick Texas Instruments C2000, for instance.

      And then, I can pick already Execution versus RAM. I pick Execution. The configuration parameter I automatically changed to accommodate my new hardware choice. And then, I can generate code. Once I click Finish, I can interactively navigate the code between the state machine and the generated code thanks to this code view.

      So for instance, if I pick this state and this transition, I retrieve the right amount-- lines of code within my system. If I want to retrieve this transition between the battery Qlow, I can highlight it on the code and see it replicated on the model. This traceability helps you learn how the code is generated. And when you start interacting with the different parameters, you're going to discover how they impact the code generation. I strongly encourage you to take an Embedded Coder training as well in order to learn how to customize the generated code to your pleasure.

      But let's go beyond functional testing and scaling up with continuous integration. Can be automate this? Yes, we can. We have workflows in which this can be made part of continuous integration and continuous delivery system or DevOps system. We have very nice documentation and technical papers on it. I don't want to spend too much time. But if this is something you're looking for, this can be automated. And it's working great for a lot of customers. So don't hesitate to check this out in order to automate this entire verification validation and code generation process.

      Is it scalable to certification workflow? As I mentioned before, for the code verification, for instance, part, sometimes you need to provide certain documentation. We provide a certification kit, which is applicable to a lot of standards in a lot of industries that are interesting for this particular audience, such as rail, agriculture, automotive, and in general, safety-related system.

      So this scales for shorter certification workflow if you have customer reference. And one of the key activities very often in this system is real-time testing. And so it's time now for, one, to showcase how you can perform real-time testing using our toolchain. Go ahead, Juan.

      Thank you very much, Vasco. My name is Juan Sagarduy. I'm an application engineer in electrification mechatronics, working in Sweden. I will be presenting enabling e-mobility with fuel cells with real-time testing and virtual prototyping. The key message of this section will be that the models used in the initial two phases can be reused for real-time testing and prototyping in a very effective way.

      If you're jumping from concept to a product, you may start with a hardware controller and software, but then a physical model in the desktop created with Simulink and Simscape. Software can be validated with a processor in the loop. However, there is an important aspect missing. That is real-time.

      So when the physical model is executed real-time on a hardware emulator, then we talk about how we need to loop this thing. This method is a very important one because it brings you very, very close to reality, but with low-cost and very low-risk. Once they're satisfied with the results of hardware-in-the-loop testing, you can schedule and perform selective tests on the final system prior to product testing your solution.

      What are the motivations for real-time testing then? So you want to accelerate innovation. So you want to test a variety of concepts. You want to pick the best one and then being able to be early on the market with the best technology. You want to detect weaknesses in your design. And you want to prove-- test that design against harsh conditions or faulty scenarios that are very costly or almost impossible to reproduce in a real setup.

      But then finally, you want your testing workflows to be reusable, effective, and streamlined. MathWorks and Speedgoat offer a fully-integrated software and hardware solution. So automatically-generated code from Simulink or Simscape is then tested at the general level in the Stateflow machines, thus, making sure that the concept and the solution is waterproof.

      What is the value of a turnkey solution for MathWorks and Speedgoat? Why should you go for it? So I think there are three main reasons for that. So let's start with support. So MathWorks and Speedgoat work as one consolidated team with the daily collaboration and very good expertise, making your satisfaction a priority.

      Functionality is best when the latest software upgrades are timely synchronized with the latest hardware upgrades. And last but not least, productivity is highest with a smooth on-ramping. That is based on well-thought and crafted training and consulting offerings tackled in a holistic way.

      When it comes to the real-time test, we can distinguish two categories. General purpose testing, mechatronics, and energy management often does not need timesteps lower than 50 microseconds. And milliseconds are common. C-based processors are used in electrical generation. It comes in handy. And this is very established for our customer base.

      However, with electrification, there is a need for high-end power electronics, HIL. And the phenomena that you want to test the modulation harmonics also require timesteps in the low-microseconds. For that, you need FPGA devices that will execute the equations in real-time. MathWorks and Speedgoat have got a very good solution. But we keep on working on expanding functionality and strengthening our offering in that particular segment.

      Many of you today will wonder, how can I take a desktop model to HIL readiness? So the first time, maybe, the most important consideration is that you need to choose a suitable fix step solver with an optimal sample time. In the end, it becomes a balancing exercise between robustness, resolution, and speed.

      The Simulink Solver Profiler will come in very handy to do that analysis. So as you see on the graph, if you run the simulation ratio, it's under one. Then your model is faster than real-time. But if it is over one, then the model is somewhat slower than real-time. And then, you need to simplify or reduce the complexity in some of your components, maybe try out a different solver.

      So if we go back to the model that Romain showed, so this model, when simulated with a variable step solver, shows the fantastic performance. The results from a discrete controller and continuous physics are defined as a golden reference for further validation.

      When we discretize, we need to do that on a Simulink solver. But our recommendation is to use the local solver for the physical parts with Simscape, the reason being that you have a bit more granularity and options to choose from. So once you run that with a solver profiler you can examine the performance.

      And then, you can even benchmark the results against the golden reference. So if the discrepancies wouldn't be too large, then you might need to reconsider and try out the lower timestep. Another very important aspect in hardware-in-the-loop is the ability to expose physical parameters as configurable or run time. So this is what we show here with the battery component, but even also the fuel cell.

      So this is important because when you select them as run time, they will be exposed in the code. So we test that out. And then, we see that the parameters do appear in the Interface section. So this is important because that means that you compile the model once. But then, you can make changes on the different parameters without the need to precompile.

      So next step, the test to HIL readiness. So then, you need to bring in the IO driver blocks that will mimic the interface between the platform emulator and the controller in your HIL rig. So the type of drivers will be determined by the communication protocol that is going to be used. But those driver blocks, they are available in the Simulink Library for driving up. So once we have configured the model in the right way, then they can go all the way to generate code with the slrt.tlc target for completeness.

      If you are interested in getting more insight on the real-time workflows, so please register and attend this upcoming webinar on May 19, where you would see Simulink real-time and the Speedgoat in action. And then, the topic will also be fuel cells. So you're are very welcome to register.

      As you know, many of our customers are already using model-based design and reporting very solid returns of investment. So if I was to pick one, I could take the one from Honeywell, where they, yeah, report a 5 to 1 improvement in productivity. So the User Stories section in mathworks.com is open and fully available for you to explore the testimonies of more companies.

      So now, we are coming to the end. And it's time to wrap up and bring up some highlights. My colleague Romain has started with highlighting the value of multi-domain simulations with Simscape in a fuel cell and battery drive train. Yeah, the goal was to assess critical performance under different configurations and then, yeah, integrate in a closed loop supervisory control.

      My colleague Vasco took a deeper look into supervisory logic development. He tackled the systematic validation code generation and even an outlook to certification. Then finally, I came in to emphasize the potential in reusing desktop models for real-time testing, but also the value in our turnkey solution offered by MathWorks and Speedgoat.

      For those of you interested in electrified propulsion, hopefully many today, so we have a very attractive learning path to offer. Of course, you can let us know if you have any specific queries on the trainings that we provide. Follow-up opportunities after the webinar today. So the presentation materials will be available to all of you. So that will include the slide decks, recordings, even bonus material.

      I would like to highlight the importance of getting a completed survey from you. Yeah, we want to get your feedback. But you won't-- we want to give you the opportunity to ask specific questions or tell us topics of interest. And then, you will be able after completing the survey to access the models that we showed today. With that, Romain, Vasco, and I would like to thank you very much for your time and attention. And we welcome any questions now.