Hardware-In-Loop Testing of Balance of Plant Controller of Fuel Cell System - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 31:16
Loaded: 0.53%
Stream Type LIVE
Remaining Time 31:16
 
1x
  • descriptions off, selected
  • en (Main), selected
    Video length is 31:16

    Hardware-In-Loop Testing of Balance of Plant Controller of Fuel Cell System

    Overview

    Organizations across the industries are working on designing and integrating fuel cell stacks to reduce carbon emissions. To guarantee the safe and efficient integration and operation of fuel cell stack, a supervisory control system, called Balance of Plant, needs to be designed and tuned to operate set of subsystems in closed loop and coordinated manner. Deep understanding of operating principals of various fuel cell systems and their interaction with each other is must to design and test various software components of Balance of Plant Controller.

    Join us to learn how modeling and simulating complete fuel cell stack, balance of power software components and other adjacent systems enables engineers from different domains to collaborate with each other and identify design issues early in the design phase. In this webinar, we will demonstrate how to:

    • Model fuel cell system in closed-loop using Simulink and Simscape
    • Design and simulate detailed controller logic and generate production quality code to target embedded controller
    • Thoroughly test controller logic in real-time with hardware-in-the-loop (HIL) test bench using Simulink Real-Time and Speedgoat target machine 

    About the Presenter

    Chirag Patel works with engineers working on control systems to streamline the transition from desktop simulations to real-time testing and hardware-in-loop (HIL) testing. Prior to joining MathWorks, Chirag worked at Lucid Motors, where he led the efforts of adopting Model-Based Design for electric powertrain, developed algorithms for battery management system and built HIL test system for vehicle control systems. While at Cessna Aircraft Company, Chirag developed simulations for electro-hydraulics systems, built iron bird test rigs for anti-skid brake systems, and designed integrated environmental control systems for business jets.

    Recorded: 19 May 2022

    Hello, everyone. And welcome to this webinar on hardware-in-the-loop testing of fuel cell control system. My name is Chirag Patel. I'm a principal application engineer at MathWorks.

    I work closely with engineers in the area of real-time testing of various control systems, including hardware-in-the-loop testing. Between my two jobs at MathWorks, I worked on early design of electric powertrain controls at Lucid Motors in California. In the last few years, we have seen huge interest in design integration and testing of fuel cells in various applications and industries.

    Our topic today is focused on hardware-in-the-loop testing of fuel cell control systems commonly known as balance of plant. Before we get into the details of core topic, it will be helpful to understand what's involved in controlling the fuel cell system. And what are the major system components that needs to be controlled here?

    And to do that, what's a better way than walking through a Simulink model of fuel cell system? Here is the model of a PEM fuel cell system. From the top level, we can see the fuel cell stack with electrode memory in the middle and gas channel for electrodes on the left and the cathode gas channel on the right side.

    Going inside the hydrogen circulation, we see four major components, starting from the hydrogen tank with the pressure releasing valve; hydrogen recirculation for unused hydrogen in the process; and a humidifier system to maintain the relative humidity closer to 1; and finally, exhaust to purge any excessive nitrogen buildup in the system.

    I know that I'm going through this a bit faster here. But if you are interested in detailed walkthrough, I will show you a link to a webinar which goes through this model in much more detail. Continuing onto the cathode side, we must control air compressor to ensure sufficient supply of oxygen and maintain its relative humidity closer to 1.

    Here we have exhaust valves for the air. Now it is critical to maintain the temperature of the fuel cell-- here in this case, 80 degrees centigrade-- to ensure safe and efficient operation of the fuel cell. And for that, we have a liquid cooling system model with pump, a radiator, and associated heat transfer to the fuel cell coolant channels.

    And finally, we have electrical load model using controlled current source for the purpose of the simplicity here. We can certainly expand into each subsystem and the component of this fuel cell model and add more fidelity. However, for the purpose of this webinar and for the purpose of testing the control system algorithm, this model can be an excellent starting point.

    Now that we have seen different components and subsystems of the fuel cell system, it will be easier to understand some of the challenges associated with designing and testing of hydrogen fuel cell controllers. In last couple of years, working closely with multiple organizations on fuel cell systems, we have learned quite a bit about the challenges and complexities faced by the engineers in this area.

    So let's look at some of the headline challenges that we plan to address today here in this webinar. The first and the foremost is the system complexity and the large number of parameters that needs to be controlled. And that can take a couple dynamics.

    As we saw during the Creek walkthrough, the balance of plant needs to monitor and control flow, pressure, temperature, humidity of hydrogen system, and air circulation system. In addition to that, we have electrical load monitoring and controls. Scope of the control system becomes more complex as we include peripheral components and their local parameters such as compressor, pump, valve, battery pack for the energy storage, and the CDC converter.

    Making it even more complex, some of these local measurements are not available due to the soft sensor cost. Or they need to be estimated, putting more growth onto the software. Moving on, our customers like you have been telling us that they have to design, test, and validate fuel cell systems and deploy them in record time.

    This results into enormous pressure getting your software design right in the first few design iterations. This challenge is not unique to designing control systems for fuel cells. And we have seen design cycles getting shorter or compressed across industries and applications. To address that, engineers have adopted agile development methods, continuous integrations, and virtualization capabilities.

    But we are not going to focus too much on the agile methods. However, we will discuss how adding hardware-in-the-loop testing in the early design phase and making as part of your continuous integration and testing can help address some of the time pressure. Now there are many more challenges associated with the hydrogen fuel cell.

    But I'm going to stop here and show you how hardware-in-the-loop testing can help address the headline challenges that we just mentioned. And the best way to start is by sharing an experience of one of our customers, Nuvera. Nuvera Fuel Cells is Massachusetts-based hydrogen fuel cell OEM focusing on powering commercial vehicles using fuel cell engines.

    They have been using Simulink for modeling and simulating their controls algorithm in closed loop mode. They developed plant models of fuel cell systems so that they can test the system in different operating conditions such as low and high ambient temperature or low and high humidity environments. To experiment with algorithms in a more realistic setting, the Nuvera engineers use agile testing.

    They load their plant models on Speedgoat real-time target computers and connect embedded controllers peripheral to Speedgoat target to form a closed-loop control system. In their own words, "This setup adds rigor while enabling engineers to iterate on their design quickly and allows for experimentation without putting a real fuel cell engine at risk." Now I'm going to use this user story as inspiration for today's agenda.

    We will start with a closed-loop simulation, including the plant model we have seen in the beginning to design and test algorithms in different operating environment. Then we will use a coder to generate production code and deploy onto NXP processor. Your ability to go from design to production C or C++ code should reduce your implementation time and risk of introducing any coding errors.

    Just like following the best hand coding practices and thoroughly unit testing your software components before deployment, you should follow the best practices for model verification validation for your control system models before generating the code. We are not going to discuss model verification and validation in this webinar. But we will leave some links for your references.

    Next, we will deploy our plant model to the Speedgoat real-time target computers and connect to our embedded controller through hardware peripherals and perform closed-loop testing. For those of you who are new to Speedgoat and hardware-in-the-loop testing concepts, we will take a deeper look into the hardware aspects as well.

    While your end application or the project will be different than what we'll be showing today, I'm very confident that you will be able to apply techniques and features learned from this webinar in your project. We will provide a link from where you can download to this presentation an example models used in this webinar. With that in mind, let's get started with our first topic.

    And now is a perfect time to jump back into our Simulink model. At top level, you can see controller model reference here on the left and the hydrogen fuel cell system model reference here on the right, making it a close-up simulation. At the top, I'm simulating electrical power demand from the load as a function of time using one of the source log.

    Going inside the plant, we have modified the model we saw earlier and have brought out all the measurements and controller inputs so that we can bring all the control functions from different subsystems together and design control logic independent of the plant model. Using Simscape for modeling the plant dynamics will allow you to bring different physical domains into the same environment and simulate interaction between these systems to study the couple dynamics.

    Additionally, you can use Simscape language to alter custom components in new physical domains if necessary. For example, we have altered this electrolyte membrane log using Simscape language. So if you haven't started creating plant models for your system, we highly recommend you look at Simscape and learn more about it.

    We have free two-hours tutorials called Simscape Onramp to help you learn basics of Simscape. Moving on the controller model, we have used Stateflow to model supervisory logic and separate the startup logic and operational logic into two parallel states. Within the individual states, we are calling these Simulink functions to calculate outputs of various control loops such as hydrogen pressure, moisture, and temperature control, hydrogen recirculation, and so on.

    Stateflow allows you to design supervisory logic, the temporal logic, task scheduling, and fault management effectively. For the purpose of the demo, the control logic is simple and minimal. However, in your project, you will have significantly more functionalities and many more software components.

    At that point, you should consider breaking your control logic into smaller units and model them as separate reference models. There are many more things to consider as a way of setting up your project. And you should adopt best practices for large-scale modeling.

    We have a dedicated training course on model management and architecture to help you learn these techniques and apply them while working on large-scale project. Moving on, let's go ahead and start the simulation. I already have our simulation set up for fast restart to save time from model compilation.

    Let's see the results in Simulation Data Inspector so that we can compare different simulations if we need to. The first nine to 10 seconds of simulation is for startup sequence, where we bring the fuel cell system to write operating state. From there, we can start producing electrical power.

    Then we gradually ramp up electrical power demand. And in response, here you can see the output current rising. And at the same time, the fuel cell stack temperature is going up as well. If our control logic works as expected, we should see relative humidity of air and hydrogen staying closer to 1 and the temperature of the stack maintained at 80 degrees centigrade or below.

    If needed, we can run more simulations to test our system in a different environment and operating conditions, as done by the engineers at Nuvera. A closed-loop simulation is a least expensive way to test control logic and find bugs. The time and effort invested in creating the plant model gets paid back many times over during the lifecycle of the project as you will find and fix design errors only in your design early in your project.

    You can reuse the same plant model for hardware-in-the-loop testing later in the project. So once you are satisfied with your simulation results and gain enough confidence in your design, you can move to the next phase of testing controller with a real plant. Now there are two ways to test control logic with a actual fuel cell stack in the system-- one, where you have identified a embedded platform or controller for final production.

    And you would like to deploy your control logic onto such device and perform additional hardware test in closed-loop with real fuel cell stack. This is the end goal of every project. However, for the project team or the project to come to this level of maturity, the embedded hardware and firmware team must have finished their first design iteration so that you can have a functioning embedded controller to program it.

    Now for the project of this scale, sometimes it makes sense to use the flexible real-time target machine from Speedgoat with the required peripherals as your controller during the early development and testing phase. This approach of testing control logic on a surrogate hardware is called rapid controls prototyping.

    The expectation here is that you will be able to test your logic and inventure your design early so that there are less surprises down the road when you move to production hardware. Today, we are not going to focus on rapid control prototyping. However, we will learn more about the Speedgoat and Simulink Real-Time when we visit hardware-in-the-loop testing.

    So with that in mind, let's go ahead and generate that code from our controller model. Here, let's open the controller as a top level model. And from the app menu, we are going to select the mineted coder. This opens C code tool strip with all the shortcuts to help you with this code generation.

    You can start with the Quick Start button to configure your model for desired outcome. So to save time, we have already completed this step. Next, I'm going to click the Generate Code button and wait for the process to complete.

    This View Code button brings a code and model side by side so that we can review the code. Let's briefly look at the code for H2 moisture controller. Here we can see the output command is calculated by multiplying numerator of our filter with the filter state. And the filter state later is calculated here in line with other blocks such as saturation, product, sum, and constant block.

    As you can see, the generic code is extremely readable and highly optimized. Now we recognize here that the code generation can be a far more complex topic for many organizations. And we really encourage you to engage with your MathWorks accounting and application engineers to get the conversation started.

    Next, I'm going to take this process a step further and use NXP-specific device level blocks for seek communications and GPIUs and instrument my model with the device error block. By using the target support package from NXP for S32K142 embedded controllers, I can generate bare-metal code for entire applications, including peripherals, and flush the generated application onto the target.

    So at this point as a control system engineer, you're very excited to see how your control logic is going to work with the actual fuel cell engine. Usually, this excitement of working with the real plant and testing on a hardware lasts a few weeks-- or at most, few months-- as the team goes through the initial testing of the common operating mode and see progress every iterations. However, most of the software is yet to be designed and tested.

    Your team is going to make hundreds of iterations and alter many more software components such as fault detection, fault monitoring, fault recovery, sophisticated estimation and optimization algorithms, and so forth. As we saw in the case of Nuvera engineers' story, testing these kinds of software iterations directly on fuel cell engines can risk the plant itself. And this is where hardware-in-the-loop testing comes in.

    In agile testing, the device in the test is our controller board with the software deployed on it. We will use the Speedgoat real-time target computer to deploy and run our plant model of a fuel cell stack and other peripheral systems in real time to ensure that the model application runs in real time, the Speedgoat target machine runs real-time operating system.

    The Speedgoat target machines also have powerful processors to run the numerically complex plant models at the desired sample time. Here in our case, the sample time is 10 millisecond. The target machines also have enough memory to log the data during the testing and can accommodate a variety of peripherals such as analog, digital, PWM's input/output, and many communication protocols to interface with your actual controller.

    While we are on the topic of hardware specification, let me talk about the different type of form factors Speedgoat offers for their target machines. So focusing on the image in the center, you can see four different Speedgoat target machines. The one in the back is called the performance target machine, which is a large 19-inch-wide computer chassis with eight open PCI slots.

    It also offers the highest-performance CPUs and the ability to upgrade your system on the field. This is the best option for hardware-in-the-loop testing and any in-lab real-time control testing. Now moving on to the three target machines in the front, starting from the smallest is our unit target machine, ideal for small I/O count applications.

    And the one in the silver chassis is the baseline target machines. And the blue one is the mobile target machine. All of these target machines are more suitable for rapid controls prototyping, especially in vehicle real-time testing. Every control system and agile test setup is unique when it comes to type of peripherals, number of I/O channels, and their voltage level.

    So every Speedgoat target machine needs to meet those unique requirements. And to match that, Speedgoat offers a variety of I/Os and provides device error blocks that you can drag and drop into your Simulink model to instrument peripherals. So here is a list of the type of I/Os Speedgoat offers such as analog, digital, PWM, end coders, and so on.

    And this is the list of the communication protocols we support. So for starting with the automotive, the most common ones are CAN, CAN-FD, LIN, J1939, and so on. Similarly, we support commonly-used protocols in our aerospace industry, industry automation, and there are many protocols that are used in multiple industries.

    Moving on, in fuel cell system, you need to emulate the sensor signals such as temperature sensors using programmable register or need to inject electrical fault. The Speedgoat can support a variety of these I/Os, including the ones required for timing and synchronization. With all of this important information with us let me show you how to run your plant model in real time for HIL.

    For that, we will start with the fuel cell system model. One of the main requirement for running the models in real time is that they need to have the fixed-step solver. Our model is already set to use the fixed-step solver. And the sample time is set to 10 millisecond, as mentioned earlier.

    Additionally, for Simscape model, you can choose local solver for Simscape network. And if you do so, you need to enable the fixed cost runtime consistency iteration and define number of iterations. So here in our case, we are limiting the number of iterations, consistency iterations, to 10.

    If your models simulate with the settings as expected and within the desired tolerances, you are ready to try your model on Speedgoat. For that, we need to go to the app menu and select Simulink Real-Time. By selecting that, it will change your system target file to slrealtime.tlc for code generation. And now we have a real-time tool strip available to perform the task required for real-time testing.

    So first, we need to select the target computer and establish the communication via ethernet. I'm going to use the performance target machine. And once connected, you can click on Run on Target button, which will sequentially generate and compile code, build application, deploy your real-time application on Speedgoat hardware, and start execution on the target machine, all from one button.

    However, you can choose to do this task individually as well. Since it takes some time to generate the code for this model, I already have done this step to save time. I'm going to deploy the pre-built application and connect and start the execution. Since I'm connected to my target machine remotely more than 3,000 miles away, even deploying the application will take some more time.

    Once applications start, you can observe signals of your interest in Data Inspector or tune the parameters interactively. This makes getting started with agile testing much easier as you don't have to switch between the different software or applications when doing the testing. Now we only ran the numerical part of the model without any I/Os connected to it.

    So the next step for us is to define what these I/Os are and use the Speedgoat device level library blocks and connect them to our inputs and output board on the plant models. So here is the model that uses a Speedgoat CAN module's analog I/O modules and PWMs to interface with the fuel cell controller. As a next step, we can deploy and run this model on Speedgoat while your controller is physically connected to the target machine through the peripherals.

    Getting to this stage where you can perform a complete closed-loop testing in real time is a major milestone for the entire project. This stage shall enable the team to not just perform the more testing but the kind of the testing that they are not too comfortable doing on actual fuel cell engine.

    For the software team, you can push a series of regression tests after every major or minor software release or integrate the agile testing as part of your continuous integration and testing process as well. And this is where Simulink Test can help you in authoring, managing, and executing the test cases on Speedgoat. It is a common testing tool to help you in testing with the model, starting from model-in-the-loop testing all the way to the agile testing.

    Today, we don't have time to go into the details of the functionality of Simulink Test. But if you are interested in learning more about it, here is the link to the product page of the Simulink Test. I hope this part of the presentation gave you enough insight into agile testing and how it can be helpful in testing your fuel cell controller. This brings us to the end of today's topic.

    And it's time to review key takeaways. We started our presentation with testing fuel cell controllers using desktop simulations. The closed-loop simulations are key in catching design errors early.

    And you can iterate your control logic many times over until you get desired results. Once you're confident about the design change, you can quickly generate efficient and human-readable source code and target HCUs without any potential coding errors. We also learned about the potential use of Speedgoat for rapid controls prototyping to help accelerate the hardware testing early in the design and development phase.

    As we learned from the Nuvera user story, agile testing adds rigor to your testing without putting your fuel cell system at risk. Simulink Real-Time and Speedgoat target machine offers flexible yet integrated solution for performing agile testing of your fuel cell system. So let's talk about some additional resources.

    If you want to learn more about getting started with the fuel cell system modeling, we have many examples in the product documentation to help you get started. Plus, there are many more technical articles and presentations on the topic of fuel cell that are available on MathWorks website. And here is the list of all the training courses that MathWorks offers on the tool and the topics we discussed today.

    We will share these slides after today's presentation. We hope this presentation offered insight into where and how MathWorks tool can help you accelerate your design and testing for your fuel cell project. So with that, on behalf of MathWorks, I would like to thank you for your time and attention today.

    View more related videos