High-reliability embedded processor redundancy method based on dynamic dual-modular redundancy

Abstract

The invention relates to a high-reliability embedded processor redundancy method based on dynamic dual-module redundancy. The invention relates to the technical field of medical ultrasonic sensors, a dynamic dual-mode redundancy architecture breaks through the limitation that a backup mode in a traditional dual-computer hot standby architecture is fixed, and a redundancy system capable of being flexibly adjusted is constructed by introducing a warm standby processor unit. According to the method, the fault nodes can be automatically identified and replaced in the system operation process, and the fault-tolerant capability and the reconstruction flexibility of the system are greatly improved in a multi-node fault scene. Meanwhile, compared with triple modular redundancy and an improved scheme thereof, the architecture does not need to maintain continuous parallel operation of three nodes, and is more suitable for application scenes sensitive to cost and resources.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of dual-machine hot backup, and is a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy. BACKGROUND

[0002] In the fields of industrial automation, cloud computing, communication network, etc., the high reliability and service continuity of a system are of great importance. With the increase of system complexity, software failure, data transmission delay and multi-node failure problems occur frequently, and the existing technology cannot meet the stringent requirements in complex scenarios. In these application scenarios, it is very important to build an embedded system with high reliability. Dual-machine hot backup redundancy is a common technology for effectively improving system reliability and maintaining reliable operation under system failure conditions.

[0003] In terms of fault detection and processing, the dual-machine hot backup technology adopts a node-level detection mechanism. This coarse-grained detection method has a large number of detection blind spots, and when a software process is abnormal, it cannot be detected and processed in time, which easily leads to a decline in the overall performance of the system or even a crash. At the same time, a single fault processing strategy lacks flexibility and is difficult to adapt to diverse fault scenarios. The master-slave switching mechanism is a key technology for dual-machine hot backup, and the traditional single heartbeat link architecture has a single point of failure. Once the heartbeat link fails, it may cause a state misjudgment of the master-slave machine, leading to a "split brain" problem, i.e., the master-slave machine simultaneously considers itself as the master, causing data conflicts and service interruption. In the system backup mode, the dual-machine hot backup architecture lacks the ability to flexibly reconstruct, and it is difficult to quickly restore the normal operation of the system. Although the three-mode redundancy and its improved scheme can improve fault tolerance, they have problems of high power consumption, large size and serious waste of resources, which are not suitable for application scenarios sensitive to cost and resources. SUMMARY

[0004] In view of the above defects or improvement needs of the prior art, the present application provides a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy, which combines a daemon process for collecting processor running states and a dual-heartbeat chain redundancy technology, and aims to improve the reliability and stability of the long-term uninterrupted operation of the dual-machine hot backup system.

[0005] The present application provides the following technical solutions: A high-reliability embedded processor redundancy architecture based on dynamic dual-mode redundancy, the architecture comprising: a master machine, a hot backup machine and a warm backup machine, and each single machine is assigned a priority, and the priorities from high to low are the master machine, the hot backup machine and the warm backup machine; After the system is powered on, the master machine and the backup machine enter a hot backup running state, and the warm backup machine enters a low-power standby mode and only starts a basic state monitoring module and a data receiving module; The daemon process is independently started in the host and the backup machine, initializes the fault symptom database, and sets the heartbeat signal sending period to 50 ms. The dual-redundancy heartbeat link completes self-checking and connection establishment, and the host and the backup machine synchronize the initial system configuration parameters and the initial value of the reliability weight.

[0006] A high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy, wherein the method is operated based on a high-reliability embedded processor redundancy architecture based on dynamic dual-mode redundancy, and characterized in that the method comprises the following steps: Step 1: The host and the backup machine execute the industrial control algorithm in real time and perform data synchronization. Step 2: State detection, the dual-redundancy heartbeat link alternately sends heartbeat signals according to the set heartbeat signal sending period. Step 3: Three-machine data synchronization, the redundant system runs the timing shared data, the host and the hot backup machine need to send data to each other, the warm backup machine receives data, and synchronizes the running state with other single machines when it is woken up. Step 4: Fault data synchronization, when the host and the backup machine switch to the host, a broadcast frame with a “host node switching” identifier is immediately sent, the warm backup machine activates the synchronization mode after receiving it, and interacts with the new host to exchange data. The host and the backup machine execute majority voting according to the three-machine data, and the voting result is synchronized to the three machines through a broadcast frame. Step 5: Dual-machine data inconsistency processing, the data of the host and the backup machine are synchronized and compared using step 3. Step 6: Host fault processing, the host triggers the hardware watchdog reset due to CPU core damage, the hot machine determines that the host node is invalid after not receiving the valid heartbeat signal of the host for three consecutive heartbeat periods, and triggers the dynamic dual-mode redundancy single-machine node-level fault tolerance process. Step 7: Hot backup machine fault processing, the hot backup machine triggers the hardware watchdog reset due to CPU core damage, and the host determines that the hot backup machine node is invalid after not receiving the valid heartbeat signal of the hot backup machine for three consecutive heartbeat periods, and triggers the dynamic dual-mode redundancy single-machine node-level fault tolerance process. Step 8: Software process fault processing. Step 9: Redundant system output control, the host and the hot backup machine in the dynamic dual-mode redundancy system simultaneously receive data transmitted from the outside of the system, process the data, and simultaneously send data to the outside.

[0007] Preferably, step 1 is specifically: Data synchronization is performed every 10 ms, and the synchronization content includes sensor acquisition data, intermediate results of operation, and control instructions; the daemon process sends heartbeat signals to the software processes in the host and the backup machine according to the period, collects process response time, memory occupancy rate, and other indicators, and updates the fault symptom database.

[0008] Preferably, the step 2 is specifically: The dual-redundant heartbeat link alternately sends heartbeat signals according to a set heartbeat signal sending period, the interval time between the two heartbeat signals is 10 ms, the heartbeat signal content contains a local operation state code, a reliability weight value and a check code, the receiving end sets a heartbeat signal timeout time as three heartbeat periods, and if no heartbeat signal of the other party is received within the timeout time, a dynamic dual-mode redundant single-machine node fault tolerance process is triggered to wake up the warm standby machine and reconfigure a dual-machine hot standby redundancy system with the surviving single machine. When one heartbeat signal is received within 60 ms, it indicates that the heartbeat signal communication link between the dual machines is not damaged due to external interference and the other single machine node is alive, and the receiving end decodes and checks the heartbeat signal and updates the other party state table.

[0009] Preferably, the step 3 is specifically: The redundancy system shares data at a running timing, the master machine and the hot standby machine send data to each other, and the warm standby machine receives the data so as to quickly synchronize with the running state of other single machines when it is woken up; the master machine sends a control instruction frame and a sensor data frame every 10 ms, the frame ID contains a master machine identifier, and the hot standby machine and the warm standby machine listen and analyze in real time; After receiving, the hot standby machine compares the local operation result with the synchronization data, and if they are consistent, the hot standby machine sends a confirmation frame containing its own state weight every 20 ms; if they are inconsistent, the hot standby machine immediately sends a difference frame with a priority identifier to mark the inconsistent field. The warm standby machine is in a low-power consumption listening mode, only receives the state frames of the master machine and the standby machine, and updates the local backup data every 100 ms, without actively sending data.

[0010] Preferably, the step 6 is specifically: The warm standby machine is automatically activated, completes system image loading and data synchronization within 50 ms, and forms a new dual-machine hot standby system with the standby machine, the hot standby machine is switched to the master machine, and the warm standby machine serves as the hot standby machine; the new master machine sends a fault switching message to a control bus, records the fault time and the last running parameters of the old master machine, and a daemon process marks the fault type of the old master machine as "permanent hardware failure" and writes it into a log.

[0011] Preferably, the step 7 is specifically: The warm standby machine is automatically activated, completes system image loading and data synchronization within 50 ms, and forms a new dual-machine hot standby system with the master machine, and the warm standby machine serves as the hot standby machine; a daemon process marks the fault type of the hot standby machine as "permanent hardware failure" and writes it into a log.

[0012] Preferably, the step 8 is specifically: The system is running a certain process of a single machine deadlock, unable to trigger node level detection alarm mechanism, daemon process does not receive the heartbeat response of the process for 2 times in succession, calls the fault analysis module, and judges as "process level permanent fault" in combination with historical data; process restart mechanism is triggered, the reliability of the single machine of the process failure is reduced by 0.5, and the reset and initialization of the process are completed within 100ms, and if the process resumes normal operation after restart, the reliability of the single machine is restored.

[0013] A computer readable storage medium has a computer program stored thereon, and the program is executed by a processor to implement a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy.

[0014] A computer device includes a memory and a processor, the memory stores a computer program, and the processor implements a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy when executing the computer program.

[0015] The present application has the following beneficial effects: The dynamic dual-mode redundancy architecture breaks the limitation of the fixed backup mode in the traditional dual-machine hot backup architecture, and a flexible redundancy system is constructed by introducing a warm backup processor unit. The architecture can automatically identify and replace the failed node during system operation, and greatly improves the fault tolerance and reconstruction flexibility of the system in the multi-node failure scenario. Compared with the three-mode redundancy and its improved scheme, the architecture does not need to maintain the continuous parallel operation of three nodes, and is more suitable for application scenarios sensitive to cost and resources.

[0016] The daemon process designed independently of the master-slave system constructs a fine-grained fault monitoring system. The process runs in a separate secure execution environment and is not affected by software faults in the master-slave system. It can periodically send heartbeat signals to each software process of the master-slave system and analyze the response information in detail. By establishing a fault symptom database and using preset rules, the framework improves the fault positioning accuracy from the traditional node level to the process level, accurately detects internal faults such as software process freezing and resource leakage that are difficult to identify by traditional systems, effectively eliminates the fault detection blind area, and improves the response speed of the system to software faults.

[0017] The dual-redundancy physical layer heartbeat line architecture designed in the present application avoids the single-point failure risk of the traditional single-heartbeat line architecture from the physical layer. When one of the links fails, the system can seamlessly switch to the other link to continue transmitting heartbeat signals, ensuring that the master and standby machines can accurately obtain the status information of the other party, and completely solving the problem of status misjudgment of the master and standby machines caused by single-link failure.

[0018] The present application assigns a reliability weight to each single machine, which is dynamically adjusted according to the real-time running state of the processor and reflects the health degree of the device. When the master and standby machines perform data synchronization, they will share the reliability weight information with each other and judge the output authority according to the weight. When the data of the two machines are consistent, the weight is equal, and the master machine is defaulted to output; when the weight is not equal, the device with the higher weight is selected to output. This mechanism effectively avoids the occurrence of the'split brain' problem from the logical level and improves the service continuity of the system. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the specific embodiments or the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or the prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0020] Figure 1 A dynamic dual-mode redundancy topology structure of the present application is shown. Figure 2 A dynamic dual-mode redundancy single machine transient fault tolerance flow chart of the present application is shown. Figure 3 A dynamic dual-mode redundancy single machine node level fault tolerance flow chart of the present application is shown. Figure 4 An output control flow chart of the dynamic dual-mode redundancy of the present application is shown. DETAILED DESCRIPTION

[0021] The technical solutions of the present application will be described in detail below with reference to the drawings. Obviously, the described embodiments are some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort belong to the protection scope of the present application.

[0022] The present application will be described in detail below with reference to the specific embodiments. Embodiment one: According to Figures 1 to 4 As shown in the figure, the specific optimization technical solution adopted by the present application to solve the above technical problems is: the present application relates to a high reliability embedded processor redundancy method based on dynamic dual-mode redundancy.

[0024] The present application provides a high reliability embedded processor redundancy architecture based on dynamic dual-mode redundancy, which comprises: a master machine, a hot standby machine and a warm standby machine, and each single machine is assigned a priority, and the priorities from high to low are the master machine, the hot standby machine and the warm standby machine. After the system is powered on, the host and the backup enter a hot backup running state, the warm backup enters a low-power standby mode, and only a basic state monitoring module and a data receiving module are started; The daemon processes are independently started in the host and the backup, initialize a fault symptom database, and set a heartbeat signal sending period to 50 ms. The dual-redundancy heartbeat link completes self-checking and connection establishment, and the host and the backup synchronize initial system configuration parameters and initial values of reliability weights.

[0025] The dynamic dual-mode redundancy architecture breaks the limitation that the backup mode is fixed in the traditional dual-computer hot backup architecture, and a flexible redundancy system is constructed by introducing a warm backup processor unit. The architecture can realize automatic identification and replacement of a fault node during system operation, greatly improves the fault tolerance and reconstruction flexibility of the system in a multi-node fault scenario. Meanwhile, compared with a three-mode redundancy and an improved scheme thereof, the architecture does not need to maintain the continuous parallel operation of three nodes, and is more suitable for application scenarios sensitive to cost and resources.

[0026] The daemon process designed in the application is independent of the host and backup systems, and a fine-grained fault monitoring system is constructed. The process runs in an independent secure execution environment and is not affected by software faults of the host and backup systems, can periodically send heartbeat signals to each software process of the host and backup systems, and can analyze the response information in detail. By establishing a fault symptom database and using preset rules, the framework improves the fault positioning accuracy from the node level to the process level, can accurately detect internal faults such as software process freezing and resource leakage that are difficult to identify by traditional systems, effectively eliminates the fault detection blind area, and improves the response speed of the system to software faults.

[0027] The dual-redundancy physical layer heartbeat wire architecture designed in the application avoids the single point failure risk of the traditional single heartbeat wire architecture from the physical layer. When one of the links fails, the system can seamlessly switch to the other link to continue transmitting heartbeat signals, ensures that the host and the backup can accurately obtain the state information of the other party, and completely solves the problem of state misjudgment of the host and the backup caused by single link failure.

[0028] The application assigns a reliability weight to each single computer, the weight is dynamically adjusted according to the real-time running state of the processor, and reflects the health degree of the equipment. When the host and the backup perform data synchronization, they will share the reliability weight information with each other, and judge the output authority according to the weight. When the data of the two computers are consistent, the weight is equal, the host is defaulted to output, and when the weight is not equal, the equipment with a higher weight is selected to output. This mechanism effectively avoids the occurrence of the "split brain" problem from the logical level, and improves the service continuity of the system. Specific embodiment two: The difference between the embodiment two and the embodiment one of the application is only that: The application provides a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy, which is based on a high-reliability embedded processor redundancy architecture based on dynamic dual-mode redundancy, and comprises the following steps: Step 1: The host and the backup machine execute the industrial control algorithm in real time, and data synchronization is performed; Step 2: State detection, the dual-redundancy heartbeat link alternately sends heartbeat signals according to the set heartbeat signal sending period; Step 3: Three-machine data synchronization, the redundancy system runs the timing shared data, the host and the hot backup machine need to send data to each other, the warm backup machine receives the data, and the running state of the other single machine is synchronized when it is woken up; Step 4: Fault data synchronization, when the host and the backup machine are switched to the host, a broadcast frame with a “main node switching” identifier is immediately sent, the warm backup machine activates the synchronization mode after receiving it, and interacts with the new host; The host and the backup machine execute majority voting according to the three-machine data, and the voting result is synchronized to the three machines through a broadcast frame; Step 5: Dual-machine data inconsistency processing, the data of the host and the backup machine are synchronized and compared using step 3; Step 6: Host fault processing, the host triggers the hardware watchdog reset due to CPU core damage, and the hot machine determines that the host node is invalid after not receiving the effective heartbeat signal of the host for three consecutive heartbeat periods, and triggers the dynamic dual-mode redundancy single-machine node-level fault tolerance process; Step 7: Hot backup machine fault processing, the hot backup machine triggers the hardware watchdog reset due to CPU core damage, and the host determines that the hot backup machine node is invalid after not receiving the effective heartbeat signal of the hot backup machine for three consecutive heartbeat periods, and triggers the dynamic dual-mode redundancy single-machine node-level fault tolerance process; Step 8: Software process fault processing; Step 9: Redundancy system output control, the host and the hot backup machine in the dynamic dual-mode redundancy system simultaneously receive the data transmitted from the outside of the system, process the data, and simultaneously send the data to the outside.

[0030] Compared with the prior art, the technical effects and advantages of the application are as follows: 1. The dynamic dual-mode redundancy architecture proposed by the application breaks the limitation that the backup mode in the traditional dual-machine hot backup architecture is fixed, and a flexible redundancy system is constructed by introducing a warm backup processor unit. The architecture can automatically identify and replace the fault node during system operation, greatly improving the fault tolerance capability and reconstruction flexibility of the system in the multi-node fault scenario. At the same time, compared with the three-mode redundancy and its improved scheme, the architecture does not need to maintain the continuous parallel operation of the three nodes, and is more suitable for application scenarios sensitive to cost and resources.

[0031] 2. The daemon process designed in this invention, independent of the primary and backup systems, constructs a fine-grained fault monitoring system. This process runs in an independent, secure execution environment, unaffected by software failures in the primary and backup systems. It periodically sends heartbeat signals to various software processes in both systems and performs detailed analysis of the response information. By establishing a fault symptom database and applying preset rules, this framework improves fault location accuracy from the traditional node level to the process level. It can accurately detect internal faults that are difficult to identify in traditional systems, such as software process freezes and resource leaks, effectively eliminating fault detection blind spots and improving the system's response speed to software faults.

[0032] 3. The dual-redundant physical layer heartbeat line architecture designed in this invention avoids the single-point failure risk of traditional single-heartbeat line architectures at the physical level. When one link fails, the system can seamlessly switch to the other link to continue transmitting heartbeat signals, ensuring that the primary and backup machines can accurately obtain the other's status information, and completely solving the problem of misjudgment of the primary and backup machine status due to single link failure.

[0033] 4. This invention assigns a reliability weight to each individual machine. This weight is dynamically adjusted based on the processor's real-time operating status, reflecting the health of the device. During data synchronization, the primary and backup machines share reliability weight information and determine output permissions based on the weights. When the data from both machines is consistent, if the weights are equal, the primary machine outputs by default; otherwise, the machine with the higher weight outputs. This mechanism effectively avoids the "split-brain" problem at the logical level, improving the system's service continuity. Specific Implementation Example 3: The only difference between Embodiment 3 and Embodiment 2 of this application is that: Step 1 specifically involves: Data synchronization is performed every 10ms, including sensor-collected data, intermediate calculation results, and control commands. The daemon process periodically sends heartbeat signals to the software processes in the host and standby machines, collects indicators such as process response time and memory usage, and updates the fault symptom database. Specific Implementation Example 4: The only difference between Embodiment 4 and Embodiment 3 of this application is that: Step 2 specifically involves: The dual-redundant heartbeat link alternately sends heartbeat signals according to the set heartbeat signal transmission cycle. The interval between the two heartbeat signals is 10ms. The heartbeat signal content includes the local running status code, reliability weight value and check code. The receiving end sets the heartbeat signal timeout time to three heartbeat cycles. If the receiving end does not receive the other party's heartbeat signal after the timeout time, the dynamic dual-mode redundant single-machine node-level fault tolerance process is triggered, the warm standby machine is woken up, and the dual-machine hot standby redundancy system is reconstructed with the surviving single machine. When a heartbeat signal is received within 60 ms, it indicates that the heartbeat signal communication link between the two machines is not damaged by external interference and the opposite single machine node is alive. The receiving end decodes and checks the heartbeat signal and updates the opposite state table. Embodiment five: The difference between embodiment five and embodiment four is only that: The step 3 is specifically: The redundant system shares data at a running timing, the master and the hot standby machine send data to each other, the warm standby machine receives data so as to quickly synchronize with the running state of other single machines when woken up; the master sends a control instruction frame and a sensor data frame every 10 ms, the frame ID contains the master identification, the hot standby machine and the warm standby machine listen and analyze in real time; After receiving, the hot standby machine compares the local operation result with the synchronization data, if consistent, sends a confirmation frame containing the state weight of itself every 20 ms; if inconsistent, immediately sends a difference frame with a priority identification, and marks an inconsistent field; The warm standby machine is in a low-power consumption listening mode, only receives the state frame of the master and the standby machine, updates the local backup data every 100 ms, and does not actively send data. Embodiment six: The difference between embodiment six and embodiment five is only that: The step 6 is specifically: The warm standby machine is automatically activated, completes system image loading and data synchronization within 50 ms, and forms a new dual-machine hot standby system with the standby machine, the hot standby machine is switched to the master, and the warm standby machine is used as the hot standby machine; the new master sends a fault switching message to the control bus, records the fault time and the last running parameter of the old master, and the daemon process marks the fault type of the old master as "permanent hardware failure" and writes it into a log. Embodiment seven: The difference between embodiment seven and embodiment six is only that: The step 7 is specifically: The warm standby machine is automatically activated, completes system image loading and data synchronization within 50 ms, and forms a new dual-machine hot standby system with the master, and the warm standby machine is used as the hot standby machine; the daemon process marks the fault type of the hot standby machine as "permanent hardware failure" and writes it into a log. Embodiment eight: The difference between embodiment eight and embodiment seven is only that: The step 8 is specifically: The system is running a certain process of a single machine, which is deadlocked and cannot trigger a node-level detection alarm mechanism, and the daemon process does not receive the heartbeat response of the process for two consecutive times, calls a fault analysis module, and determines that it is a "process-level permanent fault" in combination with historical data; a process restart mechanism is triggered, the reliability of the single machine with the failed process is reduced by 0.5, and the reset and initialization of the process are completed within 100ms; if the process resumes normal operation after restart, the reliability of the single machine is restored. Specific embodiment nine: The difference between the embodiment nine and the embodiment eight is only that: The application provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy.

[0041] The method comprises the following steps: Step 1: The host and the backup machine execute an industrial control algorithm in real time and perform data synchronization; Step 2: State detection, the dual-redundancy heartbeat link alternately sends heartbeat signals according to a set heartbeat signal sending period; Step 3: Three-machine data synchronization, the redundant system shares data at a fixed time, the host and the hot backup machine need to send data to each other, the warm backup machine receives data and synchronizes the running state with other single machines when it is woken up; Step 4: Data synchronization under fault, after the host and the backup machine are switched to the host, a broadcast frame with a "host node switching" identifier is immediately sent, the warm backup machine activates the synchronization mode after receiving the broadcast frame and interacts with the new host to exchange data; The host and the backup machine perform majority voting according to three-machine data, and the voting result is synchronized to the three machines through a broadcast frame; Step 5: Dual-machine data inconsistency processing, the data of the host and the backup machine are synchronized and compared using step 3; Step 6: Host fault processing, the host triggers a hardware watchdog reset due to CPU core damage, and the hot machine determines that the host node is invalid after not receiving the effective heartbeat signal of the host for three consecutive heartbeat periods, and triggers a dynamic dual-mode redundancy single-machine node-level fault tolerance process; Step 7: Hot backup machine fault processing, the hot backup machine triggers a hardware watchdog reset due to CPU core damage, and the host determines that the hot backup machine node is invalid after not receiving the effective heartbeat signal of the hot backup machine for three consecutive heartbeat periods, and triggers a dynamic dual-mode redundancy single-machine node-level fault tolerance process; Step 8: Software process fault processing; Step 9: Redundant system output control, the host and the hot backup machine in the dynamic dual-mode redundancy system simultaneously receive data transmitted from the outside of the system, process the data, and simultaneously send the data to the outside. Specific embodiment ten: Embodiment ten of the present application differs from embodiment nine only in that: The present application provides a kind of computer equipment, including memory and processor, the memory is stored with computer program, the processor executes the computer program when realizing a kind of high reliability embedded processor redundancy method based on dynamic dual-mode redundancy.

[0043] The method comprises the following steps: Step 1: the host and the backup machine execute industrial control algorithm in real time, and carry out data synchronization; Step 2: state detection, dual-redundancy heartbeat link alternately sends heartbeat signal according to the set heartbeat signal sending period; Step 3: three-machine data synchronization, redundant system runs timing shared data, the host and hot backup machine need to send data to each other, warm backup machine receives data, and synchronizes with the running state of other single machine when waking up; Step 4: data synchronization under fault, when the host, backup machine switches to host, immediately sends broadcast frame with "master node switching" mark, and warm backup machine activates synchronization mode after receiving, and interacts with new host data; The host and backup machine execute majority voting according to three-machine data, and the voting result is synchronized to three machines through broadcast frame; Step 5: dual-machine data inconsistency processing, the data of host and backup machine are synchronized and compared using step 3; Step 6: host fault processing, the host triggers hardware watchdog reset due to CPU core damage, and the hot machine determines that the host node fails after not receiving the effective heartbeat signal of the host for three consecutive heartbeat periods, and triggers dynamic dual-mode redundancy single node level fault tolerance process; Step 7: hot backup machine fault processing, hot backup machine triggers hardware watchdog reset due to CPU core damage, and the host determines that the hot backup machine node fails after not receiving the effective heartbeat signal of the hot backup machine for three consecutive heartbeat periods, and triggers dynamic dual-mode redundancy single node level fault tolerance process; Step 8: software process fault processing; Step 9: redundancy system output control, the host and hot backup machine in dynamic dual-mode redundancy system receive data transmitted from outside system simultaneously, and send data to outside after data processing. Specific embodiment eleven: Embodiment eleven of the present application differs from embodiment ten only in that: In view of the above defects or improvement needs of the prior art, the present application provides a dynamic dual-mode redundancy method, which combines daemon process to collect processor running state and dual-heartbeat chain redundancy technology, and aims to improve the reliability and stability of long-time uninterrupted operation of dual-machine hot standby system.

[0045] To achieve the above object, the present application provides the following technical scheme: The method comprises the following steps: Step 1: The host and the backup machine execute the industrial control algorithm in real time, and data synchronization is performed; Step 2: State detection, the dual-redundancy heartbeat link alternately sends heartbeat signals according to the set heartbeat signal sending period; Step 3: Three-machine data synchronization, the redundant system shares data at a fixed time, the host and the hot backup machine need to send data to each other, the warm backup machine receives data, and when it is woken up, it synchronizes with the running state of the other single machine; Step 4: Fault data synchronization, when the host and the backup machine switch to the host, a broadcast frame with a “main node switching” identifier is immediately sent, the warm backup machine activates the synchronization mode after receiving it, and interacts with the new host to exchange data; The host and the backup machine execute majority voting according to the three-machine data, and the voting result is synchronized to the three machines through a broadcast frame; Step 5: Dual-machine data inconsistency processing, the data of the host and the backup machine are synchronized and compared using step 3; Step 6: Host fault processing, the host triggers a hardware watchdog reset due to CPU core damage, and the hot machine determines that the host node is invalid after not receiving the valid heartbeat signal of the host for three consecutive heartbeat periods, triggering the dynamic dual-redundancy single-machine node-level fault tolerance process; Step 7: Hot backup machine fault processing, the hot backup machine triggers a hardware watchdog reset due to CPU core damage, and the host determines that the hot backup machine node is invalid after not receiving the valid heartbeat signal of the hot backup machine for three consecutive heartbeat periods, triggering the dynamic dual-redundancy single-machine node-level fault tolerance process; Step 8: Software process fault processing; Step 9: Redundant system output control, the host and the hot backup machine in the dynamic dual-redundancy system simultaneously receive data transmitted from the outside of the system, process the data, and simultaneously send data to the outside.

[0046] In the first aspect, on the basis of the traditional dual-machine hot backup architecture, a cold backup processor unit is innovatively introduced to build a flexible redundant architecture of “two main hot backups + one warm redundancy”. In this architecture, the two hosts maintain a hot backup running state, and real-time data synchronization and state interaction are performed, while the warm backup processor is in a low-power standby mode, only maintaining basic state monitoring and host running data backup functions. When the dual-machine data processing or instruction output process is inconsistent, the warm backup node will access the system and call a preset consistency checking algorithm to cross-compare the data of the three parties, eliminate data discrepancies through a majority voting mechanism, and ensure the accuracy of the output result; when any of the host / backup machines experiences an unrecoverable hardware failure or core software crash, the warm backup node will automatically activate, quickly load critical data, and reconstitute a dual-machine hot backup system with the surviving host, with the entire switching process completed in milliseconds, effectively shortening the system recovery time.

[0047] In a second aspect, a daemon process independent of the master and standby system is designed. The daemon process periodically sends a heartbeat signal to each software process of the master system, collects response information and establishes a fault symptom database, and analyzes the fault type and severity through preset rules. When detecting a software fault that cannot be identified by node-level detection such as process hang or resource leakage, the master and standby switching or process restart is actively triggered, realizing multi-level fault diagnosis from node level to process level.

[0048] In a third aspect, a dual-redundant physical layer heartbeat line architecture is designed to address the single point failure problem of the traditional single heartbeat line architecture. The architecture uses two independent physical communication links, and the heartbeat signal is transmitted alternately on the two links. The receiving end performs time stamp comparison and data integrity check on the two signals, and ensures the accuracy of the state information through cross verification mechanism. When one of the links fails, the system can still use the other link to maintain communication, effectively avoiding the state misjudgment of the master and standby machines due to the failure of a single link, and eliminating the triggering conditions of the "split brain" problem from the physical layer.

[0049] In a fourth aspect, the daemon process monitoring results are added as local reliability weights in the synchronization data of both parties. The weight of the device with high processor running state health is high. The two machines share data and compare each other. When the data of the two machines are consistent and the weights of the master and standby machines are equal, the master machine outputs by default, and the standby machine does not output. When the weights are not equal, the processor unit with high weight is selected to output. The "split brain" problem is effectively solved and the master and standby switching time is reduced.

[0050] The application provides a high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy, which comprises the following steps: Step one, system initialization, deploy "double master hot standby + one warm redundancy" architecture in industrial automation control scene, including master A, hot standby B and warm standby C, and allocate priority to each single machine, the priority from high to low is master A, hot standby B and warm standby C. After the system is powered on, master A and standby B enter hot standby running state, and warm standby C enters low-power standby mode, only starting basic state monitoring module and data receiving module.

[0051] The daemon process is independently started in master A and standby B, initializes the fault symptom database, and sets the heartbeat signal sending period to 50ms. The dual-redundant heartbeat link completes self-checking and establishes connection, and the master and standby machines synchronize the initial system configuration parameters and the reliability weight initial value (both set to 0.5).

[0052] Step two, normal operation, host A and standby B real-time industrial control algorithm, every 10 ms data synchronization, synchronization content includes sensor data, intermediate results and control instructions. Daemon process according to the cycle to host A, B in the software process to send heartbeat signal, collect process response time, memory usage, etc. Update fault symptom database.

[0053] Step three, state detection, dual redundant heartbeat link according to the set heartbeat signal transmission cycle alternately send heartbeat signal, two heartbeat signal interval time is 10 ms, heartbeat signal content contains the local running state code, reliability weight value and check code, the receiving end of the heartbeat signal timeout time is three heartbeat cycle, more than the timeout time without receiving the other side of the heartbeat signal, then trigger dynamic dual mode redundant single node fault tolerance process, wake up the standby machine, and the surviving single machine to rebuild dual hot standby redundancy system.

[0054] If in 60 ms received a heartbeat signal, it shows that the communication link between the two machines heartbeat signal is not damaged by external interference and the other single node survival, the receiving end of the heartbeat signal decoding and updating the other state table.

[0055] Step four, three machine data synchronization, redundancy system in operation need to share data regularly, host A and hot standby B need to send data to each other, the standby machine receives data, so as to quickly synchronize with other single machine running state when wake up. Host A sends control instruction frame and sensor data frame every 10 ms, frame ID contains host identification (0x01), hot standby B, standby C real-time monitoring and analysis.

[0056] Hot standby B receives, compares the local operation result with the synchronization data, if consistent, sends confirmation frame (contains its own state weight) every 20 ms; if not, immediately sends difference frame with priority identification (mark inconsistent field).

[0057] Standby C is in low power consumption listening mode, only receives host A and standby B state frame (every 100 ms), updates local backup data, does not send data actively.

[0058] Step five, fault data synchronization, when host A, standby B switch to host, immediately send broadcast frame with "master node switching" identification (ID=0x02, highest priority), standby C receives and activates synchronization mode, every 10 ms with the new host B to interact data.

[0059] When the two machine data inconsistency triggers the standby C to participate in arbitration, the standby C sends independent operation result frame (ID=0x03), the host and standby machine according to the three machine data to execute majority decision, the decision result is synchronized to the three machines through broadcast frame.

[0060] Step Six: Handling Data Inconsistency Between Two Machines. Using the process described in Step Four, the data from the primary and backup machines are synchronized and compared. When the output of primary machine A is inconsistent with the output of hot standby machine B, it indicates that one of the machines has failed, but the exact location of the fault cannot be determined. At this point, the system triggers a data consistency verification mechanism: the hot standby machine is woken up, loads the same external input data, and performs calculations. The output result is compared with the results of primary machine A and hot standby machine B in a three-way vote (2:1). If the data from machine A is deemed valid, then machine A outputs its data. Simultaneously, the daemon process records the calculation deviation of standby machine B and lowers its reliability weight from 0.5 to 0.45.

[0061] Step 7: Host Failure Handling. Host A's CPU core failure triggers a hardware watchdog reset. After failing to receive a valid heartbeat signal from Host A for three consecutive heartbeat cycles, Hot Machine B determines that the host node has failed and triggers the following... Figure 3 The dynamic dual-mode redundancy single-machine node-level fault tolerance process is shown. Warm standby machine C automatically activates, completing system image loading and data synchronization within 50ms, forming a new dual-machine hot standby system with standby machine B (hot standby machine B switches to master, and warm standby machine C acts as hot standby). The new master machine B sends a fault switching message to the control bus, records the fault time and the last operating parameters of master machine A, and the daemon process marks the fault type of master machine A as "permanent hardware failure" and writes it to the log.

[0062] Step 8: Hot Standby Machine Failure Handling. Hot standby machine B experiences a CPU core failure, triggering a hardware watchdog reset. After failing to receive a valid heartbeat signal from hot standby machine B for three consecutive heartbeat cycles, host A determines the hot standby node has failed and triggers the following... Figure 3 The dynamic dual-mode redundancy single-machine node-level fault tolerance process is shown. The warm standby machine C is automatically activated, and the system image loading and data synchronization are completed within 50ms, forming a new dual-machine hot standby system with the host A (warm standby machine C acts as the hot standby machine); the daemon process marks the fault type of the hot standby machine B as "permanent hardware failure" and writes it to the log.

[0063] Step Nine: Software Process Failure Handling. If a process on a running single machine experiences a deadlock, preventing the triggering of the node-level detection and alarm mechanism, and the daemon process fails to receive a heartbeat response from the process twice consecutively, the fault analysis module is invoked. Based on historical data, the system is determined to have experienced a "process-level permanent failure." The process restart mechanism is triggered, reducing the single-machine reliability of the faulty process by 0.5. The process is reset and initialized within 100ms. If the process resumes normal operation after restarting, the single-machine reliability is restored.

[0064] Step ten: redundant system output control, the host A and the hot standby B in the dynamic dual-mode redundant system receive the data transmitted from the outside of the system at the same time, process the data and send the data to the outside at the same time. In order to prevent the data sent to the outside by the two processors from interfering with each other, the data sent to the outside by the host is outputted and the output of the non-host is shielded. The output shielding is realized by software shielding.

[0065] When the single machine runs to the output node, it is first determined whether there is a single machine with higher reliability than the single machine in normal operation. If there is, the output of the single machine is shielded. If not, it is determined whether there is a single machine with higher output priority than the single machine in normal operation. If there is, the output of the single machine is shielded. If not, the single machine obtains the output right. The redundant system output control flow is shown in Figure 4

[0066] The above is only a preferred embodiment of the high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy. The protection scope of the high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy is not limited to the above-mentioned embodiment. Any technical solution belonging to the idea falls within the protection scope of the present application. It should be noted that, for those skilled in the art, some improvements and changes without departing from the principles of the present application should also be considered as the protection scope of the present application.​

Claims

1. A high-reliability embedded processor redundancy architecture based on dynamic dual-mode redundancy, characterized by: The architecture comprises a host, a hot backup machine and a warm backup machine, and each single machine is assigned a priority, and the priorities from high to low are the host, the hot backup machine and the warm backup machine; After the system is powered on, the host and the backup machine enter a hot backup running state, and the warm backup machine enters a low-power standby mode, and only a basic state monitoring module and a data receiving module are started; A daemon process is independently started in the host and the backup machine, initializes a fault symptom database, and sets a heartbeat signal sending period to 50 ms; A double-redundancy heartbeat link completes self-checking and connection establishment, and the host and the backup machine synchronize initial system configuration parameters and initial values of reliability weights.

2. A high-reliability embedded processor redundancy method based on dynamic dual-mode redundancy, the method is run based on the architecture of claim 1, characterized in that: The method comprises the following steps: Step 1: The host and the backup machine execute an industrial control algorithm in real time, and perform data synchronization; Step 2: State detection, the double-redundancy heartbeat link alternately sends heartbeat signals according to the set heartbeat signal sending period; Step 3: Three-machine data synchronization, the redundant system shares data in operation, the host and the hot backup machine need to send data to each other, and the warm backup machine receives data and synchronizes with the operation states of other single machines when being woken up; Step 4: Fault data synchronization, when the host and the backup machine are switched to the host, a broadcast frame with a "host node switching" identifier is immediately sent, the warm backup machine is activated after receiving the broadcast frame, and interacts with the new host to exchange data; The host and the backup machine execute majority voting according to three-machine data, and the voting result is synchronized to the three machines through a broadcast frame; Step 5: Double-machine data inconsistency processing, the data of the host and the backup machine are synchronized and compared using step 3; Step 6: Host fault processing, the host triggers a hardware watchdog reset due to CPU core damage, the hot machine determines that the host node is invalid after not receiving an effective heartbeat signal of the host for three consecutive heartbeat periods, and triggers a dynamic dual-mode redundant single-machine node-level fault tolerance process; Step 7: Hot backup machine fault processing, the hot backup machine triggers a hardware watchdog reset due to CPU core damage, the host determines that the hot backup machine node is invalid after not receiving an effective heartbeat signal of the hot backup machine for three consecutive heartbeat periods, and triggers a dynamic dual-mode redundant single-machine node-level fault tolerance process; Step 8: Software process fault processing; Step 9: Redundant system output control, the host and the hot backup machine in the dynamic dual-mode redundant system simultaneously receive data transmitted from the outside, process the data, and simultaneously send the data to the outside.

3. The method of claim 2, wherein: The step 1 is specifically: Data synchronization is performed once every 10 ms, and the synchronization content includes sensor collected data, intermediate results of operation and control instructions; the daemon process sends heartbeat signals to software processes in the host and the backup machine according to a period, collects process response time, memory occupancy and other indicators, and updates the fault symptom database.

4. The method of claim 3, wherein: The step 2 is specifically: The double-redundancy heartbeat link alternately sends heartbeat signals according to the set heartbeat signal sending period, the interval time between the two heartbeat signals is 10 ms, the heartbeat signal content includes a local operation state code, a reliability weight value and a check code, the receiving end sets a heartbeat signal timeout time to three heartbeat periods, if the heartbeat signal of the other party is not received within the timeout time, a dynamic dual-mode redundant single-machine node-level fault tolerance process is triggered, the warm backup machine is woken up, and the surviving single machine is re-built to form a double-machine hot backup redundant system; When a heartbeat signal is received within 60 ms, it indicates that the heartbeat signal communication link between the two machines is not damaged by external interference and the opposite single machine node is alive. The receiving end decodes and checks the heartbeat signal and updates the opposite state table.

5. The method of claim 4, wherein: The step 3 is specifically: The redundant system shares data at a running timing. The master and the hot standby machine send data to each other, and the warm standby machine receives the data so as to quickly synchronize with the running state of other single machines when woken up. The master sends a control instruction frame and a sensor data frame every 10 ms. The frame ID contains the master identification. The hot standby machine and the warm standby machine listen and analyze in real time; After receiving, the hot standby machine compares the local operation result with the synchronization data. If they are consistent, the hot standby machine sends a confirmation frame containing the state weight of the hot standby machine every 20 ms. If they are inconsistent, the hot standby machine immediately sends a difference frame with a priority identifier to mark the inconsistent field. The warm standby machine is in a low-power listening mode and only receives the state frame of the master and the standby machine. The local backup data is updated every 100 ms, and no data is actively sent.

6. The method of claim 5, wherein: The step 6 is specifically: The warm standby machine is automatically activated, and the system image loading and data synchronization are completed within 50 ms. The warm standby machine and the standby machine form a new dual-machine hot standby system. The standby machine is switched to the master, and the warm standby machine is used as the hot standby machine. The new master sends a fault switching message to the control bus, records the fault time and the last running parameters of the old master, and the daemon process marks the fault type of the old master as "permanent hardware failure" and writes it into the log.

7. The method of claim 6, wherein: The step 7 is specifically: The warm standby machine is automatically activated, and the system image loading and data synchronization are completed within 50 ms. The warm standby machine and the master form a new dual-machine hot standby system, and the warm standby machine is used as the hot standby machine. The daemon process marks the fault type of the hot standby machine as "permanent hardware failure" and writes it into the log.

8. The method of claim 7, wherein: The step 8 is specifically: When a process of a single machine running in the system appears deadlock and cannot trigger a node-level detection alarm mechanism, the daemon process does not receive the heartbeat response of the process for two times in succession, calls a fault analysis module, and determines "process-level permanent failure" in combination with historical data. A process restart mechanism is triggered, the reliability of the single machine in which the process appears failure is reduced by 0.5, and the reset and initialization of the process are completed within 100 ms. If the process resumes normal operation after restart, the reliability of the single machine is restored.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by a processor to implement the method of claims 2-8.

10. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that: The processor implements the method of claims 2-8 when executing the computer program.

Images