Functional safety design of VCU architecture-EEWORLD

Collect

As the trend of software-defined cars becomes stronger, it has become a basic requirement for road vehicle electronic and electrical systems to meet functional safety requirements. Recently, in the EU vehicle type approval (typeapproval is based on some UNECE regulations) and my country's CCC certification of vehicles, functional safety requirements have also been introduced for electronically controlled steering, braking, power battery management systems, etc. Efficient software architecture design obviously plays a guiding role in the implementation and implementation of functional safety, so it has become a basic attribute of the product for electronic and electrical systems to meet functional safety requirements.

In order to determine how software architecture can meet functional safety requirements, industry insiders have drawn on the E-Gas architecture. E-Gas was first applied to engine controllers (EMS) and consists of three parts: Level 1 functional layer, Level 2 functional monitoring layer, and Level 3 controller monitoring layer. Domestic related papers apply the E-Gas architecture to various control functions. Patents, literature, literature, literature, and literature all design vehicle controller hardware and software based on functional safety standards, but do not involve Level 2 software architecture.

Therefore, in order to make up for the defect that the E-Gas architecture does not explicitly propose the Level 2 software architecture based on model development MBD, and the architecture design must meet the functional safety requirements such as high cohesion, low coupling, and appropriate layering, this paper designs a Level 2 functional monitoring layer software architecture for the vehicle controller VCU, which not only meets the functional safety architecture design requirements, but also can be applied to other ECU functional safety Level 2 designs, which is helpful to further implement the functional safety design and reduce the difficulty of implementation.

1. Overall Architecture of VCU Model

Design the Level 1 and Level 2 architectures of the vehicle controller VCU model, as shown in Figure 1, including timing scheduling, input signal, Level 1, Level 2 and output signal modules, which must meet the architectural design principles and requirements of functional safety understandability, consistency, simplicity, verifiability, modularity, abstraction, encapsulation, and maintainability.

Figure 1 VCU control model architecture

Level 1 is called the functional layer, which includes basic vehicle control functions, such as motor torque demand, energy recovery, etc., vehicle high and low voltage power management, such as high voltage safety, low voltage management, etc., and the control system's response when a fault is detected. Level 2 is called the functional monitoring layer, which detects defects in Level 1 functional software. For example, by monitoring the calculated required torque value or the longitudinal acceleration of the vehicle, when a system failure occurs, it triggers a system response and enters a safe state. Level 1 and Level 2 are independently developed and their respective production codes must run in different partitions to avoid common cause failures and interference, and the Level 2 monitoring layer code must run in the hardware safety core.

2. Level 1 functional layer software architecture

Design the Level 1 functional layer architecture of the VCU model, as shown in Figure 2. When Level 1 implements and applies the basic functions of the ECU, the basic functions of the ECU must exist, including timing scheduling, input signal aggregation, output signal aggregation, and control function modules (such as vehicle operation status control, torque control, energy management, diagnosis processing, accelerator pedal control, gear control, driving range, low-voltage power supply control, instrument display control, etc.). Each model library uses the model application (ModelRefercence) method to reference, which is convenient for maintenance, reuse or transplantation of each module library.

Figure 2 VCU control model Level 1 functional hierarchy

3. Level 2 Function Monitoring Layer Architecture

The Level 2 functional monitoring architecture of the VCU model, as shown in Figure 3, includes three modules: signal verification, Level 2 process monitoring, and output monitoring. Its function is to monitor the design functional safety-related modules implemented in the Level 1 functional layer of the ECU. It belongs to the monitoring module. Adding this module can meet the functional safety requirements. The functional safety can be decomposed as follows: the Level 1 functional safety level is QM (X), and the Level 2 functional safety level is X (X), where X can be divided into ASILA/B/C/D according to specific functions.

1.Level2 signal verification software architecture

(1) Input and output interface

The input and output interfaces of the signal verification module are shown in Table 1.

Table 1 Level 2 signal verification module interface

(2) Security mechanism

The Level 2 input module verifies the integrity, effective range, rationality, etc. of the corresponding safety-related signals, and then outputs them to Level 1 and Level 2 process monitoring and output monitoring respectively. The specific verification mechanism and timing diagram are shown in Figure 4.

Figure 4 Signal verification module rack

Assume that the signal of interface 1 is received every TBDms, firstly, a timeout check is performed on the signal. If the signal is not received within the TBD signal period, the signal is determined to be lost. Then a CRC check is performed. If the check fails, the CRC of the frame signal is determined to be wrong. Then an alivecounter check is performed. If the check fails, the alivecounter of the signal is determined to be wrong. Finally, a valid and range check is performed. If the check fails, the signal is determined to be invalid. If any of the above errors are detected, the sending interface 3 is invalid and the sending interface 2 is the default value or the signal of the previous cycle to other modules.

2.Level 2 process monitoring software architecture

(1) Input and output interface

The input and output interfaces of the Level 2 process monitoring module are shown in Table 2.

(2) Security mechanism

According to the safety-related functions in the Level1 functional layer, its safety signal output is used as the input of the Level2 monitoring layer, and the Level2 monitoring layer monitors Level1. The architecture diagram is shown in Figure 5: Regardless of the Level1 functional layer, the monitored function should adopt a redundant heterogeneous algorithm in the Level2 monitoring layer to verify interface 4, and trigger the system response when an error or abnormality occurs, bringing it into a controllable state, that is, output interface 6, interface 7, interface 8, and interface 9.

3.Level2 output monitoring software architecture

(1) Input and output interface

The input and output interfaces of the Level 2 output monitoring module are shown in Table 3.

(2) Security mechanism

Level2 conducts closed-loop real-time monitoring of the final output result of level1, the CAN transceiver or hard-wired driver output, and the final execution status of the actuator. The architecture diagram is shown in Figure 6. The specific strategy is divided into three levels. The first is model output signal monitoring: Level2 uses an independent Level1 control strategy to monitor interface 10 to avoid logical errors or output disconnection; the second is drive output monitoring: interface 10 outputs to the output driver, and Level2 needs to debounce for a certain period of time to monitor whether the driver outputs correctly; the third is actuator monitoring: after the actuator responds to the interface 11 signal, it executes the action and feeds back to interface 12, and Level2 monitors whether its execution status meets the expected results. If one or more monitoring faults occur, it is necessary to send an instrument through interface 14 to remind the driver, and the system enters a safe state through interface 15 or 16.

4. Analysis and Test Verification

By applying safety analysis (FMEA and FTA) and DFA-related failure analysis at the software architecture level, the cause of failure (Fault) is found and the impact of failure (Effect) is analyzed. The results show that the Level 2 software architecture provides monitoring functions, behaviors and ASIL levels that meet the design requirements.

Reference address：Functional safety design of VCU architecture

Previous article：Research on multi-domain computing: Summary of several ideas for cross-domain integration and discussion of product strategies
Next article：The top five automotive chip manufacturers rely heavily on China

Popular Resources
Popular amplifiers

Latest Automotive Electronics Articles

2024 China Automotive Charging and Battery Swapping Ecosystem Conference held in Taiyuan
2024 is an important year for the charging and swapping industry to make innovative breakthroughs and move towards high-quality development. my country has built the world's largest charging and swapping service network. In order to further improve the charging service guarantee capability and promote the industrial chain ...
State-owned enterprises team up to invest in solid-state battery giant
According to Qichacha news, on November 15, the solid-state battery giant Tailan New Energy changed its investors. Although Foshan Birui Wanmu Equity Investment Partnership and Suzhou Qingrui Huaying Venture Capital Partnership withdrew ...
The evolution of electronic and electrical architecture is accelerating
On November 14, my country's annual output of new energy vehicles exceeded 10 million for the first time, making it the first country in the world to achieve an annual output of 10 million new energy vehicles. ...
The first! National Automotive Chip Quality Inspection Center established
On November 20, according to the Shanghai Market Supervision Bureau, the State Administration for Market Regulation officially approved the Shanghai Motor Vehicle Inspection and Certification Technology Research Center Co., Ltd. to prepare for the establishment of the National Automotive Chip Quality Inspection and Testing Center. ...
BYD releases self-developed automotive chip using 4nm process, with a running score of up to 1.15 million
Chips are very important for mobile phones. Qualcomm, MediaTek, etc. supply mobile phone chips to the world and can make money from mobile phone manufacturers. Chips are also important for smart cars. ...
GEODNET launches GEO-PULSE, a car GPS navigation device
Should Chinese car companies develop their own high-computing chips?
Infineon and Siemens combine embedded automotive software platform with microcontrollers to provide the necessary functions for next-generation SDVs
Continental launches invisible biometric sensor display to monitor passengers' vital signs

MoreSelected Circuit Diagrams

Change More Related Popular Components

MorePopular Articles

MoreDaily News

Guess you like