Fault processing method and system and domain controller

Abstract

The invention provides a fault processing method and system and a domain controller, and the method comprises the steps: collecting fault information in real time, the fault information at least comprising a fault count value, a fault state and a fault timestamp; writing the fault information into a preset fault list based on the fault count value; performing packaging processing on the fault information to obtain a fault information packet; and verifying the fault information packet based on the fault timestamp and the fault count value, so as to adopt corresponding fault processing based on the fault state after the verification is passed. According to the method provided by the invention, the technical problem that when communication abnormity or system jam occurs, the sequence of the fault state on a heartbeat packet or an error packet is disordered, so that a redundancy strategy is misjudged, and the fault state is repeatedly processed is effectively solved. And the robustness and the security of the security system are effectively enhanced.

Description

Technical Field

[0001] This application belongs to the field of automotive electronics technology, specifically relating to a fault handling method, system, and domain controller. Background Technology

[0002] Most current automotive domain controllers employ a combination of MCU (Microcontroller Unit) and SOC (System on Chip). The MCU monitors SOC fault information. Specifically, the SOC collects fault information and encapsulates it into error packets, which are then sent to the MCU in a triggered manner. The SoC's security daemon also periodically sends heartbeat packets to the MCU. Due to redundancy, these heartbeat packets also carry the fault information, ensuring that even if the MCU doesn't receive the error packet, it can still identify the fault requiring attention. Once the fault at the SOC is cleared, a fault-cleared status message is sent via a fault packet; subsequent heartbeat packets no longer carry fault information.

[0003] When multiple different faults occur in the SoC, these fault information are sequentially encapsulated into error packets and sent to the MCU one by one in a triggered manner. In addition, the SoC's security daemon periodically sends heartbeat packets containing the fault information with the highest priority. When that fault is cleared, the next highest priority fault information is placed in the heartbeat packet and sent out, ensuring that the most severe fault information is always processed first under the redundancy mechanism. Under the desired timing, whether in a single fault scenario or multiple fault scenarios, the error packets encapsulating fault information are triggered in real time, and the fault information carried in the heartbeat packet is generally sent out in the next cycle. This allows for knowing the latest status of the fault information.

[0004] However, when communication anomalies or system lag occur, the timing of heartbeat and error packet transmission becomes uncertain. This uncertainty means that the same fault state may appear in different order in heartbeat and error packets, leading to misjudgments in redundancy strategies and repeated processing of fault states, which can have a significant negative impact on the system. Summary of the Invention

[0005] This application proposes a fault handling method, system, and domain controller, aiming to solve the technical problem that when communication anomalies or system lag occur, the timing of heartbeat packets and error packets changes, causing the fault state to be disordered in the order of heartbeat packets or error packets, resulting in misjudgment of redundancy strategies, repeated processing of fault states, and causing a relatively large negative impact on the system.

[0006] Specifically, this application proposes a fault handling method, including: Real-time acquisition of fault information, which includes at least a fault count, a fault status, and a fault timestamp; writing the fault information into a preset fault list based on the fault count; encapsulating the fault information to obtain a fault information packet; and verifying the fault information packet based on the fault timestamp and the fault count, so that corresponding fault handling is carried out based on the fault status after successful verification.

[0007] In the above technical solution, the frequency and occurrence of faults can be clearly obtained through fault counts and fault timestamps, effectively avoiding time sequence errors and repeated fault handling. During fault handling, it can be determined whether the fault status is the latest fault status, thereby effectively reducing the probability of fault misjudgment and shortening the fault investigation time. The fault timestamps and fault counts can effectively prevent the omission of fault information, ensuring the consistency and integrity of fault information. The fault information packet is verified based on the fault timestamps and fault counts, ensuring the validity of the fault information before processing and enhancing the robustness and security of the functional safety system.

[0008] As one implementation method, writing the fault information into a preset fault list based on the fault count value includes: Based on a preset fault counting threshold and the fault count value, when the fault count value reaches the fault counting threshold, it is determined whether the write protection lock of the common counting variable is released. If so, the write protection lock is activated and the fault count value is reset to zero; otherwise, it waits for the write protection lock of the common counting variable to be released. The reset fault count value, the fault timestamp, and the fault status are written into the preset fault list.

[0009] By introducing a write-protected lock on a shared counter variable, multiple threads or processes can be prevented from modifying the fault count value simultaneously, thus preventing data races and conflicts. The fault count value can only be updated when the write-protected lock is released, ensuring data consistency. The fault count value is reset to zero when it reaches a preset fault count threshold, effectively managing and monitoring the number of faults. Resetting the fault count to zero prevents excessive fault records from affecting subsequent fault detection and processing, avoiding the accumulation of fault data beyond a reasonable range, thereby improving system response efficiency and the effectiveness of data processing.

[0010] Furthermore, the step of writing the fault information into a preset fault list based on the fault count value also includes: When the fault count value does not reach the fault count threshold, it is determined whether the write protection lock of the common count variable is released. If so, the protection lock is activated and the fault count value is incremented by one; otherwise, it waits for the write protection lock of the common count variable to be released. The incremented fault count value, the fault timestamp, and the fault status are written into the preset fault list.

[0011] The increment of the fault count value represents the number of times the fault information is sent. By adjusting the fault count value, the number of times the fault information is sent can be effectively recorded in real time, thereby achieving accurate fault tracking and recording.

[0012] Furthermore, the encapsulation process for the fault information includes: Based on the fault status and the fault timestamp, the fault information in the preset fault list is prioritized to obtain the highest priority fault information; the highest priority fault information is then encapsulated to obtain a fault information package.

[0013] By prioritizing fault information, the system ensures that the most urgent or critical faults are processed first. Faults with earlier timestamps or more severe conditions are given higher priority, ensuring timely fault response. Encapsulating fault information avoids the transmission of redundant information and improves the efficiency of fault information transmission.

[0014] Furthermore, the verification of the fault information packet based on the fault timestamp and the fault count value includes: The fault information packet is used to determine whether the local fault count value is less than the fault count value. If so, the fault information packet is deemed to have passed verification, and the local fault list is updated based on the fault information packet. Otherwise, the fault count value is determined to be equal to a preset value. If so, the fault information packet is further verified based on the fault timestamp. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is reported as invalid.

[0015] By comparing the local fault count with the count in the fault information packet, duplicate fault information packets can be effectively prevented from entering the local fault list, thereby avoiding the repeated processing of invalid or redundant fault states.

[0016] Furthermore, the verification of the fault information packet based on the fault timestamp and fault count value also includes: Determine whether the fault timestamp is greater than the local timestamp. If so, the fault information packet is verified and updated to the local fault list. Otherwise, the fault information packet is deemed to have failed verification and is reported as invalid.

[0017] Further verification of the fault information packet by using the fault timestamp ensures that the fault information packet is the latest rather than a historical fault information packet, thereby improving the accuracy of fault handling.

[0018] Based on the same inventive concept, this application also proposes a fault handling system, which includes at least a transmitting end and a receiving end; the transmitting end includes at least an information acquisition module, an information storage module, and a fault encapsulation module.

[0019] The information acquisition module is used to collect fault information in real time. The fault information includes at least the fault count value, fault status, and fault timestamp.

[0020] The information storage module is used to write the fault information into a preset fault list based on the fault count value.

[0021] Furthermore, the fault encapsulation module is used to encapsulate the fault information to obtain a fault information package.

[0022] Furthermore, the receiving end includes at least a fault handling module; The fault handling module is used to verify the fault information packet based on the fault timestamp and the fault count value, so that when the verification is successful, corresponding fault handling is carried out based on the fault status.

[0023] Furthermore, the receiving end also includes a counter value verification module and a time verification module; the counter value verification module is used to determine whether the local fault counter value is less than the fault counter value. If so, the fault information packet is deemed to have passed verification; otherwise, it determines whether the fault counter value is equal to a preset value. If so, the fault information packet is input into the time verification module; otherwise, the fault information packet is deemed to have failed verification and is reported as invalid. The time verification module is used to determine whether the fault timestamp is greater than the local timestamp. If so, the fault information packet is deemed to have passed verification and the fault information packet is updated to the local fault list; otherwise, the fault information packet is deemed to have failed verification and is reported as invalid.

[0024] Based on the same inventive concept, this application also proposes a domain controller, which includes at least a SOC and an MCU, and executes the fault handling method through communication between the SOC and the MCU.

[0025] Compared with the prior art, this application has at least the following beneficial effects: This application effectively solves the technical problem that changes in the timing of heartbeat packets and error packets containing fault information lead to disordered order of fault states in heartbeat or error packets, resulting in misjudgment of redundancy strategies and repeated processing of fault states, causing significant negative impacts on the system. By using fault counts and fault timestamps, the frequency and occurrence of faults can be clearly obtained, effectively avoiding time sequence disorder and repeated execution of fault processing. During fault processing, it can determine whether the fault state is the latest fault state, thereby effectively reducing the probability of misjudgment and shortening the fault investigation time. Fault timestamps and fault counts effectively prevent the omission of fault information, ensuring the consistency and integrity of fault information. Verification of fault information packets based on fault timestamps and fault counts ensures the validity of fault information before processing, enhancing the robustness and security of the functional safety system. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a fault handling method in an embodiment of this application.

[0027] Figure 2 This is a schematic diagram of a fault handling system shown in an embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the domain controller structure shown in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices. Example 1:

[0031] Please refer to Figure 1 The fault handling method mainly includes steps S100 to S400.

[0032] Step S100 includes: real-time collection of fault information, which includes at least a fault count, a fault status, and a fault timestamp. The fault information may also include a fault ID to uniquely identify each fault. The fault status can be 0 or 1, where a fault status of 0 indicates that the device is currently operating normally or the fault has been repaired, and there is no abnormality; a fault status of 1 indicates that a fault or abnormality exists. The fault timestamp is the timestamp of the moment the fault status changes, for example, 202505121223. The fault count value records the number of times a fault has been sent.

[0033] Step S200 includes: writing the fault information into a preset fault list based on the fault count value. Specifically, the fault count value is compared with a preset fault count threshold. When the fault count value reaches the preset fault count threshold, the fault count value is reset to zero; when the fault count value does not reach the preset fault count threshold, the fault count value is incremented. After adjusting the fault count value, the fault timestamp, fault count value, and fault status are updated to the preset fault list.

[0034] Step S300 includes: encapsulating the fault information to obtain a fault information packet. Before encapsulation, this may further include prioritizing the fault information in the preset fault list to obtain the highest priority fault information. The highest priority fault information is then encapsulated. This mainly involves encapsulating the fault status, fault ID, fault timestamp, and fault count value from the preset fault list to obtain the fault information packet.

[0035] Step S400 includes: verifying the fault information packet based on the fault timestamp and the fault count value, so that corresponding fault handling is taken based on the fault state after successful verification. Specifically, by detecting the fault state in the fault information packet, when the fault state indicates a fault exists, the local fault count value is compared with the fault count value. If the local fault count value is less than the fault count value, the fault state is considered the latest fault state. If the local fault count value is greater than or equal to the fault count value, further verification is performed based on the fault timestamp. When the fault timestamp is greater than the local fault timestamp, the fault state is determined to be the latest fault state. Corresponding fault handling is then taken based on this latest fault state, thereby achieving precise fault handling. This can primarily be implemented in the domain controller of a vehicle's cockpit or intelligent driving system. This allows for real-time recording of fault information from various modules within the domain controller and the implementation of corresponding fault handling, ensuring the stability and reliability of the domain controller.

[0036] For example, fault information from other functional modules can be collected in real time in the vehicle domain controller via a daemon process of the System-on-Chips (SOC). This information can include at least fault ID, fault status, fault timestamp, and fault count. At the SOC, the fault count is compared with a preset fault count threshold. When the fault count reaches the threshold, it is reset to zero; when it does not, it is incremented. After adjustment, the fault timestamp, fault count, and fault status are updated to a preset fault list. Fault information is prioritized in the preset fault list to obtain the highest-priority fault information. The fault status, fault ID, fault timestamp, and fault count of this highest-priority fault information are encapsulated to obtain a fault information packet. The SOC transmits this fault information packet to the MCU of the domain controller. Upon receiving the packet, the MCU verifies it based on its local fault count and timestamp, and performs appropriate fault handling based on the fault status after successful verification.

[0037] In some embodiments, writing the fault information into a preset fault list based on the fault count value includes: Based on a preset fault counting threshold and the fault count value, when the fault count value reaches the fault counting threshold, it is determined whether the write protection lock of the common counting variable is released. If so, the write protection lock is activated and the fault count value is reset to zero; otherwise, it waits for the write protection lock of the common counting variable to be released. The reset fault count value, the fault timestamp, and the fault status are written into the preset fault list.

[0038] When the fault count value does not reach the fault count threshold, it is determined whether the write protection lock of the common count variable is released. If so, the protection lock is activated and the fault count value is incremented by one; otherwise, it waits for the write protection lock of the common count variable to be released. The incremented fault count value, the fault timestamp, and the fault status are written into the preset fault list.

[0039] The preset fault count threshold can be set to 255. That is, when the fault count reaches 255 and the write protection lock on the common count variable is released, the write protection lock is activated, and the fault count is reset to zero. If the fault count does not reach 255, for example, if the fault count is 240, then when the write protection lock on the common count variable is released, the write protection lock is activated, and the fault count is incremented by one, i.e., the fault count is changed to 241. The adjusted fault count, along with the fault timestamp and fault status, is written to the preset fault list.

[0040] Preferably, the process of encapsulating the fault information includes: Based on the fault status and the fault timestamp, the fault information in the preset fault list is prioritized to obtain the highest priority fault information; the highest priority fault information is then encapsulated to obtain a fault information package.

[0041] By prioritizing fault information, the highest priority faults can be processed first. For example, sensor faults or system faults can be processed first, while low priority faults may include warning faults, etc.

[0042] Preferably, the verification of the fault information packet based on the fault timestamp and the fault count value includes: The fault information packet is used to determine whether the local fault count value is less than the fault count value. If so, the fault information packet is deemed to have passed verification, and the local fault list is updated based on the fault information packet. Otherwise, the fault count value is determined to be equal to a preset value. If so, the fault information packet is further verified based on the fault timestamp. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is reported as invalid.

[0043] For example, when the MCU receives a fault information packet, it first checks if the fault status of this packet has changed. If the fault status has changed (from 0 to 1), the fault information packet is retrieved from the fault list. It then checks if the local fault count value of this packet is less than the currently received fault count value. If so, the fault information packet is new, and the safety handling for this fault can be executed directly. Otherwise, it needs to further check if the obtained fault count value is 0. This condition is necessary because counting to 255 will roll back to 0. Since both the value before and after the rollback are greater than 0, it's not effective to determine whether a fault information packet with a fault count value of 0 is historical or new based solely on the local fault count value. Therefore, further verification using a fault timestamp is required.

[0044] Preferably, the verification of the fault information packet based on the fault timestamp and fault count value further includes: Determine whether the fault timestamp is greater than the local timestamp. If so, the fault information packet is verified and updated to the local fault list. Otherwise, the fault information packet is deemed to have failed verification and is reported as invalid.

[0045] By determining whether the local fault timestamp is less than the received fault timestamp, if so, it indicates that the received fault information packet is up-to-date, and the corresponding security procedure can be executed. Otherwise, it indicates that the fault information packet is not up-to-date, and the corresponding security procedure cannot be executed based on the fault status of this fault information packet. Example 2:

[0046] Please refer to Figure 2 This application also proposes a system employing the fault handling method described in Embodiment 1, which mainly includes a transmitting end and a receiving end; wherein, the transmitting end includes at least an information acquisition module, an information storage module, and a fault encapsulation module.

[0047] The information acquisition module is used to collect fault information in real time. The fault information includes at least a fault count, a fault status, and a fault timestamp. The fault information may also include a fault ID. Those skilled in the art can add or remove the fault information as needed, and are not limited to this.

[0048] The information storage module is used to write the fault information into a preset fault list based on the fault count value. Before writing the fault information into the preset fault list, the module further includes comparing the fault count value with a preset fault count threshold, thereby adjusting the fault count value.

[0049] Furthermore, the fault encapsulation module is used to encapsulate the fault information to obtain a fault information packet. Specifically, the fault encapsulation module encapsulates the fault ID, fault status, fault timestamp, and fault count value into a fault information packet, which is then transmitted to the receiving end.

[0050] Furthermore, the receiving end includes at least a fault processing module; the fault processing module is used to verify the fault information packet based on the fault timestamp and the fault count value, so as to take corresponding fault processing based on the fault status after the verification is successful.

[0051] The receiving end further includes a counter value verification module and a time verification module. The counter value verification module determines whether the local fault counter value is less than the fault counter value. If so, the fault information packet is deemed to have passed verification. Otherwise, it determines whether the fault counter value is equal to a preset value. If so, the fault information packet is input into the time verification module. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is reported as invalid. The time verification module determines whether the fault timestamp is greater than the local timestamp. If so, the fault information packet is deemed to have passed verification, and the fault information packet is updated to the local fault list. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is reported as invalid.

[0052] After receiving the fault information packet, the receiving end detects whether the fault state in the fault information packet has changed, that is, whether the fault state has changed from 0 to 1. If so, the fault information packet is verified based on the fault count value and the fault timestamp to ensure that the fault information packet is the latest fault information packet, thereby effectively avoiding the repeated processing of fault states. Example 3:

[0053] Please refer to Figure 3 This application also proposes a domain controller, which includes at least a System-on-a-Chip (SOC) and an MCU, and executes the fault handling method described in Embodiment 1 through communication between the SOC and the MCU.

[0054] In the domain controller, data communication between the SOC and MCU can be achieved through communication protocols such as data bus, serial communication, I2C, or SPI for data exchange and collaboration. The SOC may include a security daemon process, which performs real-time acquisition and updating of fault information and stores the acquired fault information. The MCU is primarily responsible for taking corresponding fault handling actions based on the fault information packets transmitted by the SOC. In this application, the SOC and MCU cooperate through corresponding firmware, hardware, or software instruction sets to achieve fault information acquisition, storage, encapsulation, and fault handling. For example, the SOC processor may execute complex fault detection algorithms, acquiring and analyzing data from sensors in real time. The MCU can then control the system hardware to perform emergency shutdown, alarm, and notification operations according to the SOC's instructions. Furthermore, the domain controller may also include a storage medium storing the instructions executed by the SOC and MCU. This storage medium can communicate and transmit data in different ways; for example, the SOC and MCU may exchange data through a shared storage area or use wireless / wired methods for remote updates and data synchronization. The storage medium can be in the form of magnetic media, optical media, semiconductor media, etc., including but not limited to hard disks, solid-state drives (SSDs), USB flash drives, optical discs, or other storage devices. Computer program instructions stored on these media can be loaded and executed by SOCs and MCUs to achieve the functions described in the fault handling method.

[0055] In summary, this application effectively solves the technical problem that changes in the timing of heartbeat packets and error packets containing fault information lead to disordered order of fault states in heartbeat or error packets, resulting in misjudgment of redundancy strategies and repeated processing of fault states, causing significant negative impacts on the system. By using fault counts and fault timestamps, the frequency and occurrence of faults can be clearly obtained, effectively avoiding time sequence disorder and repeated execution of fault processing. During fault processing, it can determine whether the fault state is the latest fault state, thereby effectively reducing the probability of misjudgment and shortening the fault investigation time. Fault timestamps and fault counts effectively prevent the omission of fault information, ensuring the consistency and integrity of fault information. Verification of fault information packets based on fault timestamps and fault counts ensures the validity of fault information before processing, enhancing the robustness and safety of the functional safety system.

[0056] In the several embodiments provided in this application, it will be understood that each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.

[0057] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0058] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.

Claims

1. A failure handling method characterized by, The method comprises the following steps: collecting fault information in real time, wherein the fault information at least comprises a fault count value, a fault state and a fault timestamp; writing the fault information into a preset fault list based on the fault count value; performing encapsulation processing on the fault information to obtain a fault information package; verifying the fault information package based on the fault count value and the fault timestamp, and taking corresponding fault processing based on the fault state when the verification is passed.

2. The failure handling method according to claim 1, characterized by, The step of writing the fault information into a preset fault list based on the fault count value comprises the following steps: based on a preset fault count threshold and the fault count value, when the fault count value reaches the fault count threshold, judging whether a write protection lock of a public count variable is released, if yes, starting the write protection lock and resetting the fault count value to zero, otherwise, waiting for the write protection lock of the public count variable to be released; and writing the reset fault count value, the fault timestamp and the fault state into the preset fault list.

3. The failure handling method according to claim 2, characterized by, The step of writing the fault information into a preset fault list based on the fault count value further comprises the following steps: when the fault count value does not reach the fault count threshold, judging whether a write protection lock of a public count variable is released, if yes, starting the write protection lock and increasing the fault count value by one, otherwise, waiting for the write protection lock of the public count variable to be released; and writing the increased fault count value, the fault timestamp and the fault state into the preset fault list. The step of performing encapsulation processing on the fault information comprises the following steps:

4. The failure handling method according to claim 3, characterized by, performing priority sorting on the fault information in the preset fault list based on the fault state and the fault timestamp to obtain a highest priority fault information; and performing encapsulation processing on the highest priority fault information to obtain a fault information package. The step of verifying the fault information package based on the fault timestamp and the fault count value comprises the following steps:

5. The failure handling method according to claim 4, characterized by, judging whether a local fault count value is less than the fault count value through the fault information package, if yes, judging that the fault information package is verified, and updating the fault information package to a local fault list based on the fault information package; otherwise, judging whether the fault count value is equal to a preset value, if yes, further verifying the fault information package based on the fault timestamp, otherwise, judging that the fault information package is not verified, and feeding back that the fault information package is invalid. The step of verifying the fault information package based on the fault timestamp and the fault count value further comprises the following steps: judging whether the fault timestamp is greater than a local timestamp, if yes, the fault information package is verified, and updating the fault information package to the local fault list; otherwise, judging that the fault information package is not verified, and feeding back that the fault information package is invalid.

6. The failure handling method according to claim 5, wherein The system at least comprises a sending end and a receiving end; the sending end at least comprises an information collection module, an information storage module and a fault encapsulation module; the information collection module is used for collecting fault information in real time, wherein the fault information at least comprises a fault count value, a fault state and a fault timestamp; 7. A system based on the fault handling method according to any one of claims 1 to 6, characterized in that the information storage module is used for writing the fault information into a preset fault list based on the fault count value; ​ ​ ​ Furthermore, the fault encapsulation module is used to encapsulate the fault information to obtain a fault information package.

8. The system for fault handling method according to claim 7, characterized in that, The receiving end includes at least a fault handling module; The fault handling module is used to verify the fault information packet based on the fault timestamp and the fault count value, so that when the verification is successful, corresponding fault handling is carried out based on the fault status.

9. The system for fault handling method according to claim 8, characterized in that, The receiving end also includes a count value verification module and a time verification module; The counting value verification module is used to determine whether the local fault count value is less than the fault count value. If so, the fault information packet is determined to have passed verification; otherwise, it is determined whether the fault count value is equal to a preset value. If so, the fault information packet is input into the time verification module. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is reported as invalid. The time verification module is used to determine whether the fault timestamp is greater than the local timestamp. If so, the fault information packet is determined to have passed verification, and the fault information packet is updated to the local fault list. Otherwise, the fault information packet is deemed to have failed verification, and the fault information packet is deemed invalid.

10. A domain controller, characterized by The domain controller includes at least a System-on-a-Chip (SOC) and an MCU, and executes the fault handling method as described in any one of claims 1-6 through communication between the SOC and the MCU.

Images