Battery Management System Development in Simulink

In the next few minutes I’ll explain the main components of the BMS modeled in Simulink. We can use this model for desktop simulations where we can, for example, reproduce diverse usage cycles and environmental conditions to evaluate the system’s response to a potentially unsafe condition; for example, a temperature, voltage, or current outside the recommended limits.

Let’s say this battery system is part of an electric vehicle powertrain. Say the battery is 75% charged and the outside temperature is 15C. In these conditions we start driving for a while, then stop and charge the battery. Finally, the battery is at rest and the balancing cycle kicks in. How do we know that during these three typical usage stages, the battery pack remains within recommended electrical and thermal limits? What if the temperature outside is 40C instead of 15C? How about if the initial state of charge is 30%? Will an aggressive drive cycle cause an undervoltage situation?

A model allows the vehicle designer to test all these situations in simulation, without risking causing damage to the real battery.

This is the BMS model in Simulink. The battery and its management system are inside this model reference.

On the top left we define the different driving scenarios that determine the test sequence provided by the subsystem on the bottom left. The green lights at the top right indicate whether there has been a fault; for example, that any cell has reached an overtemperature condition.

The system itself has a model reference representing the BMS ECU with its various monitoring and control algorithms, connected to a block with the representation of the battery pack and associated circuitry and peripherals. This model contains two versions of the battery pack: a small one with just 6 cell series, and a larger 16-module pack, each module containing a 6-cell series string. In all cases we model just one parallel string. We call these architectures 6s-1p and 96s-1p packs, respectively.

Let’s start with the description of the battery pack and its peripherals.

The variant subsystem on the left contains the two versions of the battery pack mentioned before: the small one with 6 cells and the large one with 96 cells. Let’s take a look at the small one. This battery pack is modeled in Simscape, where the component color tells us its physical domain. Blue indicates electrical and orange indicates thermal. We can see that the 6 cells are connected in series and can exchange heat with one another. The thermal layout is asymmetrical, with cell number 6 at the bottom insulated on one side (so no heat can dissipate in that direction), and cell 1 at the top exposed to the outside atmosphere and therefore getting rid of the heat by convection. This asymmetry will be responsible for a significant temperature difference among the 6 cells.

What makes this cell representative of a real-life Li ion chemistry; say, NiMnCo? Well, inside each cell there is an equivalent circuit whose topology and parameters should give me a response equivalent to the one I would observe experimentally. The equivalent circuit components should include temperature, SOC, and possible aging dependence. If you are interested in cell characterization, a detailed account on how to perform this parameter estimation on battery cells is available on our website, searching for battery modeling.

Next to the battery pack there is a subsystem with the passive balancing circuitry. Commanded by the balancing logic from the BMS algorithm, these switches selectively close when their corresponding cell needs a partial discharge to lower its SOC.

Maintaining the battery cell modules in balance allows me to better utilize its total storage capacity, as we will see in a few minutes.

A further element of the plant model is the set of charger and inverter contactor circuitry. Prior to connecting a battery pack to a charger, it is important to pre-connect them via a resistor to prevent an excessively high current from rushing into the pack and potentially damaging it. This pre-connection needs a special sequence that we will show when we describe the BMS algorithm.

Finally, the last piece of the battery plant is the charger and the load, both simply represented here by current sources commanded to follow the charging and driving profiles from the source block at the model top level.

BMS algo

Let’s now focus on the BMS algorithm. This part of the battery management system monitors, protects, limits, and reports measurements from the battery pack.

The subsystem on the left uses individual cell voltages and temperatures to calculate maximum allowable charge and discharge current levels. When a cell is at low SOC, its voltage is low, and it is important to prevent the cell from delivering a large amount of current since this would cause an excessively large voltage drop that could potentially be below the cutoff voltage specified by the cell manufacturer. Comparing the minimum cell voltage in the module against this lower threshold and dividing it by the maximum internal resistance value calculated for this cell, we compute a voltage-based current threshold.

We also know that it is important to limit current delivery or intake when temperature is too high or too low. Using a lookup table with a rising or falling S-shaped profile, we can specify a current threshold based on temperature and modulate the allowable current delivery. This is very important to avoid physical damage to the cell materials at high temperature both during charge and discharge, and at low temperatures during charge since doing so below freezing temperatures is not allowed.

These two thresholds are then compared against one another, and the lowest becomes the current limit.

The subsystem labeled State Machine defines the main operating state of the BMS. It is represented here using Stateflow, a Simulink add-on toolbox meant for designing state logic. In Stateflow we use components representing states that are active or inactive depending on the conditions, and the text we write inside the state is code that executes on entry, during, or no exit from the state.

The state machine has four parallel states (parallel meaning that they can be active at the same time):

1. The first one defines the variable BMS_State which indicates standby, driving, charging, and fault. Charging comprises constant current and constant voltage stages.
2. The second state switches the fault state ON in case a current, voltage, or temperature value reaches an unsafe level.
3. The third and fourth states define the contactor ON and OFF switching sequence for the charger and inverter. This is needed to avoid an excessively large current inrush at the beginning of the charging stage.

SOC estimation

Knowing how much longer we will be able to drive our car before we need to stop for a recharge depends on accurate estimation of the battery SOC. This is of great importance and it is much more challenging than in the case of conventional vehicle fuel gauge design, where the measurement is direct. In battery systems, we do not measure state of charge, which is not directly measurable; we actually measure something else and hopefully relate what we measure with the SOC.

The third subsystem contains three different methods for state-of-charge estimation. In practice the BMS developer would only choose one of them, but here we present all three to illustrate their individual merits and limitations. The first method, know as coulomb counting, consists of integrating the current that enters and leaves the cell to keep track of the state of charge over time. A benefit of this method is its simplicity and very low computational cost. Its drawbacks include the accumulation of current sensor error and its inability to recover from an erroneous initial condition because of the lack of feedback from voltage measurements.

The second and third SOC estimation methods implemented here are the Unscented and Extended Kalman filters. Both are variations of nonlinear Kalman Filters and they rely on a model of the unit cell to predict the terminal voltage resulting from a current stimulus, estimating the internal cell states (the SOC among them) by comparing this prediction against a measurement of the terminal voltage. The choice between EKF and UKF is typically made based on the severity of the system’s nonlinearity. In this case, the only nonlinearity present is given by the OCV-SOC relationship, and it is a mild one, so it is expected that the EKF should give adequate results.

The Kalman filter algorithm has two parts: the state update and the measurement update. The state update predicts the current state based on the previous state value and the input, and the measurement update corrects this prediction using newly acquired data. The cell model we use is implemented as a MATLAB script and corresponds to the equivalent circuit we use to simulate the battery pack.

The next task to consider is balancing. It is important to keep individual battery cells roughly at the same state of charge, otherwise the cell with the highest SOC level will limit the amount of charge that we can put into the pack, rendering the system underutilized. This state logic calculates the voltage difference between the highest and lowest cell voltages and, based on whether this difference exceeds a design value, activate passive balancing. Balance command is a Boolean vector that indicates which bleed resistor to activate so that the cell SOC is slowly reduced. Doing this with all cells but the one whose SOC is the lowest eventually makes all SOC’s converge within a prescribed tolerance.

Let’s now take a second look at the simulation results.

In this driving-charging-balancing sequence example, we first observe the individual cell voltages changing as a result of current flowing in and out. At the beginning of the simulation they are slightly different because we initialized the model with a slight SOC imbalance. Towards the end of the simulation, the values converge towards one another as a result of the balancing.

How about current? Look at the charging period. During the constant current stage, the current is de-rated during charge because the maximum module cell voltage is high enough compared to a prescribed 4.4V limit that an excessively high current could drive the voltage beyond the threshold, significantly limiting the life of the battery. Since we calculate the current limit based on the maximum resistance value within the battery cell lookup table, we are being conservative. A less conservative current limiting calculation could use the actual battery cell resistance at the estimated SOC and temperature since this information is available at all operating conditions.

The temperature traces show a significant discrepancy among the hottest and coldest cell. The reason is mainly the asymmetry in the module layout in terms of thermal behavior. Cell number 6 gets significantly hotter than cell 1 because it is thermally insulated on one side. Even when the maximum temperature reached during this simulation is not of immediate concern in terms of safety, the temperature difference exhibited here will eventually cause a much faster degradation of cell 6 compared to cell 1, leading to an undesirable unevenness in cell condition. Hence the need for active thermal management to keep thermal differences within a few degrees Celsius.

The graph on the top right shows three SOC estimation traces of the same battery cell, each performed with a different method. Yellow corresponds to coulomb counting, blue corresponds to UKF, and orange to EKF. The initial SOC in this simulation is 75%, but the SOC estimators were initialized to 80% to assess their capability to recover. It is apparent that CC never does because it has no way to realize it is wrong due to the absence of voltage information. Both KF algorithms, on the other hand, recover from the initial error within the first hour of simulated time, with the EKF outperforming the UKF.

Finally, the other two scopes indicate the BMS state and each of the six balance command signals.

In summary, we’ve utilized Simulink, Stateflow, Simscape, and Control System Toolboxes to design a battery management system using modeling and simulation.