Deploying Battery Management System Algorithms on NXP S32K from Simulink

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 mathematics. In this role, I help control system engineers transition from desktop simulations to real time testing.

Hello, my name is Marius Andrei. I'm a software engineer at NXP semiconductors. I designed and developed Simulink blocks for the model and toolboxes delivered by an NXP Let me show you a quick demonstration of what we plan to cover in this webinar.

We design and there's 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 on the S32K microcontroller. His dashboard, has been created using free master. The huddle consists of an S32K 142 MCU connected with the MC33772B battery cell controller.

To quickly test the BMS algorithm, we use the six cell emulator board. With this emulator, we can manipulate the cell voltages and the pick current. When we increase a cell voltage above a threshold, we can see over voltage fall becomes active and be a mistake transition to false state. In this webinar, we will demonstrate how you can set up such testing environment and we will also cover the key role played by simmering in the early stage of design BMS algorithm.

Before we get into details, let's understand what challenges we are addressing with is solution. So Tara, you worked on BMS project before joining Mathworks. And current role, you talk to engineers working on BMS all the time, and you tell us about some of the common issues BMS engineer face and what have you learned from this experience.

Yes absolutely Marius, so before joining mathworks, I worked on designing and implementing better management systems algorithms and dusted them on embedded hardware. Now at mathworks, I have been interacting with customers working on BMS for various and 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 the 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 to overreliance on hardware based testing of BMS algorithms. Most engineers tested 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 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.

Now, let me mention another challenge that led to this webinar. 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 similar. However, we need to interface inputs and outputs of the application layer code to device driver code. For example, a reading battery cell voltages and temperature release from cell controllers.

Integration of application layer code, either handwritten or originated with the 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 for. 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 design and Simulink and how we can test them thoroughly using simulations without the need of hardware or in the design phase.

Next, Marius will show how you can generate target optimized c-code from this model, interface with the device driver code, and deployed on NXP et cetra MCU to use. Once the code is deployed, we will test and the code executing live on MCU using NXP free master in open 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 this voltage and impair our capacity. It becomes impossible for regular microcontrollers to directly measure key parameters such as cell voltages. This requires an additional circuit call analog front end between the main MCU and the battery pack. It's discussed the BMS architecture regarding specific scenarios of the cells number and hint behind.

Let's start with small battery packs, let's say up to 24 or 48 volt. At MC33771BSPI is targeted for a battery pack with 7 up to 14 cells in series. That MC33772BSPI is targeted from 3 to six cell in series. Is battery cell controllers performed monitoring for the vital values like cell voltages current and so temperatures?

They're also capable of passive cell balancing and for detection. Battery cell information is then transferred to the microcontroller unit to the classic cell peripheral interface. In this example, we use the S32K 142 an ARM cortex M4F based MCU The main MCU who runs the BMS algorithm, is put together all the measurement results delivered by the cell controller.

Besides the supervisory tasks, the BMS algorithm performs the state of judge estimation, manages the conductor, and monitors isolation. From the back, it also performs the four 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 since balancing wants to the controller, BSPI but what if the BMS algorithm needs to manage a setback consisting of more than 14 cells?

When the bag 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 batteries controller to monitor the cell 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. Transform our physical layer, disconnects all the cell controllers of each module in a Daisy chain topology. Now the main MCU connects to the Daisy chain apology to the MC33664 transceiver. this transceiver physical layer transformer converts the MCU, SPI database to pushbit information and transfers them to the TPL bus network.

The BMS algorithm, runs independently on the communication used between the AFE and main MCU. The only settings that difference from the BMS algorithm is the cell number. As you can see, when you talk about BMS architecture, the main 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 for battery management system. The subsystem block on the left represents all BMS algorithms we want to deploy onto microcontroller. To test this algorithm because the more, we have developed a detailed model of the 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% SOC. Then we start driving for a while when the battery SOC falls we stop driving and charge our battery pack until it is almost full capacity. At the end of the driving phase, when the several wages are low enough, we limit discharged current to a lower threshold to prevent underbool debt situation.

Now, while charging battery back, we follow constant current and constant voltage commonly referred to 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 cause you 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 the desktop of simulations. The small bits 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 power inverter. Additionally, thermol engineers can use the same model to study effectiveness of the thermal management system. They can collaborate with software engineers to help develop different thermal 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 1, at the top is connected to ambient temperature. Therefore resulting into faster heat transfer to conviction.

This is symmetrical 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 parameterize so that the model matches the dynamic and sadistic behavior of an actual battery cell. Key parameters such as open circuit voltage and terminal the distance are tabulated as a function of state of charge and temperature.

If available, this data can be imported from cell datasheet else you can derive this relationship by performing cell testing in a controlled environment. Additionally, we can add equations or parameters to define capacity fade over time. We can also adjust block fidelity by selecting appropriate time constant for charge or discharge dynamics. To learn more about battery modeling and self 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 current 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 content.

Finally, we take the smallest of all limits as final discharge compliment. Similar logic is applied to calculate charge current limits where we use maximum cell voltage instead of 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 for 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 the given time using other available measurement such as the current, 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 pattern over time and dividing it by total computer capacity. This technique is called common 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 feature. This technique uses accurate temperature and battery model as input to predict several days and its internal states, including state of charge.

It uses measurement of cell voltage as feedback to correct its prediction of terminal voltage and other states. In this process, its estimate associate as one of its states. Common filter base 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 pages are within a specified tolerance typically 5 to 10 millivolts. Any imbalance in cell voltages digits 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 weight time depends on the 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 issues. The c-code can be directly generated, built, and deployed from MATLAB in simulating environment. What the code detects as the peripherals is generated on top of the NXP the keys available for free on any website. If the user needs to debunk the 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 website and, of course, in the MATLAB's item explorer. Once installed, all the toolbox blocks are available in the Simulink library browser. Our toolbox comes with support for the auto cell application layer work, and 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 strategic toolbox by placing it exactly in the middle of the model, just like using a blackbox. We feed the battery management system algorithm with values read from the hardware by the battery cell control.

Algorithm output can be used to balance the cells or to send information like SOC reports to other issue over count, for example. The blocks on the top of the model are used only to configure the MCU [INAUDIBLE]. Their generated code is only executed during initialization. Let me show you how to set the model to generate code for S32K. First, an S32K communication block is required to be added in the model. Is a mandatory block for all the model that generates code for the S32K microcontrollers.

The demo that we showed you at the beginning of the webinar, once, on the S32K1 evaluation board. This toolbox supports code 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 the storage dump. I will not go into further details. I only want to mention that you can choose to build a generated code with one of the two genes available from GCC, AAR, or Gregor's.

The S32K communicates with the NC3372B over the SPI protocol. Therefore, an SPI config block is required to configure the peripheral instance used for data transfer. In this top, we select the main MCU SPIPs to be configured as data group and select. Now, comes the fun part. The model configuration block for the battery cell controller is called MC3377XP config. The first up configuration, set the number of the battery cell controllers and the cell's number for each of them.

The typical protocol can handle up to 15 devices, while the SPI can hold only one. Estab refers to the SPI referral configuration. This SPI instance dropdown only displays the instance number of the SPI blocks already added in the model. The second driver initializes SPI transfers, so the chip selects needs to be set here. The Config SPI for BCC as Master button performs all the SPI settings in the SPI config block. In stock specifies which is to key pin is used for hard reset. Other GPIO events can be handled using interrupt blocks.

In the Pack Settings, the user can type the NTC thermistor's characteristics and the shunt register value. These settings will be used for software conversions from raw values to common units. The DPA protocol uses two SPI instances. One of them is used for sending data, configured as master, while the other one, for receiving data, configured as slave.

The MC3377XP 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 MC3377XP config block. With Get Raw 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 measurements. In case of SPI, it needs to be set to one. If the Start Conversion command for the requested CID is checked, the generated code will send the start conversion command to the requested CID. Will wait until the conversion is completed, and then returns the values Besides the main functionality, most of the blocks provide a status value of the current operation. The status value is described in the help page.

The MC3377XP family features each cell individually balancing with a current up to 300 millions. Enable this function, the cell balancing set individual block must be used. This sets the stage for the each cell balancing and sets its timer. The timer value needs to be set in minutes, zero representing 30 seconds. In measuring the cell voltages, the balancing process must be paused. These are just a couple of the blocks provided in the NXP toolbox.

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 in the host user interface, or the host interface. FreeMaster offers useful tools like variable rate, scopes, and recorders. There is also a FreeMaster like version that lets the user to create unique dashboards in a web-based environment. To enable the FreeMaster for the embedded, application the FreeMaster configuration block needs to be added in the main signaling mode. This block gives the peripheral used for data transfer between host and target. For this example, we will use the word one. The serial instance has the receiver and transfer piece related to the evaluation boards used to signal converter.

Now, let's move to the battery management system FreeMaster dashboard. This dashboard is built using the FreeMaster light. 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 packs, current, and voltage. The fourth state, provided by the BMS algorithm, are displayed in the bottom of the screen in real time, alongside with the forward history look.

Cells Pack shows the graph for each of the cells, regarding the voltage, temperature, and balancing. The change the value displayed in the graph, variety cooption is available for each of the cells. As the name suggests, the BMS raw data displays the voltage, temperature, and balancing for each of the cells. 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 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 watching the FreeMaster four part web 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 our management section on the 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 worlds. The come with user manuals that guide you on how to connect them with the S32K evaluation boards and have them ready to run. The code generated from MATLAB and Simulink. You may also find it interesting to have a look on the available NXP BMS reference designs.

Now, let me list some of the resources MathWorks have to help you learn more about this topics. As I mentioned earlier, the best remodeling 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 virtually 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 the Combined Battery Management Algorithms. Additionally, there is a webinar on how to run the loop testing of battery management system using speedboats integrated solution. This allows you to test VMS software, plus hardware, in closed loop without actually [INAUDIBLE].

In summary, we started this presentation with the goal of addressing some of the unique challenges of developing and testing the VMS algorithms. We showed that the desktop simulation of VMS algorithms can help you in understanding of interaction between different algorithms. You can test these algorithms in closed loop mode with detailed [INAUDIBLE] model. This helps you better understand and communicate electrical turmoil and software performance early in the design phase.

Next, Marius showed us how to use NXP [INAUDIBLE] and battery emulator to test the algorithms interactively on hardware. The simple, yet integrated, workflow helps software engineers quickly test their design on hardware without actual battery cells.

And finally, we address software integration challenges using NXP's model-based design toolbox, which provides device driver blocks for all the relevant functionalities of S23K 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.