Hardware-in-the-Loop Simulation for Battery Management Systems | Verifying, Validating, and Testing Battery Management Systems, Part 9

[HIL Section]

In this section, we are going to take a closer look into hardware-in-loop testing of battery management systems.

Extensive end-to-end testing of the battery management system, including all the possible fault conditions, is required to make sure that the system behaves as expected.

Doing this type of testing for the battery management system can be very time consuming. For example, before you start testing charging mode functionality, you must discharge the battery pack to appropriate state of charge level.

Testing a complete charge-and-discharge cycle for a typical electric vehicle battery pack takes hours. We are talking about days’ worth of testing when we include different operating conditions for temperature, state of charge, and other parameters.

Additionally, reproducing design issues and fault conditions can be difficult and involves safety considerations.

While doing testing with actual cells, achieving test automation, test sequencing, and report generation can be very expensive and requires lot of resources, especially when there is many test equipment involved.

Doing extensive testing with an actual battery pack is required for final system integration test and functional tests. But it doesn’t make sense to do this type of testing for every software revision or design iteration.

One way to achieve high confidence in your design iteration is by testing BMS Controller and electronics against a simulated battery pack. This method of testing a real controller against a simulated plant model in real time is called “hardware-in-loop” testing.

In HIL testing, we start with plant model of a battery pack. This is the model you may have used for testing BMS algorithms in desktop simulations.

Next, we generate C-code from battery model and compile into a real-time application which gets deployed and executed in real time by a dedicated real-time target computer.

This target computer must have required peripherals to convert numerical values into physical signals such as cell voltages and temperature. We connect peripherals of the real-time computer with BMS Controller to perform closed-loop testing.

By replacing the actual battery pack with a programmable one, we can now perform end-to-end testing of software and electronics more efficiently and safely.

Now, there are few things we need to take care of before we can do HIL testing for the BMS Controller. 

First, we need to run the model of large networks of cells in real time at a step time required by BMS Controller.

For the most common battery applications, BMS algorithms get executed between 100Hz to 500Hz. So, executing our battery plant model at 1kHz in real time is more than sufficient for HIL testing. If your battery pack has fewer than 50 cells in series, achieving desired step time can be straightforward.

The second challenge is related to hardware. Since we want to emulate the electrical behavior of a battery cell, we need to have ways to produce isolated voltages and be able to connect them in series or parallel configuration, just like actual cells. Additionally, you will require temperature sensor emulation and fault emulation as well.

To understand how we can address first challenge within Simulink, let’s take a look at an example model.

Here, we have a battery model with 16 cell modules, each with 6 cells connected in series, making it total 96 cells connected in series. Each battery cell block models electrical and thermal behavior. We use controlled current source to charge and discharge battery pack. And finally, individual cell voltages, temperature, pack current, and pack voltage is measured and sent to BMS Controller.

First step of going from desktop simulation to real-time testing is selecting a right fixed-step solver. This is usually an iterative process and we are not going into the details in this webinar.

Instead, I recommend that you visit this dedicated webinar on the topic of “Real-Time Simulation of Physical Systems Using Simscape.”

After following the steps described in this webinar, we have selected a Local-Solver for Simscape network, and identified number of consistency iterations to be 1. These solver settings yield a desired result of 1mS step time.

We also note that for certain topology, “Partitioning” solver improves performance by reducing computational cost of simulation. This helps in achieving faster simulation rates for both desktop simulation and real-time testing. The Partitioning solver converts the entire system of equations for the attached Simscape network into several smaller sets of switched linear equations that are connected through nonlinear functions. Computational cost is reduced because it is more efficient to calculate solutions for several smaller equation systems than it is to calculate the solution for one large system of equations.

Now, the solver name “Partitioning” can lead to some confusion. Just so that it is clear, the Partitioning solver does NOT partition the model. Partitioning Solver will not allow you to split the model and run on multicore processor. There are other ways to achieve this. Simulink Real-Time automatically leverages the multicore processor by default whenever it is possible.

Next, let’s go ahead and execute our battery model in Real-Time.

In the interest of time, I have already built and deployed the application to the target computer by clicking on the Build button. In the target object, we can notice the name of application deployed onto the target machine, application status, sample time, and other useful debugging information.

Let’s start the execution of the application on the target computer. While simulation is progressing, we can observe signals of our interest and tune parameters.

This simulation is only 10 seconds long. Once it’s over, we can check if the target computer was able to execute the model at the desired sample time of 1millisecond.

By inspecting the target object, we can notice here that there was no CPU Overload reported during the model execution, and maximum task execution time (TET) is well within 1 millisecond. This gives us enough margin for future model growth.

As you add more complexity and details in the model, it is very well possible that you may not be able to achieve desired sample time just by selecting right solver. In this situation, specific to battery modeling, you have a few more options that you can consider.

First option is to select a right variant of the battery block. Here, you can notice that by selecting a variant with lower fidelity, you can easily gain 10x reduction in task execution time.

Another option is to select lower order dynamics of battery cell. This also helps in reducing task execution time significantly. This gain in performance is coming from reduced fidelity.

Now, if your model complexity is lower or number of battery cells in series is less than 50, it is quite possible that you don’t have to do any of this optimization to achieve task execution time of less than 1 millisecond.   

As we discussed earlier, the second important aspect of doing HIL testing for BMS application is to emulate sensor signals and sensor faults.

For emulating cell voltages, Speedgoat provides a Battery Emulator Card IO991-06. Each Battery Emulator Card provides 6 isolated channels. Each channel can supply up to 7V, which allows us to simulate different cell chemistries. Additionally, each channel can source up to 300 mA and sink up to 100 mA. Also, Multiple I/O modules can be combined in series or parallel to achieve the required power levels.

In addition to battery voltage emulation, we need Temperature Sensor simulation cards and Fault Insertion cards to complete BMS HIL setup. Speedgoat provides various options for temperature sensor emulator card and fault insertion.

In our demonstration, we have only used IO991 for battery voltage emulation.

Now, let’s see a live demonstration of BMS HIL testing.

We start with a test model, which allows us to simulate battery cells and generate fault scenarios.

Here in this test model, we have a small battery pack with 6-cells connected in series. To simulate a fault, we added a switch which allows us to short two cell terminals without any real physical consequences and test the response of the controller. We used Toggle Switch Block to inject the fault interactively.

A controlled current source block is used to simulate charge or discharge current with the help of a Slider Block. To perform diagnostics on the cell, we measure voltage between two cell terminals.

The measured cell voltage values are fed into IO991 Block, which converts these numerical values into electrically isolated voltages each relating to individual battery cell.

The output terminals of IO991-06 card are connected to an electronics board you see in the background here, which makes physical measurements of cell voltages and communicates the information to a BMS controller, which in this case is a Texas Instruments controller board.

The BMS controller performs diagnostics on cell voltages and generate a fault status in the case of over- or undervoltage fault or short between two terminals. In this case, BMS controller turns on the LED in the event of any fault and outputs its status on a digital output port.

We read fault status from BMS controller using Digital Input port of IO133 to check if controller logic is performing as per the requirements.

Now, let’s go ahead and connect to target machine.

Up on executing this model in real time, we can change the current all the way to 10 amperes to check for any overvoltage fault or -10 ampere to check for any undervoltage fault from the controller.

We don’t see any fault yet. When we inject a short-circuit fault, we can immediately notice LED glowing on the controller board and also see our Lamp in the model changing the color from green to red, indicating there is a fault on the controller.

Let’s look at the results in Simulation Data Inspector for whole experiment. We can notice small changes in cell voltages due to change in current. And one of the cell voltages dropped significantly as we triggered the fault, and see the corresponding change in the fault status.

In this presentation, we demonstrated how to create large system-level models to design and test BMS algorithm quickly, and engineers from different domains such as electrical, software, and thermal can collaborate using Simulink as a common design platform. We also talked about different methods to run large battery models in real time for doing hardware-in-loop testing. And finally, we demonstrated how to set up HIL testing for BMS application and how it can help you gain more confidence in the design of a Battery Management System.