Controller fault diagnosis and processing method and controller

Abstract

The invention relates to a controller fault diagnosis and processing method, and aims to improve the functional safety of controllers such as an electronic stability controller and an integrated hydraulic brake-by-wire system. The method mainly comprises the following steps that firstly, a communication link is established between a main MCU (main micro-control unit) and an auxiliary MCU (auxiliary micro-control unit) of the controller, and the main MCU sends an initialization signal to the auxiliary MCU to complete establishment of communication; secondly, the auxiliary MCU obtains diagnosis data from the main MCU, and the data comprises working data and verification data generated in the normal working process of the main MCU; then, the auxiliary MCU analyzes the obtained diagnosis data to judge whether the main MCU breaks down or not; and if the analysis result shows that the main MCU breaks down, the auxiliary MCU carries out fault processing according to a preset protection mechanism. Through cooperative work of the main MCU and the auxiliary MCU, real-time fault diagnosis and processing are achieved, reliability and safety of the controller under the condition that the main MCU breaks down are ensured, and wide application prospects are achieved.

Description

Technical Field

[0001] The invention belongs to the field of vehicle chassis electronic controllers, and in particular relates to a controller fault diagnosis and processing method, and a controller applying the method. Background Art

[0002] At present, existing controllers usually implement various functions through a single MCU, and the failure of a single MCU may lead to functional failure and safety hazards. In the field of existing automotive chassis electronic controllers, there are significant defects in using a single MCU to implement various functions. First, the risk of single-point failure is extremely high. Once the MCU fails or fails, the entire control system will not work properly, resulting in functional failure, which directly affects the safety and reliability of the vehicle. Secondly, the lack of redundant design makes it impossible to provide backup support when a failure occurs, and it is impossible to perform key functions such as electronic stability control (ESC) and braking control, which increases the possibility of accidents. In addition, single-MCU systems usually lack effective real-time monitoring and fault diagnosis capabilities, and cannot detect and handle potential faults in a timely manner, resulting in the driver's inability to receive timely warnings, increasing safety hazards. In terms of maintenance and upgrades, the design of a single MCU makes the maintenance and upgrade of the system complicated, and the entire MCU or controller may need to be replaced, increasing maintenance costs and time. Finally, with the development of technology, vehicle control functions are becoming increasingly complex, and the processing power and storage capacity of a single MCU may not be able to meet the growing demand, limiting the scalability and flexibility of the system. Therefore, it is urgent to solve these problems by introducing a main and auxiliary MCU redundancy solution to improve the functional safety of the overall controller. Summary of the invention

[0003] The present invention relates to a controller fault diagnosis and processing method and a controller using the method, which is particularly suitable for the field of automobile chassis controllers and aims to improve the fault diagnosis capability and processing efficiency of the controller and ensure the reliability and safety of the system.

[0004] The present invention provides a controller fault diagnosis and processing method, comprising the following steps: S1, establishing communication between the main MCU and the auxiliary MCU of the controller, using the main MCU to send an initialization signal to the auxiliary MCU to establish a communication link; S2, using the auxiliary MCU to obtain diagnostic data from the main MCU, the diagnostic data including working data and verification data generated by the main MCU during its normal working process; S3, using the auxiliary MCU to analyze the diagnostic data to determine whether the main MCU fails; S4: If it is determined through step S3 that the main MCU fails, the fault is handled according to a preset protection mechanism.

[0005] This series of operations ensures that when a fault occurs in the main MCU of the controller, the auxiliary MCU can handle the fault in a timely manner. It not only improves the communication reliability and real-time performance between the main and auxiliary MCUs, but also enhances the system's fault diagnosis capability, thereby effectively improving the reliability and safety of the system, reducing potential safety hazards, and ensuring the stability and safety of the vehicle under complex working conditions.

[0006] The present invention also provides an automobile chassis controller, characterized in that it includes a main MCU and an auxiliary MCU that are communicatively connected to each other, the main MCU is used to send an initialization signal to the auxiliary MCU to establish a communication link, and generate diagnostic data in a parallel data format and convert it into a serial data format, the auxiliary MCU is used to obtain diagnostic data from the main MCU, analyze the diagnostic data to determine whether the main MCU fails, and perform fault processing according to a preset protection mechanism. Through this structure, the system can quickly take over control when the main MCU fails, ensuring the continuity and safety of system functions.

[0007] In summary, the controller fault diagnosis and processing method and the automobile chassis controller of the present invention are efficient and reliable, can effectively improve the fault diagnosis capability of the controller, reduce the safety hazards caused by faults, and have broad application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0009] Figure 1 A flowchart of a controller fault diagnosis and processing method provided for one embodiment of the present application; Figure 2 yes Figure 1 A flowchart of the specific sub-steps of step S3; Figure 3 yes Figure 1 A flowchart of the specific sub-steps of step S4; Figure 4 It is a block diagram of functional modules of a controller provided by an embodiment of the present application. DETAILED DESCRIPTION

[0010] The technical solutions in the embodiments of the present invention will be described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0011] The technical solution of the present invention is applicable to microcontrollers such as the Electronic Stability Control (ESC) and the Integrated Brake Control (IBC) in the chassis of automobiles. The present invention uses an IBC product, OneBox. In these controllers, each controller is usually provided with at least two microcontroller units (MCUs), namely the main MCU and the auxiliary MCU, to achieve a redundant backup function. Specifically, the main MCU is used to perform the main control tasks of the controller, while the auxiliary MCU is connected to the main MCU through an internal UART interface, and establishes full-duplex communication with the main MCU, so as to monitor the status of the main MCU in real time, and take over control when the main MCU fails, so as to ensure the stability and safety of the vehicle.

[0012] In the existing field of automotive chassis electronic controllers, systems using a single MCU have several significant disadvantages. First, the risk of single-point failure in a single MCU system is extremely high. Once the MCU fails or fails, the entire control system will not work properly, resulting in the loss of control function, seriously affecting the safety and stability of the vehicle. Secondly, a single MCU lacks redundant design, cannot provide backup support when a failure occurs, and cannot switch to the backup control unit in time, thereby increasing the possibility of accidents. In addition, a single MCU system usually lacks effective real-time monitoring and fault diagnosis capabilities, and cannot detect and handle potential faults in a timely manner, resulting in the driver's inability to obtain timely warnings, further increasing safety hazards.

[0013] The present invention solves the above shortcomings by introducing a redundant design of the main and auxiliary MCUs. Specifically, the main MCU is responsible for executing the main control tasks, while the auxiliary MCU establishes full-duplex communication with the main MCU through the internal UART interface to monitor the status of the main MCU in real time. When the main MCU fails, the auxiliary MCU can quickly take over control to ensure the continuity of the control function and the stability of the vehicle. In addition, the real-time communication and diagnostic mechanism between the main and auxiliary MCUs improves the reliability of the system, can identify and handle faults in a timely manner, and reduces potential safety risks. Therefore, the method of the present invention effectively improves the overall functional safety of the electronic stability controller and the integrated wire control brake system, and ensures the stability and safety of the vehicle under complex working conditions.

[0014] The embodiment of the present invention provides a controller fault diagnosis and processing method, which is applicable to the above-mentioned type of microcontroller with a main MCU and an auxiliary MCU, see Figure 1 and Figure 2 , the method comprises the following steps: S1, establish communication between the main MCU and the auxiliary MCU of the controller. The specific operation mode of this step can be that the main MCU sends an initialization signal to the auxiliary MCU to establish a communication link. The main MCU can send a high-level signal through a specific pin to indicate the start of communication. After receiving the signal, the auxiliary MCU confirms that the communication link has been established and is ready to receive data. This operation ensures the synchronization between the main and auxiliary MCUs, laying the foundation for subsequent data transmission.

[0015] S2, use the auxiliary MCU to obtain diagnostic data from the main MCU. The diagnostic data may include the working data generated by the main MCU during its normal working process, and these working data include system operating status, sensor data, and control instructions. Among them, the operating status data includes key parameters such as voltage, current, and temperature; sensor data is real-time data from various sensors, such as speed sensors, brake sensors, etc.; control instructions refer to control instructions issued by the main MCU; these working data are used to control the braking system, power system, steering system and other components in the car to perform conventional functions such as acceleration, deceleration, steering, and stability control on the one hand, and can also be copied to the auxiliary MCU as diagnostic data at the same time. At the same time, the diagnostic data may also include verification data specifically used for fault detection generated by the main MCU according to the system operating status and sensor feedback. The auxiliary MCU can simultaneously obtain the working data and verification data from the main MCU to ensure the integrity and reliability of the diagnostic data. Specifically, step S2 may include the following operations: S21, using the main MCU to generate diagnostic data in parallel data format and convert it into serial data format. In this step, the main MCU converts parallel data (such as sensor values) generated according to the output parameters of multiple sensors or control devices into serial data. The specific implementation method is that the main MCU uses the existing internal universal asynchronous receiver / transmitter (UART) module to convert the parallel data into a serial format bit by bit through a shift register to ensure that the data can be transmitted sequentially on a data line. This conversion process makes data transmission more efficient and reduces the number of connection lines required.

[0016] S22, sending the diagnostic data in serial data format to the auxiliary MCU via the UART protocol. The main MCU sends the converted serial data to the auxiliary MCU via the UART module. In this step, the main MCU sends the data byte by byte, and adds a start bit and a stop bit before each byte to ensure that the receiving end can correctly parse the data. The technical effect of this operation is to achieve real-time data transmission between the main and auxiliary MCUs, ensuring that the auxiliary MCU can obtain the status information of the main MCU in a timely manner.

[0017] S23, using the auxiliary MCU to reconvert the diagnostic data in the serial data format into the diagnostic data in the parallel data format. Specifically, the auxiliary MCU uses its UART receiving module to read the serial data bit by bit and reconstructs it into a parallel format through a shift register.

[0018] S3, using the auxiliary MCU to analyze the diagnostic data to determine whether the main MCU fails. In this step, the auxiliary MCU performs a cyclic redundancy check (CRC) on the received data to ensure that the data is not damaged during transmission. The specific implementation method is that the auxiliary MCU calculates the CRC value of the received data and compares it with the CRC value calculated when the main MCU sends it. If the two are consistent, it means that the data is complete; if they are inconsistent, it means that the data is damaged during transmission, and the auxiliary MCU will discard the data and request retransmission. The step S3 may include the following operations: S31, control the auxiliary MCU to enter the diagnostic mode. After data verification, the auxiliary MCU will enter the diagnostic mode and prepare to perform further integrity checks on the received data. The data verification here refers to a preliminary check on the received data before entering the diagnostic mode to ensure the validity of the data. The data verification in the following steps S32 to S36 is performed after the auxiliary MCU enters the diagnostic mode.

[0019] S32, cache the diagnostic data in parallel data format. In this step, the auxiliary MCU receives and caches all data from the main MCU, including working data and verification data. This operation ensures that the auxiliary MCU can fully analyze and process the data in subsequent steps.

[0020] S33, check data integrity. The auxiliary MCU performs an integrity check on the received data, mainly verifying the accuracy of the data through CRC verification. If the CRC verification passes, the auxiliary MCU will determine that the data is complete and continue to perform subsequent operations; if the verification fails, the auxiliary MCU will record the error and trigger the error handling mechanism. This process is closely related to the data verification in S31, ensuring that after the auxiliary MCU enters the diagnostic mode, it can effectively verify and judge the received data comprehensively to avoid repeated or erroneous processing.

[0021] S34, if the data is complete, it is determined that the main MCU has not failed. The auxiliary MCU will confirm the status of the main MCU and perform processing for the fault in the subsequent step S36. If it is confirmed that the main MCU is normal, the auxiliary MCU will process the data normally according to the predetermined logic, such as executing control instructions or updating status information. This operation ensures that the system can respond effectively under normal operating conditions.

[0022] S35, if the data is incomplete, it is determined that the main MCU has failed. In this step, the auxiliary MCU will identify failure behaviors, including information duplication, signal loss, etc. The auxiliary MCU will identify failure behaviors based on monitoring data streams. Specific implementation methods include checking the repeatability of data packets, monitoring the integrity of signals, etc. If an abnormality is found, the auxiliary MCU will record relevant information for subsequent analysis.

[0023] S36: If it is determined that the main MCU fails, the fault is identified and the auxiliary MCU is used to handle the fault. The auxiliary MCU will take corresponding measures to handle the failure according to the identified failure behavior. For example, if the main MCU fails, the auxiliary MCU will switch control, take over the functions of the main MCU, and record error information for subsequent analysis and improvement. This operation ensures the reliability and security of the system and avoids functional failures caused by single point failures.

[0024] S37, end diagnosis. After completing all diagnosis and data processing, the auxiliary MCU will enter the diagnosis end state. The specific implementation method of this step is that the auxiliary MCU will summarize the entire diagnosis process and record all diagnosis results and status information, including successful processing and any identified failure behaviors. At this time, the auxiliary MCU will also clean up the cached data and prepare for the next round of communication. This operation ensures that the system can maintain a good state after each communication to avoid data confusion.

[0025] S4, if it is determined through step S3 that the main MCU fails, the fault is handled according to the preset protection mechanism. The operations from S41 to S410 are in parallel, that is, different processing countermeasures are executed according to different types of faults that may occur. Specifically, step S4 may include the following operations: S41, send a retransmission request for diagnosing data integrity failure. When the auxiliary MCU finds that there is a problem with data integrity through CRC check in step S5, the auxiliary MCU will immediately send a retransmission request to the main MCU, requiring the main MCU to resend the data to ensure that all data received by the system is complete and reliable. This step is directly related to the data integrity check in the E2E protection mechanism. When the auxiliary MCU finds that the data check fails, triggering a retransmission request is an important measure to ensure data integrity.

[0026] S42, in response to the failure of the alive counter, the control of the main MCU is switched from the main MCU to the auxiliary MCU. If the counter does not increase when checking the alive counter, the auxiliary MCU will determine that the main MCU may have failed. In this case, the auxiliary MCU will take over the control and continue to execute system functions to ensure the normal operation of the system and avoid functional interruption caused by the failure of the main MCU. This measure ensures that the system can still maintain functional continuity when the main MCU fails, which meets the requirements of system reliability in the E2E protection mechanism.

[0027] S43, for abnormal signal faults, a fault alarm is issued. During the data verification process, if the Data ID of the data packet is found to be repeated or the Timeout Detection is triggered, the auxiliary MCU will issue a fault alarm to notify the system monitoring center or other related modules for further fault handling and system maintenance. By issuing a fault alarm, the system can respond to potential safety hazards in a timely manner to ensure functional safety, which is consistent with the fault detection and response mechanism in the E2E protection mechanism.

[0028] S44, ignore duplicate data in diagnostic data. When the auxiliary MCU recognizes that the information in the diagnostic data is transmitted repeatedly, it will ignore the duplicate data packets to ensure that only the latest data is processed to avoid redundant information from interfering with the normal operation of the system. This step ensures that only the latest data is processed to avoid redundant information interference, which reflects the monitoring of data validity in the E2E protection mechanism.

[0029] S45, request retransmission of lost data in diagnostic data. In the case of signal loss, the auxiliary MCU will trigger a retransmission request and request the main MCU to retransmit the lost diagnostic data to ensure data integrity and system continuity. Requesting retransmission of lost diagnostic data is a key link in the E2E protection mechanism to ensure the integrity and reliability of data during transmission. Through this measure, the system can recover the lost information in time and avoid functional abnormalities or system failures caused by missing data.

[0030] S46, processing the information delay of the transmitted data. If the receiving end records the information delay, the auxiliary MCU will trigger a retransmission request and take corresponding measures when the delay exceeds the predetermined threshold to ensure timely recovery of data transmission. By recording the delay information and triggering the retransmission request, the system can promptly respond to the delay problem in data transmission, which meets the requirements of the E2E protection mechanism.

[0031] S47, discard the redundant content in the received information. In the case of signal insertion, the auxiliary MCU will perform data integrity check. If redundant content is found, the data will be discarded to maintain data accuracy and system stability. This measure ensures data accuracy and maintains data integrity, reflecting the data validity check in the E2E protection mechanism.

[0032] S48, verify the sender's identity in the received information. In the case of a fake address, the auxiliary MCU will verify the sender's identity. If the identity does not match, the data will be discarded and an alarm will be issued to prevent unauthorized data from affecting system security. Through identity authentication, the reliability of the data source is ensured, which meets the security requirements of the data source in the E2E protection mechanism.

[0033] S49, reorganize the data order in the diagnostic data. When the receiving end detects that the information order in the diagnostic data is wrong, the auxiliary MCU will first extract the data ID in each data packet. Subsequently, the auxiliary MCU rearranges the received data packets of the diagnostic data according to the extracted data ID to achieve data reorganization. This process ensures the correctness of the data flow and maintains the normal operation of the system. This step reflects the monitoring of the data order and integrity by the E2E protection mechanism, ensuring that the system can adjust in time and prevent functional abnormalities caused by data order problems.

[0034] S410, request retransmission of damaged data in the diagnostic data. In the case of damaged information, the auxiliary MCU will use CRC verification. If the verification fails, the data will be discarded and the main MCU will be requested to retransmit to ensure that all data received by the system is complete and reliable. This step is directly related to the CRC verification in the E2E protection mechanism to ensure the integrity and reliability of data during transmission.

[0035] The method of the present invention significantly improves the reliability and functional safety of the system through the parallel fault diagnosis and processing mechanism between the main and auxiliary MCUs. The auxiliary MCU can quickly identify and handle multiple failure behaviors, ensure timely response when the main MCU fails, and avoid functional interruption. At the same time, the data integrity check (such as CRC, retransmission request, etc.) in the E2E protection mechanism is introduced to ensure that the data received by the system is complete and reliable, reducing risks. When the main MCU fails, the auxiliary MCU quickly switches control rights and continues to execute system functions to ensure normal operation. In addition, the fault alarm mechanism enhances the security and maintainability of the system, and by ignoring duplicate data, discarding redundant content, and reorganizing data order, it ensures that the system processes the latest and valid information to avoid redundant interference. When encountering a fake address, the auxiliary MCU can verify the identity of the sender, ensure the reliability of the data source, and prevent unauthorized data from affecting the security of the system. Finally, by processing information delay and damaged data, the auxiliary MCU can restore data transmission in time to maintain the stability and normal operation of the system. In summary, the method of the present invention provides an effective solution for the field of automotive chassis electronic controllers.

[0036] The method may further comprise the following steps: S5, after completing the diagnosis, feeds back the diagnosis result to the main MCU. The specific implementation method is that the auxiliary MCU sends a feedback signal through UART to indicate whether the reception result is successful or failed. If the reception is successful, the auxiliary MCU will send a confirmation signal; if the reception fails, the auxiliary MCU will send an error code to indicate the specific error type. This feedback mechanism ensures that the main MCU can understand the communication status in time and take corresponding measures based on the feedback results.

[0037] S6, end the communication between the main MCU and the auxiliary MCU. After all data transmission and feedback are completed, the communication end step will be executed. The specific operation method is that both the main MCU and the auxiliary MCU will send an end signal to indicate the end of the communication session. The main MCU can notify the auxiliary MCU by sending a specific end instruction. After receiving the instruction, the auxiliary MCU confirms the end of the communication and enters the standby state. This operation ensures the orderly end of the communication and prepares for the next communication. In this way, the system can maintain an efficient communication process and ensure that it can enter the next cycle in the best state after each session.

[0038] In the present invention, the main and auxiliary MCUs communicate serially through internal UARTs, using full-duplex mode to ensure real-time data transmission. Data is transmitted one by one on a data line according to the binary digits from high to low. In the specific implementation, two data lines are used to meet the full-duplex communication requirements between the main and auxiliary MCUs. Data transmission is in bytes, and each byte contains a start bit, a data bit, a check bit, and a stop bit. In addition, the connection design between the MCUs complies with the AUTOSAR standard to ensure the reliability and security of data transmission.

[0039] Another embodiment of the present invention further provides an automobile chassis controller, which can be used to implement the controller fault diagnosis and processing method described in the above embodiment. Figure 4 , the controller includes a main MCU and an auxiliary MCU, which are interconnected through a communication link. The main MCU generates working data and verification data during its normal operation, and sends these data to the auxiliary MCU in a serial format through the UART protocol. After receiving the data, the auxiliary MCU converts it into a parallel data format for cache, and enters the diagnostic mode to check the integrity of the data. If the data is complete, the auxiliary MCU will confirm that the main MCU is working normally; if the data is incomplete, the auxiliary MCU will identify that the main MCU has a fault and perform corresponding fault processing according to the preset protection mechanism, such as sending a retransmission request, switching control rights, and issuing a fault alarm. After completing the diagnosis, the auxiliary MCU will feed back the diagnosis results to the main MCU and end the communication.

[0040] It can be understood that the controller fault diagnosis and processing method provided in the embodiment of the present invention, as well as the redundant design and real-time UART communication of the controller through the main and auxiliary MCUs, significantly improve the reliability and safety of the system and avoid single point failures; introduce the data protection specifications and multiple data verification mechanisms of the AUTOSAR standard to enhance functional safety and data integrity; at the same time, provide a complete diagnostic solution, support rapid fault handling, reduce development and maintenance costs, and are applicable to a variety of chassis electronic controllers, with good adaptability and promotion potential.

[0041] The embodiments of the present invention have significant advantages over the prior art. First, through the redundant design of the main and auxiliary MCUs, the system can operate normally when one MCU fails, effectively avoiding the risk of functional failure caused by single-point failures and improving the reliability of the system. At the same time, by adopting the real-time UART communication mode, fast and stable data transmission can be achieved between the main and auxiliary MCUs, ensuring rapid status diagnosis and function switching when a fault occurs, and reducing the response time. In addition, the data protection specification of the AUTOSAR standard is introduced to ensure effective protection and verification during data transmission, thereby enhancing functional safety and data integrity. The various data verification mechanisms used in the implementation, such as CRC and Alive Counter, ensure the reliability of data during transmission, timely discover and handle data errors, and further improve system stability. At the same time, the perfect fault diagnosis scheme provided can monitor the status of the main and auxiliary MCUs in real time, and feedback the diagnosis results in time, reduce the fault recovery time, and improve maintainability. Since the reliability and safety of the system are significantly improved, the probability of failure is reduced, thereby reducing the cost investment in the development and maintenance stages. Finally, the scheme of the present invention is applicable to a variety of chassis electronic controllers, with good adaptability and great market promotion potential. In summary, the present invention significantly improves the reliability and safety of the controller through redundant design, standardized data protection, real-time communication and a complete diagnostic mechanism, and solves the single point failure and data integrity problems existing in the background technology.

[0042] In all examples shown and described herein, any specific values ​​should be interpreted as merely exemplary and not as limiting, and thus other examples of the exemplary embodiments may have different values.

[0043] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A controller fault diagnosis and processing method, characterized in that: The method comprises the following steps: S1, establishing communication between the main MCU and the auxiliary MCU of the controller, using the main MCU to send an initialization signal to the auxiliary MCU to establish a communication link; S2, using the auxiliary MCU to obtain diagnostic data from the main MCU, the diagnostic data including working data and verification data generated by the main MCU during its normal working process; S3, using the auxiliary MCU to analyze the diagnostic data to determine whether the main MCU fails; S4: If it is determined through step S3 that the main MCU fails, the fault is handled according to a preset protection mechanism.

2. The controller fault diagnosis and processing method according to claim 1, characterized in that: The step S2 comprises: S21, using the main MCU to generate diagnostic data in a parallel data format and converting it into a serial data format; S22, sending the diagnostic data in serial data format to the auxiliary MCU through the UART protocol; S23, using the auxiliary MCU to reconvert the diagnostic data in the serial data format into diagnostic data in the parallel data format.

3. The controller fault diagnosis and processing method according to claim 1, characterized in that: The step S3 includes using the auxiliary MCU to analyze the diagnostic data to determine whether the main MCU fails, specifically including: S31, controlling the auxiliary MCU to enter a diagnostic mode; S32, caching the diagnostic data in the parallel data format; S33, check data integrity; S34, if the data is complete, it is determined that the main MCU has not failed; S35, if the data is incomplete, determining that the main MCU fails; S36, if it is determined that the main MCU fails, identify the fault and use the auxiliary MCU to handle the fault; S37, end the diagnosis.

4. The controller fault diagnosis and processing method according to claim 1, characterized in that: The step S4 includes at least one of the following operations: S41, sending a retransmission request for diagnosing data integrity failure; S42, in response to a failure of an Alive Counter, the control right of the main MCU is switched from the main MCU to the auxiliary MCU; S43, for abnormal signal fault, a fault alarm is issued; S44, ignore duplicate data in the diagnostic data; S45, requesting retransmission of lost data in the diagnostic data; S46, processing information delay of transmission data; S47, discarding redundant content in the received information; S48, verifying the identity of the sender in the received information; S49, reorganize the data order in the diagnostic data; S410, requesting retransmission of damaged data in the diagnostic data.

5. The controller fault diagnosis and processing method according to claim 1, characterized in that: After step S4, the method further comprises the following steps: S5, using the auxiliary MCU to feed back the diagnosis result to the main MCU.

6. The controller fault diagnosis and processing method according to claim 5, characterized in that: After step S5, the method further comprises the following steps: S6, ending the communication between the main MCU and the auxiliary MCU.

7. The controller fault diagnosis and processing method according to claim 3 is characterized in that: The step S33 comprises: Checking whether the diagnostic data is damaged by performing a cyclic redundancy check (CRC) calculation on the diagnostic data; If the diagnostic data is not damaged, calculating the checksum of the diagnostic data to preliminarily verify whether the diagnostic data is complete; If the diagnostic data is initially verified to be complete, then the completeness of the diagnostic data is further confirmed by comparing the working data and verification data between the main MCU and the auxiliary MCU.

8. The controller fault diagnosis and processing method according to claim 4, characterized in that: The step S41 comprises: Using the auxiliary MCU to perform CRC calculation on the received diagnostic data to confirm whether the diagnostic data has an integrity fault; If it is confirmed that there is a diagnostic data integrity fault, a retransmission request will be generated using the auxiliary MCU, and the retransmission request includes a request type identifier, a fault type identifier, a sequence number of a data packet that needs to be retransmitted, and current status information of the auxiliary MCU. The auxiliary MCU is used to send the generated retransmission request to the main MCU through the UART protocol.

9. The controller fault diagnosis and processing method according to claim 4, characterized in that: The step S49 comprises: When an information sequence error is detected in the received diagnostic data, extracting a data ID in each data packet of the diagnostic data using the MCU; The auxiliary MCU is used to rearrange the data packets of the diagnostic data according to the extracted data ID, thereby reorganizing the diagnostic data.

10. An automobile chassis controller, characterized in that: It includes a main MCU and an auxiliary MCU which are communicatively connected to each other. The main MCU is used to send an initialization signal to the auxiliary MCU to establish a communication link, and generate diagnostic data in a parallel data format and convert it into a serial data format. The auxiliary MCU is used to obtain diagnostic data from the main MCU, analyze the diagnostic data to determine whether the main MCU has a fault, and perform fault processing according to a preset protection mechanism.

Images