Functional safety: There is no unreasonable risk of hazards arising from failure of electrical and electronic systems. Therefore, the first priority of functional safety development is to avoid unacceptable risks. As a vehicle component, BMS generally obtains the FSR (Function safety requirements) at the conceptual stage from the Safety Goal at the vehicle level during functional safety development, and then analyzes the TSR (Technical safety requirements) at the electrical and electronic level from the FSR at the conceptual stage. Finally analyze the BMS
software and hardware functional safety requirements. The figure below is a schematic diagram of the ISO26262 development process.
In the ISO26262 standard, we distinguish between two types of failures, errors and failures: random and systematic failures. Systematic failures can be avoided by appropriate methods at the design stage, while random failures can only be reduced to an acceptable level. Systematic or even random failures will occur in hardware, while software failures are more systematic failures. First, according to the security objectives, determine the security level. For each hazard event, according to its exposure probability E, controllability C, severity S three elements, determine its ASIL level.
According to the development process of ISO26262, starting from requirements, including conceptual design, system design, hardware design, software design, and finally production release, after-sales maintenance, corresponding functional safety requirements are put forward, which covers the entire life cycle of the car , so as to ensure that the functions of automotive electronic products are safe and reliable, and even if the function fails, it will not cause danger. As the key to new energy vehicles, BMS has more and more complex functional requirements. BMS must have basic sampling functions such as voltage, current, and temperature, and at the same time supervise the operation process of the battery in real time. Temperature and other protection functions, and SOP, SOC, SOH prediction, fault diagnosis, balanced control, thermal management, fast and slow charging management, etc. Applying the ISO26262 standard requirements to the development of BMS will greatly improve the security of BMS.
If the BMS is regarded as a safety element out of context (independent safety unit), the independent safety unit means that other elements in the vehicle are temporarily ignored during the product development cycle. According to the Saftety Goal provided by the OEM, the BMS developer supplier derives the Saftety Requirements according to the Satety Goal, followed by the system design, hardware design, software design and so on.
As a part of the whole vehicle, some functions on the whole vehicle will interact with the battery system, and the results of their actions must be considered from the perspective of related items.
BMS is developed in accordance with the development practice of automotive electronics and electrics, according to the main process of the V model, and the OEM will participate in the testing part on the right side of the V model.
3. Definition of related items
The battery high voltage system is mainly composed of junction box, module, battery balance connector, high voltage connector module, BMS, etc. The BMS collects data such as voltage and temperature through sensors for processing, calculates the SOC/SOH of the battery, and diagnoses faults. At the same time, information exchange is carried out with the VCU through the vehicle CAN. When defining the relevant items, analyze the battery system components and define the scope of the functional safety analysis. The following figure is the structure and principle block diagram of the battery system. The functional safety goals undertaken by BMS are obtained at the level of vehicle-related items. On this basis, the development and verification of BMS products are carried out.
4. Development process
First identify the hazardous event. According to different working conditions, different driving habits and weather conditions, the most likely hazardous events are analyzed, and the hazardous events are assigned to various functional departments of the system. In ISO26262-3, Hazrad analysis can be confirmed by methods such as brainstorm, DFMEA, etc. Taking the monomer overcharge hazard event as an example, the level of the hazard event is determined according to the three elements of the ASIL level. The table below is a simple HARA analysis of cell overcharge. In this table, if the thermal runaway of the battery cell causes the vehicle to catch fire on an urban road, the ASIL Level is C; when the vehicle is at a low speed, the ASIL Level is A.
List all possibilities of function failure due to malfunction;
Summarize all functions and faults, differentiate them by operating mode, and form a matrix of hazardous events. Through hazard analysis and risk assessment, functional safety objectives for hazard events are defined. Combine the safety levels of the same hazard event in different scenarios, and use the highest functional safety level as the safety level of the hazard event. In order to avoid the occurrence of hazardous events, a safety goal is formed.
The safety objectives can be considered from the perspective of avoiding the occurrence of hazardous events, and can also be proposed from the perspective of avoiding the occurrence of failures. For example, a safety goal is proposed for the hazard of over-discharge causing an internal short-circuit battery to catch fire. From the perspective of avoiding hazards, the safety goal is proposed to prevent over-discharge from causing a short-circuit battery to catch fire. From the perspective of avoiding failure, the safety goal is proposed to avoid temperature limit failures. The ASIL level of the safety target is the highest level of the hazardous event.
After the safety goal is derived, some safety-related parameters also need to be specified. These parameters include: operation mode, fault tolerance time, safe state, functional redundancy, etc.
The second step is to determine the functional safety requirements FSR. Each safety objective defines at least one functional safety requirement. Although a functional safety requirement can cover more than one safety objective, each FSR inherits the highest ASIL from the associated SG. Through a layered approach, safety objectives are derived from risk assessment and hazard analysis, and functional safety requirements are derived from the safety objectives. The functional safety level of the FSR, which automatically inherits the highest level of the safety target.
The third step is to refine the technical safety requirements (TSR) from the functional safety requirements (FSR). Throughout the development life cycle, the technical safety requirements are the technical requirements to implement the concept of functional safety. The intent is from the detailed single-level functional safety requirements to System-level security technical requirements. The following table shows the transformation of functional safety requirements into technical safety requirements, which is only for reference in the process.
The fourth step, the system design stage, the system and subsystems need to implement the technical security requirements defined above, and need to reflect the security detection and security mechanisms defined above. The technical safety requirements should be assigned to the system design elements, and the system design should complete the technical safety requirements. Regarding the realization of the technical safety requirements, the following issues should be considered in the system design, define the system architecture, assign TSR to hardware and software, and define Software and hardware interface HIS. The hardware-software interface specification shall specify the interaction of hardware and software, and be consistent with the concept of technical security, and shall include components of hardware devices that are controlled by software and hardware resources to support software operation.
System design, three principles are given in the standard: modularity, appropriate granularity and simplicity. For different security levels, emphasis is placed on design considerations that focus on different aspects.
Technical safety requirements, either directly or after further refinement, are assigned to hardware and software.
After the system design is complete, design verification also needs to be considered. The higher the functional safety goal, the more inclined to the way of physical verification.
The fifth step is the functional safety design of the hardware system. The detailed security requirements of the hardware come from the TSR, the system architecture and the system boundary HSI. According to ISO 26262-8 Chapter 6.4.2 Hardware safety requirements specification shall include each hardware requirement related to safety, and hardware safety requirements shall be verified in accordance with ISO 26262-8 Chapter 6 and Chapter 9 requirements to provide evidence. Hardware design can start with a hardware functional block diagram. All elements and internal interfaces of the hardware block diagram should be displayed. Then a detailed circuit diagram is designed and verified, and finally the possible failures of the hardware architecture are verified by methods such as deductive method (FTA) or inductive method (FMEA). For the BMS system, the battery pack voltage sensor is a very important sensor, so it is necessary to analyze the different failure modes of the battery pack voltage sensor for different ASIL levels. Some failure modes can be prevented by hardware requirements, and some failure modes can be separated into software requirements to prevent.
The design of each technical safety requirement is closely related to the actual product function, technological development level, and supplier level, etc., and is the starting point for product differentiation of different manufacturers. The specific implementation of the product has its own different ideas. Some do not apply the safety mechanism, and directly require the components to improve their own functional safety level; some choose to add a monitoring mechanism or provide a redundant design with different principles to improve the functional safety level.
The hardware design verification principles recommended by the standard are as follows:
The sixth step, software system design. Software development in the automotive industry generally follows the V model, with the development process on the left and the testing process on the right. The BMS software development process is basically consistent with the V model of the software development process recommended in Part VI of ISO26262, as shown in the figure below. In the design of software architecture, the maintainability and testability of the software need to be considered. In the automotive industry, software should consider maintainability during the entire product cycle, and at the same time consider the ease of implementation of software architecture design testing. In the ISO 26262 standard, testing is a very important aspect, and any design should take into account at the same time. Ease of testing. So far, the design and development of the product has been completed.
The software architecture design principles recommended by the standard are as follows:
The error handling mechanism recommended by the software architecture level standard is as follows:
The standard recommended software design verification methods are as follows:
- 1. BMS design based on functional safety_Han Yuping
- 2. Research on the evaluation method of safety integrity level in line with ISO_26262 standard_He Bo
- 3. Overview of the development of the concept stage of BMS based on ISO26262_Tianxing
- 4. Research on BMS design method based on functional safety and its reliability_Inkai
- 5. GB∕T 34590.3-2017 Road Vehicle Functional Safety Part 3: Concept Stage
- 6. GB∕T 34590.4-2017 Road Vehicle Functional Safety Part 4: Product Development: System Level
- 7. GB∕T 34590.5-2017 Road Vehicle Functional Safety Part 5: Product Development: Hardware Level
- 8. GB∕T 34590.6-2017 Road Vehicle Functional Safety Part 6: Product Development: Software Level
Sheet fabrication services for mild steel, high strength low alloy (HSLA) steel, cold/hot rolled steel, galvanized steel, stainless steel, aluminum, copper and brass. Capable of fabricating parts up to 12 ft. length and +/-0.001 in. tolerance. Various capabilities include contract manufacturing,custom stamping,edge rolling, forming,top laser cutting, roll bending and welding. Finishing and secondary services such as hardware installation, tapping, deburring, cleaning, heat treating, plating, anodizing and painting available. Sheet Metal Prototype and low to high volume production runs offered. Suitable for commercial/residential architectural, aluminum brake shape parts, wall Panel systems, brackets, general flashings, rails, call button plates and ship building component parts.