A functional safety architecture system for a vehicle controller and its working method

Abstract

This invention provides a functional safety architecture system for a vehicle controller and its operating method, belonging to the field of functional safety development technology for new energy vehicles. The system divides the vehicle controller (VCU) into a Level 1 functional layer, a Level 2 functional monitoring layer, and a Level 3 controller monitoring layer. This architecture forms a scientific and efficient layered monitoring framework and effectively realizes functional safety decomposition. These three layers can be assigned to three different development teams, allowing for parallel development, significantly reducing development difficulty and improving development efficiency. For the Level 2 functional monitoring layer, safety during vehicle operation is ensured through the verification of safety-related signals during the execution of basic functions in the Level 1 functional layer and the monitoring of the Level 1 output software architecture.

Description

Technical Field

[0001] This invention belongs to the field of functional safety development technology for new energy vehicles, specifically relating to a functional safety architecture system for a vehicle controller and its working method. Background Technology

[0002] With the increasing trend of software-defined vehicles, efficient software architecture design plays a guiding role in the implementation and deployment of functional safety. It aims to cover a range of vehicle electrical functions and regulatory requirements, integrating the needs of R&D, production, and after-sales scenarios, and balancing cost, risks of new technology applications, flexibility, and scalability. This is a vehicle software architecture development approach from a holistic vehicle perspective. In EU vehicle type approval (based on some UNECE regulations) and my country's 3C certification, functional safety requirements have also been introduced for electronically controlled steering, braking, and battery management systems.

[0003] The Vehicle Control Unit (VCU) is the central control unit of a new energy vehicle. It monitors the status of the motor and battery, collects signals from the accelerator pedal, brake pedal, and various actuators and sensors, and, after comprehensively analyzing the driver's intentions, makes corresponding judgments and monitors the actions of lower-level component controllers. The VCU is responsible for the vehicle's normal driving, regenerative braking, energy management of the vehicle's drive system and power battery, network management, fault diagnosis and handling, and vehicle status monitoring, thereby ensuring the vehicle operates normally and stably with good power, economy, and reliability. The VCU hardware mainly consists of a power module, MCU, signal acquisition module, drive output module, and communication function module. The VCU system has multiple functions, including automatically interpreting the operator's intentions, torque management, motor and battery coordinated control management, charging process management, fault diagnosis, and CAN network control.

[0004] When developing functional safety products, to reduce development difficulty and improve development efficiency, the ASIL level of each module needs to be decomposed. The originally complex VCU functional safety development can be broken down into two parts: basic functions and functional safety. The QM level standard is applied to the development of basic functions, while the decomposed ASIL level standard is applied to the development of safety functions. To ensure that the software architecture meets functional safety requirements, the VCU system software architecture must consider avoiding, detecting, or handling random hardware and software system failures.

[0005] Domestic papers and patents mainly focus on designing vehicle controller hardware and software for functional safety standards, with little attention paid to specific design schemes for Level 2 functional monitoring layer software architecture that meet functional safety requirements such as layered structure and high development efficiency. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the existing vehicle controller (VCU) layered architecture, which is not fully layered and does not consider the design and testing functions of the Level 2 functional monitoring layer. This invention provides a functional safety architecture system for a vehicle controller and its working method.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A functional safety architecture system for a vehicle controller, comprising:

[0009] Level 1 Functional Layer: Used to execute the basic functions of the Vehicle Control Unit (VCU);

[0010] Level 2 Functional Monitoring Layer: Used to monitor the operational status of Level 1 Functional Layer in real time and ensure its normal operation; including the verification and judgment of safety-related signals during the execution of basic functions of Level 1 Functional Layer, and the monitoring of software architecture during the execution of basic functions of Level 1 Functional Layer.

[0011] Level 3 controller monitoring layer: It is used to monitor whether the basic functions of the Level 1 functional layer are running normally, and to monitor whether the monitoring program of the Level 2 functional monitoring layer is running normally. When the Level 1 functional layer and the Level 2 functional monitoring layer malfunction, Level 3 can detect it and take corresponding measures.

[0012] In the Level 2 functional monitoring layer, data segments, arbitration segments, control segments, and CRC segments are set in the data frames to extend standard data frames into extended data frames, where:

[0013] The arbitration segment is placed after the start of frame and is used to identify the priority of the data frame;

[0014] The control section is placed after the arbitration section and is used to indicate the number of bytes of data and the number of reserved bits;

[0015] The data segment is placed after the control segment and is used to store the content that the data frame needs to be sent.

[0016] The CRC segment is placed after the data segment and is used to check for byte segments that have transmitted errors in the data frame.

[0017] The Level 1 functional layer and the Level 2 functional monitoring layer are developed independently, and their respective production code must run in different partitions.

[0018] A method for operating a functional safety architecture system for a vehicle controller includes:

[0019] Upon receiving an action signal, the Level 1 functional layer executes basic functions based on the action signal.

[0020] The Level 2 functional monitoring layer verifies and judges the safety-related signals received from the Level 1 layer, and monitors the software architecture during the execution of basic functions in the Level 1 functional layer through the monitoring program. If a fault occurs, it will be promptly reported back to the Level 1 functional layer.

[0021] The Level3 controller monitoring layer implements independent monitoring, monitoring whether the Level1 functional layer is operating normally, and whether the monitoring program of the Level2 functional monitoring layer is running normally. If the monitoring program does not run in the set order or does not execute within the specified time, the check fails, and the system will enter a safe state.

[0022] The process by which the Level 2 functional monitoring layer verifies and judges the security-related signals of the Level 1 functional layer is as follows:

[0023] S1: The vehicle control unit (VCU) receives safety-related signals;

[0024] S2: Assuming that the interface signal is received every TBD ms, the received security-related signals are first checked for timeout. If no signal is received within the TBD ms signal period, the signal is determined to be lost.

[0025] S3: Perform CRC check on the security-related signals that have not been lost. If the check fails, the signal frame is determined to have a CRC error.

[0026] S4: Perform an live counter check on security-related signals that pass CRC verification to monitor the real-time performance and effectiveness of data transmission;

[0027] S5: Perform a signal validity check on the security-related signals that have passed the live counter check. If the check fails, the signal is deemed invalid.

[0028] S6: Perform a signal rationality check on the security-related signals that have passed the validity check. If the check fails, the signal is deemed unreasonable.

[0029] After the safety-related signals are verified, a fault message is generated when an error occurs. The Level 2 functional monitoring layer then feeds the fault message back to the Level 1 functional layer.

[0030] The specific method for generating fault information is as follows:

[0031] Identify the faulty node:

[0032] If a faulty node exhibits CANH and CANL anomalies or transceiver anomalies at the physical layer, the fault information is obtained by monitoring and diagnosing its message transmission method through the dual MCU control principle.

[0033] The control process of the dual MCU control principle is as follows: the master M-MCU controls the driver chip to drive digital output, the slave S-MCU diagnoses the working status of the driver chip and obtains the corresponding diagnostic results. Then, the master M-MCU and the slave S-MCU exchange diagnostic information through SPI communication. At the same time, the master M-MCU will parse and process the diagnostic results to obtain fault information.

[0034] The master M-MCU and slave S-MCU each control their corresponding CAN transceivers. The slave S-MCU forms a communication function redundancy with the master M-MCU. Under normal circumstances, the master M-MCU controls the corresponding CAN transceiver to complete communication, and the slave S-MCU monitors it. When an abnormality is detected in the communication function controlled by the master M-MCU, the slave S-MCU takes over the operation of the master M-MCU and restores the vehicle controller's communication function to control the vehicle.

[0035] The Level 2 functional monitoring layer monitors the software architecture of the Level 1 functional layer. The monitoring includes closed-loop monitoring of output signals, drive outputs, and actuator feedback.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] This invention provides a functional safety architecture system for a vehicle controller and its operating method, dividing the vehicle controller (VCU) into a Level 1 functional layer, a Level 2 functional monitoring layer, and a Level 3 controller monitoring layer. This architecture forms a scientific and efficient layered monitoring framework and effectively realizes functional safety decomposition. These three layers can be assigned to three different development teams, allowing for parallel development, greatly reducing development difficulty and improving development efficiency. For the Level 2 functional monitoring layer, safety during vehicle operation is ensured by verifying safety-related signals during the execution of basic functions in the Level 1 functional layer and monitoring the output software architecture of the Level 1 functional layer.

[0038] Furthermore, the standard data frame was extended to an extended data frame, increasing the number of nodes on the CAN bus, the flexibility of the data link, and the data processing capability, while maintaining the same priority mechanism as the standard data frame. This extension enables the CAN bus to support more complex and large-scale network systems.

[0039] Furthermore, signal verification and judgment are adopted to improve the reliability of data transmission, ensure vehicle safety performance, and reduce maintenance costs.

[0040] Furthermore, the system monitors and diagnoses message transmission through a dual-MCU control principle. If one MCU fails or malfunctions, the other MCU can still function normally, ensuring that the system's basic functions are unaffected. This redundancy design improves the system's reliability and stability.

[0041] Furthermore, the Level 2 functional monitoring layer adopts a control strategy independent of the Level 1 functional layer for monitoring, which improves the flexibility, energy efficiency, accuracy, safety, maintainability, and scalability of the vehicle controller (VCU). Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the three-layer architecture of the present invention.

[0043] Figure 2 This is a schematic diagram of the data frame format for the Level 2 functional monitoring layer.

[0044] Figure 3 This is a schematic diagram showing the data frame format corresponding to the Level 2 functional monitoring layer.

[0045] Figure 4 A flowchart for verifying security-related signals for the Level 2 functional monitoring layer input module.

[0046] Figure 5 This is a diagram showing the signal flow for security function verification at the Level 2 functional monitoring layer.

[0047] Figure 6 A schematic diagram of signal transmission between the master M-MCU and the slave S-MCU.

[0048] Figure 7 A schematic diagram illustrating the working process of the master M-MCU and slave S-MCU.

[0049] Figure 8 This is a schematic diagram of the monitoring software architecture for the Level 2 functional monitoring layer. Detailed Implementation

[0050] To further understand the content of this invention, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments are merely illustrative and not limiting of the invention.

[0051] Functional safety development is a top-down, layer-by-layer process, refining the architecture from top to bottom and ultimately decomposing it into specific hardware and software designs. All designs originate from the initial system-level architecture design; a scientific and efficient system architecture design ensures the entire product design stays on the right track. In terms of software design, this invention adopts a layered and modular design approach, completing the main program, subroutines, and interface layer programs for the Level 2 functional monitoring layer of the vehicle controller software. After dividing the components into hierarchical layers, the software architecture focuses on describing the relationships between components, namely static and dynamic relationships. Static design includes interfaces between components, relationships with hardware, and the hierarchical structure of components. Dynamic design includes the functionality of events and behaviors, the logical sequence of data processing, control flow and concurrent processes, data flow passed through interfaces and global variables, and time constraints.

[0052] like Figure 1 As shown, the functional safety architecture system for the vehicle controller of this invention consists of three parts: a Level 1 functional layer, a Level 2 functional monitoring layer, and a Level 3 controller monitoring layer. This architecture forms a scientific and efficient layered monitoring framework and effectively realizes functional safety decomposition. It typically adopts a QM+ASIL X (ASIL X) safety decomposition strategy, whereby the functional implementation software (Level 1 functional layer) is developed at the QM level, while redundant software or safety measures (Level 2 functional monitoring layer, Level 3 controller monitoring layer) are developed according to the required ASIL X (ASIL X) level. This effectively reduces the development cost of functional software safety.

[0053] Level 1 Functional Layer: Used to execute the basic functions of the vehicle control unit (VCU), such as drive system control, energy management, and network management. Based on the driver's operating intentions, such as accelerator pedal position and brake pedal force, it calculates parameters such as the torque required by the electric motor, coordinates the movement of various components, and ensures the normal operation of the electric vehicle.

[0054] Level 2 Functional Monitoring Layer: This layer monitors the operational status of the Level 1 functional layer in real time to ensure its proper functioning. This includes verifying and judging safety-related signals during the execution of basic functions in the Level 1 functional layer, as well as monitoring the software architecture during this process. The monitoring unit (such as an SBC or slave MCU) performs functions such as real-time monitoring of the functional operation status, self-memory diagnostics, and diagnosis and control of driver-level shutdown paths.

[0055] Level 3 controller monitoring layer: Monitors whether the basic functions of Level 1 functional layer are running normally, and monitors whether the monitoring program of Level 2 functional monitoring layer is running normally. When Level 1 functional layer and Level 2 functional monitoring layer fail, Level 3 can detect and take corresponding measures in a timely manner.

[0056] It should be noted that by dividing the vehicle controller (VCU) into a three-layer structure, the development difficulty is reduced. These three layers can be assigned to three different development teams, allowing for parallel development, which greatly reduces development difficulty and improves development efficiency.

[0057] The vehicle control unit (VCU) transmits signals with other controllers, sensors, and actuators via the CAN bus. Signal types must include data frames, remote frames, fault frames, check frames, and frame intervals. Data frames and remote frames have two formats: standard and extended. The standard format uses an 11-bit identifier (ID), while the extended format uses a 29-bit ID. The uses of each frame are shown in Table 1.

[0058] Table 1

[0059] Frame type Frame usage Data Frame Frames of data sent by the sender to the receiver remote frames Frames receiving data from units with the same ID in the receiving direction Fault Frame When a fault is detected, a frame is sent to other units to notify them of the fault. Verification frame Verify the accuracy of transmitted and received signals. Frame interval Frames that separate data frames, remote frames, and the previous frame.

[0060] As a further technical solution of the present invention, in the Level 2 functional monitoring layer, to meet the requirements of the VCU functional safety development organization's Level 2 functional monitoring layer, a data segment, an arbitration segment, a control segment, and a CRC segment are set in the data frame:

[0061] Data segment: The content of the data, which can be sent from 0 to 16 bytes;

[0062] Arbitration segment: A segment used to identify the priority of this frame;

[0063] CRC segment: The segment used to check for frame transmission errors;

[0064] Control segment: A segment that indicates the number of bytes of data and reserved bits;

[0065] ACK segment: Indicates confirmation that the data was received normally;

[0066] like Figure 2 As shown, the CAN protocol can receive and send 11-bit standard data frames and 29-bit extended data frames. The only difference between the CAN standard data frame and the extended data frame is the frame ID length, which allows for the expansion of more CAN nodes. The standard format is suitable for smaller networks with fewer nodes and identifier requirements, while the extended format is suitable for larger networks, requiring more nodes and more complex identifier management.

[0067] The standard CAN bus communication format consists of the following:

[0068] Start of Frame (SOF): 1 bit, fixed dominant bit, i.e. logic 0, indicating the start of a data frame. Nodes can only send this data during bus idle periods.

[0069] Identify ID: 11 bits, ID10 to ID0, ID10 is the most weighted bit (MSB) and ID0 is the least weighted bit (LSB), and they are transmitted in the order of ID10 to ID0;

[0070] RTR: Remote Transmission Request, used to identify whether a frame is a data frame or a remote frame. When the RTR bit is dominant ('0'), it indicates a data frame; when the RTR bit is recessive ('1'), it indicates a remote frame. It is located in the arbitration segment after the identifier bit.

[0071] IDE: Identifier bit extension, used to distinguish whether a data frame is in standard or extended format. When the IDE bit is dominant ('0'), it indicates that the data frame is in extended format; when the IDE bit is recessive ('1'), it indicates that the data frame is in standard format. It is located in the control section.

[0072] r0: Reserved bit. Bit r0 is not used in the current CAN standard and is reserved for possible future use. It must be set to dominant ('0'). Located in the control section, immediately adjacent to the Data Length Code (DLC).

[0073] DLC: Data Length Code, used to indicate the number of bytes of data in a data segment. It occupies 4 bits and can represent a data length of 0 to 8 bytes. It is located in the control segment, after bit r0.

[0074] Data segment: 0 to 8 bytes, length specified by the Data Length Code (DLC), contains the actual data to be transmitted between nodes. It is located after the control segment.

[0075] CRC Segment: The CRC segment consists of a CRC Sequence (Cyclic Redundancy Check) and a CRC delimiter. The CRC Sequence consists of 15 characters and is used to check for errors that may occur during data transmission or storage. A number (i.e., a CRC checksum) is appended to the end of the data frame to ensure the correctness and integrity of the data transmission.

[0076] CRC delimiter: Used in the encapsulation and decapsulation process of data frames. It marks the start and end positions of the data frame so that the receiving end can accurately decapsulate the data frame, ensuring data integrity and reliability.

[0077] ACK Segment: The ACK segment is used to confirm whether the reception was normal. It consists of two bits: the ACK slot and the ACK delimiter. The transmitting unit sends two recessive bits in the ACK segment. When the receiver correctly receives a valid message, it sends a dominant bit to the transmitter during the ACK slot (sending the ACK signal) to acknowledge the successful reception and notify the transmitting unit that normal reception has ended. This is called "sending ACK" or "returning ACK".

[0078] End of frame: Consists of 7 recessive bits, used to indicate the end of a frame.

[0079] like Figure 3 As shown, when a data frame is converted from a standard format to an extended format:

[0080] A 29-bit identifier (ID) needs to be determined for the new extended format data frame. This ID should be related in some way to the 11-bit ID of the original standard format data frame, but must also be unique within the CAN network. The IDE bit is set to dominant ('0'). The extended format ID field is 29 bits, while the standard format is only 11 bits. Therefore, the remaining 18 bits need to be padded for the extended format ID field. The other fields of the data frame remain unchanged.

[0081] The working method of a functional safety architecture system for a vehicle controller is as follows:

[0082] Upon receiving an action signal, the Level 1 functional layer executes basic functions based on the action signal.

[0083] The Level 2 functional monitoring layer performs safety-related signal verification and judgment on the action signals sent by the Level 1 layer, and monitors the software architecture during the execution of basic functions in the Level 1 functional layer through the monitoring program. If a fault occurs, it will be promptly reported back to the Level 1 functional layer.

[0084] The Level3 controller monitoring layer implements independent monitoring, monitoring whether the Level1 functional layer is operating normally, and whether the monitoring program of the Level2 functional monitoring layer is running normally. If the monitoring program does not run in the set order or does not execute within the specified time, the check fails, and the system will enter a safe state.

[0085] Specifically, the Level 2 functional monitoring layer architecture includes torque monitoring of the Level 1 functional layer, comparison of torque requests and actual torque, monitoring of current demand, diagnosis of input and output signals, reading and monitoring of actuator-related status, and handling of faults detected by diagnosis. The Level 1 functional layer and the Level 2 functional monitoring layer are independently developed and their respective production codes must run in different partitions to avoid common causes of failure and to prevent interference. Furthermore, the Level 2 functional monitoring layer code must run within the hardware security kernel. The input and output interfaces of the process monitoring module of the Level 2 functional monitoring layer are shown in Table 2.

[0086] Table 2

[0087]

[0088] (1) The Level 2 functional monitoring layer verifies the security-related signals during the execution of the basic functions of the Level 1 functional layer as follows:

[0089] The Level 2 functional monitoring layer input module verifies the integrity, effective range, and reasonableness of the relevant safety-related signals, and then outputs them to the process monitoring and output monitoring modules of the Level 1 and Level 2 functional monitoring layers, respectively. The specific verification logic is as follows: Figure 4 As shown.

[0090] S1: The vehicle control unit (VCU) receives safety-related signals;

[0091] S2: Assuming that the interface 1 signal is received every TBD ms, the received security-related signals are first checked for timeout. If the signal is not received within the TBD ms signal period, it is determined that the signal is lost.

[0092] S3: Perform CRC check on the security-related signals that have not been lost. If the check fails, the signal frame is determined to have a CRC error.

[0093] S4: Perform an live counter check on security-related signals that pass CRC verification to monitor the real-time performance and effectiveness of data transmission;

[0094] S5: Perform signal validity verification on security-related signals that pass the live counter check. If the verification fails, the signal is deemed invalid.

[0095] S6: Perform a signal rationality check on the security-related signals that have passed the validity check. If the check fails, the signal is deemed unreasonable.

[0096] like Figure 5As shown, the VCU controller outputs the required verification signal to the Level 2 functional monitoring layer. The Level 2 functional monitoring layer uses the safety-related signal output from the Level 1 functional layer as its input. The Level 2 functional monitoring layer monitors the Level 1 functional layer. The monitored Level 1 functional layer should use a redundant heterogeneous algorithm to verify interface 4 in the Level 2 functional monitoring layer. When an error occurs, it enters a safety state, generates fault information, outputs the relevant fault signal level, interrupts the error signal activation, and the warning light on the instrument panel remains on.

[0097] Based on the analysis of communication function failures, nodes may experience CANH and CANL anomalies and transceiver malfunctions at the physical layer; erroneous frames and bus shutdown anomalies at the data link layer; and message data anomalies at the application layer. CANH and CANL anomalies at the physical layer can be monitored and diagnosed by sending messages from the S-MCU, while transceiver anomalies can be diagnosed automatically. In response to the aforementioned signal processing fault types and the dual-MCU control principle, corresponding safety mechanisms are designed for input signal processing. The master M-MCU and slave S-MCU respectively acquire important input signals, and then exchange the acquired data via SPI communication to perform range limitation diagnosis, difference value comparison, and correlation diagnosis.

[0098] The control process based on the dual MCU control principle is as follows:

[0099] like Figure 6 As shown, the master M-MCU and slave S-MCU form a dual control system for the driver chip. By default, the master M-MCU controls the driver chip to output digital signals, while the S-MCU diagnoses the driver chip's operating status. The master M-MCU and slave S-MCU exchange diagnostic information via SPI communication, and the master M-MCU simultaneously parses and processes the diagnostic results. Signal transmission between the master M-MCU and slave S-MCU is achieved through PWM, CAN, and LIN Ethernet. The master M-MCU issues commands to the slave S-MCU based on its control logic. Upon receiving a command, the slave S-MCU analyzes the module it is responsible for to determine if immediate execution is appropriate. If appropriate, it executes the command immediately and sends an execution status signal back to the master M-MCU; otherwise, it refuses to execute and sends a rejection signal back to the master M-MCU.

[0100] like Figure 7As shown, the master M-MCU and slave S-MCU each control their corresponding CAN transceiver. The slave S-MCU provides redundant communication functionality with the master M-MCU. Under normal circumstances, the master M-MCU controls its corresponding CAN transceiver to complete communication, while the slave S-MCU monitors it. When an abnormality is detected in the communication function controlled by the master M-MCU, the slave S-MCU takes over the operation of the master M-MCU and restores the vehicle controller's communication function to control the vehicle.

[0101] The specific implementation method is as follows:

[0102] For the detection of abnormal analog signal input, the signal is acquired simultaneously by the master M-MCU and the slave S-MCU. Taking the acquisition and processing of the brake pedal opening signal S1 as an example, the master M-MCU and the slave S-MCU first acquire the brake pedal opening signal S1 respectively and monitor its power supply voltage. Then, the slave S-MCU transmits the acquired and converted result to the master M-MCU through SPI communication. The master M-MCU compares the differences between the results acquired by the master M-MCU and the slave S-MCU. If the difference value is too large, the acquired value is considered invalid and an error count is performed. When the number of consecutive errors exceeds a certain number, it is reported as a vehicle fault level.

[0103] For anomaly detection in digital signal output, the main approach is to diagnose the driver chip. The S-MCU communicates with the driver chip via SPI to monitor its status and then transmits the diagnostic results to the master M-MCU via SPI. The master M-MCU processes the diagnostic results and reports a fault if an open circuit or short circuit is found in the driver chip channel. The application layer then assesses the fault level to control the vehicle's safe operation. When a master M-MCU is unable to control its driver chip, the slave S-MCU takes over to control the vehicle.

[0104] (2) Level 2 Functional Monitoring Layer Output Monitoring Software Architecture

[0105] like Figure 8 As shown, the Level 2 functional monitoring layer performs closed-loop monitoring of the output results, drive output, and actuator feedback of the Level 1 functional layer. The specific strategies are as follows:

[0106] 1) Safety signal monitoring: The Level 2 functional monitoring layer uses a control strategy independent of the Level 1 functional layer to monitor the relevant interfaces;

[0107] 2) Driver output monitoring: Interface 2 outputs to the output driver. After a certain period of time, the Level 2 function monitoring layer monitors whether the driver outputs correctly.

[0108] 3) Actuator monitoring: After the actuator responds to the signal of interface 2, it performs the action and feeds back to interface 7. The Level 2 functional monitoring layer monitors whether its execution status meets the expected results. If a monitoring fault occurs, it sends an instrument reminder to the driver through interface 5 and then enters a safe state.

[0109] The specific implementation method is as follows:

[0110] The Level 2 functional monitoring layer monitors the brake pedal function of the Level 1 functional layer. When the driver presses the brake pedal, the Level 1 functional layer receives the brake pedal signal. Interface 1 in the Level 2 functional monitoring layer monitors the signal, and interface 2 verifies the signal before outputting it to the drive output monitoring. The Level 2 functional monitoring layer then performs fault confirmation to determine whether the drive signal is output correctly, i.e., whether the actuator receives the execution signal from interface 2 and begins braking. If the brake pedal signal is received, the braking function is executed and feedback is sent to interface 7. The Level 2 functional monitoring layer monitors whether the execution status meets the expected results. If a monitoring fault occurs, it sends a reminder to the driver via interface 5 to stop the braking process and then enters a safe state.

[0111] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A functional safety architecture system for a vehicle controller, characterized in that, include: Level 1 Functional Layer: Used to execute the basic functions of the Vehicle Control Unit (VCU); Level 2 Functional Monitoring Layer: Used to monitor the operational status of Level 1 Functional Layer in real time and ensure its normal operation; This includes verifying and judging security-related signals during the execution of basic functions in the Level 1 functional layer, as well as monitoring the software architecture during the execution of basic functions in the Level 1 functional layer; In the Level 2 functional monitoring layer, data segments, arbitration segments, control segments, and CRC segments are set in the data frames to extend standard data frames into extended data frames, where: The arbitration segment is placed after the start of frame and is used to identify the priority of the data frame; The control section is placed after the arbitration section and is used to indicate the number of bytes of data and the number of reserved bits; The data segment is placed after the control segment and is used to store the content that the data frame needs to be sent. The CRC segment is placed after the data segment and is used to check for byte segments in the data frame that have been transmitted incorrectly. The Level 1 functional layer and the Level 2 functional monitoring layer are developed independently, and their respective production code must run in different partitions; Level 3 controller monitoring layer: It is used to monitor whether the basic functions of the Level 1 functional layer are running normally, and to monitor whether the monitoring program of the Level 2 functional monitoring layer is running normally. When the Level 1 functional layer and the Level 2 functional monitoring layer fail, Level 3 can detect and take corresponding measures. The working method of the vehicle controller functional safety architecture system based on the above architecture is as follows: Upon receiving an action signal, the Level 1 functional layer executes basic functions based on the action signal. The Level 2 functional monitoring layer verifies and judges the safety-related signals received from the Level 1 layer, and monitors the software architecture during the execution of basic functions in the Level 1 functional layer through the monitoring program. If a fault occurs, it will be promptly reported back to the Level 1 functional layer. The Level3 controller monitoring layer implements independent monitoring, monitoring whether the Level1 functional layer is operating normally, and whether the monitoring program of the Level2 functional monitoring layer is running normally. If the monitoring program does not run in the set order or does not execute within the specified time, the check fails and the system enters a safe state. The process by which the Level 2 functional monitoring layer verifies and judges the security-related signals of the Level 1 functional layer is as follows: S1: The vehicle control unit (VCU) receives safety-related signals; S2: Assuming that the interface signal is received every TBD ms, the received security-related signals are first checked for timeout. If no signal is received within the TBD ms signal period, the signal is determined to be lost. S3: Perform CRC check on the security-related signals that have not been lost. If the check fails, the signal frame is determined to have a CRC error. S4: Perform an live counter check on security-related signals that pass CRC verification to monitor the real-time performance and effectiveness of data transmission; S5: Perform a signal validity check on the safety-related signals that have passed the live counter check. If the check fails, the signal is deemed invalid. S6: Perform a signal rationality check on the security-related signals that have passed the validity check. If the check fails, the signal is deemed unreasonable.

2. The working method of a functional safety architecture system for a vehicle controller according to claim 1, characterized in that, After the safety-related signals are verified, a fault message is generated when an error occurs. The Level 2 functional monitoring layer then feeds the fault message back to the Level 1 functional layer.

3. The working method of a functional safety architecture system for a vehicle controller according to claim 2, characterized in that, The specific method for generating fault information is as follows: Identify the faulty node: If a faulty node exhibits CANH and CANL anomalies or transceiver anomalies at the physical layer, the fault information is obtained by monitoring and diagnosing its message transmission method through the dual MCU control principle.

4. The working method of a functional safety architecture system for a vehicle controller according to claim 3, characterized in that, The control process of the dual MCU control principle is as follows: the master M-MCU controls the driver chip to drive digital output, the slave S-MCU diagnoses the working status of the driver chip and obtains the corresponding diagnostic results. Then, the master M-MCU and the slave S-MCU exchange diagnostic information through SPI communication. At the same time, the master M-MCU will parse and process the diagnostic results to obtain fault information.

5. The working method of a vehicle controller functional safety architecture system according to claim 4, characterized in that, The master M-MCU and the slave S-MCU each control their corresponding CAN transceivers. The slave S-MCU forms redundancy in communication function with the master M-MCU. Under normal circumstances, the master M-MCU controls the corresponding CAN transceiver to complete communication, and the slave S-MCU monitors it. When an abnormality is detected in the communication function controlled by the master M-MCU, the slave S-MCU takes over the operation of the master M-MCU and restores the vehicle controller's communication function to control the vehicle.

6. The method for operating a functional safety architecture system for a vehicle controller according to claim 1, characterized in that, The Level 2 functional monitoring layer monitors the software architecture of the Level 1 functional layer. The monitoring includes closed-loop monitoring of output signals, drive outputs, and actuator feedback.

Images