Development of body domain controller based on ISO 26262

Abstract ： The body domain controller using a single microcontroller unit (MCU) lacks diagnostic coverage for multi-point fault failures due to the lack of external chips to monitor the working conditions of the main MCU, which affects the potential failure rate. In addition, due to the insufficient chip pins of a single MCU, the single-point failure failure rate is greatly increased after the use of a check chip, making it difficult to meet the requirements of functional safety level B. In order to meet the requirements of functional safety, a body domain controller with a dual MCU architecture based on the domestic automotive chip AC78406 is designed. The controller design can eliminate the hardware random failure rate of the multi-way check chip, while increasing the diagnostic coverage of MCU failures, thereby improving the functional safety level.

0 Preface

The increasing number of functions in the body of new energy commercial vehicles has brought new challenges to body control and vehicle wiring harnesses. In order to reduce the number and cost of controllers and reduce the complexity of the vehicle wiring harness, it is necessary to concentrate multiple independent controllers on one controller, and the concept of domain controller is proposed [1] . The original body domain controller design of XCMG Automobile uses a single microcontroller unit (MCU) as the main control processor. After integrating more functions, the original design can no longer meet the functional safety requirements. Therefore, this paper considers the use of a dual MCU collaborative control design. The dual MCU design has been widely used in vehicle control or active safety core devices such as vehicle controllers and anti-lock braking systems. Its purpose is to increase fault redundancy. When the main MCU fails, the slave MCU takes over control, so that some core functions can continue to work and avoid vehicle loss of control [2-5] .

This paper adopts the master-slave MCU method, modifies the original body domain controller solution, and designs a set of master-slave MCU communication protocols, adding diagnostic functions to the protocol. The two MCUs can monitor each other's working status. If the other party crashes or works abnormally, the MCU reset can be initiated and the fault information can be recorded, which not only meets the functional design requirements, but also improves the functional safety level.

1 Body domain controller design requirements

The body domain controller (BDC) of new energy commercial vehicles integrates the body control module (BCM), air conditioner (AC), pilot door control module (PDCM) and central gateway controller. The body control module is responsible for multiple functions such as hazard warning lights, sunroof, door control, reading lights, sleep lights, horn, safety indicator lights, and driving lights [6] ; the AC controller is responsible for the air conditioning function of the cab; the pilot door control module is responsible for the window lifting and rearview mirror adjustment light functions; the central gateway controller is the hub for information transmission between different networks and is responsible for coordinating data exchange, protocol conversion, and fault diagnosis between different CAN bus networks and other data network protocols.

In order to save the number and cost of controllers, reduce the wiring harness of the whole vehicle, and simplify the network structure of the whole vehicle, this paper designs a body domain controller that integrates the central gateway, air-conditioning controller, body controller, and co-pilot door and window controller, and optimizes it based on functional safety.

2 ISO 26262 Functional Safety Requirements

ISO 26262 is a functional safety standard developed for the development and production of automotive electronic systems. It applies to all devices consisting of electrical, electronic and software elements that provide safety-related functions.

2.1 Confirmation of functional safety objectives

ISO 26262 requires the use of hazard analysis and risk assessment (HARA) to identify hazards caused by product functional failures, classify hazardous events, and then define corresponding safety goals (SG) to avoid unacceptable risks [7] . Each safety goal is assigned a corresponding automotive safety integrity level (ASIL). ASIL is divided into four levels from low to high: A, B, C, and D. The higher the level, the higher the risk of hazardous events.

Through vehicle hazard analysis and risk assessment, the safety targets of all relevant functions in the vehicle body domain are obtained. This paper takes some lighting and wiper control functions in Table 1 as examples for explanation.

Table 1 Summary of safety goal

2.2 Confirmation of safety mechanism and diagnostic coverage of components

The ISO 26262 standard divides diagnostic coverage into three levels: low, medium, and high, with the coverage of each level reaching 60%, 90%, and 99%, respectively [8] .

The controller MCU uses the domestic automotive grade chip AC78406, which is based on the ARM CortexM4F core, has 144 pins, contains 1.128 MB of Flash and 124 KB of system SRAM, and its functional safety complies with ASIL B. The AC78406 chip has core self-test, access protection, security management unit, internal error checking and correction (ECC) and cyclic redundancy check (CRC), clock and power monitoring mechanisms, and has a digital readback function to check the correctness of data transmission.

To prevent random hardware failures in the 5 V power supply module on the board, an additional limp home power supply is added. When a power supply failure occurs, the limp home power supply starts, and the hardware mechanism directly turns on the warning light and turn signal, etc., to remind the driver.

The high-side driver uses Texas Instruments' TPS1H100, which has overload protection and short-circuit protection functions, as well as thermal shutdown/thermal regulation ground loss protection and power loss protection with self-recovery functions; in addition, it has a diagnostic pin that can detect open circuit, short circuit, overload and ground short circuit, as well as diagnose current limiting.

Table 2 shows the safety mechanisms and diagnostic coverage of components.

Table 2 Signal processing security mechanism and diagnostic
coverage

2.3 Hardware parameter requirements for functional safety indicators

Hardware functional safety confirmation mainly measures whether the corresponding ASIL requirements are met through hardware architecture indicators. The industry generally conducts failure mode effect and diagnostic analysis (FMEDA) on the circuit. According to the failure and failure impact of each component in the circuit diagram, a hardware indicator calculation table is compiled to calculate three parameters: single-point fault metric (SPFM), latent fault metric (LFM), and probabilistic metric for random hardware failures (PMHF) [9-10] . The specific calculation formula is as follows:

(1)

(2)

Where: the subscript “SR,HW” indicates the safety-related hardware element; λ is the safety-related failure rate; M SPF is the single-point fault metric; M LF is the latent fault metric; M PMHF is the random hardware failure probability metric; λ SPF is the single-point fault failure rate; λ RF is the residual fault failure rate; λ MPF,Latent is the potential multi-point fault failure rate; T is the product life cycle.

The unit of failure rate is FIT (failures in time), 1 FIT means that the device fails once every 10 9 hours of operation. A high single-point failure metric means that the proportion of single-point failures and residual failures of the related hardware is low, so the higher the value of the single-point failure metric, the better.

The requirements of functional safety on hardware indicators are shown in Table 3.

Table 3 Hardware metrics

Table 3 Hardware index

3 Calculation of hardware architecture indicators for single MCU solution

3.1 Single MCU Solution Hardware Failure Metric Calculation

The following takes safety goal SG1 (controller responds correctly to the turn signal) as an example and combines the system's diagnostic measures to perform hardware failure analysis. The turn signal control circuit is shown in Figure 1.

Fig.1 Turn signal control circuit under a single MCU

The turn signal switch is used as a signal input, and is connected to the MCU after a pull-up operation. The MCU output pin drives the high-side driver. When the MCU detects that the switch is at a low level, it sets the control output pin to a high level, driving the high-side driver to output a high voltage to the lamp group. TPS1H100 has a diagnostic pin that outputs a current diagnostic signal, and this pin is grounded through a resistor. The MCU determines the fault condition of the high-side driver based on the voltage feedback of this pin. Due to the insufficient pins of the domain controller main control MCU, the input needs to use a check chip.

When R6 is short-circuited to ground, U1 has an overcurrent fault, the fault feedback signal will be pulled high, and the output will be turned off. When U2 fails, due to the lack of sufficient diagnostic measures, the single point failure rate of this failure is high. When the MCU fails such as ECC error, external clock instability, etc., the use of safety mechanisms SM1~4 can effectively detect such faults.

According to the failure modes and distribution laws of electronic components listed in ISO 26262-5, the applicable safety mechanisms and their diagnostic coverage under each failure mode, and referring to the standard provisions on the failure rate of electronic components in GB/T 37963-2019[11], the hardware indicator calculation table of the turn signal control circuit shown in Table 4 was compiled.

Table 4 Hardware index calculation
table of turn signal control circuit under single MCU

3.2 Conclusion of hardware random failure analysis

The calculation results of hardware indicators are shown in Table 5. The single point fault metric is 88.5%, and the potential fault metric is 41.1%, which only meets the requirements of ASIL A.

Table 5 The result of hardware index calculation of turn signal control circuit under single MCU

The above results show that the single MCU design cannot meet the ASIL B target. The reason is that there is no external chip to monitor whether the main control MCU is working properly, resulting in a lack of coverage of multi-point failures, affecting the potential failure rate; secondly, after the body domain controller integrates multiple functions, the single MCU has insufficient pins and must use a multi-way check IC to meet the design requirements, resulting in a significant increase in the single-point failure rate, thus failing to meet the technical safety goals.

4 Functional safety optimization

4.1 Functional Safety Optimization Circuit

In order to solve the above problems, a higher specification MCU can be used as the main control chip. For example, Infineon's TRAVEO T2G series of body control dedicated chips and NXP's S32K344 series meet the design requirements, but the prices of both are far higher than AC78406, and the cost is too high.

This paper proposes an effective way to improve the functional safety of the vehicle body domain controller. In order to eliminate the hardware random failure rate of the multiplexer chip and increase the diagnostic coverage of MCU failures, and ultimately meet the functional safety goals, an additional identical MCU is selected as the slave MCU, and a set of master-slave MCU communication protocols are designed, and diagnostic functions are added to the protocol. The two MCUs are independently connected to the bus diagnostic network, supporting diagnostic reading and clearing. Compared with using high-specification imported chips, using two domestic MCUs is also more cost-effective.

According to the above design, the body domain controller adds the SM7 safety mechanism, that is, the dual MCUs monitor each other, and the diagnostic coverage is set at 90%.

The new turn signal control circuit is shown in Figure 2. The two MCUs are directly connected to each other's reset pins, and the external IO signal is directly driven by the MCU. Due to the addition of the SM7 safety mechanism, the two MCUs can monitor each other, so when one of the MCUs fails due to a common cause, the other MCU can detect it in time and reset the system to a safe state, which has high robustness and avoids single point failure caused by failure of the multi-way check chip.

Fig.2 Turn signal control circuit under dual MCU

Compared with Figure 1, Figure 2 reduces the component U2 and adds a slave MCU. According to the new control schematic and the newly added diagnostic conditions, the hardware indicators of the turn signal control circuit are recalculated. Due to the addition of the diagnostic mechanism SM7, the master and slave MCUs can be covered by this mechanism when single-point failures and potential multi-point failures occur. After calculation, the improved hardware indicator results are shown in Table 6.

Table 6 The hardware index calculation result of turn signal control circuit under dual MCU

It can be seen from Table 6 that the single point fault metric of the optimized turn signal control system hardware architecture is 94.7%, and the potential fault metric is 78.8%. Referring to the ISO 26262 hardware architecture indicator requirements, this indicator meets ASIL B.

Through the analysis in the previous article, adding an additional MCU can improve the single-point fault metric and potential fault metric and reduce the random hardware failure probability metric at only a small additional cost, thereby increasing the functional safety level from ASIL A to ASIL B, thereby improving the reliability of the body domain controller.

4.2 Hardware Design Verification

ISO 26262 recommends three hardware integration test methods, namely functional test, fault injection test, and electrical test. Here, fault injection test is used to add test points to the circuit, manually simulate the occurrence of faults, and use an oscilloscope to monitor the controller output signal to verify the integrity and correctness of the safety mechanism. Taking TPH1S100 as an example, in normal operation, the diagnostic pin will feedback the output in the form of current. When a short circuit to ground occurs, the diagnostic pin feedback will exceed the normal range. The MCU can use this pin to determine the working status of the driver chip. When a short circuit fault is manually triggered at the R6 position, the diagnostic pin level is shown in Figure 3, which meets the design requirements.

Fig.3
Fault injection testing

5 Master-slave MCU communication protocol design

5.1 Communication Process

In order to ensure the accuracy and real-time performance of the master-slave MCU communication, a communication protocol between the master and slave MCUs is designed based on the serial peripheral interface (SPI) communication, as shown in Figure 4. The master MCU is the host and the slave MCU is the slave. Since SPI is full-duplex communication, the master and slave MCUs can exchange data with each other at the same time, and the maximum timeout of all communications is 200 μs.

Fig.4 Communication
protocol

As shown in Figures 5 and 6, the communication is divided into two groups of data packets, read and write. Both groups of data packets are 16 bytes, including the sequence number, data frame and cyclic redundancy check. The write data packet is sent from the master MCU to the slave MCU for the control of the slave MCU digital output and pulse width modulation (PWM) duty cycle; the read data packet is replied from the slave MCU to the master MCU for returning the read value and error status of the slave MCU digital input.

Fig.5 Write data
packets

Fig.6 Read data
packets

As shown in Figure 7, it can be clearly seen from the waveform obtained by using a logic analyzer that the communication process between the master and slave MCUs is consistent with the designed communication protocol.

Fig.7
Master-slave MCU communication process

5.2 Communication fault diagnosis

The SPI-based communication protocol developed in this paper has two types of faults: communication timeout fault and verification error fault.

Communication timeout fault: In the master-slave MCU communication, when the master MCU does not receive the reply information from the slave MCU for two consecutive cycles, the slave MCU communication times out, the master MCU resets the slave MCU, clears the error counter, and records the fault information.

Checksum error: Checksum error is divided into sequence number checksum, data frame checksum and CRC checksum. Sequence number checksum is a counter included as part of the information in each individual safety-related frame transmitted on the bus. The counter value increases when each consecutive frame is generated. The receiver can then detect any frame loss or frame failure by verifying whether the counter value is increased by 1. Bit 0 of each byte of the data frame is an odd check bit. The last 2 bytes of the read and write data packet are the CRC checksum. The above check methods can ensure the stability and security of the master-slave communication process.

6 Hardware-in-the-Loop Simulation Test

6.1 Hardware-in-the-Loop Simulation System

This paper uses a hardware in loop (HIL) simulation test system based on Vector equipment to perform functional testing on the vehicle domain controller. Hardware in the loop simulation is a semi-physical closed-loop simulation method that connects the real controller to a virtual modeled environment to test and verify various functions, thereby improving development quality and shortening the R&D cycle [12] . The test cabinet consists of a power management module, a programmable power supply, a conditioning power supply, an industrial computer, and a series of Vector function boards [13] . During the test, the controller is connected to the HIL cabinet through an expansion rack, and a test project is built using the bus simulation and test tool CANoe as a carrier to achieve real-time signal interaction between the controller and the HIL cabinet; the input and output signal buttons created on the test project panel are used to control the HIL cabinet to simulate the real car to send switch signals to the controller, and the output response signal of the controller is displayed to the host computer through the cabinet for observation of the results. The LabCar bench is a physical device close to the size of a real car, in which various devices are arranged according to the structure of the real car [14] . The physical construction is carried out on the LabCar bench according to the positions of the real car parts, wiring harnesses, batteries and other electrical components. The controller that has passed the HIL cabinet verification is installed on the LabCar for testing to check whether components such as the lights and turn signals can work normally.

6.2 Construction of vehicle body domain controller test platform

As shown in Figure 8, the one-button start controller, main driver door control, tire pressure sensor, vehicle controller and other message nodes are added to the simulation setting window, and they are connected through the bus card. According to the vehicle communication rules, the test system sends bus messages through the simulation node and uses the digital interface to simulate the vehicle signal, and checks whether the controller meets the functional design requirements by judging the response of the controller under test.

Fig.8
Simulation setup window

According to the functions of the vehicle body domain controller and the specific HIL test conditions, a test panel is built, which includes the control of the commercial vehicle's headlights, turn signals, cab interior lights, wipers, sunroofs, air conditioners and other functions. In addition, the control signals of each actuator are also made on the panel to facilitate timely observation of the response of the controller control signal.

6.3 Body Domain Controller Function Test

After the test project is built, write test cases based on the functional specifications of the body domain controller, and then verify the functions of the body domain controller one by one through the test panel built by the above test platform. This process can not only verify the correctness of the functional logic of the application layer, but also verify the effectiveness of the controller's bottom layer for input and output digital signals, analog signals, PWM speed control signals and CAN signal processing. Table 7 lists all the functional test items of the domain controller. Write the test items into scripts according to the use cases for automated testing, and only analyze the test results at the end, which can save a lot of testing time. The results of the CANoe test script are shown in Figure 9.

Fig.9 Test script execution
result

Table 7 Controller function test items

After testing, the above functions of the body domain controller meet the design requirements, and the application layer functions of the body domain, door control and air conditioning can be executed correctly. The processing capabilities of this controller for digital signals, analog signals, PWM signals and CAN signals involved in the domain controller functions meet the design requirements, and the processing of application layer logic meets the expected goals.

7 Conclusion

Based on the actual needs of enterprises, this paper proposes a design method for a body domain controller with a dual MCU architecture while taking into account cost and practicality. By using injection testing and HIL functional testing, it is proved that the controller meets the design requirements. This solution has good reliability and engineering practicality, and provides new ideas for the design of future body domain controllers.

references :

[1] ZOU Y, SUN WJ, ZHANG XD, et al. Study on the technology development of multi-domain electrical and electronic architecture for intelligent networked vehicles[J]. Automotive Engineering, 2023, 45(6): 895-909. (in Chinese)

[2] QIN L. Analysis and design of the function safety for pure electric vehicle controller[D]. Chongqing: Chongqing University of Posts and Telecommunications, 2019. (in Chinese)

[3] DU D Q. Development and testing of VCU fault diagnosis system for pure electric vehicle[D].Changchun:Jilin University,2016.(in Chinese)

[4] WANG WD, ZHANG W, JIANG F. Research on the fault diagnosis technique of automotive integral ABS/ASR/VDC systems based on dual MCU[J]. Microcomputer & Its Applications, 2010, 29(22): 79-82. (in Chinese)

[5] SONG X J. Hardware design of vehicle control unit for EV based on dual MCU[J]. Auto Electric Parts, 2014(5):33-36. (in Chinese)

[6] LU W F. Research on the development of EV vehicle control unit according to ISO 26262 standard[D]. Chengdu: Xihua University, 2018. (in Chinese)

[7] YANG L, WANG Q, SUI JP, et al. Research on FMEDA accuracy based on ISO 26262[J]. Automobile Technology, 2020(7): 58-62. (in Chinese)

[8] WANG X Y. Study on functional safety technology of vehicle control unit system for pure electric vehicle[D].Tianjin:Hebei University of Technology,2018.(in Chinese)

[9] BHAVANA R,INDELA O,YARAGATTI M S.Functional safety requirements of traction inverter in accordance to ISO 26262[J].E3S Web of Conferences,2020,184:01062.

[10] SU C X. Hardware development of electronic control platform for shift-by-wire system based on functional safety standard[D].Hangzhou:Zhejiang University,2022.(in Chinese)

[11] GUO JZ, ZHANG J, MIN R, et al. Design of power supply system for automobile instrument based on functional safety[J]. Chinese Journal of Electron Devices, 2021, 44(6): 1339-1345. (in Chinese)

[12] DING ZH, LUO F, SUN Z C. Development of vehicle fault diagnostic system based on CANoe[J]. Automotive Engineering, 2007, 29(5): 449-452. (in Chinese)

[13] Xia Chao, Li Xin, Cheng Yue. Hardware in the loop test system of transmission control unit for electronic-mechanical continuously variable transmission[J]. Journal of Chongqing University of Technology(Natural Science), 2016, 30(9): 18-25.XIA C, LI X, CHENG Y. Hardware in the loop test system of transmission control unit for electronic-mechanical continuously variable transmission[J]. Journal of Chongqing University of Technology(Natural Science), 2016, 30(9): 18-25.(in Chinese)

[14] LEI LY, LIU K, FU Y. AMT control quality evaluation test system based on CANoe[J]. Advanced Materials Research, 2014, 902: 195-200.

END