Multi-threaded software and hardware fault analysis method and device applied to lockstep core

Abstract

The present invention provides a multi-threaded software and hardware fault analysis method and device applied to a lockstep core, relating to the technical field of software and hardware fault monitoring of an ECU, comprising: detecting the internal hardware of a multi-core processor and the software process of each thread in a current cycle respectively; if the internal hardware has a fault in the current cycle, storing and backing up first software and hardware information at a first current moment according to a preset fault type, and resetting the internal hardware; if the software process has a fault in the current cycle, storing and backing up second software and hardware information at a second current moment according to a preset fault type, and resetting the software process; analyzing the software and hardware faults of the lockstep core based on the first software and hardware information and the second software and hardware information; and alleviating the technical problem of data interference and data pollution caused by subsequent fault analysis using such backup data by unifying hardware fault detection and software fault detection under the same timing.

Description

Technical Field

[0001] The present invention relates to the technical field of ECU software and hardware fault monitoring, and in particular to a multi-threaded software and hardware fault analysis method and device applied to a lockstep core. Background Art

[0002] As the number of ECUs and lines of code in self-driving cars continues to increase, the complexity of the entire automotive system is also increasing. At the same time, the complexity of the self-driving system and the diversity of software algorithms have led to an increasing number of parts requiring design-in of expected functional safety. Automotive functional safety has become an issue that cannot be ignored.

[0003] Current international standards explicitly mandate the use of watchdog timers for software time and program flow monitoring to enhance the functional safety of the entire hardware and software system. Currently, multi-core processors incorporate the Lock-Step function, which has become a hardware redundancy safety design in autonomous driving and one of the measures to achieve high diagnostic coverage.

[0004] However, in current system diagnostic processing, when system hardware or software fails, the overall hardware and software system cannot achieve unified backup processing and unified reset operations, resulting in misaligned fault data between multiple cores and multiple threads, causing data interference and data pollution for subsequent fault analysis and fault recovery. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a multi-threaded hardware and software fault analysis method and device applied to a lock-step core, by unifying hardware fault detection and software fault detection under the same timing, and simultaneously backing up and aligning hardware and software data when any fault occurs, so as to alleviate the technical problem of data interference and data pollution caused by subsequent fault analysis using such backup data.

[0006] In a first aspect, an embodiment provides a multi-threaded software and hardware fault analysis method applied to a lockstep core. Each ECU includes a multi-core processor, each multi-core processor includes at least one lockstep core, and each lockstep core is configured with multiple threads. The method is applied to the lockstep core and includes:

[0007] In a current cycle, the internal hardware of the multi-core processor and the software process of each thread are respectively detected; wherein the detection of the internal hardware and the software process occurs in the same cycle;

[0008] If the internal hardware has a processing logic fault in the current cycle, first software and hardware information at the first current moment is stored and backed up according to a preset fault type, and the internal hardware is reset; wherein the first software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when the hardware fault occurs at the first current moment;

[0009] If a software process of at least one thread in the lockstep core fails in a current cycle, second software and hardware information at a second current moment is stored and backed up according to a preset fault type, and the software process is reset; wherein the second software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when a software fault occurs at the second current moment;

[0010] Analyze software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

[0011] In an optional embodiment, the step of detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle includes:

[0012] The fault detection operation on the internal hardware of the multi-core processor and the fault detection operation on the software process of each thread are associated and executed in the same current cycle, so that the hardware fault detection result and the software fault detection result of the lock-step core are in the same time sequence.

[0013] In an optional embodiment, if the internal hardware has a processing logic failure in the current cycle, the step of storing and backing up the first software and hardware information at the first current moment according to a preset failure type and resetting the internal hardware includes:

[0014] Under the function of the lockstep core, detecting whether there is a processing logic fault in the internal hardware of the multi-core processor in the current cycle;

[0015] If there is a hardware failure, the first software and hardware information at the first current moment is stored and backed up according to the preset fault type, the internal hardware of the multi-core processor is reset, and the software and hardware system corresponding to the ECU is restarted; wherein, the first software and hardware information includes hardware data and software data that meet the requirements of the preset fault type at the first current moment.

[0016] In an optional embodiment, if a software process of at least one thread in the lockstep core fails in a current cycle, the step of storing and backing up second software and hardware information at a second current moment according to a preset fault type and resetting the software process includes:

[0017] Based on a comparison result of the actual execution count and the preset execution count of each thread of the lockstep core within a preset period, determining whether the software process of each thread has a fault in the current period; wherein the functional safety level of each thread corresponds to the preset execution count within the corresponding preset period;

[0018] If a fault exists, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset; wherein the second software and hardware information includes hardware data and software data that meet the preset fault type requirements at the second current moment.

[0019] In an optional embodiment, if a fault occurs, the step of storing and backing up the second software and hardware information at the second current moment according to a preset fault type and resetting the software process further includes:

[0020] Refreshing the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle;

[0021] If a software process in the current thread has a fault in the current cycle, determining whether the hardware trigger value is greater than zero;

[0022] If the hardware trigger value is greater than zero, the watchdog is fed during the hardware watchdog interrupt cycle, the hardware trigger value is reduced by one, and then the step of determining whether the hardware trigger value is greater than zero is performed;

[0023] If the hardware trigger value is less than zero, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset.

[0024] In an optional embodiment, the step of refreshing the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle includes:

[0025] If the software process of the current thread fails in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to zero;

[0026] If the software process of the current thread does not have a fault in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to an initial value; wherein the initial value is determined based on the fault tolerance requirement and fault recovery time requirement of each thread.

[0027] In an optional embodiment, before the step of detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle, the method further includes:

[0028] Initialize the peripherals of the hardware watchdog, and configure the interrupt cycle of the hardware watchdog and the fault detection configuration information corresponding to each functional safety level.

[0029] In a second aspect, an embodiment provides a multi-threaded software and hardware fault analysis device applied to a lock-step core. Each ECU includes a multi-core processor, each multi-core processor includes at least one lock-step core, and each lock-step core is configured with multiple threads. The device is applied to the lock-step core and includes:

[0030] a detection module, configured to detect the internal hardware of the multi-core processor and the software process of each thread in a current cycle; wherein the detection of the internal hardware and the software process occurs in the same cycle;

[0031] a hardware fault backup module, configured to store and back up first hardware and software information at a first current moment according to a preset fault type, and reset the internal hardware if a processing logic fault occurs in the internal hardware during a current cycle; wherein the first hardware and software information is used to represent hardware data and software data corresponding to the preset fault type when a hardware fault occurs at the first current moment;

[0032] a software fault backup module, configured to store and back up second software and hardware information at a second current moment according to a preset fault type, and reset the software process if a software process of at least one thread in the lockstep core fails in a current cycle; wherein the second software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when the software fault occurs at the second current moment;

[0033] An analysis module analyzes software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

[0034] In a third aspect, an embodiment provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the computer program, the steps of the method described in any of the aforementioned embodiments are implemented.

[0035] In a fourth aspect, an embodiment provides a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the steps of the method described in any one of the aforementioned implementation methods.

[0036] Embodiments of the present invention provide a multi-threaded hardware and software fault analysis method and apparatus for a lock-step core. Hardware and software fault detection for the lock-step core are placed within the same timing cycle. If a hardware fault occurs within the cycle, hardware and software data of a predetermined fault type corresponding to the time the hardware fault occurs are backed up, and the hardware state is reset to eliminate the hardware fault. The backup data can now determine the time the hardware fault occurred within the cycle and the specific states of the hardware and software data of the fault type encountered at that time. Furthermore, if a software fault occurs within the cycle, hardware and software data of the predetermined fault type corresponding to the time the software fault occurred are backed up, and the software state is reset. The backup data can now determine the time the software fault occurred within the cycle and the specific states of the software data of the fault type encountered at that time. Based on the first hardware and software information and the second hardware and software information, the times at which the hardware and software faults occurred, respectively, within the current timing cycle, as well as the hardware and software data of the predetermined type when each fault occurred, can be determined. This allows alignment and unification of the hardware and software data, enabling effective analysis of hardware and software faults in the lock-step core.

[0037] Other features and advantages of the present disclosure will be set forth in the following description, or some features and advantages may be inferred or unambiguously determined from the description, or may be learned by practicing the above-mentioned technology of the present disclosure.

[0038] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1 A flow chart of a multi-threaded software and hardware fault analysis method applied to a lockstep core provided by an embodiment of the present invention;

[0041] Figure 2 A schematic diagram of the application architecture of a multi-threaded software and hardware fault analysis method applied to a lockstep core provided by an embodiment of the present invention;

[0042] Figure 3 A flowchart of another multi-threaded software and hardware fault analysis method applied to a lockstep core provided by an embodiment of the present invention;

[0043] Figure 4 A functional module diagram of a multi-threaded software and hardware fault analysis device applied to a lockstep core provided by an embodiment of the present invention;

[0044] Figure 5 A schematic diagram of the hardware architecture of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0045] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0046] Current international standards explicitly mandate the use of watchdog timers for software time and program flow monitoring to enhance the functional safety of the entire hardware and software system. Currently, multi-core processors incorporate the Lock-Step function, which has become a hardware redundancy safety design in autonomous driving and one of the measures to achieve high diagnostic coverage.

[0047] However, in current system diagnostic processing, watchdog monitoring of multi-core and multi-threaded systems or lock-step core fault diagnosis are not used in a unified and combined manner, resulting in misaligned fault data between multi-core and multi-threaded systems, causing data interference and data pollution for subsequent fault analysis and fault recovery.

[0048] Based on this, an embodiment of the present invention provides a multi-threaded hardware and software fault analysis method and device applied to a lock-step core, which can unify hardware fault detection and software fault detection under the same timing, and simultaneously back up and align the hardware and software data when any fault occurs, so that the backed-up hardware and software data has dual identification of the hardware and software fault type and the time of fault occurrence, and has a more accurate analysis effect when the backed-up hardware and software data is subsequently used for fault analysis.

[0049] To facilitate understanding of this embodiment, a multi-threaded software and hardware fault analysis method for a lock-step core disclosed in an embodiment of the present invention is first described in detail. This method can be applied to a lock-step core. In an actual vehicle, multiple ECUs are included, each ECU includes a multi-core processor, each multi-core processor includes at least one lock-step core, and each lock-step core is configured with multiple threads. The method provided in this embodiment of the present invention can be used to monitor and analyze software and hardware faults in the ECU, in particular, software and hardware faults in the lock-step core and its configured threads in the ECU.

[0050] Figure 1A flowchart of a multi-threaded software and hardware fault analysis method applied to a lockstep core is provided in an embodiment of the present invention.

[0051] like Figure 1 As shown, the method includes the following steps:

[0052] Step S102 : In the current cycle, the internal hardware of the multi-core processor and the software process of each thread are detected respectively.

[0053] Among them, the detection of internal hardware and software processes occurs in the same cycle; this cycle can be set according to actual conditions, such as a value of 20 milliseconds; placing the internal hardware detection and the software process detection of each thread in the same cycle makes the software fault detection results and the hardware fault detection results have time correlation, that is, the software fault detection results and the hardware fault detection results at this time can be synchronously compared.

[0054] Step S104: If there is a processing logic failure in the internal hardware in the current cycle, the first software and hardware information at the first current moment is stored and backed up according to a preset failure type, and the internal hardware is reset.

[0055] Among them, the first hardware and software information is used to represent the hardware data and software data corresponding to the preset fault type when a hardware fault occurs at the first current moment; the first hardware and software information can know the time when the hardware fault occurs and the values ​​of the hardware data and software data corresponding to the preset fault type in the case of the hardware fault.

[0056] It should be noted that if there is a logical processing failure in the internal hardware of the multi-core processor, the internal hardware of the multi-core processor is reset after the backup is stored. After the reset operation, the hardware failure is eliminated by default, that is, if there is no hardware failure, the subsequent steps will continue.

[0057] Step S106 : If a software process of at least one thread in the lock-step core fails in the current cycle, the second software and hardware information at the second current moment is stored and backed up according to a preset failure type, and the software process is reset.

[0058] Among them, the second hardware and software information is used to represent the hardware data and software data corresponding to the preset fault type when a software fault occurs at the second current moment; the second hardware and software information can know the time when the software fault occurs and the values ​​of the hardware data and software data corresponding to the preset fault type in the case of the software fault.

[0059] It should be noted that if there is a software process failure in at least one thread of the lock-step core of the multi-core processor, the software process of the multi-core processor is reset after the backup is stored. After the reset operation, it is assumed that the software failure is eliminated, that is, if there is no software failure, the subsequent steps are continued.

[0060] Step S108 : analyzing the software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

[0061] It should be noted that the first software and hardware information and the second software and hardware information both have the time when the corresponding fault occurs, as well as the presentation of software data and hardware data of the specific fault type corresponding to each fault occurrence time. Based on such first software and hardware information and the second software and hardware information, a more accurate analysis of the fault can be performed, and such data will not interfere with each other and cause data pollution.

[0062] In a preferred embodiment of actual application, hardware fault detection and software fault detection of the lock-step core are placed in the same timing cycle. If a hardware fault occurs within the cycle, the hardware and software data of the predetermined fault type corresponding to the time when the hardware fault occurs are backed up, and the hardware state is reset to eliminate the hardware fault. At this time, the backup data can be used to determine the time when the hardware fault occurs in the current cycle and the specific status of the hardware and software data of the fault type encountered at that time. On this basis, if a software fault occurs within the cycle, the hardware and software data of the predetermined fault type corresponding to the time when the software fault occurs are backed up, and the software state is reset. Here, the backup data can be used to determine the time when the software fault occurs in the current cycle and the specific status of the software data of the fault type encountered at that time. Based on the first hardware and software information and the second hardware and software information, the time when the hardware fault and software fault respectively occur in the current timing cycle, as well as the predetermined type of hardware and software data when each fault occurs, can be determined, thereby achieving alignment and unification of the hardware and software data, and effectively analyzing the hardware and software faults of the lock-step core.

[0063] As an optional embodiment, the architecture of the multi-threaded software and hardware fault analysis method applied to the lock-step core can be as follows: Figure 2As shown, each ECU includes a multi-core processor consisting of multiple cores, each with multiple threads. For example, in an n-core automotive processor, Core0, Core1, Core2, and Core3 are lockstep cores, enabling the Lock-Step function. Coren does not support Lock-Step. Lock-Step fault detection is enabled for Core0 through Core3 to ensure hardware system safety. Based on system software requirements, each core can be configured as multiple threads, with different threads achieving different functional safety levels.

[0064] The hardware-software fusion monitoring module includes a Lock-Step functional fault detection module and a watchdog cycle monitoring module (WdgM) based on the NeuSAR platform. The WdgM module performs cycle monitoring on all threads of all cores to ensure that all software threads of the processor are within the watchdog monitoring range to ensure the reliability of software operation.

[0065] In actual applications, when the ECU executes a program, due to unknown faults, unexpected resource and time consumption, etc., the program execution of the critical thread may time out, the logical state of the critical thread may switch incorrectly, or the program may run away. Once this phenomenon occurs, the software fault must be troubleshooted. Due to the multi-core and multi-threaded architecture of the automotive autonomous driving system, different ASIL levels are divided according to the functional safety level, including four levels, namely A, B, C, D and QM, of which A is the lowest safety level and D is the highest safety level. The higher the ASIL level, the greater the risk of harm. QM is sufficient to comply with normal quality management. Threads with different functional safety levels will be set with different execution times within a preset cycle. The watchdog monitoring logic (software watchdog) will provide different monitoring measures for threads with different safety levels based on this.

[0066] As an optional embodiment, for threads with the highest functional safety level, when the thread is blocked or runs away, the watchdog monitoring should immediately take fault action to ensure the safety of the software and hardware systems; for threads at the QM level or lower level, the watchdog monitoring needs to reserve fault self-recovery time and have a fault-tolerant mechanism to ensure the robustness and stability of the entire software system.

[0067] For current multi-core processors, the Lock-Step function offers faster error detection and higher error coverage, covering a wide range of error types, including hardware, transient, and persistent. This overcomes the limitation of the watchdog timer, which can only monitor software program logic. Furthermore, this function does not consume additional processor software resources, requires no additional software overhead, has no impact on storage space, and occupies almost no Flash or RAM space. By reducing the number of hardware components and connections, hardware reliability is improved compared to using two independent MCUs, and fault diagnosis capabilities are enhanced. Faults are detected at their source and the moment they first occur, eliminating the need for latent faults. Software reliability is also improved, eliminating the need for dual CPU communication and data synchronization, reducing data comparison and decision-making logic, and reducing the complexity of software verification.

[0068] Before step S102, the method provided by the embodiment of the present invention further includes initialization and specific information configuration, including:

[0069] Step 1.1) Initialize the peripherals of the hardware watchdog, configure the interrupt cycle of the hardware watchdog and the fault detection configuration information corresponding to each functional safety level.

[0070] First, initialize the hardware watchdog peripheral. This primarily involves configuring the window watchdog's interrupt cycle (i.e., the watchdog feeding period) and functional safety-related fault detection. This interrupt cycle can be set to, for example, 16 milliseconds or 64 milliseconds, depending on the specific situation. The fault detection configuration information represents actual hardware failure scenarios related to engineering safety. This fault detection configuration information indicates which hardware failures constitute hardware failures at different functional safety levels.

[0071] Secondly, the NeuSAR software's window development specification management module, WdgM, is initialized and enabled, turning on the cycle monitoring function for all threads. The monitoring cycle for each thread can be set to a specific value, such as 20 milliseconds.

[0072] In some embodiments, step S102 of detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle includes:

[0073] In step 2.1), the fault detection operation on the internal hardware of the multi-core processor and the fault detection operation on the software process of each thread are associated and executed in the same current cycle, so that the hardware fault detection results and the software fault detection results of the lock-step core are in the same time sequence.

[0074] Among them, the unified monitoring and processing measures that combine software watchdog monitoring for software fault detection and the processor's Lock-Step function for hardware fault detection are executed in the same current cycle. The hardware fault detection results and software fault detection results can be effectively analyzed to prevent the occurrence of uncontrollable faults and hardware faults. From the overall perspective of software and hardware, the monitoring accuracy and stability of the entire vehicle ECU system are improved.

[0075] Based on the above embodiment, when a hardware fault is detected by the lockstep core's own function in step S104, after backup storage, a reset operation is performed to eliminate the hardware fault, and then the subsequent step S106 is executed. Exemplarily, this can be achieved by the following steps, specifically including:

[0076] In step 3.1), under the function of the lockstep core, whether there is a processing logic fault in the internal hardware of the multi-core processor in the current cycle is detected.

[0077] Step 3.2): If there is no hardware failure, directly execute step S106.

[0078] Step 3.3): If there is a hardware fault, the first software and hardware information at the first current moment is stored and backed up according to the preset fault type, the internal hardware of the multi-core processor is reset, and the software and hardware system corresponding to the ECU is restarted.

[0079] The first hardware and software information includes hardware data and software data that meet the requirements of the preset fault type at the first current moment. For example, the preset fault types include A, B, C, D, E, and F, where A, B, and C are hardware fault types and D, E, and F are software fault types. If a hardware fault exists at this time, the hardware data in the first hardware and software information are the hardware parameter values ​​corresponding to A, B, and C respectively when the hardware fault occurs at this time, while the software fault types D, E, and F can be left blank, or the software parameter values ​​at the current moment are collected respectively, or a preset fixed value is set respectively. Based on this backup storage of the first hardware and software information, the time when the fault occurred can be known, and then according to the values ​​corresponding to the hardware data and software data respectively, it can be known that the fault type is a hardware fault.

[0080] Exemplarily, a fault is determined based on the Lock-Step function of the corresponding multi-core processor in the thread. If a Lock-Step fault occurs in the multi-core processor, it indicates that a fault has occurred in the hardware processing logic inside the processor. According to the system processing requirements, the first software and hardware information of the multi-core processor is stored and backed up for fault diagnosis and fault recovery. The multi-core processor is then reset, and the software and hardware system corresponding to the ECU to which the embodiment of the present invention is applied is restarted.

[0081] In some embodiments, when a software fault is detected, step S106 performs storage backup and resets the software to eliminate the fault, and then executes step S108. Exemplarily, step S108 can be implemented by the following steps, specifically including:

[0082] Step 4.1) Based on the comparison result of the actual execution times of each thread of the lock-step core within the preset cycle and the preset execution times, it is determined whether the software process of each thread has a fault in the current cycle.

[0083] Each thread's functional safety level corresponds to a preset number of executions within a corresponding preset period. For example, the preset number of executions varies depending on the functional safety level. If the actual number of executions within the preset period exceeds the preset number, the thread has a software process failure in the current period. For example, the current period may be 10 seconds, and the preset period may be 20 milliseconds. This can be adjusted accordingly in actual applications.

[0084] Step 4.2): If there is no fault, directly execute the subsequent step S108; perform fault information according to the backed-up stored data.

[0085] Step 4.3): If a fault exists, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset.

[0086] The second hardware and software information includes hardware data and software data that meet the preset fault type requirements at the second current moment. For example, the preset fault types include A, B, C, D, E, and F, where A, B, and C are hardware fault types and D, E, and F are software fault types. If a software fault exists at this time, the software data in the second hardware and software information are the software parameter values ​​corresponding to D, E, and F when the software fault occurs at this time, and the hardware fault types A, B, and C can be left blank, or the hardware parameter values ​​at the current moment are collected, or a preset fixed value is set. Based on this backup storage of the second hardware and software information, the time when the fault occurred can be known, and then based on the values ​​corresponding to the hardware data and software data, it can be known that the fault type is a software fault.

[0087] In practical applications, the WdgM module in NeuSAR software specifically monitors software threads to ensure they run periodically, ensuring that no tasks are missed or delayed. If a thread is blocked or if unexpected resource and time consumption occur, resulting in the loss of monitoring points within a cycle, but this is not a fatal system failure, a certain amount of redundant judgment and processing logic can be reserved, allowing the ECU a certain amount of fault tolerance and recovery time to ensure the robustness and stability of the overall operation of the ECU software system. Based on this, step 4.3) in the aforementioned embodiment can also consider redundant re-execution of backup and reset operations, specifically including:

[0088] Step 4.3.1) refreshes the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle.

[0089] Exemplarily, if the software process of the current thread fails in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to zero; if the software process of the current thread does not fail in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to the initial value.

[0090] The initial value is determined based on the fault tolerance requirement and fault recovery time requirement of each thread.

[0091] It should be noted that the watchdog monitoring redundancy judgment processing logic can be implemented within the system hardware interrupt. This logic is unaffected even when the software system fails, thus avoiding the impact of software thread blocking on the redundant judgment and enabling redundant detection of watchdog results independent of software timing. In practical applications, the NeuSAR-WdgM module can periodically update the hardware trigger value based on the status of all thread monitoring points. The initialization value of this trigger value is set based on the fault tolerance and fault recovery time requirements of the overall software system. For example, the higher the fault tolerance requirement, the larger the hardware trigger value, the longer the redundancy time, and the better the fault tolerance and redundancy capability. The shorter the fault recovery time requirement, the smaller the hardware trigger value, so that once a fault occurs, it can be quickly reset and eliminated to meet the requirement of short fault recovery time. It is also possible to consider both fault tolerance and fault recovery time requirements in a holistic analysis, and determine the hardware trigger value as an integer greater than 0 to meet both fault tolerance and fault recovery time requirements.

[0092] In step 4.3.2), if the software process in the current thread has a fault in the current cycle, it is determined whether the hardware trigger value is greater than zero.

[0093] In step 4.3.3), if the hardware trigger value is greater than zero, the hardware watchdog is fed during the interrupt cycle, and the hardware trigger value is reduced by one. Then, the step in step 4.3.2) is executed to determine whether the hardware trigger value is greater than zero.

[0094] Step 4.3.4): If the hardware trigger value is less than zero, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset.

[0095] When a software fault occurs, as an optional embodiment, a hardware interrupt operation can be triggered through a redundant judgment method. First, the overall software thread monitoring is determined to be normal by checking whether the hardware trigger value is greater than 0. When the hardware trigger value is greater than 0, it indicates that the software system thread monitoring is normal. Even if a software fault occurs, the fault is a non-fatal fault such as thread blocking. The current ECU software system is still within the fault tolerance range and can continue to execute the software system's operating process, namely, feeding the hardware peripheral window watchdog to ensure that the hardware watchdog peripheral operates normally and does not generate a hardware reset. At the same time, the hardware trigger value is decremented by 1, indicating that the redundant judgment is normal and waiting for the trigger value to be refreshed in a new cycle. If the hardware trigger value is determined to be less than 0, it means that the NeuSAR-WdgM software watchdog has detected a software fault. The fault monitored by the software system has exceeded the pre-set fault tolerance capability. At this time, the system needs to store fault information and back up data. The hardware watchdog peripheral feeding operation is no longer executed. The hardware watchdog peripheral generates a hardware reset signal to reset the software system, ensuring the security of the software and hardware systems.

[0096] Specifically, the WdgM software watchdog logic in the NeuSAR software in each thread is evaluated; based on the monitoring results of all threads, the hardware trigger value in the software watchdog is periodically refreshed. If a software system fault exists at this time, the severity of the fault in the entire software system is determined based on the hardware trigger value of the watchdog monitoring redundancy algorithm. If the software fault is not serious, all software threads are running normally, and the window feeding operation of the hardware watchdog peripheral is executed to ensure the normal operation of the hardware watchdog peripheral. If the software fault is serious and the system software thread cannot operate normally, the preset fault information storage and data backup are executed according to the system processing requirements, and the processor reset operation is executed to restart the software and hardware system for fault diagnosis and recovery.

[0097] The embodiment of the present invention adds a watchdog monitoring redundancy algorithm between software watchdog monitoring and hardware watchdog peripheral reset, and adds multi-core and multi-threaded watchdog program monitoring through software logic; after a non-fatal fault occurs, sufficient cache time and fault recovery time are reserved for the system, thereby increasing the redundancy of the overall system and improving the robustness and robustness of the system.

[0098] Figure 3 A schematic diagram of another multi-threaded software and hardware fault analysis method applied to a lockstep core is provided in an embodiment of the present invention.

[0099] Reference Figure 3 ,First, the hardware watchdog is initialized and the NeuSAR software watchdog is initialized; ,then the processor Lock-step is used to determine whether there is a fault;

[0100] If there is a hardware failure, the fault information is stored and the data is backed up, and the hardware system is reset. Then, the process of determining whether there is a fault based on the processor lock-step is re-executed.

[0101] If there is no hardware fault, then if the NeuSAR-WdgM module detects a software fault, the hardware trigger value is periodically refreshed according to the detection result, and then it is determined whether the hardware trigger value is greater than 0;

[0102] If not, the fault information is stored and data is backed up, and the hardware system is reset, and then the step of determining whether there is a fault according to the processor lock-step is executed again;

[0103] If so, the hardware interrupt period dog feeding operation is executed, the hardware trigger value is reduced by 1, and then the step of determining whether the hardware trigger value is greater than 0 is executed.

[0104] The embodiments of the present invention combine the Lock-Step function of the processor's multi-core architecture, leveraging its advantages of faster error detection and higher error coverage. System faults can be detected using hardware in just two or three cycles. Combined with a software watchdog to monitor all threads on all cores, this ensures fault detection and coverage for the entire system, both from a software and hardware perspective. Furthermore, software monitoring and hardware monitoring are combined for unified processing. When system hardware or software fails, the overall software and hardware system can achieve unified backup and reset operations, preventing uncontrolled and hardware failures. Furthermore, fault data across multiple cores and threads is aligned, preventing data interference and contamination during subsequent fault analysis and recovery.

[0105] To address the safety redundancy flaws inherent in multi-threaded watchdog monitoring, a safety redundancy monitoring algorithm has been added. When non-fatal issues occur in software threads, watchdog monitoring increases the system's safety redundancy, providing additional recovery time. This ensures the robustness and stability of the software system and provides ample buffering time for faulty system storage and data updates. This dual-security approach, combined with software safety redundancy monitoring and hardware peripheral watchdog functionality, improves the monitoring accuracy and stability of the overall hardware and software system.

[0106] In some embodiments, as Figure 4 As shown, an embodiment of the present invention further provides a multi-threaded software and hardware fault analysis device 200 applied to a lock-step core. Each ECU includes a multi-core processor, each multi-core processor includes at least one lock-step core, and each lock-step core is configured with multiple threads. The device is applied to the lock-step core and includes:

[0107] The detection module 201 detects the internal hardware of the multi-core processor and the software process of each thread in the current cycle; wherein the detection of the internal hardware and the software process occurs in the same cycle;

[0108] The hardware fault backup module 202 is configured to store and back up first hardware and software information at a first current moment according to a preset fault type if a processing logic fault occurs in the internal hardware during the current cycle, and to reset the internal hardware; wherein the first hardware and software information is used to represent hardware data and software data corresponding to the preset fault type when the hardware fault occurs at the first current moment;

[0109] The software fault backup module 203 is configured to store and back up second software and hardware information at a second current moment according to a preset fault type if a software process of at least one thread in the lockstep core fails in a current cycle, and to reset the software process; wherein the second software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when the software fault occurs at the second current moment;

[0110] The analysis module 204 analyzes the software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

[0111] To achieve multi-core, multi-threaded program monitoring while also taking into account the processor's Lock-Step functionality, this embodiment of the present invention integrates both software and hardware. Based on the NeuSAR software (compliant with the AutoSAR standard) WdgM module, it adds a watchdog monitoring redundancy algorithm and LockStep function fault diagnosis. This allows for comprehensive fault monitoring of the vehicle's hardware and software systems, ensuring their reliability. Furthermore, combined with a hardware watchdog peripheral, software processing logic controls the processor reset.

[0112] Furthermore, the detection module 201 is used to associate the fault detection operation of the internal hardware of the multi-core processor and the fault detection operation of the software process of each thread to be executed in the same current cycle, so that the hardware fault detection result and the software fault detection result of the lock-step core are in the same time sequence.

[0113] Furthermore, the hardware fault backup module 202 is used to detect whether there is a processing logic fault in the internal hardware of the multi-core processor in the current cycle under the function of the lock-step core; if there is a hardware fault, the first software and hardware information at the first current moment is stored and backed up according to the preset fault type, and the internal hardware of the multi-core processor is reset, and the software and hardware system corresponding to the ECU is restarted; wherein, the first software and hardware information includes hardware data and software data that meet the requirements of the preset fault type at the first current moment.

[0114] In some embodiments, the software fault backup module 203 is used to determine whether the software process of each thread has a fault in the current cycle based on a comparison result of the actual number of executions of each thread of the lock-step core within the preset cycle and the preset number of executions; wherein the functional safety level of each thread corresponds to the preset number of executions within the corresponding preset cycle; if a fault exists, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset; wherein the second software and hardware information includes hardware data and software data that meet the preset fault type requirements at the second current moment.

[0115] In some embodiments, the software fault backup module 203 refreshes the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle; if there is a fault in the software process in the current thread in the current cycle, it is determined whether the hardware trigger value is greater than zero; if the hardware trigger value is greater than zero, the watchdog is fed in the interrupt cycle of the hardware watchdog, and the hardware trigger value is reduced by one, and then the step of determining whether the hardware trigger value is greater than zero is executed; if the hardware trigger value is less than zero, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset.

[0116] In some embodiments, the software fault backup module 203 is used to refresh the hardware trigger value corresponding to the current thread to zero if the software process of the current thread has a fault in the current cycle; if the software process of the current thread does not have a fault in the current cycle, refresh the hardware trigger value corresponding to the current thread to an initial value; wherein the initial value is determined based on the fault tolerance requirements and fault recovery time requirements of each thread.

[0117] In some embodiments, before the step of respectively detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle, the device is also used to initialize the peripherals of the hardware watchdog, configure the interrupt cycle of the hardware watchdog and the fault detection configuration information corresponding to each functional safety level.

[0118] Figure 5 Schematic diagram of the hardware architecture of the electronic device 300 provided in an embodiment of the present invention. Figure 5As shown, the electronic device 300 includes a machine-readable storage medium 301 and a processor 302. It may also include a non-volatile storage medium 303, a communication interface 304, and a bus 305. The machine-readable storage medium 301, the processor 302, the non-volatile storage medium 303, and the communication interface 304 communicate with each other via the bus 305. The processor 302 reads and executes the machine-executable instructions for multi-threaded software and hardware fault analysis of the lock-step core in the machine-readable storage medium 301, thereby executing the multi-threaded software and hardware fault analysis method for the lock-step core described in the above embodiment.

[0119] The machine-readable storage medium referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as a CD, DVD, etc.), or similar storage media, or a combination thereof.

[0120] The non-volatile medium may be a non-volatile memory, a flash memory, a storage drive (such as a hard drive), any type of storage disk (such as an optical disk, a DVD, etc.), or similar non-volatile storage medium, or a combination thereof.

[0121] It can be understood that the specific operation methods of each functional module in this embodiment can refer to the detailed description of the corresponding steps in the above method embodiment, and will not be repeated here.

[0122] An embodiment of the present invention provides a computer-readable storage medium, in which a computer program is stored. When the computer program code is executed, the multi-threaded software and hardware fault analysis method applied to a lockstep core as described in any of the above embodiments can be implemented. For specific implementation, please refer to the method embodiment and will not be repeated here.

[0123] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems and devices can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0124] In addition, in the description of the embodiments of the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed connections, detachable connections, or integral connections; they may refer to mechanical connections or electrical connections; they may refer to direct connections or indirect connections through an intermediate medium; and they may refer to internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0125] In the description of the present invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limitations on the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0126] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-mentioned embodiments, ordinary technicians in this field should understand that any technician familiar with this technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed by the present invention, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered by the protection scope of the present invention.

Claims

1. A multi-threaded software and hardware fault analysis method applied to a lockstep core, characterized in that: Each ECU includes a multi-core processor, each multi-core processor includes at least one lock-step core, each lock-step core is configured with multiple threads, and the method is applied to the lock-step core, including: In a current cycle, the internal hardware of the multi-core processor and the software process of each thread are respectively detected; wherein the detection of the internal hardware and the software process occurs in the same cycle; If the internal hardware has a processing logic fault in the current cycle, first software and hardware information at the first current moment is stored and backed up according to a preset fault type, and the internal hardware is reset; wherein the first software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when the hardware fault occurs at the first current moment; If a software process of at least one thread in the lockstep core fails in a current cycle, second software and hardware information at a second current moment is stored and backed up according to a preset fault type, and the software process is reset; wherein the second software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when a software fault occurs at the second current moment; Analyze software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

2. The method according to claim 1, characterized in that The step of detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle includes: The fault detection operation on the internal hardware of the multi-core processor and the fault detection operation on the software process of each thread are associated and executed in the same current cycle, so that the hardware fault detection result and the software fault detection result of the lock-step core are in the same time sequence.

3. The method according to claim 1, characterized in that If the internal hardware has a processing logic failure in the current cycle, the steps of storing and backing up the first software and hardware information at the first current moment according to a preset failure type and resetting the internal hardware include: Under the function of the lockstep core, detecting whether there is a processing logic fault in the internal hardware of the multi-core processor in the current cycle; If there is a hardware failure, the first software and hardware information at the first current moment is stored and backed up according to the preset fault type, the internal hardware of the multi-core processor is reset, and the software and hardware system corresponding to the ECU is restarted; wherein, the first software and hardware information includes hardware data and software data that meet the requirements of the preset fault type at the first current moment.

4. The method according to claim 1, wherein If a software process of at least one thread in the lockstep core fails in a current cycle, the steps of storing and backing up second software and hardware information at a second current moment according to a preset fault type and resetting the software process include: Based on a comparison result of the actual execution count and the preset execution count of each thread of the lockstep core within a preset period, determining whether the software process of each thread has a fault in the current period; wherein the functional safety level of each thread corresponds to the preset execution count within the corresponding preset period; If a fault exists, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset; wherein the second software and hardware information includes hardware data and software data that meet the preset fault type requirements at the second current moment.

5. The method according to claim 1 or 4, characterized in that If a fault exists, the step of storing and backing up the second software and hardware information at the second current moment according to the preset fault type and resetting the software process also includes: Refreshing the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle; If a software process in the current thread has a fault in the current cycle, determining whether the hardware trigger value is greater than zero; If the hardware trigger value is greater than zero, the watchdog is fed during the hardware watchdog interrupt cycle, the hardware trigger value is reduced by one, and then the step of determining whether the hardware trigger value is greater than zero is performed; If the hardware trigger value is less than zero, the second software and hardware information at the second current moment is stored and backed up according to the preset fault type, and the software process is reset.

6. The method according to claim 5, characterized in that The step of refreshing the hardware trigger value corresponding to each thread according to the fault detection result of the software process of each thread in the current cycle includes: If the software process of the current thread fails in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to zero; If the software process of the current thread does not have a fault in the current cycle, the hardware trigger value corresponding to the current thread is refreshed to an initial value; wherein the initial value is determined based on the fault tolerance requirement and fault recovery time requirement of each thread.

7. The method according to claim 1, characterized in that Before the step of detecting the internal hardware of the multi-core processor and the software process of each thread in the current cycle, the method further includes: Initialize the peripherals of the hardware watchdog, and configure the interrupt cycle of the hardware watchdog and the fault detection configuration information corresponding to each functional safety level.

8. A multi-threaded software and hardware fault analysis device applied to a lockstep core, characterized in that: Each ECU includes a multi-core processor, each multi-core processor includes at least one lock-step core, and each lock-step core is configured with multiple threads. The device is applied to the lock-step core and includes: a detection module, configured to detect the internal hardware of the multi-core processor and the software process of each thread in a current cycle; wherein the detection of the internal hardware and the software process occurs in the same cycle; a hardware fault backup module, configured to store and back up first hardware and software information at a first current moment according to a preset fault type, and reset the internal hardware if a processing logic fault occurs in the internal hardware during a current cycle; wherein the first hardware and software information is used to represent hardware data and software data corresponding to the preset fault type when a hardware fault occurs at the first current moment; a software fault backup module, configured to store and back up second software and hardware information at a second current moment according to a preset fault type, and reset the software process if a software process of at least one thread in the lockstep core fails in a current cycle; wherein the second software and hardware information is used to represent hardware data and software data corresponding to the preset fault type when the software fault occurs at the second current moment; An analysis module analyzes software and hardware failures of the lockstep core according to the first software and hardware information and the second software and hardware information.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A machine-readable storage medium, characterized in that The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the steps of the method according to any one of claims 1 to 7.

Images