Today, the editor attempted to organize information related to the functional safety development process of the power battery BMS. However, the information in the validation section is not sufficient, and there will be an opportunity to supplement it later.
Functional Safety Definition Functional Safety
There is no unreasonable risk of harm caused by malfunctions in electronic and electrical systems. Therefore, the primary task of functional security development is to avoid unacceptable risks. As a component of the entire vehicle, the functional safety development of BMS is generally carried out by obtaining the concept stage FSR (Function Safety Requirements) from the safety goal at the vehicle level, and then analyzing the electronic and electrical level TSR (Technical Safety Requirements) from the concept stage FSR. Finally, the functional safety requirements of BMS software and hardware are separated.
The following figure is a schematic diagram of the development process of ISO26262.
2.Overview
In the ISO26262 standard, we need to distinguish between two types of faults, errors, and failures: random and systematic failures. Systematic failures can be avoided through appropriate methods during the design phase, while random failures can only be reduced to an acceptable level. Systematic or even random failures can occur in hardware, while software failures are more of a systemic nature. Firstly, determine the safety level based on the safety objectives. For each hazardous event, determine its ASIL level based on its exposure probability E, controllability C, and severity S.
According to the development process of ISO26262, starting from requirements, including conceptual design, system design, hardware design, software design, and ultimately production release, after-sales maintenance, corresponding functional safety requirements have been proposed, covering the entire life cycle of the car, ensuring the safety and reliability of the functions of automotive electronic products, even if functional failure does not cause danger. As a key component of new energy vehicles, BMS has increasingly complex functional requirements. BMS must have basic sampling functions such as voltage, current, and temperature, as well as real-time monitoring of the battery’s operation process, protection functions such as overvoltage, undervoltage, overcurrent, and over temperature. At the same time, it can predict SOP, SOC, and SOH, diagnose faults, balance control, thermal management, and fast and slow charging management. Applying the requirements of ISO26262 standard to the development of BMS will greatly improve the safety of BMS.
If BMS is regarded as a Safety Element Out of Context, the meaning of the independent security unit will not consider other elements in the vehicle within the product development cycle. According to the SAFTETY Goal provided by the OEM, BMS developers suppliers export SAFTETY Requirements based on Satety GOAL, followed by system design, hardware design, software design, etc. As part of the vehicle, some functions on the entire vehicle will interact with the battery system, and the results of its role must be considered from the perspective of the relevant item.
According to the development practice of automotive electronics and electronics, BMS will be developed according to the main process of the V model. The OEM will participate in the test part of the right side of the V model.
3.Related item definition
The battery high -voltage system is mainly composed of wiring boxes, modules, battery balance connectors, high -voltage connector modules, BMS, etc. BMS is processed by collecting voltage, temperature and other data through sensors, calculating the SOC/SOH of the battery, and fault diagnosis. At the same time, information interaction with VCU is performed through the vehicle CAN. When the relevant item definition is performed, it is necessary to analyze the components of the battery system to define the scope of functional security analysis. The figure below is the frame diagram of the battery system structure and principle. The functional safety goals undertaken by BMS are obtained at the level of the vehicle. On this basis, the development and verification of BMS products.
4.The development process first determines the harmful event
Based on different operating conditions, different driving habits, and weather conditions, the harmful incidents that are more likely to be analyzed, and the functional departments assigned to the system work for harmful events. In ISO26262-3, HAZRAD analysis can be confirmed by BrainStorm, DFMEA and other methods. Taking a single over -charge hazard event as an example, according to the three elements of the ASIL level, determine the level of the incident. The following table is a simple HARA analysis with a simple battery cell. In this table, the battery heat out of control on the urban road causes the vehicle to fire. The designated ASIL Level is C; when the vehicle is relatively low, the ASIL Level is A. All the possibilities of the list function due to faults;
Summarize all functions and faults, and distinguish the operation mode to form a matrix of the harmful event. Through harm analysis and risk assessment, define the functional safety goals of the harmful event. The safety level of the same harm in the same scene is used in different scenes, and the highest functional security level is used as the safety level of the harmful event. In order to avoid the occurrence of endangering events, and then formed a security goal.
Safety targets can be considered from the perspective of avoiding harmful events, and safety goals can also be proposed from the perspective of avoiding faults. For example, a safety goal is proposed to the hazards that caused the internal short -circuit battery to fire. From the perspective of avoiding harm, safety goals are proposed to prevent short -circuit batteries from causing short -circuit batteries. From the perspective of avoiding faults, the safety goals are faulty to avoid temperature restrictions. The ASIL level of security targets is the highest level of the event. The safety goals are obtained, and some security -related parameters are also required. These parameters include: operating mode, fault tolerance time, safety state, function redundancy, etc.
Determine the functional security requirements FSR. Each security target defines at least one functional security requirement. Although a functional security requirement can COVER more than one security goal, each FSR inherits the highest ASIL from related SG. Through the layered method, the security goals are obtained from risk assessment and hazard analysis, and the functional security requirements are obtained by security goals. FSR’s functional security level and automatically inherit the highest level of security targets.
Third, refine the technical safety requirements (TSR) by functional security requirements (FSR)
In the entire development life cycle, technical security needs should implement the technical requirements of functional security concepts, and its intention is from the single -level functional security requirements of details to system -level security technical requirements. The following table is a chestnut that transformed into technical security requirements for functional security requirements, for reference only in the process.
The fourth step is that during the system design stage, the system and subsystems need to implement the technical safety requirements defined above, and need to reflect the safety testing and safety mechanism defined before. The technical security requirements should be assigned to the design factors of the system. At the same time, the system design should complete the technical security requirements. Regarding the implementation of technical security requirements, the following issues should be considered in the system design. Software hardware interface HIS. Software and hardware interface specifications The interaction of hardware and software specified in the software and hardware interfaces are consistent with the concept of technical security. It should include the hardware equipment of the component, which is supported by software and hardware resource control to support software. System design and standards are given three principles: modular, appropriate particle size and simple. For different security levels, emphasize design considerations on different side.
Technical security requirements, after further or after further refinement, are allocated to hardware and software. After the system design is completed, design verification needs to be considered. The higher the functional safety goal, the more tendency to the method of physical verification.
5, hardware system functional security design
The detailed security requirements of hardware come from TSR, system architecture and system boundary HSI. According to the ISO 26262-8 chapter 6.4.2 hardware security requirements specifications shall include each hardware requirements related to security, and the hardware security requirements shall be verified in accordance with the requirements of ISO26262-8 Chapter 6 and 9 to provide evidence to provide evidence. The hardware design can start with the hardware function block diagram, and all the elements and internal interfaces of the hardware block diagram should be displayed. Then design and verify the detailed circuit diagram, and finally verify the faults that may occur through the interpretation method (FTA) or induction method (FMEA). For the BMS system, the battery pack voltage sensor is a very important sensor. Therefore, for different ASIL levels, the battery pack voltage sensor needs to be analyzed differently. Some failure modes can be prevented through the requirements of hardware, and part of the failure mode can be separated as software demand to prevent.
How to design each technical security requirement is closely related to the actual product function, technological development level, and the level of supplier levels. It is the starting point of different manufacturers’ products. The specific implementation of the product has its own different ideas, and some are not applicable to the safety mechanism. It directly requires parts to improve its own functional security level; some choose to increase the monitoring mechanism or provide different principles of redundant design to improve the functional security level.
The principles of hardware design recommended by standards are as follows: Table as follows:
Note: The scope of this verification and review is the technical correctness of hardware design
Methods whether the hardware security requirements in the hardware design of 1A and 1B check the hardware security requirements are complete and correctly executed
When the analysis method 1 and 2 are not sufficient, use the specific point of 3A and 3B to check hardware design (such as fault injection technology)
Six, software system design
The software development of the automotive industry generally follows the V model. The left is the development process and the corresponding test process on the right. The BMS software development process is basically consistent with the software development process V model recommended by the ISO26262 part 6, as shown in the figure below. In the design of software architecture, the maintenance and testability of the software needs to be considered. In the automotive industry, software should consider maintenance in the entire product cycle, and at the same time, the design and testing of the software architecture should be easy to achieve. In the ISO 26262 standard, testing is a very important aspect. Any design should be considered at the same time. The convenience of testing. At this point, the design and development of the product has been completed.
The design principles for the software architecture recommended by the standard are as follows:
The error processing mechanism recommended by the software architecture level standards is as follows:
Software design verification methods recommended by standards are as follows:
