A Security Enhancement Method and System for Multi-Core Systems Based on Watchdog Timer

Abstract

This invention provides a watchdog-based security enhancement method and system for multi-core systems. The system includes multiple processors, a watchdog timer configured for each processor, and a cloud platform. The processors are paired up as detection groups. The method includes: for each detection group, when the first processor performs a watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results; based on the monitoring results, the first processor determines whether the second processor has malfunctioned; if the second processor malfunctions, the first processor obtains the corresponding fault information and sends it to the cloud platform; the cloud platform repairs the second processor based on the fault information. This invention improves the security and reliability of multi-core systems.

Description

Technical Field

[0001] This invention relates to the field of electronic equipment monitoring technology, and in particular to a method and system for enhancing the security of multi-core systems based on a watchdog timer. Background Technology

[0002] Watchdog technology primarily refers to a technique used to monitor and restore the normal operation of computer systems. It is widely used in microcontroller units (MCUs) and computer systems. In modern electronic devices, watchdog timers (WDTs) are widely used to monitor system operating status. When a system experiences an unrecoverable crash due to a fault, error, or other reason, the watchdog timer triggers a system reset to ensure system reliability.

[0003] Watchdog timer technology, as a means of preventing and recovering from system anomalies, has been widely used in single-core systems, but its utilization in multi-core systems has been underutilized. In modern computer systems, multi-core processors have become the standard configuration for improving computing efficiency and processing power. However, a single processor failure in a multi-core system can lead to a decline in overall system performance or instability.

[0004] Therefore, in existing technologies, multi-core systems have poor stability and security. Summary of the Invention

[0005] This invention provides a watchdog-based method and system for enhancing the security of multi-core systems, which addresses the shortcomings of poor stability and security in existing multi-core systems. It enables real-time fault detection for each processor, allowing for timely location and repair of faulty processors, thereby improving the stability and security of multi-core systems.

[0006] This invention provides a watchdog-based security enhancement method for multi-core systems, applied to multi-core systems including multiple processors, a watchdog timer configured for each processor, and a cloud platform. The multiple processors are paired up as detection groups. The method includes:

[0007] For each detection group, when the first processor performs the watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results.

[0008] The first processor determines whether the second processor has malfunctioned based on the monitoring results;

[0009] If the second processor malfunctions, the first processor obtains the fault information corresponding to the second processor and sends the fault information to the cloud platform.

[0010] The cloud platform repairs the second processor based on the fault information.

[0011] According to the present invention, a multi-core system security enhancement method based on a watchdog timer is provided, wherein when the first processor performs a watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results, including:

[0012] When the first processor performs the watchdog timer feeding operation, it sends a handshake request signal to the second processor.

[0013] If the first processor does not receive a response signal from the second processor within the predetermined response time, the monitoring result is determined to be that the second processor has a potential fault; otherwise, the monitoring result is determined to be that the second processor is in normal condition.

[0014] According to the present invention, a watchdog-based security enhancement method for multi-core systems includes a first processor determining whether a second processor has malfunctioned based on monitoring results, comprising:

[0015] When the monitoring result indicates that the second processor has a potential fault, the first processor attempts to resend the handshake request signal to the second processor.

[0016] If the first processor sends the handshake request signal to the second processor multiple times in a row and does not receive a response signal from the second processor, then the second processor is determined to be faulty; otherwise, the second processor is determined to be in normal condition.

[0017] According to the present invention, a watchdog-based security enhancement method for multi-core systems is provided, wherein the fault information includes:

[0018] The program counter register value of the second processor, the ID number of the second processor, the fault address of the second processor, and the fault time of the second processor.

[0019] According to the present invention, a watchdog-based multi-core system security enhancement method is provided, wherein sending the fault information to the cloud platform includes:

[0020] The fault information is encrypted using a strong encryption algorithm, and the encrypted fault information is sent to the cloud platform through a secure communication protocol.

[0021] According to the present invention, a watchdog-based multi-core system security enhancement method is provided, wherein the cloud platform repairs the second processor based on the fault information, including:

[0022] The cloud platform performs data analysis on the fault information to identify the fault type of the second processor;

[0023] The cloud platform provides repair suggestions or automatically triggers a repair process based on the fault type of the second processor.

[0024] According to a watchdog-based security enhancement method for a multi-core system provided by the present invention, the multi-core system further includes a user terminal; after the cloud platform provides repair suggestions or automatically triggers a repair process based on the fault type of the second processor, the method further includes:

[0025] The cloud platform generates a fault report and determines the system status of the multi-core system;

[0026] The cloud platform updates the fault information, the system status of the multi-core system, the fault report, and the repair suggestions to the user terminal in real time.

[0027] According to a watchdog-based security enhancement method for multi-core systems provided by the present invention, after the cloud platform updates the fault information, the system status of the multi-core system, the fault report, and the repair suggestions to the user terminal in real time, the method further includes:

[0028] The user terminal displays the fault information, the system status of the multi-core system, the fault report, and the repair suggestions visually through the user interface.

[0029] According to the present invention, a watchdog-based security enhancement method for multi-core systems is provided, the method further comprising:

[0030] The watchdog timer has two operating modes: a first mode and a second mode.

[0031] If the watchdog timer is in the first mode, a direct reset is performed; wherein, the direct reset includes: if the processor corresponding to the watchdog timer does not perform a watchdog operation during the watchdog feeding cycle, the watchdog timer directly resets and restarts the processor corresponding to the watchdog timer.

[0032] If the watchdog timer is in the second operating mode, an interrupt reset process is executed. The interrupt reset process includes: if the processor corresponding to the watchdog timer does not perform a watchdog feeding operation during the watchdog feeding cycle, the interrupt handler is entered; if the processor corresponding to the watchdog timer still does not perform a watchdog feeding operation during the next watchdog feeding cycle, the watchdog timer resets and restarts the processor corresponding to the watchdog timer.

[0033] The present invention also provides a multi-core system, the multi-core system comprising: multiple processors, a watchdog timer configured for each processor, and a cloud platform, wherein the multiple processors are paired in pairs as a detection group;

[0034] For each detection group, the first processor is used to monitor the status of the second processor and obtain the monitoring results when the watchdog timer is fed.

[0035] The first processor is also used to determine whether the second processor has malfunctioned based on the monitoring results;

[0036] The first processor is further configured to, if the second processor malfunctions, obtain fault information corresponding to the second processor and send the fault information to the cloud platform;

[0037] The cloud platform is used to repair the second processor based on the fault information.

[0038] The watchdog-based multi-core system security enhancement method and system provided by this invention pairs multiple processors into detection groups. Within each detection group, the two processors monitor and detect faults in each other. This grouping strategy not only simplifies the system architecture but also improves the sensitivity and response speed of fault detection. Furthermore, when the first processor determines that the second processor has malfunctioned based on the monitoring results, it can obtain the corresponding fault information of the second processor in real time and send the fault information to the cloud platform for timely repair of the second processor, ensuring the performance and stability of the entire system. Therefore, the solution of this invention improves the reliability and security of multi-core systems. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0040] Figure 1 This is one of the flowcharts of the watchdog-based multi-core system security enhancement method provided by the present invention.

[0041] Figure 2 This is the second flowchart of the watchdog-based multi-core system security enhancement method provided by the present invention.

[0042] Figure 3 This is a flowchart illustrating the watchdog process under different modes provided by the present invention.

[0043] Figure 4This is a schematic diagram of the system architecture of the multi-core system provided by the present invention. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0045] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0046] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities and do not necessarily imply a specific order or sequence, unless otherwise indicated. It should be understood that such terms can be used interchangeably where appropriate, for example, in situations where implementation is possible in orders other than those given in the embodiments illustrated or described in this application.

[0047] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclusively include, for example, a product or device that includes a series of components is not necessarily limited to those that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0048] The term "watchdog" used in the embodiments of this application refers to an important system reliability protection mechanism that monitors the system's operating status and automatically restarts the system in the event of a failure. By configuring and controlling the watchdog, we can improve the stability and reliability of the system. In practical applications, we need to select appropriate watchdog configuration parameters based on specific requirements and system characteristics, and periodically "feed" the watchdog to ensure the normal operation of the system.

[0049] Watchdog technology primarily refers to a technique used to monitor and restore the normal operation of computer systems. It is widely used in microcontrollers (MCUs) and computer systems. Applications of watchdog technology include the following: Watchdog Timer (WDT): A timer circuit used to prevent program infinite loops or system crashes. It typically has one input (feeding the dog) and one output (usually connected to the microcontroller's reset pin). Hardware Watchdog: Uses a dedicated hardware timer to monitor the main program's execution. If the timer is not reset (fed) within a set time, it expires and triggers a reset signal, resetting the microcontroller (MCU). Software Watchdog: In some systems, watchdog functionality can be implemented in software, such as using an idle timer / counter in a microcontroller system to design a software watchdog. Independent Watchdog Timer (IWDG): A type of watchdog, typically consisting of a decrementing counter that generates a reset signal when the counter value reaches 0. The counter value needs to be reset before it reaches 0 to avoid a reset. Window Watchdog Timer (WWDG): Unlike a standalone watchdog, a window watchdog generates a reset signal when its counter value falls between predefined upper and lower limits for the window without being fed. The watchdog works by automatically counting after startup; if it is not reset (fed) within the set time, the counter overflows, triggering an interrupt or system reset. The watchdog can be reset independently of other components.

[0050] The technical solution of this application and how it solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The following is a combination of... Figures 1-3 This invention describes a watchdog-based security enhancement method for multi-core systems.

[0051] Figure 1 This is one of the flowcharts illustrating the watchdog-based multi-core system security enhancement method provided by this invention. In practical applications, the watchdog-based multi-core system security enhancement method provided by this invention is applied to multi-core systems, which include multiple processors, a watchdog timer configured for each processor, and a cloud platform. The multiple processors are paired up as detection groups. Figure 1 As shown, the method includes steps 101 to 104.

[0052] Step 101: For each detection group, when the first processor performs the watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results.

[0053] Specifically, a multi-core system comprises multiple processors. Leveraging the advantage of parallel operation, these processors are grouped in pairs, meaning each processor is paired with another processor to form a detection group. For example, a multi-core system with four processors can be divided into two detection groups. Understandably, with this grouping method, each processor corresponds to a specific processor that monitors its own operating status and performs fault detection. Therefore, this grouping strategy not only simplifies the system architecture but also improves the sensitivity and response speed of fault detection.

[0054] Optionally, each detection group can be equipped with other numbers of processors according to actual monitoring and fault detection needs; this embodiment does not impose specific limitations.

[0055] Optionally, the pairing of each processor can be dynamically adjusted to adapt to different system loads and processor performance.

[0056] In this system, the first processor and the second processor belong to the same monitoring group. Specifically, the first processor is the processor in the detection group currently performing the watchdog timer feeding operation. The second processor is the processor in the detection group currently being monitored and used for fault detection. In practical applications, each of the two processors in each detection group can act as either the first or the second processor, meaning that the two processors in each detection group monitor and detect faults from each other.

[0057] In practical applications, the two processors in each detection group can communicate with each other, sending status information, handshake request signals, and response signals. Therefore, the two processors in each detection group can monitor each other and detect their operational status.

[0058] A watchdog timer (WDT) is a timer circuit used to prevent programs from entering infinite loops or system crashes. Specifically, a watchdog timer prevents deadlock by preventing the system from entering an infinite loop due to software errors. It also monitors the system's operating status to ensure normal operation. Finally, it automatically restarts the system if it fails to reset the timer within a specified time.

[0059] In this embodiment, each processor has its own watchdog timer. Each processor has an independent watchdog timer, allowing for individual monitoring of its status and improving system fault tolerance. If one processor fails, it will not affect the watchdog timers of other processors, thus improving the overall system reliability. Each watchdog timer can be configured independently, with different feeding cycles set according to the specific needs and workload of each processor, increasing system flexibility. Because each processor has its own watchdog timer, when a fault occurs, each processor's watchdog timer can respond quickly upon detecting an anomaly, promptly triggering a restart or error handling program to quickly locate the specific processor, improving the reliability of the multi-core system. Independent watchdog timers help maintain system stability, especially in multi-tasking and multi-threaded environments.

[0060] In this embodiment, "feeding the watchdog" is a common term used with watchdog timers. It describes the process of preventing the watchdog timer from timing out and triggering a system reset. Within the watchdog timer's preset feeding period, the system must perform a feeding operation to reset the watchdog timer's counter. In practice, if the watchdog timer's counter is not reset within the feeding period, the watchdog timer will assume a system malfunction (such as a program infinite loop or system suspension) and trigger a system reset or interrupt. By periodically feeding the watchdog, the system can ensure that the watchdog timer does not erroneously trigger a reset, thereby maintaining the normal operation of the system.

[0061] In practical applications, when the system starts up, the watchdog timer is activated and initialized, and begins its countdown. During system operation, the processor will perform a watchdog timer feed operation during the watchdog feed cycle to reset the watchdog timer, thereby preventing the watchdog timer from timing out and ensuring normal system operation.

[0062] Based on the above explanation, the processor typically executes the watchdog timer feeding operation within a fixed feeding cycle. It can be understood that while the first processor is performing the watchdog timer feeding operation, it monitors the status of the second processor, obtaining the monitoring results. This allows for timely detection of faults or anomalies in the second processor, improving the real-time performance of the multi-core system. Furthermore, for each detection group, the two processors monitor and detect faults together, preventing system crashes caused by a single processor failure, thus improving the security and reliability of the multi-core system. In summary, combining fault detection with watchdog feeding not only improves system reliability and stability but also simplifies system design, optimizes resource utilization, and reduces the impact of faults on business operations. This strategy can meet the real-time and reliability requirements of multi-core processor systems.

[0063] In this invention, the method by which the first processor monitors the status of the second processor and obtains the monitoring results is not specifically limited. As an example, the first processor can directly read the memory-mapped registers of the second processor to obtain status information, thereby monitoring the status of the second processor and obtaining monitoring results. As another example, the first and second processors can share a memory region for exchanging status and monitoring information. The first processor determines the status information of the second processor by accessing the shared memory region, thus monitoring the status of the second processor. As yet another example, the first processor can monitor the performance counters of the second processor, such as instruction cycle count or cache hit count, to detect performance degradation or abnormal behavior. As yet another example, a multi-core system may provide an API that allows the first processor to query the health status and operating condition of the second processor. As yet another example, the first processor can monitor the clock signal and frequency of the second processor to ensure they are within the normal range.

[0064] Specifically, in one implementation, Figure 2 This is the second flowchart of the watchdog-based multi-core system security enhancement method provided by the present invention, as shown below. Figure 2 As shown, step 101 above includes step 201 and step 202.

[0065] Step 201: For each detection group, when the first processor performs the watchdog timer feeding operation, it sends a handshake request signal to the second processor.

[0066] Step 202: If the first processor does not receive a response signal from the second processor within the predetermined response time, the monitoring result is determined to be that the second processor has a potential fault; otherwise, the monitoring result is determined to be that the second processor is in normal condition.

[0067] In practice, the first processor sends a handshake request signal to the second processor, and the second processor returns a response signal; this is called a handshake. For example, the handshake request signal can be a status query signal, used to request the second processor to send its current status information; correspondingly, the response signal is the status information of the second processor. For example, the handshake request signal can be a heartbeat signal, and correspondingly, the response signal is a heartbeat response signal.

[0068] In practical applications, the first processor and the second processor can be implemented in a variety of ways, including but not limited to: memory-mapped communication, message queues, interrupts, and dedicated communication interfaces.

[0069] Specifically, for each detection group, when the first processor performs the dog-feeding operation, it sends a handshake request signal to the second processor. When the second processor is functioning normally, it will send a response signal to the first processor within a predetermined response time after the first processor sends the handshake request signal. Therefore, if the first processor does not receive a response signal from the second processor within the predetermined response time, it indicates that the second processor may have a potential fault, and the monitoring result is determined to be a potential fault in the second processor. Conversely, if the first processor receives a response signal from the second processor within the predetermined response time, it indicates that the second processor is functioning normally, and the monitoring result is determined to be normal operation of the second processor.

[0070] In this embodiment, the inter-processor handshake request and response mechanism enables real-time monitoring of processor status, timely detection of faults or abnormal behaviors, and improved system response speed. Furthermore, it simplifies system maintenance and fault diagnosis, allowing for rapid identification of potentially faulty processors. Therefore, this embodiment provides an effective health monitoring method, contributing to stable system operation and high performance.

[0071] Step 102: The first processor determines whether the second processor has malfunctioned based on the monitoring results.

[0072] In practical applications, after the first processor obtains the monitoring results, it further determines whether the second processor has malfunctioned based on the monitoring results. Specifically, in one embodiment, step 102 includes:

[0073] When the monitoring results indicate that the second processor has a potential fault, the first processor attempts to resend the handshake request signal to the second processor.

[0074] If the first processor sends handshake request signals to the second processor multiple times in a row but does not receive a response signal from the second processor, the second processor is determined to be faulty; otherwise, the second processor is determined to be in normal condition.

[0075] Specifically, when the first processor performs the watchdog timer feed operation, it sends a handshake request signal to the second processor. If the first processor does not receive a response signal from the second processor within the predetermined response time, it automatically marks the second processor as having a potential fault.

[0076] Furthermore, the first processor attempts to resend the handshake request signal to the second processor. In practice, the first processor can resend the handshake request signal to the second processor multiple times consecutively, and the maximum number of resends can be set according to actual needs. For example, if the maximum number of resends is 4, and the monitoring result indicates that the second processor has a potential fault, the first processor attempts to resend the handshake request signal to the second processor 3 times. If the first processor does not receive a response signal from the second processor after sending the handshake request signal to the second processor 3 times consecutively, it is determined that the second processor has a fault; otherwise, it is determined that the second processor is in normal condition.

[0077] In this embodiment, after the first processor sends a handshake request signal to the second processor for the first time, if it does not receive a response signal from the second processor, the second processor is automatically marked as potentially faulty. The first processor attempts to resend the handshake request signal to the second processor. Only after the first processor has sent handshake request signals to the second processor multiple times consecutively and has not received a response signal from the second processor is the second processor determined to be faulty. It can be understood that by attempting handshakes multiple times, false positives caused by temporary communication problems or momentary processor overload are reduced, and determining a fault only after receiving multiple consecutive no responses improves the accuracy of fault detection.

[0078] Step 103: If the second processor malfunctions, the first processor obtains the corresponding fault information of the second processor and sends the fault information to the cloud platform.

[0079] In this embodiment, the cloud platform primarily refers to a remote, centralized service capable of receiving fault information from multi-core processor systems, performing data analysis, identifying fault modes, and providing repair suggestions or automatically triggering repair processes. Simultaneously, the cloud platform is also responsible for updating fault information and system status to the user terminal in real time, ensuring that users can be informed of the system status promptly. Such a cloud platform can improve system maintainability, reliability, and user experience. For example, the cloud platform can be a cloud server, a third-party service provider offering cloud computing resources, a data center with a large number of servers and storage devices, a cloud platform providing specific software applications, a platform providing application development and execution, or a cloud platform providing big data processing and analysis capabilities, etc.

[0080] In one example, the fault information includes the program counter (PC) register value of the second processor, the ID number of the second processor, the fault address of the second processor, and the fault time of the second processor.

[0081] The PC register value refers to the value of the PC register itself. In practice, the PC register is a register in a computer processor used to store the address of the next instruction to be executed. It is a crucial component of the processor's state, indicating the current location of program execution. Specifically, the PC register holds the address of either the currently executing instruction or the address of the next instruction to be executed. At each clock cycle of the processor, the PC register value is incremented, pointing to the next instruction, which is then fetched from that address and executed. At the hardware level, the PC register value can be monitored for performance analysis and power management. Therefore, the PC register value is key to understanding the processor's current operating state and is crucial for program execution, debugging, performance analysis, and system stability. In the event of a fault, the PC register value can provide important clues about the cause and location of the fault.

[0082] In practical applications, each processor typically has a unique identifier, or ID number. This ID number helps to quickly identify the specific processor that has failed in a multi-core system. Therefore, determining the ID number of the second processor can pinpoint the specific processor that has failed.

[0083] The fault address of the second processor refers to the memory address or instruction address that caused the second processor to malfunction. This could be a memory access address that caused the exception, or an instruction address that caused the error.

[0084] The failure time of the second processor can be a specific timestamp recording the occurrence of the failure, which helps to analyze the context of the failure, such as system load and executed tasks, and can be used for failure trend analysis.

[0085] In practical applications, after the first processor determines that the second processor has failed, the first processor will read the PC register value and other relevant status information of the failed processor (i.e., the second processor) to provide data support for fault analysis.

[0086] In this embodiment, the method by which the first processor obtains the fault information corresponding to the second processor is not specifically limited. For example, the system can be configured to automatically record the fault information corresponding to the faulty processor to a log file when a fault is detected, and the second processor can read the fault information corresponding to the second processor from the log file. As another example, dedicated monitoring tools and software can be used to track the processor's state and capture fault information when a fault occurs. As yet another example, the processor's internal state, including the PC register value and other status information, can be accessed through debugging interfaces such as JTAG and Core Sight.

[0087] Furthermore, after the first processor obtains the fault information corresponding to the second processor, it sends the fault information to the cloud platform so that the cloud platform can analyze the fault information and repair the second processor in a timely manner.

[0088] Optionally, in one example, step 103 above, which sends the fault information to the cloud platform, includes: encrypting the fault information using a strong encryption algorithm, and sending the encrypted fault information to the cloud platform through a secure communication protocol.

[0089] In this example, a strong encryption algorithm is used to encrypt the fault information, and the encrypted fault information is sent to the cloud platform through a secure communication protocol. This ensures that the fault information is transmitted to the cloud platform securely and without loss, allowing the cloud platform to analyze the fault information and repair the second processor in a timely manner, thereby improving the reliability and security of the multi-core system.

[0090] Step 104: The cloud platform repairs the second processor based on the fault information.

[0091] Specifically, in one embodiment, step 104 includes: the cloud platform performing data analysis on the fault information to identify the fault type of the second processor; and the cloud platform providing repair suggestions or automatically triggering a repair process based on the fault type of the second processor.

[0092] In practical applications, after receiving fault information, the cloud platform can perform further data analysis to identify the fault type. For example, the fault type could be hardware failure, software error, overheating, power supply issues, etc. Furthermore, after identifying the fault type of the second processor, the cloud platform can provide timely repair suggestions or automatically trigger a repair process based on the fault type of the second processor.

[0093] Specifically, the cloud platform can provide repair suggestions based on the type of fault in the second processor. For example, these suggestions may include operational steps, configuration changes, software updates, etc. In practical applications, after the cloud platform provides repair suggestions, users can choose whether to repair the second processor according to the suggestions.

[0094] Specifically, corresponding repair processes can be pre-configured for different fault types. For some known fault types that can be handled automatically, the cloud platform can automatically trigger repair processes, such as restarting services, resetting configurations, and applying patches.

[0095] In this embodiment, corresponding repair suggestions or automatic triggering of repair processes are provided for different fault types, which can simplify the processor repair process, save processor repair time, and improve the reliability and security of multi-core systems.

[0096] In this embodiment, multiple processors are paired up into detection groups. Within each group, the two processors monitor and detect faults in each other. This grouping strategy simplifies the system architecture and improves the sensitivity and response speed of fault detection. Furthermore, when the first processor determines that the second processor has malfunctioned based on the monitoring results, it can obtain the corresponding fault information of the second processor in real time and send it to the cloud platform for timely repair, ensuring the performance and stability of the entire system. Therefore, this embodiment improves the reliability and security of the multi-core system.

[0097] Furthermore, in one possible implementation, the aforementioned multi-core system also includes a user terminal. After the cloud platform provides repair suggestions or automatically triggers a repair process based on the fault type of the second processor, the method further includes:

[0098] The cloud platform generates a fault report and determines the system status of the multi-core system;

[0099] The cloud platform will update fault information, system status of multi-core systems, fault reports, and repair suggestions to the user terminal in real time.

[0100] In practical applications, the first processor sends fault information to the cloud platform, including PC register values, processor ID, fault address, and fault time. The cloud platform collects fault information corresponding to all faulty second processors in the multi-core system. Furthermore, the cloud platform utilizes its data analysis capabilities to conduct in-depth analysis of the collected fault information, identifying the fault type and root cause. Based on the analysis results, the cloud platform generates a detailed fault report, including the fault type, possible causes, scope of impact, and recommended operating procedures.

[0101] In practical applications, determining the system status of a multi-core system typically involves collecting, analyzing, and processing data from various parts of the system. For example, the cloud platform collects status data through interfaces with the multi-core system (such as APIs, network interfaces, etc.). This data may include processor load, temperature, memory usage, storage usage, network status, etc. The cloud platform then synthesizes all collected status data to analyze and determine the system status of the multi-core system.

[0102] Furthermore, the cloud platform will update fault information, system status of multi-core systems, fault reports, and repair suggestions to the user terminal in real time, ensuring that users can understand the system status in a timely manner.

[0103] In this implementation, after receiving fault information, the cloud platform can perform further data analysis, identify the fault type, and provide repair suggestions or automatically trigger the repair process. The cloud platform updates fault information and system status to the user terminal in real time, ensuring that users can understand the system status in a timely manner and reducing the inconvenience caused by system failures.

[0104] Furthermore, in one possible implementation, after the cloud platform updates fault information, the system status of the multi-core system, fault reports, and repair suggestions to the user terminal in real time, the method further includes:

[0105] The user interface will visualize fault information, system status of multi-core systems, fault reports, and repair suggestions.

[0106] In this embodiment, the user terminal provides a user-friendly interface that displays system status, fault reports, and repair suggestions, enabling users to easily manage multi-core processor systems and achieving human-computer interaction.

[0107] In practical applications, a watchdog in Human-Machine Interaction (HMI) typically refers to a system-level monitoring mechanism used to ensure stable system operation and prevent program infinite loops or system crashes. While the watchdog generally does not directly interact with the user in the HMI, its role is crucial for improving the user experience. For example, the following are scenarios where watchdog timers might involve human-computer interaction: System status indication: On some devices, system status may be indicated by LEDs or displays, which may include the watchdog's status, such as normal operation or reset; Error message prompts: If the watchdog triggers a system reset, an error message or warning may need to be displayed on the human-computer interface to inform the user that the system has automatically restarted; Configuration interface: In some advanced devices, users may be allowed to configure watchdog parameters, such as timeout and feeding cycle, through the human-computer interface; Logging: The system may log watchdog events and provide them to users or maintenance personnel for viewing through the human-computer interface to facilitate fault diagnosis; Maintenance mode: In maintenance mode, technicians can test the watchdog through the human-computer interface to ensure its normal operation; Security mechanisms: The watchdog can be part of a security mechanism, triggering a security program when a system anomaly is detected and notifying the user through the interface.

[0108] Furthermore, in one possible implementation, the watchdog timer's operating modes include a first mode and a second mode. Figure 3 This is a flowchart illustrating the watchdog process under different modes provided by the present invention, such as... Figure 3 As shown, the method further includes steps 301 to 302.

[0109] Step 301: Determine whether the watchdog timer is in the first mode.

[0110] Step 302: If the watchdog timer is in the first mode, then perform a direct reset.

[0111] The direct reset process includes: if the processor corresponding to the watchdog timer does not perform the watchdog operation during the watchdog feeding cycle, the watchdog timer directly resets and restarts the processor corresponding to the watchdog timer.

[0112] Step 303: If the watchdog timer is in the second mode, then execute the interrupt reset process.

[0113] The interrupt reset process includes: if the processor corresponding to the watchdog timer does not perform the watchdog feeding operation during the watchdog feeding cycle, the interrupt handler is entered; if the processor corresponding to the watchdog timer still does not perform the watchdog feeding operation during the next watchdog feeding cycle, the watchdog timer resets and restarts the processor corresponding to the watchdog timer.

[0114] Specifically, in the first mode, the system will immediately reset once the watchdog timer times out. This approach is suitable for systems that require rapid recovery, such as in safety-critical applications. The first mode does not require complex interrupt handling logic, making system design and implementation relatively simple.

[0115] Specifically, in the second mode, the system has the opportunity to handle potential errors or exceptions through an interrupt service routine before the watchdog timer expires. This allows the system to perform error recovery operations, such as logging and state saving, before an actual reset. If the problem can be resolved in a timely manner, the system can avoid unnecessary restarts, thereby reducing system downtime. For systems requiring complex error handling and recovery strategies, the second mode provides greater flexibility. By allowing the system to perform self-checks and state recovery before a reset, system stability and reliability are improved. Optionally, in the second mode, after entering the interrupt handler, a warning or notification can be provided to the user so that the user can save their work or take other necessary actions.

[0116] In this implementation, the watchdog timer operates in two modes: a first mode and a second mode. The first mode provides a fast and simple system reset mechanism, suitable for applications with high response time requirements; while the second mode offers greater flexibility and error handling capabilities, suitable for applications requiring complex error recovery strategies. Users can select the most suitable mode based on specific application needs and system characteristics, improving the flexibility of multi-core systems.

[0117] This embodiment provides a watchdog-based security enhancement method for multi-core systems. The multi-core system includes multiple processors, a watchdog timer configured for each processor, and a cloud platform. The processors are paired up as detection groups. The method includes: for each detection group, when the first processor performs a watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results; the first processor determines whether the second processor has malfunctioned based on the monitoring results; if the second processor malfunctions, the first processor obtains the corresponding fault information and sends it to the cloud platform; the cloud platform repairs the second processor based on the fault information. This embodiment's solution, by pairing multiple processors into detection groups, allows for mutual monitoring and fault detection between the two processors in each group. This grouping strategy simplifies the system architecture and improves the sensitivity and response speed of fault detection. Furthermore, when the first processor determines that the second processor has malfunctioned based on the monitoring results, it can obtain the corresponding fault information in real time and send it to the cloud platform for timely repair of the second processor, ensuring the performance and stability of the entire system. Therefore, this embodiment's solution improves the reliability and security of the multi-core system.

[0118] The multi-core system provided by this invention is described below. The multi-core system described below and the watchdog-based multi-core system security enhancement method described above can be referred to and correspond to each other.

[0119] Figure 4 This is a schematic diagram of the system architecture of the multi-core system provided by the present invention, such as... Figure 4 As shown, the multi-core system includes: multiple processors 40, a watchdog timer 41 configured for each processor 40, and a cloud platform 42. The multiple processors 40 are paired up in pairs to form a detection group 43.

[0120] For each detection group 43, the first processor is used to monitor the status of the second processor and obtain the monitoring results when the watchdog timer 41 is fed.

[0121] The first processor is also used to determine whether the second processor has malfunctioned based on the monitoring results;

[0122] The first processor is also used to obtain the corresponding fault information of the second processor and send the fault information to the cloud platform 42 if the second processor fails.

[0123] Cloud platform 42 is used to repair the second processor based on fault information.

[0124] Specifically, the multi-core system includes multiple processors 40. Leveraging the advantage of multi-core parallel operation, the processors 40 are grouped in pairs, meaning each processor 40 is paired with another processor 40 to form a detection group 43. For example, if the multi-core system includes four processors 40, these four processors 40 can be divided into two detection groups 43. Understandably, with this grouping method, each processor 40 corresponds to one processor 40 for monitoring its own operating status and fault detection. Therefore, this grouping strategy not only simplifies the system architecture but also improves the sensitivity and response speed of fault detection.

[0125] Optionally, depending on the actual monitoring and fault detection needs, each detection group 43 may be equipped with other numbers of processors 40. This embodiment does not impose specific limitations.

[0126] Optionally, the pairing of each processor 40 can be dynamically adjusted to adapt to different system loads and processor 40 performance.

[0127] In this system, the first processor and the second processor belong to the same monitoring group. Specifically, the first processor refers to the processor 40 among the two processors 40 in detection group 43 that is currently performing the watchdog timer feeding operation. The second processor refers to the processor 40 among the two processors 40 in detection group 43 that is currently being monitored and fault detected. In practical applications, each of the two processors 40 in each detection group 43 can act as either the first processor or the second processor, meaning that the two processors 40 in each detection group 43 monitor and detect faults in each other.

[0128] In practical applications, the two processors 40 in each detection group 43 can communicate with each other, sending status information, handshake request signals, and response signals. Therefore, the two processors 40 in each detection group 43 can monitor each other and detect their working status.

[0129] The watchdog timer 41 (WDT) is a timer circuit used to prevent program infinite loops or system crashes. Specifically, the watchdog timer 41 prevents deadlock by preventing the system from entering an infinite loop due to software errors. It also monitors the system's operating status to ensure normal operation. Finally, it automatically restarts the system if it fails to reset the timer within a specified time.

[0130] In this embodiment, each processor 40 is assigned a watchdog timer 41. Each processor 40 has an independent watchdog timer 41, allowing for individual monitoring of its status and improving system fault tolerance. If one processor 40 fails, it will not affect the watchdog timers 41 of other processors 40, thus improving the overall system reliability. Each watchdog timer 41 can be configured independently, with different feeding cycles set according to the specific needs and workload of each processor 40, improving system flexibility. Since each processor 40 has its own watchdog timer 41, when a fault occurs, each processor 40's watchdog timer 41 can respond quickly upon detecting an anomaly, promptly triggering a restart or error handling program to quickly locate the specific processor 40, improving the reliability of the multi-core system. Independent watchdog timers 41 help maintain system stability, especially in multi-tasking and multi-threaded environments.

[0131] In this embodiment, "feeding the watchdog" is a common term for the watchdog timer 41, describing the process of preventing the watchdog timer 41 from timing out and triggering a system reset. Within the preset feeding cycle of the watchdog timer 41, the system must perform a feeding operation to reset the watchdog timer 41's counter. In practice, if the watchdog timer 41's counter is not reset within the feeding cycle, the watchdog timer 41 will assume a system malfunction (such as a program infinite loop or system hang) and trigger a system reset or interrupt. Through periodic feeding operations, the system can ensure that the watchdog timer 41 does not erroneously trigger a reset, thereby maintaining the normal operation of the system.

[0132] In practical applications, when the system starts up, the watchdog timer 41 is activated and initialized, and begins its countdown. During system operation, the processor 40 will perform a watchdog timer feeding operation during the watchdog feeding cycle to reset the watchdog timer 41, thereby preventing the watchdog timer 41 from timing out and ensuring normal system operation.

[0133] Based on the above explanation, processor 40 typically executes the watchdog timer 41's watchdog feeding operation within a fixed feeding cycle. It can be understood that while the first processor is executing the watchdog timer 41's watchdog feeding operation, it monitors the status of the second processor, obtains the monitoring results, and can promptly detect faults or anomalies in the second processor, improving the real-time performance of the multi-core system. Furthermore, for each detection group 43, the two processors 40 monitor and detect faults together, preventing the entire system from crashing due to a single processor 40's failure, thus improving the security and reliability of the multi-core system. In summary, combining fault detection operations with watchdog feeding operations not only improves system reliability and stability but also simplifies system design, optimizes resource utilization, and reduces the impact of faults on business operations. This strategy can meet the real-time and reliability requirements of multi-core processor systems.

[0134] In this invention, the method by which the first processor monitors the status of the second processor and obtains the monitoring results is not specifically limited. As an example, the first processor can directly read the memory-mapped registers of the second processor to obtain status information, thereby monitoring the status of the second processor and obtaining monitoring results. As another example, the first and second processors can share a memory region for exchanging status and monitoring information. The first processor determines the status information of the second processor by accessing the shared memory region, thus monitoring the status of the second processor. As yet another example, the first processor can monitor the performance counters of the second processor, such as instruction cycle count or cache hit count, to detect performance degradation or abnormal behavior. As yet another example, a multi-core system may provide an API that allows the first processor to query the health status and operating condition of the second processor. As yet another example, the first processor can monitor the clock signal and frequency of the second processor to ensure they are within the normal range.

[0135] Specifically, in one embodiment, the first processor is used to monitor the status of the second processor when performing the watchdog timer 41 feeding operation and to obtain the monitoring result. Specifically, it is used to: send a handshake request signal to the second processor when performing the watchdog timer 41 feeding operation; if no response signal is received from the second processor within a predetermined response time, it is determined that the monitoring result indicates that the second processor has a potential fault; otherwise, it is determined that the monitoring result indicates that the second processor is in normal condition.

[0136] In this embodiment, the handshake request and response mechanism between processors 40 enables real-time monitoring of the processor 40's status, timely detection of faults or abnormal behaviors, and improved system response speed. Furthermore, it simplifies system maintenance and fault diagnosis, allowing for rapid identification of potentially faulty processors 40. Therefore, this embodiment provides an effective health monitoring method, contributing to stable system operation and high performance.

[0137] In practical applications, after the first processor obtains the monitoring results, it further determines whether the second processor has malfunctioned based on the monitoring results. Specifically, in one embodiment, when the first processor determines whether the second processor has malfunctioned based on the monitoring results, it specifically performs the following: if the monitoring results indicate that the second processor has a potential malfunction, the first processor attempts to resend a handshake request signal to the second processor; if the first processor sends handshake request signals to the second processor multiple times consecutively but does not receive a response signal from the second processor, it determines that the second processor has malfunctioned; otherwise, it determines that the second processor is in a normal state.

[0138] In this embodiment, after the first processor sends a handshake request signal to the second processor for the first time, if it does not receive a response signal from the second processor, the second processor is automatically marked as potentially faulty. The first processor attempts to resend the handshake request signal to the second processor. Only after the first processor has sent handshake request signals to the second processor multiple times consecutively and has not received a response signal from the second processor is the second processor determined to be faulty. It can be understood that by attempting handshakes multiple times, false judgments caused by temporary communication problems or momentary processor overload are reduced, and determining a fault only after receiving multiple consecutive no responses improves the accuracy of fault detection.

[0139] In one example, the fault information includes the program counter (PC) register value of the second processor, the ID number of the second processor, the fault address of the second processor, and the fault time of the second processor.

[0140] Furthermore, after the first processor obtains the fault information corresponding to the second processor, it sends the fault information to the cloud platform 42 so that the cloud platform 42 can analyze the fault information and repair the second processor in a timely manner.

[0141] Optionally, in one example, when the first processor sends the fault information to the cloud platform 42, it is specifically used to: encrypt the fault information using a strong encryption algorithm, and send the encrypted fault information to the cloud platform 42 through a secure communication protocol.

[0142] In this example, a strong encryption algorithm is used to encrypt the fault information, and the encrypted fault information is sent to the cloud platform 42 through a secure communication protocol. This ensures that the fault information is transmitted to the cloud platform 42 securely and without loss, and that the cloud platform 42 can analyze the fault information and repair the second processor in a timely manner, thereby improving the reliability and security of the multi-core system.

[0143] Specifically, in one embodiment, when the cloud platform 42 is used to repair the second processor based on the fault information, it is specifically used for: the cloud platform 42 performing data analysis on the fault information to identify the fault type of the second processor; and the cloud platform 42 providing repair suggestions or automatically triggering the repair process based on the fault type of the second processor.

[0144] In this embodiment, corresponding repair suggestions or automatic triggering of repair processes are provided for different fault types, which can simplify the processor 40 repair process, save processor 40 repair time, and improve the reliability and security of multi-core systems.

[0145] In addition, in one possible implementation, the multi-core system also includes a user terminal, and the cloud platform 42 is further used to: generate a fault report and determine the system status of the multi-core system; and update the fault information, the system status of the multi-core system, the fault report, and repair suggestions to the user terminal in real time.

[0146] In this embodiment, after receiving fault information, the cloud platform 42 can perform further data analysis, identify the fault type, and provide repair suggestions or automatically trigger the repair process. The cloud platform 42 updates the fault information and system status to the user terminal in real time, ensuring that the user can understand the system status in a timely manner and reducing the inconvenience caused by system failures.

[0147] In addition, in one possible implementation, the aforementioned client is used to visualize fault information, the system status of the multi-core system, fault reports, and repair suggestions through a user interface.

[0148] In this embodiment, the user terminal provides a user-friendly interface that displays system status, fault reports, and repair suggestions, enabling users to easily manage multi-core processor systems and achieving human-computer interaction.

[0149] Furthermore, in one possible implementation, the watchdog timer 41 operates in two modes: a first mode and a second mode. The watchdog timer 41 is used to determine whether its operating mode is the first mode. If the watchdog timer 41 operates in the first mode, it performs a direct reset. The direct reset includes: if the processor 40 corresponding to the watchdog timer 41 does not perform a feed operation during the feed cycle, the watchdog timer 41 directly resets and restarts the processor 40. The watchdog timer 41 is also used to perform an interrupt reset if its operating mode is the first mode. The interrupt reset includes: if the processor 40 corresponding to the watchdog timer 41 does not perform a feed operation during the feed cycle, it enters an interrupt handler; if the processor 40 corresponding to the watchdog timer 41 still does not perform a feed operation during the next feed cycle, the watchdog timer 41 resets and restarts the processor 40.

[0150] In this embodiment, the watchdog timer 41 operates in two modes: a first mode and a second mode. The first mode provides a fast and simple system reset mechanism, suitable for applications with high response time requirements; while the second mode offers greater flexibility and error handling capabilities, suitable for applications requiring complex error recovery strategies. Users can select the most suitable mode based on specific application needs and system characteristics, improving the flexibility of multi-core systems.

[0151] This embodiment provides a multi-core system comprising multiple processors, a watchdog timer configured for each processor, and a cloud platform. The processors are paired in pairs to form detection groups. The method includes: for each detection group, when the first processor performs a watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results; the first processor determines whether the second processor has malfunctioned based on the monitoring results; if the second processor malfunctions, the first processor obtains the corresponding fault information and sends the fault information to the cloud platform; the cloud platform repairs the second processor based on the fault information. This embodiment's solution, by pairing multiple processors in pairs to form detection groups, allows two processors in each detection group to monitor and detect faults against each other. This grouping strategy not only simplifies the system architecture but also improves the sensitivity and response speed of fault detection. Furthermore, when the first processor determines that the second processor has malfunctioned based on the monitoring results, it can obtain the corresponding fault information of the second processor in real time and send the fault information to the cloud platform for timely repair of the second processor, ensuring the performance and stability of the entire system. Therefore, this embodiment's solution improves the reliability and security of the multi-core system.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A watchdog-based security enhancement method for multi-core systems, characterized in that, Applied to a multi-core system, the multi-core system includes multiple processors, a watchdog timer configured for each processor, and a cloud platform, wherein the multiple processors are paired up as detection groups; the method includes: For each detection group, when the first processor performs the watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results. The first processor determines whether the second processor has malfunctioned based on the monitoring results; If the second processor malfunctions, the first processor obtains the fault information corresponding to the second processor and sends the fault information to the cloud platform. The cloud platform repairs the second processor based on the fault information.

2. The watchdog-based multi-core system security enhancement method according to claim 1, characterized in that, When the first processor performs the watchdog timer feeding operation, it monitors the status of the second processor and obtains the monitoring results, including: When the first processor performs the watchdog timer feeding operation, it sends a handshake request signal to the second processor. If the first processor does not receive a response signal from the second processor within the predetermined response time, the monitoring result is determined to be that the second processor has a potential fault; otherwise, the monitoring result is determined to be that the second processor is in normal condition.

3. The watchdog-based multi-core system security enhancement method according to claim 2, characterized in that, The first processor determines whether the second processor has malfunctioned based on the monitoring results, including: When the monitoring result indicates that the second processor has a potential fault, the first processor attempts to resend the handshake request signal to the second processor. If the first processor sends the handshake request signal to the second processor multiple times in a row and does not receive a response signal from the second processor, then the second processor is determined to be faulty; otherwise, the second processor is determined to be in normal condition.

4. The multi-core system security enhancement method based on watchdog timer according to claim 1, characterized in that, The fault information includes: The program counter register value of the second processor, the ID number of the second processor, the fault address of the second processor, and the fault time of the second processor.

5. The multi-core system security enhancement method based on watchdog timer according to claim 1, characterized in that, Sending the fault information to the cloud platform includes: The fault information is encrypted using a strong encryption algorithm, and the encrypted fault information is sent to the cloud platform through a secure communication protocol.

6. The watchdog-based security enhancement method for multi-core systems according to claim 1, characterized in that, The cloud platform repairs the second processor based on the fault information, including: The cloud platform performs data analysis on the fault information to identify the fault type of the second processor; The cloud platform provides repair suggestions or automatically triggers a repair process based on the fault type of the second processor.

7. The watchdog-based multi-core system security enhancement method according to claim 6, characterized in that, The multi-core system also includes a user terminal; after the cloud platform provides repair suggestions or automatically triggers a repair process based on the fault type of the second processor, the method further includes: The cloud platform generates a fault report and determines the system status of the multi-core system; The cloud platform updates the fault information, the system status of the multi-core system, the fault report, and the repair suggestions to the user terminal in real time.

8. The watchdog-based multi-core system security enhancement method according to claim 7, characterized in that, After the cloud platform updates the fault information, the system status of the multi-core system, the fault report, and the repair suggestions to the user terminal in real time, the method further includes: The user terminal displays the fault information, the system status of the multi-core system, the fault report, and the repair suggestions visually through the user interface.

9. The watchdog-based security enhancement method for multi-core systems according to any one of claims 1-8, characterized in that, The method further includes: The watchdog timer has two operating modes: a first mode and a second mode. If the watchdog timer is in the first mode, a direct reset is performed; wherein, the direct reset includes: if the processor corresponding to the watchdog timer does not perform a watchdog operation during the watchdog feeding cycle, the watchdog timer directly resets and restarts the processor corresponding to the watchdog timer. If the watchdog timer is in the second operating mode, an interrupt reset process is executed. The interrupt reset process includes: if the processor corresponding to the watchdog timer does not perform a watchdog feeding operation during the watchdog feeding cycle, the interrupt handler is entered; if the processor corresponding to the watchdog timer still does not perform a watchdog feeding operation during the next watchdog feeding cycle, the watchdog timer resets and restarts the processor corresponding to the watchdog timer.

10. A multi-core based system, characterized in that, The multi-core system includes: multiple processors, a watchdog timer configured for each processor, and a cloud platform. The multiple processors are paired up in pairs to form a detection group. For each detection group, the first processor is used to monitor the status of the second processor and obtain the monitoring results when the watchdog timer is fed. The first processor is also used to determine whether the second processor has malfunctioned based on the monitoring results; The first processor is further configured to, if the second processor malfunctions, obtain fault information corresponding to the second processor and send the fault information to the cloud platform; The cloud platform is used to repair the second processor based on the fault information.

Images