Battery management systems (BMS) support safe and efficient operation of battery packs in electric vehicles, grid power storage systems, and other battery-driven equipment.
This webinar shows how to use Simulink and Embedded Coder to generate C code for BMS algorithms and deploy them to an NXP S32K microcontroller. Starting with Kalman filter-based state-of-charge (SoC) and cell balancing algorithms modeled in Simulink, we will use Embedded Coder to generate optimized code for the NXP microcontroller. The code generation workflow will feature the use of the NXP Model-Based Design Toolbox, which provides an integrated development environment and toolchain for configuring and generating all the necessary software to execute complex applications on NXP MCUs. In addition, Model-Based Design Toolbox includes a Simulink embedded target for NXP MCUs and peripheral device blocks and drivers.
Chirag Patel, MathWorks
Chirag Patel works with engineers in control system design 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 and battery management algorithms. Chirag holds a master’s degree in control systems from Wichita State University, Kansas.
Marius Andrei, NXP
Marius Andrei joined NXP in 2017 where contributes to Model-Based Design Software solutions development for NXP Automotive Products. Marius graduated from the Politehnica University of Bucharest in Romania with a master's degree in Advanced Computer Architectures.
Hello and welcome to this webinar on deploying battery management system algorithms on NXP S32K from Simulink. My name is Chirag Patel. I'm an application engineer at MathWorks. In this role, I help control system engineers transition from desktop simulations to real-time testing.
Hello, my name is Marius Andrei. I am software engineer at NXP Semiconductors. I design and develop Simulink blocks for the Based Design toolboxes delivered by NXP. Let me show you a quick demonstration of what we plan to cover in this webinar.
We design and test the BMS algorithm in Simulink environment, then we generate code using embedded coder. The battery management system dashboard shows the behavior of the BMS algorithm that runs from the S32K microcontroller. This dashboard has been created using FreeMASTER.
The hardware consists of an S32K 142 MCU connected with a MC33772B battery cell controller. To quickly test the BMS algorithm, we use the 6 cell emulator board. With this emulator, we can manipulate the cell voltages and the peak current.
When we increase a cell voltage above a threshold, we can see over voltage fold becomes active. And BMS state transitions to fold state. In this webinar, we will demonstrate how we can set up such testing environment, and we will also cover the key role played by Simulink in the early stage of design BMS algorithm.
Before we get into details, let's understand what challenges we are addressing with this solution. So Chirag, you worked on BMS project before joining MathWorks. In your current role, you talk to engineers working on BMS all the time. Can you tell us about some of the common issues BMS engineers face, and what have you learned from this experience?
Yes, absolutely, Marius. So before joining MathWorks, I worked on designing and implementing battery management system algorithms and tested them on embedded hardware [INAUDIBLE]. Now at MathWorks, I have been interacting with customers working on BMS for various end applications. Most of my interaction is with embedded software and electrical engineers.
These embedded engineers need information on cell properties and characteristics to develop BMS algorithms for which they rely on in-house battery experts or their cell vendors. In addition to core BMS software and hardware engineers, you have mechanical and thermal engineers as part of the extended team. These engineers design overall mechanical packaging and thermal management system for the entire battery pack.
The key challenge here is how to translate and transfer key information between these groups of engineers without any loss of information and translation error. Engineers from different domains prefer to work in their own design environments and mostly report to different managers. This can lead to a lack of information flow between them, reduce collaboration, and inefficient workflow.
The second challenge is related to long iteration cycle due to all reliance on hardware-based testing of BMS algorithms. Most engineers test [INAUDIBLE] BMS algorithms on hardware with actual battery cells or entire pack. With this testing method, it takes longer to detect errors, and sometimes you're not able to test all the scenarios. Often, this kind of end-to-end hardware plus software testing is done by a test engineer or entirely a different group. This results into delay in getting feedback to software developer, causing longer iteration cycles.
It's about the software integration between the device driver code and application layer code. As Marius showed earlier in the demo, BMS application software can be designed and verified independent of the hardware using Simulink. However, we need to interface inputs and outputs of the application layer code to device driver code, for example, reading battery cell voltages and temperature values from cell controllers. Integration of application layer code, either handwritten or originated with device driver code, is a manual process. This device driver code is hardware specific and requires detailed understanding of chosen embedded platform and communication protocol.
When I was working on BMS project, this is the area where I needed help to better integrate software and automate part of the deployment platform. While talking to other BMS engineers, it became clear that I was not alone. So I reached out to an expert for some help, and this became the main reason Marius and I started collaborating last year. And since then, Marius and his team at NXP have developed solutions that can help BMS engineers work on this challenge.
Our goal for this webinar is to discuss and demonstrate how MathWorks and NXP solutions can help address these challenges. So here is our agenda for today's webinar. First, Marius will help us understand BMS architecture and how different pieces of hardware work together. Next, I will review common BMS algorithms designed in Simulink and how we can test them thoroughly using simulations without the need of hardware early in the design phase.
Next, Marius will show how you can generate target optimize C code from these models, interface with the device [INAUDIBLE] code, and deploy it on NXP S32K MCUs. Once the code is deployed, we will test and debug the code exhibiting live on MCU using NXP FreeMASTER in open loop mode. And finally, we will list all the relevant resources that MathWorks and NXP have on our website to help you get started with your BMS project. So Marius, please explain the key parts of battery management system and how they interact with each other.
Sure, Chirag. A typical battery pack has battery cells connected in series and parallel to match required DC voltage and ampere hour capacity. It becomes impossible for regular microcontrollers to directly measure key parameters such as cell voltages. This requires an additional circuit called analog front-end between the main MCU and the battery pack.
Let's discuss the BMS architecture regarding specific scenarios of the cells number and NXP hardware. Let's start with small battery packs, let's say up to 24 or 48 volts. A MC33771BSPI is targeted for a battery pack with 7 up to 14 cells in series. The MC33772BSPI is targeted from 3 to 6 cells in series.
These battery cell controllers perform monitoring for the vital values like cell voltages, current, and cell temperatures. They're also capable of passive cell balancing and full detection. Battery cell information is then transferred to the microcontroller unit through the classic cell peripheral interface. In this example, we use the S32K142, an Arm Cortex and four-based MCU.
The main MCU runs the BMS algorithm. These put together all the measurement results delivered by the cell controller. Besides the supervisory tasks, the BMS algorithm performs the state-of-charge estimation, manages the conductor, and monitors the isolation. From the pack, it also performs a full detection and recovery. It also monitors if the key values are under the safety limits.
Another key task of the battery management system is the cell balancing. The main MCU sends balancing commands to the cell controller via SPI. But what if the BMS algorithm needs to manage a cell pack consisting of more than 14 cells?
When the [INAUDIBLE] consists of large number of cells in series, for example, 96 cells, we have to divide the battery pack in smaller modules. For each module, we use an individual battery cell controller to monitor the cells voltages and temperatures. But this approach comes with an electrical issue.
The negative terminal of one module has the same electrical potential as the positive terminal for the previous module. Overcome this electrical issue, we use a high-speed differential isolated communication called TPL, Transformer Physical Layer. This connects all the cell controllers of each module in a daisy chain topology. Now, the main MCU connects to the daisy chain topology to the MC33664 transceiver. These transceiver physical layer transformer converts the MCU SPI data bit to pulse bits information and transfer them to the TPL [INAUDIBLE] network.
The BMS algorithm runs independently on the communication used between the FE and main MCU. The only settings that differ from the BMS algorithm is the cell number. As you can see when you talk about BMS architecture, the main three components are the battery pack, the analog front-end, and the main MCU. Now, Chirag will show us how to design BMS algorithm in Simulink.
Thank you, Marius. This is a top-level Simulink model of a battery management system. The subsystem block on the left represents all BMS algorithms we want to deploy onto microcontroller. To test this algorithm in closed loop mode, we have developed a detailed model of a battery pack represented by the subsystem block on the right.
Before we investigate each subsystem in detail, let's quickly look at simulation results where battery pack is subjected to a typical automotive use case. Here, we started the simulation with the battery pack charge at 75% SLC, then we start driving for a while. When the battery SLC falls, we stop driving and charge our battery pack until it is almost full capacity.
At the end of the driving phase when the cell voltages are low enough, we limit discharge current to a lower threshold to prevent under-voltage situation. Now while charging battery pack, we follow Constant Current and Constant Voltage commonly referred as CCCV charging method. Additionally, we need to monitor any imbalance developed in the battery pack and perform required cell balancing.
The imbalance in the pack is caused due to many reasons, including uneven aging of the cells or uneven distribution of cell temperature as shown here in the plot. As you can see, this single simulation helps us evaluate most common BMS algorithm, such as current limit calculations, state machine transitions, state-of-charge estimation, cell balancing, and interaction among these algorithms.
Software developers can develop many different test scenarios and validate software logic to [INAUDIBLE] simulations. This small-base design approach allows them to make rapid design iterations without going through costly hardware testing, more importantly because the simulation of BMS can be used by electrical engineers to evaluate interaction of battery pack with charger and powering merger.
Additionally, thermal engineers can use the same model to study effectiveness of a thermal management system. They can collaborate with software engineers to help develop different tunnel management techniques to support, for example, fast charging of battery pack without compromising long-term safety and health of the battery pack.
Now, let's look at how we put together a model for the battery pack. Here, we created a small battery pack with six cells connected in series using battery block from Simscape Electrical. These battery cells exchange heat with each other.
Cell number 6 at the bottom is insulated on one side, so no heat can dissipate in that direction. And cell number one at the top is connected to ambient temperature, therefore resulting into faster heat transfer through convection. This asymmetrical thermal layout is the main reason we saw large difference in cell temperature during our simulation.
Now, let's look at how each battery block is parameterized so that the model matches the dynamic and steady state behavior of an actual battery cell. Key parameters such as open circuit voltage and terminal resistance are tabulated as a function of state-of-charge and temperature. If available, this data can be imported from cell datasheet. [INAUDIBLE] you can derive this relationship by performing cell testing in controlled environment.
Additionally, we can add equations or parameters to define capacity fed or time. We can also adjust block fidelity by selecting appropriate time constant for charge or discharge dynamics. To learn more about battery modeling and cell characterization, please visit battery modeling page on MathWorks website.
Now, let's take a quick look into BMS algorithms. This is a top-level model of all the algorithms we have implemented in this example. In your project, based on the end application, you may have more software components than you see here. Starting from the left, the first software component calculates discharge and charge count limits. We use this equation based on minimum cell voltage and internal cell resistance to calculate current limit.
Lookup tables are used to calculate temperature-based current limits. Finally, we take smallest of all the limits as final discharge current limit. Similar logic is applied to calculate charge current limits where we use maximum cell voltage and set off minimum cell voltage.
Moving on to the BMS state machine, we have dedicated software component that manages different operating states of entire battery pack, including full detection and contractor management. We use state flow to model different states and transition conditions between them. SOC estimation is one of the most talked about algorithm of BMS.
Since state of charge cannot be measured directly, we must estimate its value at a given time using other available measurement such as background, temperature, and voltage. There are different techniques and algorithms available to estimate state of charge in battery pack. A simple technique to calculate SOC is by integrating pack current over time and dividing it by total ampere over capacity.
This technique is called column counting. It is easy to implement. However, it accumulates any error impact measurement or time, resulting into poor estimation. Also, this technique cannot recover itself from error in initial conditions.
The second SOC estimation method is based on extended common filter. This technique uses air current, temperature, and battery model as input to predict cell voltage and its internal states, including state of charge. It uses measurement of cell voltage as feedback to correct this prediction of terminal voltage and other states. In this process, it estimates SOC as one of its states. Common filter based state estimation algorithms perform better and correct themselves over time, even if there is an error in the initial condition.
Now, let's look at cell balancing software component. The cell balancing is required to ensure all cell voltages are within a specified tolerance, typically 5 to 10 millivolts. Any imbalance in cell voltages or the state of charge effectively reduces usable capacity of battery pack. We have implemented cell balancing algorithm in state flow. When the difference between the maximum cell voltage and minimum cell voltage grows wider and when operating condition is right, we start balancing battery pack.
There are no standard algorithms for performing cell balancing. In our example, we activate balancing for all the cells with a terminal voltage higher than the midpoint of the target range. Selecting values of balancing register and wait times depends on size of the battery pack and its end application, for example, how large cell imbalance is expected in the field use and available time to complete the cell balancing.
To learn more about these algorithms, please refer to this four part video series on MathWorks website. These videos are also available on YouTube. Now, I will invite Marius to show us how to deploy these algorithms on NXP S32K [? MCU. ?]
Thank you, Chirag. Let me show you the software development tools available for automotive ECUs. A C code can be directly generated, built and deployed, from MATLAB and Simulink environment. All the code that acts as the [INAUDIBLE] is generated on top of the NXP [INAUDIBLE] available for free on the NXP website. If the user needs to debug generated code, the S32 design studio can be used.
For today's demo, we used a model-based design toolbox for S32K1. In case you don't have our toolbox installed already, it is available for free on the NXP website, and of course in the MATLAB's add-on explorer. Once installed, old toolbox blocks are available in the Simulink library browser.
Our toolbox come with support for [INAUDIBLE] cell application layer, or in most of the S32K peripherals and optimized Automotive Math and Motor Control Library in the wide variety of examples. The battery management system blocks are available in the external devices category. The blocks allow users to access all the functionalities of the NXP battery cell controllers directly in Simulink.
We choose to integrate the BMS algorithm with the S32K toolbox by placing it exactly in the middle of the model, just like using a block box. We feed the battery management system algorithm with values read from the hardware by the battery cell controller. An algorithm output can be used to balance the cells or to send information like SOC or fold to other ECU [INAUDIBLE] for example. The blocks on the top of the model are used only to configure the MCU peripherals. Their generated code is only executed during utilization.
Let me show you how to set the model to generate code for the S32K. First, an S32K communication block is required to be added in the model. It's the mandatory block for all the models that generates code for the S32K microcontrollers.
The demo that we've shown you at the beginning of the webinar runs on the S32K142 evaluation board. This toolbox supports core generation for all the S32K1 microcontrollers family. For example, if I had to run this model on the S32K144,
I would just have to change the controller in this [INAUDIBLE] done. I will not go into further details. I only want to mention that you can choose the builder generated code with one of the two [INAUDIBLE] available from GCC, [INAUDIBLE] or [INAUDIBLE].
The S32K communicates with the MC33772B over the SPI protocol. Therefore, an SPI config block is required to configure the peripheral instance used for data transfer. In this tap, we select the main MCU SPI piece that will be configured as data group and chip select.
Now comes the fun part. The model configuration block for the battery cell controller is called MC3377xB config. First up, configuration, set the number of the battery cell controllers and the cell number for each of them. The TPL protocol can handle up to 15 devices, while the SPI mode, only one. This tab refers to the SPI peripheral configuration.
The SPI instance dropdown only displays the instance number of the SPI blocks already added in the mode. The cell controller driver initializes SPI transfers, so the chip select needs to be set here. The config SPI for [INAUDIBLE] master button performs all the SPI settings in the SPI config block. [INAUDIBLE] specifies which S32K pin is used for hardware reset.
Other GPIO events can be handled using [INAUDIBLE] blocks. In the back settings, the user can type the NTC [INAUDIBLE] characteristics and the shunt resistor value. These settings will be used for software conversions from raw values to common units. The TPI protocol uses two SPI [INAUDIBLE] protocol [? uses ?] [? to ?] [? display ?] instances. One of them is used for sending data, configured as master, or the other one for receiving data configured as slave.
The MC3377xB get values block-- returns the values in volts, amps, and degrees Celsius. The results for the current and temperature are software converted based on the settings specified in the MC3377xB config block. With [INAUDIBLE] values block, the user can access the raw values too.
Let's open the block and see what options we have. Controller ID selects which cell controller performs the measurement. In case of SPI, it needs to be set to 1. If the start conversion command for the requested CIDs checked, the generated code will send the start conversion command to the requested CID. We'll wait until the conversion is completed and then return to values. Besides the main functionality, most of the blocks provide the status value of the current operation. The status value is described in the help page.
The MC3377xB family features each cell individually balancing with a current up to 300 milliamps. Enable this function, the cell balancing set individual block must be used. This sets the stage for each cell balancing and sets its timer. The timer value needs to be set in minutes, zero representing 30 seconds. By measuring the cell voltages, the balancing process must be paused.
These are just a couple of the blocks provided in the [? NXP ?] [INAUDIBLE] If you want to find out more about our blocks or have any questions, you can write us on the NXP community page. This page is connected directly to the development team, so you will get the best support you can have. I should also mention that, here, a free back-to-basics guide is available together with the free motor control courses and an introduction to battery management system blocks.
Now, that we've generated code and placed a target, we are going to use FreeMASTER to monitor and tune up the running application. FreeMASTER has two main components, the embedded application and the host-user interface. For the host interface, FreeMASTER offers useful tools like variable read-write, scopes, and recorders. There is also a FreeMASTER lite version that lets the user to create unique dashboards in a web-based environment.
We enable the FreeMASTER for the embedded application. The FreeMASTER configuration block needs to be added in the main Simulink mode. This block continues the peripheral used for data transfer between host and target. For this example, we will use the board one. This cellular instance has the receive and transfer pins routed to the evaluation boards USB to serial converter.
Now, let's move to the battery management system FreeMASTER dashboard. This dashboard is built using the FreeMASTER lite. The first panel displays the critical information for the battery pack.
On the left-hand side, the summary tab shows the values for the state of charge, voltage, current. While on the right-hand side, you can see the evolution of the pack's current and voltage. The fourth state provided by the BMS algorithm are displayed in the bottom of the screen in real-time alongside with default history log.
Cells Pack shows the graph for each of the cells, regarding the voltage, temperature, and balancing. The value displayed in the graph right-click option is available for each of the cells. As the name suggests, the beam is raw data-- displays the voltage, temperature and balancing for each of the sets.
The system configuration tab lets the user to set the connection parameters. There are both options that allow either running these dashboard directly in the browser or inside the classic FreeMASTER application. Besides the connection parameters, the user can tweak some BMS settings and measurement units and can even choose between dark or light template. If you want to start using FreeMASTER in our project and design user dashboards like the one we've just presented, I strongly recommend start watching the FreeMASTER four-part webinar series.
Until now, we have only mentioned the NXP community, one of the places where you can meet directly with the NXP engineers. The NXP cell controllers used in this webinar and others are available under power management section on the NXP website. You can have access to full augmentation, application notes, fact sheets, and other tools or software.
But if you want to develop your own battery management system application, you can start using one of our development boards. They come with user manuals that guide you on how to connect them with a S32K evaluation board and have them ready to run the code generated from MATLAB and Simulink. You may also find interesting to have a look on the available NXP BMS reference designs.
Now, let me list some of the resources MathWorks has to help you learn more about these topics. As I mentioned earlier, the battery modeling solution page on MathWorks website is a great place to start. It lists all the resources, including white papers, technical articles, and customer success stories on battery management system.
I should also point out that the models used in this webinar are available on file exchange for download. Look for submission with the title Design and Test Lithium Ion Battery Management Algorithms. Additionally, there is a webinar on hardware and the loop testing of battery management system using speed [INAUDIBLE] integrated solution. This allows you to test BMS software plus hardware in closed loop without actual battery pack.
In summary, we started this presentation with the goal of addressing some of the unique challenges of developing and testing BMS algorithms. We showed that the desktop simulation of BMS algorithms can help you in understanding of interaction between different algorithms. You can test these algorithms in closed loop mode, which detail battery pack model. This helps you better understand and communicate electrical, thermal, and software performance early in the design phase.
Next, Marius showed us how to use NXP FreeMASTER and battery emulator to test BMS algorithms interactively on hardware. This simple, yet integrated, workflow helps software engineers quickly test their design on hardware without actual battery cells.
And finally, we addressed software integration challenges using NXP's model-based design toolbox, which provides device driver blocks for all the relevant functionalities of S32K MCUs, battery cell controllers, and communication protocols. This significantly reduces overhead of manually integrating device driver code with application layer code. We hope that the features and capabilities discussed in this webinar will help you accelerate development of your BMS project. Thank you.
Select a Web Site
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .Select web site
You can also select a web site from the following list:
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.