Heartbeat anomaly detection method and system for heterogeneous multi-core system based on time difference feedback

Abstract

The application discloses a heartbeat abnormality detection method and system based on time difference feedback for a heterogeneous multi-core system, which comprises: a master core periodically performing a heartbeat detection task according to a preset reference period, and maintaining a state record of each slave core, the state record containing a last read heartbeat value and accumulated non-update time; in each heartbeat detection task, the following operations are performed: obtaining a current heartbeat value of the slave core, and calculating an actual time interval between the current detection and the last detection; comparing the current heartbeat value with the last read heartbeat value: if the two are different, resetting the accumulated non-update time to zero; if the two are the same, adding the actual time interval to the accumulated non-update time and judging whether the accumulated accumulated non-update time exceeds a threshold value, if yes, determining that the slave core is abnormal. The application scheme decouples the abnormality determination and the detection frequency by introducing a time difference detection mechanism, and improves the accuracy of the abnormality determination and the robustness of the system.

Description

Technical Field

[0001] This invention belongs to the technical field of embedded heterogeneous multi-core processing systems, specifically relating to a method and system for detecting abnormal heartbeats in heterogeneous multi-core systems based on time difference feedback. It is particularly suitable for scenarios requiring high-reliability heartbeat detection, such as ARM+DSP architecture base station systems and multi-core processor monitoring. Background Technology

[0002] In a heterogeneous multi-core base station system based on an ARM+DSP architecture, the DSP typically acts as a slave core, responsible for the physical layer and signal processing tasks, while the ARM acts as the master core, responsible for the data link layer, network layer, and system management. To ensure system reliability, each DSP core runs an independent heartbeat task, periodically incrementing the heartbeat count and writing it to shared memory. The ARM reads the heartbeat values ​​of each core at fixed intervals (e.g., 5 seconds) and determines whether the core is operating normally by comparing whether the heartbeat values ​​have changed. If a core's heartbeat value fails to update for multiple consecutive times (e.g., 10 times), the core is considered abnormal, the log is recorded, and the base station is reset.

[0003] This mechanism works under normal operating conditions, but in special scenarios such as base station upgrades and activations, periodic tasks on the ARM side may be blocked due to system scheduling delays. When the blockage is cleared, the backlogged tasks will be executed multiple times in a very short period of time. At this time, the heartbeat count value on the DSP core has not yet been updated to the shared memory, causing the ARM to read the same heartbeat value multiple times in a short period of time, incorrectly accumulating abnormal counts, triggering misjudgments and resetting the base station, thus affecting system stability.

[0004] In summary, the existing technology has the following shortcomings: it relies on the number of detections rather than the time dimension, and the anomaly judgment is based on the "number of consecutive detections" without considering the fluctuation of the detection time interval, which is prone to misjudgment due to task scheduling anomalies; misjudgment will trigger unnecessary resets, which will seriously affect user experience and system reliability in critical operations such as upgrades and activations. Summary of the Invention

[0005] This invention aims to provide a method and system for detecting heartbeat anomalies in heterogeneous multi-core systems based on time-difference feedback, in order to solve the problem of misjudgment of heartbeats caused by task scheduling delays in existing technologies. By introducing a time-difference detection mechanism, anomaly determination is decoupled from detection frequency, thereby improving the accuracy of anomaly determination and the robustness of the system.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] In a first aspect, this application provides a method for detecting abnormal heartbeats in heterogeneous multi-core systems based on time-difference feedback, comprising the following steps: The main core periodically executes the heartbeat detection task according to the preset baseline period T_base, and maintains the status record of each slave core. The status record includes the last read heartbeat value and the cumulative time without update. In each heartbeat detection task, perform the following operations: Obtain the current heartbeat value from the kernel and calculate the actual time interval Δt between the current detection and the previous detection; Compare the current heartbeat value with the previously read heartbeat value: if they are different, reset the cumulative unupdated time to zero; if they are the same, add the cumulative unupdated time to the actual time interval Δt. Determine whether the accumulated unupdated time exceeds the preset time exception threshold T_threshold. If so, determine that the core jump exception should be performed.

[0008] Optionally, it also includes: When a kernel jumps to an abnormality, the master kernel immediately collects the context information of the abnormal kernel, stores the collected context information in non-volatile storage, and then triggers a system reset.

[0009] Optionally, it also includes a load-aware adaptive adjustment step based on the detection cycle deviation: The main core records the actual execution time of each heartbeat detection task, calculates the actual time interval between two adjacent detections, and establishes a sliding window to store the sequence of actual time intervals of the most recent N detections. Calculate the average value of the actual time interval within the sliding window, and calculate the deviation rate between the average value and the reference period T_base; When the deviation rate exceeds the preset deviation tolerance threshold, the system is determined to be in a high-load state, and the time anomaly threshold T_threshold is temporarily raised to the time anomaly adjustment threshold T_threshold_adj; when the deviation rate recovers to within the deviation tolerance threshold and remains stable for M cycles, the time anomaly threshold is restored to its original value.

[0010] Optionally, the formula for calculating the deviation rate is: dev_ratio=|Δt_avg-T_base| / T_base×100% Where Δt_avg is the average value of the actual time interval within the sliding window.

[0011] Optionally, the deviation tolerance threshold is 20% of the reference period T_base, and the calculation formula for the time anomaly adjustment threshold is: T_threshold_adj=T_threshold×K Where K is the adaptive coefficient, and K is greater than 1.

[0012] Optionally, the actual time interval Δt is obtained using a high-precision timestamp function.

[0013] Optionally, the size of the sliding window is N=10, and the base period is T_base=5 seconds.

[0014] Optionally, the time anomaly threshold T_threshold ranges from 30 seconds to 120 seconds.

[0015] Optionally, the context information includes at least one of the following: program counter, stack pointer, general-purpose register value, and memory image of critical data area.

[0016] Secondly, this application provides a heterogeneous multi-core system for detecting abnormal heartbeats based on time-difference feedback, used to implement the method described in the first aspect, the system comprising: The status recording module is used to maintain the status record of each slave core. The status record includes the heartbeat value read last time and the cumulative time not updated. The time difference detection module is used to obtain the current heartbeat value of the slave core in each heartbeat detection task, calculate the actual time interval Δt between the current detection and the previous detection, and update the cumulative unupdated time according to whether the heartbeat value has changed. The anomaly detection module is used to determine whether the cumulative non-update time exceeds a preset time anomaly threshold, and if it does, it determines to jump out of the core anomaly. The adaptive adjustment module is used to dynamically adjust the time anomaly threshold based on the deviation rate between the average value of the actual time interval within the sliding window and the reference period. The exception handling module is used to collect and store context information when an exception is determined to jump from the core, and then trigger a system reset.

[0017] Compared with the prior art, this application has the following beneficial effects: When the master core performs a heartbeat detection task, it records the heartbeat value of each slave core and the cumulative time without updating that heartbeat value. Then, in the next heartbeat detection task, if the detected heartbeat value is the same as the previous one, the actual time interval between the current and previous detections is added to the cumulative time without updating. The system then checks if the cumulative time without updating exceeds a time anomaly threshold. If it does, the slave core is considered to have a heartbeat anomaly. This design, by accumulating the actual physical time (i.e., the actual time interval) rather than the number of detections, decouples anomaly detection from the frequency of the detection task, thus avoiding misjudgments of slave core anomalies due to system scheduling delays. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Furthermore, these drawings and textual descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to specific embodiments.

[0019] Figure 1 A flowchart illustrating a method for detecting abnormal heartbeats in a heterogeneous multi-core system based on time difference feedback, provided in an embodiment of this application; Figure 2 This is a schematic diagram of a heterogeneous multi-core system heartbeat anomaly detection system based on time difference feedback, provided as an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0021] Example 1 This embodiment provides a method for detecting abnormal heartbeats in a heterogeneous multi-core system based on time-difference feedback. This method is applied to a heterogeneous multi-core base station system based on an ARM+DSP architecture, where the ARM acts as the master core and the DSP as the slave core. Figure 1 As shown, the method includes the following steps: Step S1: Initialization and Status Record Maintenance. Specifically, the master core periodically executes the heartbeat detection task according to the preset baseline period T_base, and maintains the status record of each slave core. The status record includes the last read heartbeat value and the cumulative time without update.

[0022] In this step, the baseline period T_base for heartbeat detection is preset in the master core (ARM), and an independent status record table is established for each slave core (DSP) to record the heartbeat value of the slave core last read and the cumulative time without updating the heartbeat value, so as to provide a data storage basis for subsequent heartbeat anomaly judgment based on time difference.

[0023] In practice, during the system startup phase, the main core completes the following initialization tasks: Parameter configuration: Set the baseline detection period T_base (e.g., 5 seconds), time anomaly threshold T_threshold (e.g., 50 seconds), sliding window size N, deviation tolerance threshold δ, etc.

[0024] Data structure establishment: Maintain a heartbeat status record structure for each slave core (assuming a total of 6 cores, numbered Core0~Core5), which should contain at least the following fields: last_value: The heartbeat value read last time; stall_time_ns: This is the cumulative time (in nanoseconds) that the heartbeat value of the slave kernel has not been updated. last_time: The timestamp of the last heartbeat detection.

[0025] The main core creates a high-precision timer with a period of T_base, which wakes up the heartbeat detection task when the timer expires.

[0026] In this way, through independent state recording, the heartbeat state of each slave core can be tracked separately without interference.

[0027] Step S2: Heartbeat Detection and Time Difference Accumulation. Specifically, in each heartbeat detection task, the following operations are performed: obtain the current heartbeat value of the slave core and calculate the actual time interval Δt between the current detection and the previous detection; compare the current heartbeat value with the previously read heartbeat value: if they are different, reset the accumulated unupdated time to zero; if they are the same, add the accumulated unupdated time to the actual time interval Δt.

[0028] In this step, by comparing whether the heartbeat value changes, it is decided whether to clear the accumulated non-update time to zero (heartbeat updates normally) or to accumulate the actual time interval of this detection (heartbeat stops). This changes the basis for anomaly judgment from "number of consecutive detections" to "the actual physical length of time the heartbeat stops", thereby eliminating misjudgments caused by scheduling jitter of the detection task itself.

[0029] In practice, each time a detection task is executed, the master core performs the following sub-steps for each enabled slave core: 1. Get the current timestamp now (using a high-precision clock, such as clock_gettime(CLOCK_MONOTONIC), with precision down to the nanosecond level).

[0030] 2. Read the current heartbeat value current_val of the slave core from shared memory.

[0031] 3. Calculate the actual time interval between this test and the previous test: Δt = now - last_time Where last_time is the timestamp recorded when the last detection was performed on the slave core.

[0032] 4. Compare the current heartbeat value (current_val) with the last read heartbeat value (last_value): If the two are different, it means that the core jump is working normally. In this case, the accumulated unupdated time stall_time_ns will be reset to 0, and last_value will be updated to current_val.

[0033] If the two are the same, it means that the core has not been updated since the last detection, so stall_time_ns is incremented by Δt.

[0034] 5. Update the last_time of the slave core to now.

[0035] Traditional methods, when a detection task is blocked and executed multiple times consecutively, accumulate "detection counts" because the heartbeat value remains unchanged, easily triggering thresholds. This method, however, accumulates the actual physical time interval. As long as the heartbeat value has been updated during this period, the accumulated time without update is reset to zero. For example, if the ARM is blocked for 10 seconds due to load, and the first detection after recovery finds that the heartbeat has been updated (the DSP was operating normally during this time), the accumulated time is reset to zero. Even if the heartbeat value remains unchanged in the subsequent second detection, the accumulated interval is only in the millisecond range, far below the 50-second abnormal threshold. Therefore, this method solves the problem of misjudgments caused by the inherent delay of the detection task itself.

[0036] Step S3: Anomaly Detection. Specifically, the main core determines whether the accumulated unupdated time exceeds the preset time anomaly threshold T_threshold. If so, the core jumps out of control.

[0037] In this step, the cumulative unupdated time is compared with a preset time anomaly threshold. When the cumulative stagnation time exceeds the time anomaly threshold, it is determined that a real anomaly has occurred in the kernel (rather than a false alarm caused by detection delay), thereby triggering the subsequent anomaly handling process.

[0038] In practice, after each update of stall_time_ns, the main core checks whether stall_time_ns is greater than T_threshold. If the result is yes, the slave core is determined to jump to an exception.

[0039] If an anomaly is detected, the subsequent anomaly handling process (step S4) is executed.

[0040] Generally, the time anomaly threshold T_threshold ranges from 30 to 120 seconds. It should be noted that the time anomaly threshold T_threshold must be set greater than the sum of the maximum interval between skipping tasks from the core and the maximum latency detected by the ARM, usually 5 to 10 times the heartbeat cycle (e.g., if the heartbeat cycle is 5 seconds, T_threshold is 50 seconds) to ensure that normal slight delays will not lead to misjudgments.

[0041] Step S4: Exception Handling. Specifically, when an exception is determined to occur in the slave kernel, the master kernel immediately collects the context information of the exception slave kernel, stores the collected context information in non-volatile storage medium, and then triggers a system reset.

[0042] In this step, after confirming the kernel anomaly, key diagnostic data is quickly extracted and persistently stored to provide a basis for subsequent problem localization. Then, a system reset is performed to restore service.

[0043] In practice: The main core performs the following operations: 1. Collect context information from the exception kernel, including but not limited to the program counter, stack pointer, general-purpose register values, and memory images of critical data areas.

[0044] 2. Compress and package the collected information, and add timestamps.

[0045] 3. Write to non-volatile storage media (such as Flash, disk, or remote log server).

[0046] 4. Trigger a base station system reset to restore normal system operation.

[0047] This ensures that critical fault logs are not lost due to reset, facilitating later analysis and location of the cause of kernel anomalies.

[0048] Step S5: Load-aware adaptive adjustment. Specifically, the main core records the actual execution time of each heartbeat detection task, calculates the actual time interval between two adjacent detections, and establishes a sliding window to store the sequence of actual time intervals of the most recent N detections; calculates the average value of the actual time intervals within the sliding window, and calculates the deviation rate between this average value and the base period T_base; when the deviation rate exceeds the preset deviation tolerance threshold, the system is determined to be in a high-load state, and the time anomaly threshold T_threshold is temporarily increased to T_threshold_adj; when the deviation rate recovers to within the deviation tolerance threshold and remains stable for M periods, the time anomaly threshold is restored to its original value.

[0049] In this step, by monitoring the fluctuations in the execution interval of the detection task itself, the system load status of the main ARM core is perceived. When the load is high, the abnormal threshold is automatically increased to reduce the detection sensitivity and avoid misjudgment caused by system overload. After the load returns to normal, the threshold is gradually restored to ensure the real-time nature of fault detection.

[0050] In practice, the following process is executed: 1. Time interval recording: At the start of each heartbeat detection task, record the actual execution time and calculate the time difference Δt_task between the start time of the previous task and the start time of the previous task.

[0051] 2. Sliding window maintenance: Establish a circular buffer of length N (e.g., N=10) to store the most recent N Δt_task values, while maintaining the sum within the window to quickly calculate the average.

[0052] 3. The deviation rate is calculated using the following formula: dev_ratio=|Δt_avg-T_base| / T_base×100% Where dev_ratio is the deviation rate and Δt_avg is the average value of the actual time interval within the sliding window.

[0053] 4. Deviation tolerance threshold judgment: If dev_ratio > δ, the system is determined to be in a high load state. The deviation tolerance threshold δ can usually be 20% of the base period T_base.

[0054] 5. Threshold adjustment: Enter adaptive mode and temporarily raise the time anomaly threshold to: T_threshold_adj=T_threshold×K Where K is an adaptive coefficient greater than 1 (e.g., K=1.5).

[0055] Then set the stable counter stable_count=0 and the adaptive_mode flag=true (i.e., enable adaptive mode).

[0056] 6. Recovery Mechanism: When dev_ratio ≤ δ and the system is in adaptive mode, the stable counter stable_count gradually increases. When stable_count ≥ M (e.g., M = 5), the system exits adaptive mode and restores T_threshold to its original value.

[0057] Therefore, under high load, the detection task itself may experience delays. If the original time anomaly threshold is still used, it may lead to false positives due to the slightly longer accumulated time. Therefore, temporarily increasing the threshold can tolerate some scheduling delays and avoid erroneous resets. Once the load recovers, the original time anomaly threshold is gradually restored to ensure that anomalies are detected promptly.

[0058] To better understand, the implementation process of this application will be explained in detail using the heartbeat anomaly detection system of a 5G base station as an example.

[0059] This embodiment uses a 5G base station system based on an ARM+DSP architecture as an example. The ARM side runs a Linux operating system, responsible for system management and control plane processing; the DSP side runs a bare-metal program, responsible for physical layer signal processing. Each of the DSP cores (6 in total) runs an independent heartbeat task, incrementing its private heartbeat counter by 1 and writing it to shared memory every 2 seconds. Based on this, the detection process is as follows: (I) System Initialization and Data Structure Definition During the system startup phase, ARM completes the following initialization: The baseline detection period T_base = 5 seconds.

[0060] The time anomaly threshold T_threshold = 50 seconds.

[0061] The sliding window size is N=10.

[0062] Deviation tolerance threshold δ=20%.

[0063] The adaptive coefficient K = 1.5.

[0064] The number of cycles to restore stability is M=5.

[0065] Define a state structure for each DSP core: struct core_heartbeat_status { uint32_t last_value; / / Last read heartbeat value struct timespec last_time; / / Last detection timestamp (nanosecond precision) uint64_t stall_time_ns; / / Cumulative time without update (nanoseconds) bool is_active; / / Whether the kernel is enabled }; Create a circular buffer named interval_buffer with a length of 10 to store the actual time interval of the most recent 10 detections.

[0066] II) Main Process of Heartbeat Detection Task An ARM processor creates a high-precision timer with a period of 5 seconds. Each time the timer expires, the following steps are executed: Get the current timestamp now.

[0067] Iterate through all enabled DSP cores: a. Read the heartbeat value current_val from shared memory.

[0068] b. Calculate Δt = now - last_time based on the last_time of the core.

[0069] c. If current_val == last_value, then stall_time_ns += Δt; otherwise, reset stall_time_ns = 0 and update last_value.

[0070] d. If stall_time_ns≥50×10^9 nanoseconds, an exception is detected and exception handling is initiated.

[0071] e. Update last_time=now.

[0072] Calculate the current task execution interval Δt_task (the time since the start of the last task), store it in the sliding window, and update the window sum.

[0073] (III) Load-aware adaptive adjustment After each detection task is completed, execute: Calculate the average value Δt_avg of Δt_task within the sliding window.

[0074] Calculate the deviation rate dev_ratio = |Δt_avg-5| / 5×100%.

[0075] If dev_ratio > 20% and the system is not currently in adaptive mode, then enter adaptive mode and temporarily increase T_threshold to 50 × 1.5 = 75 seconds.

[0076] If dev_ratio ≤ 20% and the system is in adaptive mode, the stability counter is incremented by 1. When the condition is met for 5 consecutive times, the system exits adaptive mode and restores T_threshold to 50 seconds.

[0077] (iv) Abnormal Handling When a core's stall_time_ns exceeds 50 seconds (or 75 seconds in adaptive mode), the ARM immediately: Collect the program counter, stack pointer, general-purpose register values, and critical memory image of the core.

[0078] Compress and package the file, add a timestamp, and write it to Flash.

[0079] Triggered a base station system reset.

[0080] Scenario Verification: During base station upgrade testing, the ARM's heartbeat detection task was blocked for 10 seconds due to high load. Upon recovery, the first detection showed the DSP heartbeat value had been updated (because the DSP was operating normally during this period), and the accumulated time without update was reset to zero. Subsequent consecutive detections (intervals of only milliseconds) showed no change in the heartbeat value, but the accumulated time was only a few milliseconds. The final accumulated time was far less than 50 seconds, preventing false alarms. Simultaneously, the adaptive mechanism detected a detection interval fluctuation exceeding 20% ​​and automatically raised the threshold to 75 seconds, further ensuring no false alarms due to subsequent occasional delays. Experiments demonstrate that this method completely eliminates the problem of accidental resets in upgrade scenarios.

[0081] Example 2 This embodiment provides a heartbeat anomaly detection system based on time-difference feedback in a heterogeneous multi-core system, configured on the main core, to implement the method of Embodiment 1. For example... Figure 2 As shown, the system includes the following structure: The status recording module 110 is used to maintain the status record of each slave core. The status record includes the heartbeat value read last time and the cumulative time not updated. The time difference detection module 120 is used to obtain the current heartbeat value of the slave core in each heartbeat detection task, calculate the actual time interval Δt between the current detection and the previous detection, and update the cumulative unupdated time according to whether the heartbeat value has changed. The anomaly detection module 130 is used to determine whether the cumulative non-update time exceeds a preset time anomaly threshold, and to determine an anomaly jump from the core if it exceeds the threshold. The adaptive adjustment module 140 is used to dynamically adjust the time anomaly threshold based on the deviation rate between the average value of the actual time interval within the sliding window and the reference period. The exception handling module 150 is used to collect and store context information when an exception is determined to jump from the core, and then trigger a system reset.

[0082] The functional implementation details of each module correspond one-to-one with the aforementioned method steps, and will not be repeated here.

[0083] In addition, some embodiments also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the heartbeat anomaly detection method for heterogeneous multi-core systems based on time difference feedback as described in Embodiment 1.

[0084] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0085] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0086] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0087] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0088] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0089] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0090] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0091] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for detecting abnormal heartbeats in a heterogeneous multi-core system based on time-difference feedback, characterized in that, Includes the following steps: The main core periodically executes the heartbeat detection task according to the preset baseline period T_base, and maintains the status record of each slave core. The status record includes the last read heartbeat value and the cumulative time without update. In each heartbeat detection task, perform the following operations: Obtain the current heartbeat value from the kernel and calculate the actual time interval Δt between the current detection and the previous detection; Compare the current heartbeat value with the previously read heartbeat value: if they are different, reset the cumulative unupdated time to zero; if they are the same, add the cumulative unupdated time to the actual time interval Δt. Determine whether the accumulated unupdated time exceeds the preset time exception threshold T_threshold. If so, determine that the core jump exception should be performed.

2. The method according to claim 1, characterized in that, Also includes: When a kernel jumps to an abnormality, the master kernel immediately collects the context information of the abnormal kernel, stores the collected context information in non-volatile storage, and then triggers a system reset.

3. The method according to claim 1, characterized in that, It also includes a load-aware adaptive adjustment step based on detection cycle deviation: The main core records the actual execution time of each heartbeat detection task, calculates the actual time interval between two adjacent detections, and establishes a sliding window to store the sequence of actual time intervals of the most recent N detections. Calculate the average value of the actual time interval within the sliding window, and calculate the deviation rate between the average value and the reference period T_base; When the deviation rate exceeds the preset deviation tolerance threshold, the system is determined to be in a high-load state, and the time anomaly threshold T_threshold is temporarily raised to the time anomaly adjustment threshold T_threshold_adj; when the deviation rate recovers to within the deviation tolerance threshold and remains stable for M cycles, the time anomaly threshold is restored to its original value.

4. The method according to claim 3, characterized in that, The formula for calculating the deviation rate is: dev_ratio=|Δt_avg-T_base| / T_base×100% Where Δt_avg is the average value of the actual time interval within the sliding window.

5. The method according to claim 3, characterized in that, The deviation tolerance threshold is 20% of the base period T_base, and the calculation formula for the time anomaly adjustment threshold is as follows: T_threshold_adj=T_threshold×K Where K is the adaptive coefficient, and K is greater than 1.

6. The method according to claim 1, characterized in that, The actual time interval Δt is obtained through a high-precision timestamp function.

7. The method according to claim 3, characterized in that, The size of the sliding window is N=10, and the base period is T_base=5 seconds.

8. The method according to claim 1, characterized in that, The time anomaly threshold T_threshold ranges from 30 seconds to 120 seconds.

9. The method according to claim 2, characterized in that, The context information includes at least one of the following: program counter, stack pointer, general-purpose register value, and memory image of critical data area.

10. A heterogeneous multi-core system for detecting abnormal heartbeats based on time-difference feedback, configured on the main core, characterized in that, The system for implementing the method according to any one of claims 1 to 9, the system comprising: The status recording module is used to maintain the status record of each slave core. The status record includes the heartbeat value read last time and the cumulative time not updated. The time difference detection module is used to obtain the current heartbeat value of the slave core in each heartbeat detection task, calculate the actual time interval Δt between the current detection and the previous detection, and update the cumulative unupdated time according to whether the heartbeat value has changed. The anomaly detection module is used to determine whether the cumulative non-update time exceeds a preset time anomaly threshold, and if it does, it determines to jump out of the core anomaly. The adaptive adjustment module is used to dynamically adjust the time anomaly threshold based on the deviation rate between the average value of the actual time interval within the sliding window and the reference period. The exception handling module is used to collect and store context information when an exception is determined to jump from the core, and then trigger a system reset.

Images