Electrification is driving the use of batteries for a range of applications, including electric vehicles (e.g., cars, buses), ships, electric vertical takeoff and landing (eVTOL), and battery energy storage systems (BESS). These applications have different requirements for battery system design in terms of cell selection, battery pack design (power/energy density, volume, weight, and lifetime) and battery management system (BMS) development.
Simulation of the battery system design before testing provides insight into the dynamic behavior of the battery pack. It also lets you explore and compare BMS algorithms, expand operational test cases, and shorten the technology development cycle from battery cell to battery system.
The workflow for battery system development begins with battery modeling, followed by:
Using Simulink® and Simscape Battery™, the battery system development workflow begins with battery modeling, then battery pack design, followed by developing BMS algorithms. Then you can perform closed-loop desktop simulation to validate the battery pack design and BMS. The next step is real-time simulation of models using rapid prototyping and hardware-in-the-loop testing. The final stages of development involve hardware implementation, deployment, and testing.
System-level simulation for battery system development.
There are three different types of battery models: equivalent circuit models (ECMs), electrochemical models, and data-driven models. You can create these models and run simulations using Simscape Battery and Simulink products, and all these models can be integrated into Simulink with support for code generation.
Equivalent Circuit Models
Battery ECMs use electrical circuit elements such as resistors, capacitors, and voltage sources to mimic the dynamic behavior of a battery cell. Due to their simplicity and computational efficiency, ECMs are used for battery management system (BMS) design and system-level simulation. Simscape Battery provides a prebuilt ECM block, the Battery Equivalent Circuit block, which models the electro-thermal dynamics of a battery and supports battery hysteresis on open-circuit voltage (OCV), battery degradation (cycling aging and calendar aging), and fault simulation including thermal runaway.
Electrochemical Battery Models
Electrochemical battery models are mathematical models that describe the internal physical and chemical processes occurring within a battery during charging and discharging. Compared with ECMs, electrochemical battery models provide detailed insights into internal battery processes, making them valuable for cell design, degradation studies, fast charging current optimization, and more accurate performance prediction under extreme operating conditions.
Simscape Battery provides:
- Battery Single Particle block to represent a battery by using a single particle model with electrolyte dynamics (SPMe) including lithium plating and solid electrolyte interface (SEI) growth.
- Doyle-Fuller-Newman (DFN) battery model, also called pseudo-two-dimensional (P2D) battery model to simulate detailed physical electrochemical processes that occur inside a battery, such as lithium diffusion, electrochemical reactions, charge conservation, and heat generation dynamics
Data-Driven Battery Models
Data-driven battery models use empirical data with methods such as system identification, machine learning, and deep learning to simulate and predict battery behavior. They can be integrated into Simulink for system-level simulation and support code generation. Data-driven battery models are ideal when internal dynamics are difficult to capture analytically, for example, battery degradation mechanisms in battery aging modeling. Data-driven battery models are suitable for electric vehicle fleet management, predictive maintenance, advanced diagnostics, and other applications where large data sets are available and enhance accuracy in forecasting battery life.
You can use deep learning to create a low-order nonlinear state-space model. The training data for this kind of model can be experimental data or simulation data from very high-fidelity models (e.g., FEA battery models).
Key Takeaways
- Use prebuilt ECM (equivalent circuit model) block with battery degradation (cycling aging and calendar aging), and fault simulation (thermal-runaway).
- Simulate electrochemical process using SPMe and DFN battery models.
- Create data-driven battery models, integrated into Simulink and supporting code generation.
Resources
Using the Battery Builder app or the Simscape Battery application programming interface (API) in MATLAB®, you can design a battery pack. Foundational elements of the design include cell design, parallel assembly, module, module assembly, and battery pack design.
Battery pack design from cell to pack.
Using the Battery Builder app or API, you can:
- Build and visualize battery models with different geometries and topologies, from cell to module and from module to pack.
- Model cooling plates with customizable fluid paths and thermal connections to the battery pack.
- Build battery model from custom cell component
- Model heat exchange between cells
- Explore cell-to-cell temperature variation and measure cooling efficiency.
- Generate a custom Simulink library model for your battery pack design.
- Set a suitable model resolution to strike a balance between model fidelity and simulation speed.
Key Takeaways
- Develop a customized battery pack with different model resolutions.
- Add thermal effects into the battery model.
- Generate battery pack models for simulation.
Resources
Engineers can use MATLAB and Simulink to design a battery thermal management system to regulate battery pack temperature within specifications and ensure it delivers optimal performance for a variety of operating conditions.
Thermal analysis comparison of a new and aged lithium-ion battery using Simscape Battery.
Capture Battery Thermal Behavior
Using Simscape Battery, engineers can model battery thermal behavior across multiple fidelity levels, from cell to pack, to capture temperature nonuniformity and its impact on performance, safety, and aging.
At the cell level, you can discretize the thermal model along the cell height to increase the fidelity of the thermal modeling and model the thermal gradient inside the cell.
At the module and pack levels, configurable inter‑cell thermal paths enable conduction, convection, and radiation effects to be represented, supporting analysis of cell‑to‑cell temperature variation and thermal propagation.
To balance accuracy and simulation speed, Simscape Battery also supports reduced‑order thermal models derived from high‑fidelity finite‑element or finite‑volume analyses, preserving dominant thermal dynamics while enabling system‑level simulation, real‑time execution, and hardware‑in‑the‑loop testing.
These thermal models can be directly coupled to detailed cooling representations, such as liquid‑cooled plates with configurable flow paths, enabling evaluation of temperature distribution and cooling effectiveness under realistic operating conditions. Simscape Battery provides prebuilt cooling plate blocks that support different flow configurations, including parallel channels, U-shaped rectangular channels, and edge cooling.
Parallel channels block in Simscape Battery.
U-shaped channels block in Simscape Battery.
Edge Cooling block in Simscape Battery.
Design Controls for Battery Thermal Management
With Simulink, you can design closed-loop controls that combine feedforward and PID techniques for circulation system controls, such as feed stream (valve) control, mass flow (pump) control, and heat exchange path selection control. With Simscape Battery, you can use prebuilt blocks, such as Battery Coolant Control and Battery Heater Control, to build battery thermal management control algorithms. With Stateflow, you can also design supervisory control logic for switching between different operating modes—such as heating versus cooling—based on the environmental temperature and the battery temperature.
Key Takeaways
- Build battery module with inter-cell heat exchange.
- Use prebuilt cooling plate blocks.
- Model Thermally- Discretized Cell with Immersion Cooling.
- Model Battery Temperatures Using Reduced-Order Thermal Models
Resources
“1D simulation has been used in Mahindra Electric to optimize the BTMS. In this system model, the battery, cooling circuit, and refrigeration circuit were effectively implemented using Simscape. The vehicle, driver, and equivalent circuit model were implemented on the Simulink platform.”
A battery management system directly influences the safety, efficiency, and longevity of the battery, and by extension, the overall performance and reliability of the system. The primary functions of a battery management system are monitoring, state estimation, cell balancing, power management, thermal management, protection, and communications.
Primary functions of a battery management system.
Simulink and Simscape enable you to gain insight into the dynamic behavior of the battery pack, explore software architectures, test operational cases, and begin hardware testing early, reducing design errors. Engineers can use built-in BMS control blocks in Simscape Battery to evaluate the designed battery pack performance, develop the BMS algorithms, and run system-level simulations.
Estimating State of Charge
Methods to estimate state of charge (SOC) range from simple current integration (Coulomb counting) and voltage monitoring to sophisticated model-based and data-driven methods, such as Kalman filters and neural networks.
Accurate battery models are vital to the development of algorithms for model-based SOC estimation in a battery management system. Traditional approaches to SOC estimation in a battery management system, such as open-circuit voltage (OCV) lookup and current integration (Coulomb counting), are easy to implement and reasonably accurate in some cases. However, the OCV-based approach requires OCV measurement, which needs to be preceded by an extended resting period. Coulomb counting suffers from issues of poor initialization and accumulation of current measurement noise. The extended Kalman filter (EKF) and unscented Kalman filter (UKF) approaches have been shown to provide accurate results for a reasonable computational effort in real-world BMS implementations.
Simscape Battery provides several prebuilt SOC Estimator blocks (with variable capacity option) and supports code generation: Coulomb counting, adaptive Kalman filter, and Kalman filter.
In contrast to a Kalman filter, using a neural network to develop an SOC estimator does not require extensive information about the battery or its nonlinear behavior. Instead, the network is trained with current, voltage, and temperature data and SOC as a response. You can compress a neural network using projection, which exhibits faster forward passes when run on the CPU or deployed to BMS embedded hardware using library-free C or C++ code generation.
Key Takeaways
- Simscape Battery contains three SOC estimators: Coulomb counting, an adaptive Kalman filter, and a Kalman filter.
- An SOC estimator can be developed using a neural network without extensive information about the battery.
Resources
Estimating State of Health
All batteries, including those that meet performance specifications at time of manufacture, degrade over time due to calendar life and cycling, suffering a gradual loss in reserve capacity and an increase in internal resistance. While the latter is relatively straightforward to estimate using short time measurements, the former requires a full charge or discharge excursion for an accurate calculation, which is not always practical.
This challenge has led to growing interest in state-of-health (SOH) estimation as well as the development of adaptive Kalman filter formulations augmented to include battery parameters in addition to states. An accurate estimation of the instantaneous internal resistance is very helpful for the BMS to establish power limitations.
Simscape Battery provides built-in SOH estimators to estimate battery capacity including Kalman filter, least squares with and without variable weights, resistor based and capacity based SOH estimator
SOH estimation is more subjective than SOC estimation; there is no universal agreement on how SOH is to be defined. As a result, each organization may have its own specific method for quantifying an SOH estimate, making it impossible to use general-purpose, off-the-shelf solutions. Using Simulink and Simscape, you can develop and simulate custom SOH estimation algorithms that are in line with your organization’s specific interpretation of battery health.
Key Takeaways
- Simscape Battery provides prebuilt blocks to estimate capacity using Kalman filter or least-squares algorithms.
Resources
Cell Balancing, Battery Charging, and Battery Monitoring
Simscape Battery provides prebuilt library blocks for cell balancing, battery charging, and battery protection.
Cell balancing capabilities keep a similar SOC in all cells by dissipating the excess charge through a bleed resistor. Balancing is necessary to prolong the life of cells that can be damaged by overcharge or discharge. Multiple cells improve capacity when cells are balanced.
Cell balancing in Simscape Battery as a function of SOC and time.
Battery charging is controlled with a constant-current/constant-voltage (CC-CV) algorithm. This is a common approach that maintains battery life by preventing overcurrent and overvoltage when charging. Current is limited during charging until a preset voltage is reached.
Battery charge vs. time using a CC-CV algorithm in Simscape Battery.
Protecting the battery requires monitoring current, voltage, and temperature. Simscape Battery provides blocks that you can incorporate into your BMS algorithms.
Battery monitoring blocks implemented into a BMS model.
Key Takeaways
- Simscape Battery provides blocks for cell balancing, current and voltage control, and monitoring voltage, current, and temperature.
Resources
Desktop simulation in Simulink enables you to verify functional aspects of the battery system design. On the desktop, the battery system, environment, and algorithms are simulated using behavioral models. For example, you can explore active versus passive cell balancing configurations and algorithms to evaluate the suitability of each balancing approach for a given application. You can use desktop simulation to explore new design ideas and test multiple system architectures before committing to a hardware prototype. You can also perform requirements testing in desktop simulations; for example, you can verify that contactors are prevented from opening or closing when an isolation fault is detected.
When the battery system under development must meet safety requirements, you can integrate tests based on formal methods into your software development process in accordance with standards such as IEC 61508, IEC 61851, and ISO® 26262.
“While developing the controller model in Simulink, we frequently checked compliance with style guidelines and modeling standards using the Model Advisor. We also checked for dead logic, divide-by-zero errors, and other design errors in our models using Simulink Design Verifier™.”
Once validated via desktop simulation, you can use Simulink models to generate C and HDL code for rapid prototyping (RP) or hardware-in-the-loop (HIL) testing to further validate the BMS algorithms in real time. With RP, instead of handwriting control software code for real-time testing, you generate code from your controller model and deploy it to a real-time computer that performs the functions of the production microcontroller. With automatic code generation, algorithm changes made in the model can be tested on real-time hardware in hours rather than days. Further, you can interact with real-time control hardware from within Simulink to change algorithm parameters and log test data.
As with rapid prototyping, HIL testing involves generating code from a Simulink model and deploying it to a real-time computer. In the case of HIL testing, code is generated from the battery system models rather than the control algorithm models, providing a virtual real-time environment that represents battery pack, active and passive circuit elements, loads, charger, and other system components. This virtual environment lets you validate the functionality of the BMS controller in real time before developing a hardware prototype and in an environment where hardware will not be damaged.
Tests developed during desktop simulation can be carried over to HIL testing to ensure that requirements are met as the BMS design progresses. Though HIL testing is employed primarily to test code running on a microcontroller or FPGA, you can instead use a rapid prototyping system, such as Simulink Real-Time™ and Speedgoat® target hardware, and connect it to the HIL setup before production controller hardware is selected.
“With Model-Based Design, we have an integrated process for development from idea through production code generation. MathWorks tools enabled us to develop key battery management technology using our own expertise in an environment that facilitated early and continuous verification of our design.”
Validating BMS Software
Real-time simulation—encompassing both rapid prototyping and HIL testing—provides power electronics control engineers with additional insights into how a BMS design will perform on hardware. In both RP and HIL, the objective is to emulate in hardware one aspect of the overall design: the BMS controller in RP and the balance of the battery system in HIL. Real-time simulation offers several significant advantages in BMS design, letting you:
- Conduct RP to start validating algorithms before the final controller hardware is selected.
- Exploit the flexibility of a real-time test system for rapid design iteration and testing.
- Conduct HIL testing before the battery system prototype hardware is available.
- Use a combination of RP and HIL testing to exercise BMS algorithms for test cases that may be difficult, expensive, or destructive if you were to use the actual hardware.
Hardware-in-the-loop (HIL) testing of battery management system software. The BMS code is generated from BMS algorithms modeled in Simulink and deployed to a Texas Instruments® C2000 microcontroller. The plant model (battery pack, contactor, inverter, charger) is modeled in Simulink. Code is generated and deployed to run on Speedgoat real-time machine with battery emulator.
By reusing desktop simulation models in Simulink to generate code for real-time simulation, you can shorten overall development time. You can generate C/C++ and HDL code that executes on computers optimized for real-time performance. Code generated from Simulink models for real-time simulations includes interfaces that enable you to adjust control parameters while the real-time simulation is running.
Performing Rapid Prototyping
During hardware testing, making changes to controller code can cause delays and additional risks. Modifying the code by hand, recompiling it, and deploying it to the microcontroller or FPGA takes time—potentially a long time if you are a control algorithm developer who relies on a software or hardware engineer to make the changes. Depending on the extent of the changes required, you also risk introducing new problems into the implemented code.
Instead of handwriting code updates to controller software, you can use Simulink to generate code that executes in real time on a dedicated computer and uses high-speed I/O to communicate with test hardware. In addition to eliminating manual coding and its associated delays, another advantage of this RP approach is that you can validate changes to the BMS software by running the simulation model on the desktop first to verify that no other problems were introduced.
Testing with Hardware-in-the-Loop
Because hardware prototypes for a battery system can take considerable effort to build and modify, and because they are often costly to repair, it is not always feasible to test such prototypes against the electrical system in which the battery pack will operate. Given these limitations, even small design changes can threaten development schedules, and BMS designs tend to evolve slowly because teams consider radical departures from the previous design as too risky.
With Simulink, you can generate C/C++ and HDL code from the model of the hardware in your battery system and the greater system of which it is part, including the supply and the load. Once you deploy this code to a real-time computer, you are able to run real-time simulations of the hardware against your controller code before testing the controller in a battery system prototype. As a result, you can find and correct control design errors before they potentially damage expensive and difficult-to-replace prototype hardware. You can also uncover hardware design errors, such as incorrect component sizing.
Many HIL real-time systems, including Speedgoat target hardware, incorporate battery emulators, letting you emulate portable battery power supplies, emulate battery stacks for electric vehicles, or sink current to simulate batteries under charge.
“I feel that Speedgoat has certainly developed a plug-and-play real-time platform for Simulink. For us, that translates into more time testing our control systems and less time developing a HIL bench.”
Resources
In the hardware implementation stage, the Simulink control models that have been verified via desktop simulation, RP, and HIL are used to generate efficient, production-ready code for the BMS. If necessary, production code generation can be incorporated into workflows compliant with formal certification standards used in the automotive, aerospace, and other regulated industries.
Production-Ready Code Generation
Simulink generates readable, compact, and efficient C/C++ and HDL code from controller models that is ready for implementation on production microcontrollers, FPGAs, and ASICs. Unlike code generated for RP, code generated for production use does not include the extra interfaces needed to support real-time monitoring, parameter tuning, and data logging. Optimization settings enable you to precisely control the generated functions, files, and data to improve code efficiency and facilitate integration with legacy code, data types, and calibration parameters.
Performing Processor-in-the-Loop Simulations
In processor-in-the-loop (PIL) simulation, the C/C++ or HDL code runs on the microcontroller or FPGA while the device is stepping in execution with a Simulink model of the BMS hardware, limiting the risk of damaging a hardware prototype during initial evaluations of the BMS code. Although PIL simulations are not executed in real time, they are bit-true, enabling you to verify your code under a range of conditions and build confidence that it will execute properly once deployed on the real system.
Generating Production Code
Desktop simulation, RP, HIL, and PIL simulations all enable you to verify and validate the control algorithms for the BMS. With Simulink, you can use those same algorithms as the basis for generating production-ready code—either optimized and stable C/C++ code for implementation on microcontrollers or synthesizable HDL code for FPGA programming or ASIC implementation. Automatic code generation eliminates manual algorithm translation errors and produces C/C++ and HDL code with numerical equivalence to the algorithms you validated in Simulink. By simulating your control algorithms over all possible operating and fault conditions, you increase confidence that the generated code will handle those same conditions in the real system, even if you are unable to test for all of them. If hardware tests later indicate that algorithm changes are needed, you can simply modify the algorithms in your model, rerun simulation test cases to verify the correctness of the changes, and generate new, updated code. All generated C/C++ and HDL code is fully portable, optimizable with a range of options, and bidirectionally traceable to the Simulink model.
Automatically generated BMS production code from BMS algorithms modeled in Simulink. The code is deployed to a Texas Instruments C2000 microcontroller.
“We check every requirement needed for certification via simulation in Simulink before verifying it on the real circuit—and because we used Embedded Coder® to generate code directly from our model, there’s no gap between our simulations and the real embedded software.”
