4th December 2019
3 Complex Scenarios to Ensure Faster Product Development With ION’s Hardware-in-the-loop Testing
Electronic products are pretty complicated, to say the least. For faster product development, many components and aspects of engineering have to come together. It’s not always feasible to have a hardware setup, which successfully emulates the complex application environment of the electronic product.
It can get too expensive, time-consuming and in general introduce inefficiencies in the product development and testing cycle. Let’s have a look at an example to better understand the issues faced. Let us consider a Battery Management System (BMS).
The BMS must monitor multiple cell parameters and take decisions based on them. Some of the parameters are:
– Cell voltages
– Cell temperatures
– Current flow
– Actuator states to name a few
To create a hardware setup which duplicates the end-level application environment, one would need:
– Electronic Loads
– Various sensors to measure current, temperature, etc.
It is not possible to create real-time, application-level conditions necessary to test 100s (or even 1000s) of test cases.
Especially in an agile software development cycle, wherein new software features are continuously developed, new releases have to be tested out quickly for faster product development, before releasing them to customers.
This is where Hardware in The Loop (HIL) comes into the picture.
Hardware in the loop provides a tool for engineers to develop and test their solutions in a fast and efficient manner, for faster product development, reducing cost and time overheads and allowing thorough testing of products.
We at ION, have time and again used this approach to develop and test out new firmware features for our products.
In our endeavor to design state-of-the-art Battery Management Systems, engineers strive to develop new additional technologies that aid us in our ultimate vision.
One such tool is BATLAB.
BATLAB is a software designed by ION Energy to be used for generating complex real-world test scenarios for faster product development, which help the Firmware Engineers to test out new firmware features, in a quick and efficient manner.
The Complex Scenarios BATLAB Emulates for faster product development:
In order to emulate accurate real-world test scenarios, BATLAB asks the user for certain inputs. The section below will explain all the test conditions BATLAB can emulate and along with the inputs that it requires.
1. Battery Pack Electrical Emulations
Most of the data needed to simulate the electrical behavior of a cell is available in the datasheet and the accompanying graphs which are usually provided by the cell manufacturer.
– Battery Pack configuration
– Battery Capacity
– Nominal Charging and Discharging current of the pack
– Resistance and capacitance values according to the well known 2RC Mathematical Model of the cells.
BATLAB’s proprietary algorithms predict battery SoC and SoH based on these inputs.
2. Battery Pack Thermal Emulations
The safe and efficient working of a battery is highly dependent on its thermal environment. Extreme temperatures directly affect the capacity of the battery. The Internal Resistance of the battery also changes along with the battery temperature, which affects the SoC and SoH.
BATLAB takes into account:
– Battery Pack Dimensions
– Changes in the internal resistance of a cell
– Effect of battery cooling using a fan
– Thermal parameters of the battery such as it’s specific heat capacity, Latent heat, etc.
These inputs directly affect the software’s SoC and SoH estimations.
3. OCV and SoC Estimations
While static cell voltages are easy to simulate, what is needed is the cell voltages to change dynamically. This change in cell voltage is dependent on the current profile applied to the cells and the thermal environment around the battery pack and is also unique to each type of cell chemistry.
BATLAB has features which can calculate the OCV of a cell and constantly keep changing the cell voltages based on how the cells are being used.
Cell manufacturers provide customers with multiple graphs which are generated after rigorous testing of their cells. BATLAB provides the option to incorporate some of these graphs into the simulation to make accurate SoC predictions. The first graph that can be incorporated in the algorithm is the SoC vs temperature vs Internal Resistance graph.
Using mathematical analysis, BATLAB can predict fairly accurately the expected Internal Resistance of a cell at given SoC and temperature. This value of internal resistance helps in calculating the Open Circuit Voltage of a cell.
Cell Internal Resistance vs Temperature curve plotted at different SoC values
Another graph that can be utilized is the OCV vs Normalized SoC graph. This graph varies from chemistry to chemistry. Currently, BATLAB is able to make use of this feature to predict SoC for NMC, LiFePO4 and LCO chemistries.
BATLAB’s Coulomb Counting method is very accurate (Since the current is an emulated quantity, there is no measurement error introduced). Making use of this and the above-mentioned features, the software can accurately change the OCVs of the cells depending on the current profile and the thermal simulations running in the backend.
This provides the Firmware engineers with an accurate battery emulation to optimize their SoC calculation algorithms without having to depend on an actual battery pack.
OCV vs SoC graph for NMC Cell Chemistry Now that we have seen the individual features of the software, let us see how it all comes together from an application perspective.
Now that we have seen the individual features of the software, let us see how it all comes together from an application perspective.
Power Delivery Emulation
A simplified power delivery circuit which updates in real-time can be found on BATLAB. Currently, it shows a Battery at 98.01% SoC with 10 amps discharging current, with the discharge actuator turned ON.
Once BATLAB has all the inputs, the software can simulate the cell power delivery, and see how the SoC will drop or rise over time, depending on the direction of current applied. Current can be applied in charging and discharging directions.
A current profile can be loaded into the software, and the simulation will output corresponding graphs of SoC, Current, and cell voltages over time. There is also an option to emulate the precharge power delivery, which is useful for capacitive loads.
Battery Manufacturers can make use of this to determine how their cell would perform in different application scenarios.
A section of the PDU Emulator also allows for taking into consideration fuses and contactors being used in the battery application and incorporate their parameters in the simulation.
Interfacing BATLAB with the BMS
Now that we have a fair idea of what the basic capabilities of BATLAB are, let’s move on to how the BATLAB software interacts with ION Energy’s BMS Platforms.
There are two ways it can to this:
1. Connect via Hardware
BATLAB makes use of National Instruments DAQ Devices to output voltages which act as cells for the BMS Hardware. As seen in an earlier section, Batlab also emulates the Power Delivery Unit using similar hardware.
2. Connect via CANbus
All of ION Energy’s BMS platforms have the functionality of interfacing with peripheral devices via CANBus. Making use of this feature, the engineers at ION Energy developed a firmware for the BMS Platforms, which can connect to BATLAB using a CAN to USB Adapter.
The cell voltages, temperatures, PDU parameters are all sent to the BMS via CANBus altogether eliminating the need for any kind of hardware other than the BMS itself! This method has greatly helped our FW Engineers in faster product development, building new features without needing any setup to power up the BMS Hardware.
Once the new features are developed, they are ported to the production firmware and are tested by placing BATLAB in Hardware connection mode.
Hardware in the loop is fast becoming a standard industry procedure. At ION we have been quick to incorporate this in our Firmware development process and intend to build upon it for faster product development.
Using HIL has given the firmware engineers a lot of flexibility. They were able to simulate multiple test cases, without investing the time or money to create any hardware setups.