Frequently Asked Question

BMS Testing Solution - FAQ
Last Updated about a month ago

In this article, some of the commonly asked questions regarding the various aspects of the BMS Testing solution are presented, including Device considerations, HIL BMS Interface, Battery Cell models, and Testing considerations.

(1) Does the BMS HIL testing solution require a Premium License?

For HIL applications limited to the BMS testing solution, a special licensing framework dedicated to the features required to enable the operation of BMS Interface and the battery stack real-time model is available. Get in touch with our Team for further information!

(2) How many cells can we model?

The number of parallel cells can be defined in the properties of the Battery Cell component, being modelled by multiplying and dividing the appropriate parameters according to the desired number and assuming that all the cells in the parallel configuration have equal parameters. Therefore, there is no theoretical limitation for the number of cells in parallel.

When it comes to serially connected cells, the answer is not that straightforward, depending on different factors. Since each battery cell component is implemented using one controlled voltage source, the maximum number of cells in series is limited by the maximum number of signal processing sources available (16 SP sources per SPC). Therefore, this limitation varies depending on the HIL device. For example, for one HIL606 device up to 128 battery cell components can be implemented in series, while for one HIL404 the limitation is up to 64 cells.

Another important factor to consider is the execution rate of the battery cell components. If execution rates lower than the standard 100 us are set, the CPU time slot utilization may become a limitation more stringent than the one abovementioned.

(3) What is the HIL IO requirement of one Cell Emulator (channel of the HIL BMS Interface)?

Each Cell Emulator requires:

  • 1 Analog Output - Cell voltage signal
  • 1 Analog Input - Balancing current signal
  • 1 Digital Output - Fault signal

(4) How many cell emulators (cell model + BMS Interface) can we have per HIL device?

Currently, each BMS interface can be connected to a maximum of 16 cells in the model.

Given the required number of IOs per Cell Emulator (see (3)), this means the following:  

  • 4-series devices: 16 Cells* (one HIL BMS Interface is used)
  • 6-series devices: 32 Cells (two HIL BMS Interfaces are used)

*In this kind of setup, all of the AOs (16/16), AIs (16/16), and one half of DOs (16/32) will be utilized. None of the DIs will be utilized (0/32). This would unable you to interface additional analog signals (e.g. Pack Current, Pack Voltage, Thermistor Voltages...).

(5) What is the required simulation time step for BMS models?

Considering the sampling of Analog signals (voltages and currents) from the BMS Interface, the recommended simulation step is 10 us or lower. 

(6) How does the Cell Emulator take into account the effect of the temperature in the battery stack operation?

The BMS interface includes a resistor emulator feature, which can be parametrized based on look-up-tables according to the characteristic of the BMS thermistors. Additionally, thermal models of the cell can be built in the model to calculate the cell temperatures from the ambient temperatures using the Thermal network component.

(7) Why is HIL606 the preferred device over the HIL604 when it comes to the BMS HIL testing solution?

Some of the more obvious reasons for this preference are down to the more powerful FPGA processor, enabling simulations with smaller simulation steps, as well as better DI sampling resolution.

A very important difference also lies in their respective Signal processing capabilities. Due to a more powerful CPU architecture (see System Architecture), the HIL606 has ~10 times the resources for Signal Processing than the HIL 604.

Having in mind the way our Battery Cell component is implemented, each Cell takes up some Signal Processing resources - the more cells you have, the higher the overall Signal Processing utilization. Additionally, the smaller the defined Execution Rate of these Battery Cells, the higher resource utilization per Cell.

We can consider the following example: You can simulate up to 20 Battery Cells with a 10ms Execution Rate on the HIL604. In this case, the HIL604 would perform the same as the HIL 606 (provided that there are not many other Signal Processing components).

If you would want to increase the number of Battery Cells or simulate these 20 Battery Cells with a faster Execution Rate (100us for example), the HIL604 would not be sufficient due to signal processing computing interval overrun.

(8) How can we perform Open Wire faults? 

Open Wire faults are executed by using the real, physical Fault insertion circuit of the Cell Emulator inside the HIL BMS Interface:

To perform a Cell disconnection of a desired channel, we set the appropriate HIL Device Digital Output (in the simulation) to logical high. This will cause the relay to open, and this connection will be physically disconnected from the cell emulator. 

(9) How can we perform Short Circuit faults of Cells?

The Battery Cell component allows for dynamically overriding the Cell Voltage, through its internal SCADA Inputs called Vcell Override and Vcell Value Set. By setting the value of Vcell Override to 1, and the value of Cell Voltage to 0 V, you will be able to simulate a Short circuit of a cell. 

(10) How can we perform Reverse Polarity faults of Cells?

The Battery Cell component allows for dynamically overriding the Cell Voltage, through its internal SCADA Inputs called Vcell Override and Vcell Value Set. By setting the value of Vcell Override to 1, and Cell Voltage to a negative value, you will be able to simulate a Reverse Polarity fault of the cell. Reverse Polarity is also a supported capability of the Cell Emulator channel.

(11) How can we acknowledge the effects of Battery aging?

The effects of Battery aging can be included through the State of Health property defined on the Battery Cell component, parametrized as a vector called SOH_values. After being parametrized, you have the possibility to change the value of SOH during simulation runtime, as it is an internal SCADA Input, called SOH_set

By changing this vector, you will be able to acknowledge the effects of battery aging, as this parameter influences parameters such as Cell internal resistance, available capacity etc. You can see the full list of parameters impacted by SOH below: 

(12) Can I create my own Battery Cell model or use a model from other software tools (e.g. Simulink)?

The Battery Cell model is based on the state-of-the-art Enhanced self-correcting cell model, which provides high-fidelity in emulating different kinds of electro-chemical behavior found in real-life batteries (e.g. Diffusion Processes, Voltage hysteresis, etc.), as well as flexibility in the choice of battery types to be emulated (by way of its detailed parametrization options).

However, by using appropriate power stage (sources, contactors) and Signal Processing components (e.g. Mathematical and Logical functions, C function), you have the freedom to create your own, custom, battery models. 

Depending on their complexity and way of implementation, battery models can be imported using some of the methods listed here: Can I import models from other software tools to Typhoon?

Please Wait!

Please wait... it will take a second!