Research on torque monitoring strategy of vehicle controller based on functional safety

［Abstract］ Torque control is the core function of vehicle control unit (VCU), and its safety is of vital importance. To this end, this paper conducts functional safety analysis based on ISO 26262 standard to solve the problem of unexpected torque output abnormality of VCU, and proposes a three-layer monitoring strategy for torque control based on EGAS architecture. Firstly, based on the definition of VCU related items, the vehicle safety integrity level and safety goals are determined through hazard analysis and risk assessment. Secondly, the functional safety requirements and technical safety requirements are derived by fault tree analysis method. Thirdly, according to the safety goals, a functional safety mechanism based on AURIX TC275 three-core main control chip and TLF35584 power monitoring chip is designed. In addition, CPU resources are allocated through a three-layer monitoring strategy to achieve the separation of basic functions and monitoring functions of torque control. Finally, processor-in-the-loop testing is carried out, including UDE debugging, UDS diagnosis and TLF35584 safe state control test. The results show that the three-layer monitoring strategy can realize the basic functions of VCU torque control and enter the safe state in time when a fault occurs, thereby achieving the safety goal.

Preface

As automobiles continue to develop towards intelligence and integration, the number and complexity of automotive electronic and electrical systems continue to increase [1]. In order to ensure the overall safety of automobiles under complex systems, the International Organization for Standardization (ISO) officially released the first edition of the road vehicle functional safety standard ISO 26262 in 2011 [2], and released the second edition of ISO 26262 in 2018 [3]. According to the definition in the ISO 26262 standard, functional safety means that there is no unreasonable risk caused by hazards caused by abnormal functional performance of electronic and electrical systems.

EGAS (electronic gas pedal) is the abbreviation of electronic throttle system, which consists of accelerator pedal, engine control unit, electronic throttle and sensor. The EGAS monitoring concept is a concept abstracted from the engine control system. The monitoring concept divides the engine control system into three layers. It was jointly proposed by several German automobile OEMs and the corresponding guidance documents were formulated [4]. The EGAS monitoring concept was created earlier than the ISO 26262 standard, but later the EGAS working group updated the monitoring concept according to the ISO26262 standard.

The vehicle control unit (VCU) is the core control unit of pure electric vehicles. It is responsible for analyzing the driver's intention and providing the expected torque to the motor control system [5]. Since torque control is the core function of the VCU and is directly related to the safety of the vehicle, if the VCU outputs unexpected torque during vehicle driving, it may cause life-threatening hazards. Therefore, improving the safety of the VCU torque control becomes a necessary and difficult problem. Xiong Zaihui [6] aimed at the safety goal of excessive VCU output torque, combined with the EGAS safety architecture, adopted the hardware design of the main chip + monitoring chip and called the software safety component of the hardware mechanism, but it did not involve the allocation of different CPU cores to different layers of tasks, and there was a coupling problem. Wu Kai [7] took the acceleration of the vehicle without pressing the accelerator pedal as an example, designed the EGAS monitoring system and modeled it for simulation testing, and verified the effectiveness of the monitoring system. However, the TC1782 main control chip used was a single-core processor, so it did not cover each layer of the three-layer architecture designed by it. Wu Jingbo et al. [8] proposed a multi-layer monitoring strategy based on the EGAS architecture to achieve the safety goal of avoiding unexpected torque changes. The monitoring layer was designed based on the dual-core chip MPC5744P, and the basic functional module and the safety module were separated through different core allocations. However, it did not fully consider the design and testing of the safety modules related to the software part of the processor monitoring layer.

In this regard, referring to the ISO 26262 standard, this paper further studies the functional safety of VCU torque control, and proposes a three-layer monitoring strategy based on the EGAS architecture based on the AURIXTC275 main control chip and the TLF35584 power monitoring chip, which allocates the three CPUs to the three-layer architecture to achieve independent operation and fully cover the three layers, realizing software and hardware decoupling. A fault handling strategy is also designed to enable the system to recover quickly or quickly enter a safe state.

This paper is structured as follows: First, the relevant items are defined with reference to the ISO 26262 standard. Then, the Automotive Safety Integrity Level (ASIL) and safety goals are determined through hazard analysis and risk assessment, and then the functional safety requirements and technical safety requirements are derived. Secondly, a three-layer monitoring strategy is proposed and designed in detail. Finally, a processor-in-the-loop test is performed to verify that it can achieve the safety goals.

1 Functional safety analysis

1.1 Definition of relevant items

First, the relevant items of VCU are defined. The purpose is to define and describe the relevant items from the vehicle level. The main functions of VCU are described as power system control, signal acquisition, safety status management, power management, signal output control and interface management. This article adopts the safety element independent of the environment (SEooC) development method. The assumed use environment of SEooC is the scope defined by the relevant item definition. The information requested by the driver can be provided outside the VCU, and the information reaches the required ASIL level. For the VCU torque control function, the relevant items are defined, as shown in Figure 1.

1.2 Hazard Analysis and Risk Assessment

According to the ISO 26262 standard, the Hazard and Operability Analysis (HAZOP) is applicable to hazard identification. Since the HAZOP method helps to structure and systematically check the operation of related items at the vehicle level, this paper adopts the HAZOP method to identify hazards. According to the simplified HAZOP method in SAEJ2980［9］, three guide words are selected: loss of function, more than expected, and less than expected. Therefore, the hazards of torque function abnormality mapped to the vehicle level are: unexpected vehicle acceleration, unexpected vehicle acceleration loss, unexpected vehicle deceleration, and unexpected vehicle deceleration loss.

Severity (S) represents the estimate of potential harm in a specific driving scenario, exposure probability (E) is determined by the corresponding scenario, and controllability (C) measures the difficulty of the driver or other road traffic participants to avoid the considered accident in the considered operating scenario. Taking into account the severity, exposure probability and controllability, the ASIL level is finally determined through Figure 2.

This paper selects common vehicle operation scenarios and performs HARA analysis on the VCU torque control function. The results are shown in Table 1.

1.3 Determination of safety objectives

The safety goal is the highest level of safety requirements of the HARA analysis results at the vehicle level. From Table 1, we can preliminarily obtain multiple safety goals for the VCU torque control function. According to the ISO 26262 standard, similar safety goals can be merged into one safety goal, and the highest ASIL level can be assigned to the merged safety goal [10]. Therefore, the safety goal is derived as "avoiding unexpected torque output abnormalities of the VCU", corresponding to the ASIL C level. The safe state is that the VCU is reset and an alarm is issued to notify the driver. When the reset cannot eliminate the fault, the torque output is interrupted. In addition, based on the empirical value and the VCU reset time, the fault tolerance time interval (FTTI) is set to 100 ms.

1.4 Functional safety requirements

When defining each functional safety requirement, the operating mode , FTTI, safe state, and functional redundancy can be considered. In order to formulate a complete and effective set of functional safety requirements, safety analysis methods such as fault tree analysis (FTA) and failure mode and effect analysis (FMEA) can provide support. Since the FTA method can systematically analyze the cause of the failure and can use easy-to-understand graphical expressions, this paper uses the FTA method for safety analysis, taking the unexpected torque output abnormality of the VCU as the top event, and analyzing from top to bottom to find the underlying fault events that violate the safety goals, as shown in Figure 3.

Functional safety requirements are derived from the safety goals and allocated to the system architecture design and external measures, as shown in Table 2.

1.5 Technical safety requirements

Technical safety requirements (TSRs) are necessary technical requirements for implementing FSRs. The purpose is to refine the FSRs at the item level to the TSRs at the system level. TSRs are derived from FSRs, as shown in Table 3. TSRs should be assigned to system architecture design elements as software or hardware as implementation technologies, so this paper assigns software and hardware types.

2 Software Architecture Design for Functional Safety

According to the requirements of the software architecture design part in ISO 26262, the software architecture design should express the software architecture elements and their interaction methods in the form of a hierarchical structure. In addition, considering that the EGAS concept provides a classic automotive functional safety system architecture solution and can realize hierarchical monitoring [11], this paper designs a VCU torque control 3-layer monitoring strategy based on the EGAS architecture. Since different chips have different transplantation difficulties for the 3-layer architecture, in order to fully cover the 3-layer architecture and improve the independence of each layer, this paper will be based on the AURIX TC2753 core control chip and the TLF35584 power monitoring chip, which better conforms to the designed 3-layer architecture.

2.1 AURIX TC275 and TLF35584

AURIX TC275 (abbreviated as TC275) adopts a 32-bit TriCore processor architecture, and the three CPUs can perform tasks in an independent manner. The safety management unit (SMU) of TC275 is the core component of the safety architecture, providing a common interface to manage the behavior of TC275 when there is a fault. SMU centralizes all alarm signals related to different hardware and software safety mechanisms. Alarm signals can report internal faults to the external environment through the fault signal protocol (FSP) to control the safety status of the system [12]. The default fault signal protocol is an error pin.

TLF35584 is a power chip for secure microprocessors. It has independent voltage monitoring with reset function and configurable functional watchdog. Through the SPI interface with the main control chip, the chip can be flexibly configured and controlled [13]. It can be used as an independent monitoring component to monitor the TC275 software behavior.

2.2 Layer 3 Monitoring Strategy

Based on the EGAS 3-layer architecture, a 3-layer monitoring strategy is designed for the torque control function of the VCU. The 3-layer architecture is the function layer (Level 1), the function monitoring layer (Level 2) and the controller monitoring layer (Level 3), as shown in Figure 4.

The functional layer (Level 1) mainly implements the basic torque control function . It analyzes the driver's needs based on information such as pedal position, gear position, vehicle speed, actual motor speed, etc., calculates the target torque, and finally outputs the control signal. In addition, there are some diagnostic functions, such as the rationality check of the pedal signal, etc. Based on the diagnostic results, Level 1 will also execute the corresponding fault response.

The functional monitoring layer (Level 2) monitors Level 1 through redundant software logic. The overall idea is to estimate the driver's target torque using another algorithm independent of Level 1, and compare the target torque with the actual torque based on the actual motor torque output fed back to the VCU by the motor controller [4]. If the difference between the two is greater than a predefined threshold and lasts for more than a certain period of time, the system will enter a safe state [TSR-06]. In addition, a second independent information collection and processing path is used as a redundancy for Level 1 [TSR-01, TSR-02, TSR-04, TSR-05].

The controller monitoring layer (Level 3) consists of two parts: an independent monitoring module in hardware and monitoring software in the functional controller. This article uses TC275 as the functional controller and TLF35584 as the monitoring controller. TC275 and TLF35584 communicate through SPI. TLF35584 periodically asks TC275 questions, and TC275 answers within the specified time [TSR-08]. If TLF35584 gets an incorrect answer, it will repeatedly send the same question and start the fault counter. In order to detect the latent failure of TLF35584, TC275 will periodically send an incorrect answer to test whether the monitoring function of TLF35584 is normal. In addition, voltage monitoring [TSR-07], memory test [TSR-03], shutdown path test and A/D conversion test are also included.

The three CPUs of TC275 are two lock-step CPUs (CPU0 and CPU1) and one non-lock-step CPU (CPU2). In addition, CPU0 is a high-efficiency, low-power architecture, while CPU1 and CPU2 are high-performance architectures. According to the three-layer architecture designed in this paper, the three CPUs are now allocated. First, since CPU0 is a high-efficiency, low-power architecture with a lock-step core, it is allocated to Level 1 to implement basic functions, ensure efficient execution of torque control functions, and reduce power consumption and improve reliability. Secondly, since CPU1 is a high-performance architecture with a lock-step core, it is allocated to Level 2 to implement the monitoring function of Level 1, ensuring that the comparison and verification of the target torque and the actual torque can be quickly executed and the fault tolerance can be improved through lock-step monitoring. Finally, since CPU2 is a high-performance architecture, it is allocated to the Level 3 software part to ensure faster execution of A/D conversion tests, memory tests, etc.

2.2.1 Level 1 Design

Under the premise of ensuring that the pedal torque demand is valid, such as the motor is enabled, not in charging state, and the vehicle is in Ready state, the pedal torque demand can be determined based on the pedal opening, gear position, vehicle speed, and actual motor speed.

There are many methods to calculate pedal torque, such as acceleration method, dynamic model method, table lookup method, etc. According to the application in the actual project, in order to improve the calculation efficiency and simplify the calculation process, Level 1 chooses the table lookup method to calculate the pedal torque. The actual motor speed is obtained by the CAN message sent by the MCU to the VCU, and the maximum torque corresponding to the actual motor speed is determined by the table lookup linear interpolation method, and then the pedal torque is obtained by multiplying the obtained maximum torque with the pedal opening.

When Level 2 cannot independently perform fault responses, it must rely on Level 1 to implement and monitor them. The Level 2 software must also arrange the boundaries defined according to the relevant items. In this article, the pedal torque will be considered as the target torque.

2. 2. 2 Level 2 Design

Level 2 uses a different target torque calculation method from Level 1. For the purpose of simplicity and higher accuracy than the table-based linear interpolation method, a curve fitting method is used to obtain the maximum torque at the actual motor speed. The calculated target torque is compared with the actual motor output torque fed back to the VCU by the motor controller. When the difference between the actual output torque and the target torque exceeds 5% [14], different fault responses are enabled, as shown in Table 4.

When Level 2 cannot independently perform fault response, it must rely on Level 1 to implement and monitor it. Level 2 software must also arrange checkpoints to support Level 3 to monitor program flow, and Level 2 memory areas will be periodically monitored by Level 3.

2.2.3 Level 3 Software Design

The design of the safety function module for the software part in Level 3 mainly includes the following contents.

Question and answer monitoring. Using the functional watchdog function of TLF35584, TLF35584 asks questions and expects to get the correct answer from TC275 within a defined time period. If the answer is wrong or the correct answer is received at the wrong time, it is considered an incorrect answer. In addition, in order to test that the function of TLF35584 is in a normal state, TC275 will give incorrect answers within a certain time interval. Wrong answers will increase the functional watchdog fault counter. When the count exceeds the threshold, TLF35584 will trigger a VCU reset.

Shutdown path test. Mainly to ensure safe shutdown in case of failure. The test is performed before each vehicle start, and the motor can only be authorized to run after the test passes. If the shutdown path fails, the VCU will remain in the reset state until the motor can be authorized to run.

A/D conversion test. Mainly to ensure that the A/D conversion function is normal. If the A/D conversion function fails, it will cause abnormal analysis of the driver's torque demand. At this time, TC275 will be reset and the fault will be eliminated, otherwise the vehicle cannot start.

Memory test. Ensure that the RAM and FLASH modules inside TC275 can work properly, and improve the reliability and safety of TC275. Before each vehicle start, a RAM and FLASH test should be performed, and the vehicle is allowed to start only when no faults are found. In the memory test, at least addressing errors, address buffer overflow errors, and bit flip errors need to be detected.

2.2.4 Alarm Event

The SMU of TC275 has a flexible alarm configuration function. This paper sets the corresponding alarm events from the software and hardware levels for the designed 3-layer control architecture, as shown in Table 5.

2.2.5 Unified diagnostic service

Unified Diagnostic Services (UDS) is part of the ISO 14229 standard [15] , which defines different diagnostic services and message formats that allow diagnostic tools to interact with the vehicle's electronic control units.

When the VCU detects a fault, it will store the corresponding fault code, which is the diagnostic trouble code (DTC). Since the DTC information reading service allows the client to read the DTC status information stored in the server, this article uses the DTC information reading service with a service ID of 0x19 to obtain the information stored when the VCU fails. The 0x19 service defines 28 sub-functions, and different diagnostic information can be obtained according to different sub-functions. This article uses the 0x02 sub-function to read the DTC information through the DTC status mask.

DTC can reflect the fault location and fault type. This article follows the ISO 15031-6 protocol [16] to define the DTC format, using an encoding method of two root bytes and one fault type byte. The DTC of the SMU fault is now defined as P102046.

2.2.6 Level 3 Hardware Design

The Error Pin of TC275 is connected to the ERR pin of TLF35584 . When an Alarm event occurs, the SMU of TC275 reports the internal fault to TLF35584 through ErrorPin. When the safety status signals SS1 and SS2 of TLF35584 are both low, the VCU will be kept in reset state from the hardware level.

Alarms are divided into software alarms and hardware alarms. When an alarm occurs, the software alarm needs to call a function in the software to set the alarm, while the hardware alarm is automatically set by the chip hardware self-detection and triggers subsequent actions. When the alarm is generated, an interrupt will be entered. First, the function is called to clear the alarm state, and then the function is called to release the FSP. Secondly, the fault count is increased by 1 and stored in the defined Flash, where the initial value of the fault count is 0. Thirdly, the set DTC state function is called to set the defined SMU fault to the FAILED state. Finally, the software reset of the VCU will be triggered. When the fault count value exceeds 10 times and the alarm occurs again, after entering the interrupt clear alarm state, it will enter the While infinite loop, waiting for the SS1 and SS2 signals to change from high level to low level, and finally keep the VCU in the reset state.

The ERR pin is a high-low switching signal in normal state. When the high-low switching stops and remains at a low level or high level, it will be detected as an error. The response of the ERR pin can be divided into two types: immediate response and recovery delay response. This article will use the recovery delay response mechanism of the TLF35584 chip as the safety state control of the Level 3 monitoring module.

When the alarm occurs, the ERR signal stops switching and remains at a low level. After the detection time is exceeded , an interrupt will be generated to indicate the start of the recovery delay time . If the alarm occurs for longer than , that is, after reaching , it will be pulled to a low level, and then pulled to a low level after the optional delay time , as shown in Figure 5. If the alarm occurs for shorter than , that is, before reaching, the ERR signal starts switching again, then SS1 and SS2 will remain at a high level, as shown in Figure 6. Among them, the configuration is 10ms and the configuration is 0 ms , that is, the SS1 and SS2 pins are in the same situation.

3 Processor-in-the-Loop Testing

According to the software requirements of ISO 26262, this paper conducts processor-in-the-loop (PIL) testing on the designed three-layer monitoring architecture.

3.1 Code writing and burning debugging

First, the Level 1 and Level 2 control strategies are built in modules through Matlab/Simulink , and the code is generated with the help of Simulink's code generation tool Embedded Coder.

Secondly, use the HighTec compiler to write the HighTec project that needs to be burned into the VCU, and configure the code generated by Simulink into it. When generating the code, all modules are generated in one function, and there is a deep coupling relationship. In order to achieve the purpose of stratification, the function needs to be decoupled. After decoupling, it is divided into two program code segments for Level 1 and Level 2. The function corresponding to Level 1 is called in CPU0, and the function corresponding to Level 2 is called in CPU1. The calling cycle of both is 10 ms.

Finally, use the PLS/UDE tool to burn the HighTec compiled code into VCU and debug it. Breakpoints can be reached in both functions corresponding to Level 1 and Level 2, and multiple variables are also normal values, indicating that the program has been successfully run in VCU.

3.2 Level 1 and Level 2 Testing

By using the Time/Value Chart function in UDE, we can observe the changes of variables such as pedal torque, actual motor torque and limited vehicle speed over time.

Taking the accelerator pedal torque as an example, the accelerator pedal torque values ​​of Level 1 and Level 2 are compared, and the results are shown in Figure 7. As can be seen from the figure, the accelerator pedal torque values ​​of the two paths are basically the same, and the deviation is within 2 N·m, so the pedal torque calculated by Level 2 can be used as a redundant calculation for Level 1.

The following fault injection test is conducted to verify whether the Level 2 will respond according to the definition in Table 4 when a fault occurs. The fault injection method is to perform gain processing after the pedal opening is collected. In order to cover the three faults, the typical values ​​in the three fault ranges are selected, and the following settings are set: Fault injection 1 is a level 3 fault, that is, the gain is selected as 1.08 times; Fault injection 2 is a level 2 fault, that is, the gain is selected as 1.15 times; Fault injection 3 is a level 1 fault, that is, the gain is selected as 1.30 times. The results are shown in Figure 8. Under normal conditions, the pedal torque is basically consistent with the actual torque, and the vehicle speed is limited to 140 km/h. When fault injection 1 is used, the calculated difference between the actual motor torque and the pedal torque is 8%, and the vehicle speed limit is 80 km/h, which is a level 3 fault; when fault injection 2 is used, the calculated difference between the actual motor torque and the pedal torque is 15%, and the vehicle speed limit is 30 km/h, which is a level 2 fault; when fault injection 3 is used, the calculated difference between the actual motor torque and the pedal torque is 30%, and the vehicle speed limit is 0 km/h, which is a level 1 fault. In summary, the fault injection can respond in time and meet the requirements, so the test passed.

3.3 UDS diagnostic test

This paper uses the ISOLAR AUTOSAR configuration tool and CANoe bus detection tool to perform UDS diagnostic testing. First, use the ISOLAR AUTOSAR tool to configure the DTC, and configure the severity of the DTC to check immediately when a fault occurs (system fault level), as shown in Figure 9. In addition, code must be generated after the configuration is completed.

Secondly, the generated code is transplanted into the HighTec project. It is mainly a function to set the event status. When an SMU Alarm event occurs, this event status function sets the SMU fault to the FAILED state, and when the SMU is in normal state, this event status function sets the SMU fault to the PASSED state.

Finally, CANoe is used for UDS diagnosis. When an Alarm event occurs, the input service request is 0x19, 0x02, 0x08, and the positive answer is 0x59, 0x02, 0xFF, 0x10, 0x20, 0x46, 0x2F, where 0x102046 is the DTC, indicating that the SMU is faulty, and 0x2F represents the status of the DTC, indicating that the DTC test has been completed and the DTC fault code has been detected.

3.4 TLF35584 safety status control test

In order to verify the safety state control reaction of TLF35584 when the SMU of TC275 generates an alarm , two situations are tested: the alarm generation time is shorter than the recovery delay time and the alarm generation time exceeds the recovery delay time.

When the SMU generates the alarm shown in Table 5, the ERR pin and the SS1 and SS2 pins are measured using an oscilloscope when the alarm occurs for a period longer than the recovery delay time. The results are shown in Figure 10. The yellow line represents ERR, and the green line represents SS1 and SS2. As can be seen from the figure, when the SMU is in a normal state, the ERR pin is a square wave signal with a 50% duty cycle, and SS1 and SS2 are high. When the alarm occurs, the ERR pin stops switching between high and low levels and is pulled to a low level. SS1 and SS2 are pulled to a low level after a certain delay. Since it corresponds to Figure 5, the test passes.

The situation where the alarm occurs when the time is shorter than the recovery delay time is shown in Figure 11. The yellow line represents ERR, and the pink line represents SS1 and SS2. The green line represents an IO level that is pulled up and down to demonstrate the sum of the detection time and the recovery delay time. This IO is high in normal state, and the level is pulled down when the alarm occurs, and it is restored to a high level after the FSP is released. It can be seen from the figure that when the alarm occurs, the ERR pin stops switching between high and low levels and is pulled to a low level, but because the ERR pin restarts switching between high and low levels during the recovery delay time, the SS1 and SS2 pins are always at a high level. Since it corresponds to Figure 6, the test passes.

4 Conclusion

In order to achieve the safety goal of "avoiding unexpected torque output abnormality of VCU", this paper designs a three-layer monitoring strategy for torque control based on EGAS architecture based on the three-core architecture of TC275 and the safe state control of TLF35584. First, based on the definition of related items, HARA analysis is carried out to determine the safety goals and their ASIL levels, and then the functional safety requirements and technical safety requirements are derived. Secondly, each layer in the three-layer architecture is designed in detail, and each layer is assigned a CPU to achieve full coverage and decoupling as much as possible. In addition, a fault handling strategy is designed to enable the system to enter a safe state when a fault occurs. Finally, the processor-in-the-loop test is carried out: the UDE debugging test of Level 1 and Level 2 shows that the designed strategy can respond quickly to faults and enter the graded speed limit state; the UDS diagnosis shows the effectiveness of the alarm and can read the fault of the SMU; the TLF35584 safe state control test shows that the TLF35584 can effectively respond to the alarm of the TC275 SMU and perform safe processing. In summary, it is proved that the designed three-layer monitoring strategy can achieve the defined safety goals.

References

［ 1］ SHAO Wenbo, LI Jun, ZHANG Yuxin, et al. Key technologies to ensure the safety of the intended functionality for intelligent vehicles［J］. Automotive Engineering, 2022, 44（9）：1289-1304.

[2] Road vehicles-functional safety: ISO 26262: 2011［S］. Interna⁃ tional Organization for Standardization, first edition. 2011.

[3] Road vehicles-functional safety: ISO 26262: 2018［S］. Interna⁃ tional Organization for Standardization, second edition. 2018.

［4］ EGAS Workgroup. Standardized EGAS monitoring concept for gasoline and diesel engine control units. version 6.0［S］.2015.

［ 5］ SASETECH. White paper on automobile functional safety［M］. 2023.

［ 6 ］ XIONG Zaihui. Development and implementation of a plug in hybrid vehicle controller based on functional safety ［D］. Hefei: Hefei University of Technology, 2021.

［ 7 ］ WU Kai. Design and implementation of functional safety ECU monitoring system ［D］. Chengdu： University of Electronic Science and Technology， 2015.

[8] WU Jingbo, LU Yaozhen, LI Mingming, et al. Research on torque monitoring strategy for new energy vehicles based on ISO26262［J］. Modern Electronic Technology, 2021, 44(11): 87-92.

[9] SAE J2980. Considerations for ISO 26262 ASIL hazard classification ［S］. SAE International, 2018.

［ 10］ WANG Wei. Development and implementation of electric vehicle controller based on functional safety［D］. Changsha：Hunan University，2018.

[11] GROßMANN M, HIRZ M, FABIAN J. Efficient application of multi-core processors as substitute of the EGAS (Etc) monitoring concept [C]. 2016 SAI Computing Conference (SAI). IEEE, 2016: 913-918.

［ 12］ Infineon Technologies. AURIX TC27x D-Step 32-bit single-chip microcontroller user's manual［ Datasheet］［M］.V2.2， 2014.12.

［13］ Infineon Technologies.TLF35584 multi voltage safety micro pro⁃ cessor supply［Datasheet］［M］. V2.0, 2017.03.16.

[14] ZHANG Jiaji, LI Qiang, WANG Yanbo, et al. Safety analysis and design of pure electric bus VCU based on ISO 26262［J］. Auto Electric Parts, 2019（10）：13-16.

[15] Road vehicles-unified diagnostic services (UDS)-part 1: application layer: ISO14229-1［S］.2020.

[16] Road vehicle-communication between vehicle and external equipment⁃ ment for emissions-related diagnostics-part6: diagnostic trouble code definitions: ISO15031-6［S］.2015.

END