The V-model
Less effort at every stage of development.
The BMS is built from ready-made, pre-tested edge devices, and its software runs in the vehicle maker’s own controller.
Requirements and architecture
Architecture from the requirements
The requirements of each vehicle translate straight into an architecture of ready-made edge devices, with the battery software in the OEM’s own controller. Where none fits, an edge device can be shaped to the vehicle’s needs.
A conventional BMSThe architecture is fitted around the BMS vendor’s hardware. A requirement it doesn’t cover can mean adapted hardware or a new variant, agreed with the vendor.
Safety and security concept
Designed to arrive pre-certified
The edge devices are designed to arrive pre-certified to ISO 26262, up to ASIL D, and to meet ISO 21434. With no firmware in them, their safety documents stay the same when the battery software changes.
A conventional BMSA safety case for each hardware and software variant, built on the vendor’s FMEDA. Software changes most often, and each change sends the safety documents back to the vendor.
Hardware
Edge devices without firmware
Each edge device is a PCB in its housing, with no MCU or firmware of its own to develop, update or certify.
A conventional BMSBMS boards with their own MCUs, SBCs and firmware, each certified with its board.
Software
Only the algorithms to write
The Complex Device Driver (CDD) in the zonal or central controller delivers every sensor reading and the edge devices’ diagnostics. The vehicle maker writes its own battery algorithms on top, and keeps them.
A conventional BMSBattery software inside the vendor’s BMS. A new feature or a fix is a change request to the vendor.
Integration
Ethernet, with no gateway
Every HV battery pack connects over Ethernet straight to the zonal or central controller. The battery software runs there, beside the vehicle’s other applications.
A conventional BMSA separate BMS controller, often behind a gateway, with its own network messages to define and map.
Validation
Pre-tested edge devices
The edge devices arrive pre-tested, so validation goes to the vehicle maker’s own software and the vehicle.
A conventional BMSThe BMS validated as a whole for each variant, hardware, firmware and software together.
Production and service
Updated over the air
The battery software is updated over the air with the vehicle’s other software. HV battery packs from second sources, built on the same edge devices, run on the same software.
A conventional BMSUpdates, service tools and second sources tied to the BMS vendor.
Variants
Each new variant takes less effort, time and cost than the first.
A new variant builds on the battery software and integration of the first. It takes a configuration change, sometimes a different pick of ready-made edge devices or a new calibration, and no requalification.
Questions OEMs ask
Where does the battery software run?
In one place, the zonal or central controller, beside the vehicle’s other software. The OEM changes it there, on its own schedule, with no separate BMS controller to update.
Who owns the battery software and the battery data?
The OEM. The Complex Device Driver (CDD) handles the edge devices, reading their sensors, driving their actuators and checking their communication. The battery algorithms on top are the OEM’s own, written for its vehicles, and every reading stays in its controller.
What happens when an edge device detects a fault?
Depending on the fault, the edge device is designed to bring the system to a safe state on its own, in hardware, or to report it to the zonal controller at once.
Can other sensors and actuators be added?
Yes. They plug in alongside the edge devices, through general-purpose I/O, and are controlled from the zonal or central controller with the rest.
How are the edge devices set up and monitored?
With a desktop application. It configures the edge devices, sets up the CDD and integrates it into the controller’s software, and monitors the edge devices as they run.