Thiswebinar 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.
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 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
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
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.
3a8082e126