The ISO 26262 functional safety standard is becoming an absolute necessity for electric passenger cars, road vehicles, and other EVs on the market. Considering that the Battery Management System (BMS) is a defining factor for the safety of these electric applications, certification on at least ASIL C level is also becoming a market need for BMS. While the demand is present, the certification process is neither simple nor cheap, and solutions for off-the-shelf certified/certifiable BMS are sparse on the market.
The main reason for this is probably the fact that the ISO26262 demands that you provide a calculated estimate of the rate of hazard occurrence due to random hardware failures. Furthermore, you are obliged to prove that the so-called Probabilistic Metric for Hardware Failure (PMHF) is achieved.
To support this, over a hundred different documents and reports are required to be submitted to an accredited, external organisation for analysis, review, and approval for obtaining an ISO 26262 certification for a specific BMS product. Although the standard offers some options for configuration and calibration, such a certified product typically lack flexibility too, as recertification is subject to even minor safety critical modifications. Therefore, a fully certified ISO 26262 Battery Management System is most often purchased as a customised product for a single or limited amount of product lines.
Breaking down the certification and development process
“Lithium Balance has been through the ISO 26262 certification procedure on multiple occasions, first, during the development of a customised BMS created for some of the major electric passenger car OEMs. Afterwards, challenging the market norms, we found a working solution for the development of an ISO 26262 Battery Management System, that comes off-the-shelf, and maintains its flexibility regardless of the strict certification process, the third generation n-BMS platform, thanks to a clever software-level design.” – claimed Claus Friis Pedersen, R&D Director at Lithium Balance.
“Whereas the development of an ISO 26262 certified BMS solution took us over two years, with the n-BMS platform, the (re-)certification process for custom specific solutions can be cut down to a fraction hereof”.
“ISO 26262 defines requirements for the whole life cycle of a product, including management, development, production, operation, service, and decommissioning, and requires that the fulfilment of all requirements are proven, documented, reviewed, and verified/validated, while potential failures are analysed, and risks specified and quantified”, Claus explained.
For the n-BMS platform, the process started with breaking down the development and certification procedure into three phases, the concept phase, product development phase, and post-RFP phase. These phases were then broken down to smaller stages as well. The concept phase was consisting of an item definition stage, where the overall functions and basic design of the BMS was defined, a stage where Hazard Analysis and Risk Assessment (HARA) was made, an important analysis technique to ensure potential safety hazards are considered, and then the definition of the functional safety concept stage, where the main safety goal was set. For the n-BMS, “Avoiding battery SOA (Safe Operating Area) violation” was defined, as well as further safety functions and steps, such as what safety support functions shall be applied, when the BMS should provide warnings, and when should it enter “Safe-state”, where all battery contactors are disconnected.
The product development phase included the actual development of the hardware and software by first looking at the BMS on a system level, deriving the safety requirements set from the functional safety concept, creating a system architecture, defining safety mechanics for detection and avoidance of failures, and safety analyses at a system level, such as Failure Mode and Effect Analysis (FMEA) and Failure Tree Analysis (FTA). For an ASIL-C certification there shall be no potential single-point failures in the system that are not covered by a safety mechanism.
Development on a hardware level was made in a similar structure. After deriving Hardware Safety requirements and test specifications, a detailed hardware design was made with HW/SW interface specification and test specification, which included a 32 bit RISC floating-point and dual core lockstep CPU on the master board and several slave boards to suit a number of different customer interests in terms of number of battery cells per slave and connector types. At this level quantitative analysis, FMEDA and quantitative FTA were conducted to provide the previous figures for the likelihood of failure.
“With the third generation n-BMS platform, we developed one of the first ISO 26262 certified BMS off-the-shelf, with a “sandbox” ASW that allows for a large degree of customisability without any negative effects on its safety functions, pioneering the way towards safer electric vehicles on the road and shorter time-to-market for automotive OEMs, who will not have to go through the lengthy and rather costly ISO 26262 certification process”.
Risk-free implementation of your own software code
What truly makes the n-BMS platform unique, however, is its software-level design. It includes an open API that allows customers to include their own software code in the BMS, without any risk posed on the ISO 26262 certification, thanks to a clever design. The n-BMS platform’s software has been separated into two layers, the Base-Layer-Software (BSW) and the Application-Layer-Software (ASW). All safety critical functions and hardware drivers are included in the BSW, allowing more flexibility and customisability for the ASW, which contains non-safety critical features only, such as SoX algorithms. The two layers are separated by an open API interface layer, making the connection between BSW and ASW seamless and programming simple.
In addition, a complete ASW package of functionality has also been developed for the n-BMS platform, with full configurability, so the depth of customisation is completely up to the user. Via the open API, users can safely supplement, or completely replace the added ASW functionality with their own custom algorithms and battery models using the MATLAB toolbox or Simulink codes, without any effect on the ISO 26262 certification.
The software design was followed by proving freedom from interference between safety critical parts and non-safety critical parts, and further tests, including environmental tests, EMC test, system integration test, and Fault Injection test to invoke safety mechanisms. With that, the product was ready for production, however, further paperwork to the independent organisation, TÜV SÜD in Lithium Balance’s case, was still filed during the production, service, and decommissioning.
Conclusion
With the third generation n-BMS platform, we developed one of the first ISO 26262 certified BMS off-the-shelf, with a “sandbox” ASW that allows for a large degree of customisability without any negative effects on its safety functions, pioneering the way towards safer electric vehicles on the road and shorter time-to-market for automotive OEMs, who will not have to go through the lengthy and rather costly ISO 26262 certification process.” Claus concluded.
