Cooperative verification and reliable action method and system for soft error prevention of protection control equipment

Abstract

The invention discloses a cooperative verification and reliable action method and system for soft error prevention of protection control equipment. The system forms a multi-level verification and self-repairing mechanism through mutual cooperation of the three CPUs. Specifically, the system performs data self-checking through the starting CPU and the protection CPU respectively, and transmits a checking result to the co-processing CPU, and a co-checking module executes partition polling transmission and snapshot comparison of a program, so that real-time monitoring of a running state and program co-checking are realized. When the system is abnormal, an arbitration decision is made through the consistency judgment module and the arbitration module, if a soft error or data inconsistency occurs, the system automatically calls a backup program or data for recovery through the self-repairing module, and it is ensured that the system can be rapidly recovered to a normal state. According to the method, through multi-level data and program verification and in combination with an automatic self-repairing mechanism, the soft error resistance of the relay protection control device is remarkably improved, and high reliability and safety of the system are ensured.

Description

Technical Field

[0001] The present invention belongs to the field of power relay protection control and measurement control, and in particular to a method and system for coordinated verification and reliable action of soft error prevention of protection and control equipment. Background Art

[0002] As the complexity and importance of power system relay protection and control devices increase, the environment facing safe power system operation becomes increasingly demanding. Soft errors have become a significant threat to relay protection and control devices. Soft errors are transient faults caused by single-event events (SEUs) or multiple-bit upsets (MBUs), often occurring when high-energy particles impact memory or logic circuits. While these soft errors do not directly cause physical damage to hardware, they can profoundly impact the normal functioning of the device, potentially leading to data flips, calculation errors, program execution anomalies, and hidden device failures. These can cause erroneous outputs or even misoperation of the relay protection and control device, leading to overall system instability and a serious threat to power system safety.

[0003] In existing technologies, relay protection control devices typically employ a dual-CPU redundant architecture. Two independently operating CPUs output their own results to determine whether the system is in a normal state and jointly determine the protection action status. This dual-redundancy design can improve system reliability to a certain extent. However, with the frequent occurrence of soft errors caused by space particle radiation effects, it is difficult to effectively deal with complex soft error scenarios. Currently, the following main issues exist:

[0004] (1) Limited soft error protection capabilities

[0005] Dual-CPU redundant architectures primarily detect system failures by comparing the outputs of the two CPUs. However, this result comparison mechanism is only effective for catching hardware-level errors and cannot address more complex soft errors, such as those in memory buffers (MBUs). In the case of MBUs, multiple bits in the memory can flip simultaneously, potentially affecting the outputs of both CPUs, resulting in consistent but erroneous results and making this synchronization error undetectable. Because this architecture lacks coordinated verification at the data and program layers, its soft error protection capabilities are significantly insufficient in these complex scenarios.

[0006] (2) Lack of program verification mechanism

[0007] While existing dual-CPU architectures can monitor and compare final output results, they cannot monitor program execution in real time. During program execution, soft errors can affect the execution order or logic of instructions, leading to program execution errors. The dual-CPU architecture fails to detect these intermediate errors, making it difficult to detect errors that occur during program execution. In particular, when program execution errors coincide with data output results, these errors can be overlooked, leading to system malfunctions or incorrect processing.

[0008] (3) Imperfect self-repair mechanism

[0009] Existing dual-CPU architectures can detect faults in certain situations, but the system lacks effective self-repair capabilities. Once an error is detected, the system often requires external intervention or manual repair, which not only increases response time but can also cause the system to be unstable or shut down for extended periods. The lack of an automated self-repair mechanism prevents existing systems from recovering promptly after soft errors, compromising system stability and reliability.

[0010] Patent 202310912543.X describes a relay protection control method and system based on a multi-core processor chip. This system utilizes a multi-core processor solution, utilizing synchronization checks between the protection and startup cores to perform multiple data comparisons and verifications to ensure the reliability and safety of the relay protection control device. The specific implementation includes: 1. Using a dual-core architecture, including a startup CPU and a protection CPU, the two cores operate independently and mutually verify their output results; 2. Through redundant program and data backup, the system performs verification in the event of data errors or program anomalies to determine whether the system is in a healthy state.

[0011] Although this technology has shown certain advantages in resolving some hardware failures, it still has some limitations for complex soft errors (such as SEU and MBU). In particular, when soft errors occur in multiple storage units or logic units, it is difficult to accurately locate and correct the errors by relying solely on dual-core comparison. Summary of the Invention

[0012] The purpose of the present invention is to overcome the deficiencies of the existing dual-CPU redundant architecture of relay protection control devices in terms of soft error protection, program verification and self-repair capabilities, and to propose a three-core collaborative verification and action export execution method and system for soft error protection of relay protection control devices to improve the reliability and stability of the device system.

[0013] The technical solutions for achieving the objectives of the present invention are as follows: On the one hand, a coordinated verification and reliable action system for soft error prevention of protection and control equipment is provided. The system includes a startup CPU, a protection CPU, and a co-processing CPU built into the protection and control equipment. Through the mutual cooperation between the three, a multi-level verification and self-repair mechanism is formed to achieve soft error protection and action exit execution for the system;

[0014] The system performs multi-level verification through the startup CPU, protection CPU and co-processing CPU, including: performing data self-verification through the startup CPU and protection CPU respectively, and transmitting the verification results to the co-processing CPU; performing program co-verification through the co-processing CPU;

[0015] At the same time, the co-processing CPU makes arbitration decisions based on the verification results, and determines the system exit action or performs exception processing;

[0016] The self-repair mechanism specifically includes: triggering a self-repair instruction during the abnormal processing, and the system performs self-repair processing until it operates normally.

[0017] Furthermore, the startup CPU is responsible for system startup, data self-checking and relay protection control export startup control tasks, and has a built-in RAM ECC check module for real-time self-checking of the startup CPU's operating data;

[0018] The protection CPU is responsible for the core relay protection control logic calculation and has a built-in RAM ECC check module for real-time self-checking of the protection CPU's operating data;

[0019] The startup CPU and protection CPU are both equipped with a data backup module and a data self-repair module, which are used to back up and repair the operating data of the startup CPU / protection CPU respectively;

[0020] The startup CPU and the protection CPU back up the running data to the corresponding data backup modules respectively before performing data self-checking and transferring the program to the co-processing CPU.

[0021] Furthermore, the co-processing CPU includes a monitoring and inspection module and an arbitration module;

[0022] The monitoring and verification module is used to verify and monitor the data and programs that start the CPU and protect the CPU;

[0023] The arbitration module is used to determine the system exit action or perform exception processing according to the output of the monitoring and inspection module.

[0024] Furthermore, the monitoring and verification module includes a receiving module, a co-verification module, a self-repair module and a monitoring module;

[0025] The receiving module is used to receive the self-check results of the startup CPU and the protection CPU, and transmit them to the arbitration module and the monitoring module at the same time;

[0026] The co-verification module is used to verify the programs for starting the CPU and protecting the CPU transmission respectively, and transmit the verification results to the arbitration module and the monitoring module at the same time;

[0027] The self-repair module is used to receive self-repair instructions, perform self-repair on the program, and send the self-repair instructions to the startup CPU and the protection CPU to trigger their respective self-repair functions;

[0028] The monitoring module is used to receive and store feedback information from the receiving module, the co-verification module, and the self-repair module in real time to update the system status in real time; if it is monitored that the self-repair status of each module is successful, a recovery instruction is sent to the arbitration module, and the arbitration module controls the system status to return to normal; otherwise, an abnormal instruction is sent to the arbitration module, and the arbitration module generates a locking signal to control the system to enter a locking state, and an alarm signal is issued through the monitoring system.

[0029] Furthermore, the startup CPU and the protection CPU transfer the program to the co-verification module in a partition patrol manner, and transfer the program of one partition in turn in each interrupt control cycle, and ensure that all program partitions are fully transmitted within the specified time.

[0030] Furthermore, after receiving the program transmitted by the partition patrol, the co-verification module generates a unique identifier for each partition as a snapshot, and compares it with the previous snapshot of each partition in a one-to-one correspondence, and outputs the verification result; at the same time, the co-verification module will update the snapshot of the current partition;

[0031] The verification result includes pass or fail. If the comparison is consistent, the verification result is pass, otherwise the verification result is fail;

[0032] At the same time, after the co-verification module receives the program transmitted by the partition patrol, it also stores and backs up the program in a partition manner for the self-repair module to call; after the self-repair module receives the self-repair instruction, it performs self-repair by calling the backed-up program in the co-verification module.

[0033] Furthermore, the monitoring module is also used to identify hidden system faults and issue an alarm while ensuring that the system status is updated in real time.

[0034] Furthermore, the arbitration module includes a consistency judgment module, a decision module and an exception handling module;

[0035] The consistency judgment module is used to receive the signal data output by the receiving module and the co-verification module, and respectively judge whether the self-verification result of the startup CPU is consistent with the verification result of the co-verification module on the startup CPU program, and whether the self-verification result of the protection CPU is consistent with the verification result of the co-verification module on the protection CPU program; if the verification results are all consistent, a consistency signal is output to the decision module, otherwise an abnormal state signal is generated to the decision module;

[0036] The decision module arbitrates based on the principle of taking more than more, specifically: if the start relay and action relay corresponding to the start CPU and the protection CPU are both in the "output allowed" state, and the consistency judgment module outputs a consistency signal and generates an "export action allowed" instruction, each relay is controlled to continue normal operation; otherwise, an activation instruction is sent to the exception handling module;

[0037] The exception handling module is used to generate a self-repair instruction after receiving the activation instruction, and transmit the self-repair instruction to the self-repair module.

[0038] Furthermore, in the new interrupt control cycle, the consistency determination module obtains the repaired / updated system status from the monitoring module and continues to perform normal self-checking and arbitration operations to ensure continuous and stable operation of the system.

[0039] On the other hand, based on the system, a method for coordinated verification and reliable action of soft error prevention of protection control equipment is provided, the method comprising the following steps:

[0040] Step 1: The startup CPU and the protection CPU respectively perform real-time data self-checking and send the check results to the co-processing CPU. At the same time, the startup CPU and the protection CPU send their respective programs to the co-processing CPU.

[0041] Step 2: The co-processing CPU processes the received program, generates a corresponding snapshot, and compares the snapshot with the previous snapshot to generate a program verification result;

[0042] Step 3, the co-processing CPU determines whether the self-check result of the startup CPU in step 1 is consistent with the check result of the startup CPU program by the co-processing CPU in step 2, and whether the self-check result of the protection CPU in step 1 is consistent with the check result of the protection CPU program by the co-processing CPU in step 2. If all are consistent, a consistency signal is generated; otherwise, an abnormal state signal is generated.

[0043] Step 4: The co-processing CPU makes a blanking decision based on the signal generated in step 3: If step 3 outputs a consistency signal, and the start relay and action relay corresponding to the start CPU and protection CPU are both in the "output allowed" state, the co-processing CPU generates an "output action allowed" instruction to control each relay to continue normal operation, including driving the output relay to perform an action; otherwise, the co-processing CPU generates an abnormal processing signal and goes to step 5;

[0044] Step 5: Generate a self-repair instruction to trigger the self-repair function of the boot CPU, protection CPU, and co-processing CPU; at the same time, monitor the self-repair result in real time. If the self-repair result is successful, update the snapshot data and feedback to step 1 to continue execution; otherwise, go to step 6;

[0045] Step 6: Enter the locked state, issue an alarm signal, and end the process.

[0046] Compared with the prior art, the present invention has the following significant advantages:

[0047] (1) Improved soft error protection capabilities

[0048] This invention utilizes a multi-core collaborative architecture and ECC checking to effectively detect and repair single-bit flip errors, as well as multi-bit flip errors. For multi-bit flips, the system triggers a self-repair mechanism through the exception handling module, restoring the damaged program or data using backup data. This overcomes the difficulty of repairing multi-bit flips and ensures system stability and reliability under complex soft error conditions.

[0049] (2) Real-time verification of program running status

[0050] This invention utilizes a partition patrol mechanism to perform real-time verification of programs that start and protect the CPU. Verification of all program partitions can be completed within a short period of time during each interrupt control cycle, effectively improving the efficiency and accuracy of error detection during program execution while reducing CPU load. When a program error is detected, the coprocessing CPU uses a self-repair module to quickly recover the damaged program code, ensuring continued stable system operation.

[0051] (3) Multi-level arbitration and self-repair mechanism

[0052] Through an arbitration mechanism based on the 2-out-of-2 principle for consistency judgment, the present invention can more accurately determine the system status at the relay output, preventing malfunctions caused by erroneous signals. When an anomaly is detected, the system uses a self-repair module to call backup data to repair damaged programs and data, thereby enhancing the system's resilience to soft errors and automatic recovery capabilities.

[0053] The present invention is further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 Schematic diagram of the structure of a three-core collaborative verification system for soft errors of a relay protection control device in one embodiment.

[0055] Figure 2 FIG. 1 is a multi-level check logic flow chart of soft error protection in one embodiment.

[0056] Figure 3 1 is a flowchart of system arbitration and self-repair under a three-core collaborative verification architecture in one embodiment.

[0057] Figure 4 Schematic diagram of a relay drive and execution circuit in one embodiment.

[0058] Figure numerals: 1—starting CPU, 2—protecting CPU, 3—co-processing CPU, 4—monitoring and verification module, 5—arbitration module, 6—receiving module, 7—co-verification module, 8—self-repair module, 9—monitoring module, 10—consistency judgment module, 11—decision module, 12—abnormal handling module, 13—CPU system, 14—relay driving module, 15—actuator, 16—action relay, 17—starting relay, 18—operation box. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0060] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), such directional indications are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0061] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features specified as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but this must be based on the fact that ordinary technicians in this field can implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0062] The present invention provides a method and system for coordinated verification and reliable operation of soft errors in protection and control equipment, which will be described in detail below with respect to a relay protection and control device.

[0063] In one embodiment, a coordinated verification and reliable action system for soft error prevention in relay protection and control devices is provided. The system includes a startup CPU, a protection CPU, and a co-processing CPU built into the protection and control device. Through the mutual cooperation between the three, a multi-level verification and self-repair mechanism is formed to achieve soft error protection and action exit execution for the system.

[0064] The system performs multi-level verification on the startup CPU, protection CPU, and co-processing CPU, including:

[0065] First-level data verification: The startup CPU and the protection CPU respectively perform data self-verification, and transmit the verification results to the co-processing CPU;

[0066] Second-level program co-verification: program co-verification is performed through the co-processing CPU;

[0067] At the same time, the co-processing CPU makes arbitration decisions based on the verification results, and determines the system exit action or performs exception processing;

[0068] The self-repair mechanism specifically includes: triggering a self-repair instruction during the abnormal processing, and the system performs self-repair processing until it operates normally.

[0069] Here, the multi-level verification mechanism is designed to ensure the integrity and reliability of data and programs of the relay protection control device during operation, especially to provide higher protection capabilities when dealing with soft errors.

[0070] Furthermore, in one embodiment, the startup CPU is responsible for system startup, data self-checking, and relay protection control output startup control tasks, and has a built-in RAM ECC check module for real-time self-checking of the startup CPU's operating data;

[0071] The protection CPU is responsible for the core relay protection control logic calculation and has a built-in RAM ECC check module for real-time self-checking of the protection CPU's operating data;

[0072] The startup CPU and protection CPU are both equipped with a data backup module and a data self-repair module, which are used to back up and repair the operating data of the startup CPU / protection CPU respectively;

[0073] The startup CPU and the protection CPU back up the running data to the corresponding data backup modules respectively before performing data self-checking and transferring the program to the co-processing CPU.

[0074] Here, preferably, the startup CPU and the protection CPU are transmitted to the co-processing CPU via an internal bus or a high-speed transmission channel.

[0075] Here, the data processed by the startup CPU includes but is not limited to initialization parameters, system status data, user configuration data and log data, etc.; the data processed by the protection CPU includes but is not limited to measurement data, protection setting parameters, historical fault records, etc.

[0076] Here, the ECC checking principle is: for single-bit upset, ECC self-checking can detect and repair single-bit errors; for multi-bit upset (MBU), ECC self-checking can detect multi-bit errors. Although it cannot be automatically repaired, it will generate an ECC self-repair exception signal, which will eventually be passed to the exception handling module of the co-processing CPU for subsequent repair.

[0077] Furthermore, in one of the embodiments, the co-processing CPU includes a monitoring and checking module and an arbitration module;

[0078] The monitoring and verification module is used to verify and monitor the data and programs that start the CPU and protect the CPU;

[0079] The arbitration module is used to determine the system exit action or perform exception processing according to the output of the monitoring and inspection module.

[0080] Here, the monitoring and verification module includes a receiving module, a co-verification module, a self-repair module and a monitoring module;

[0081] The receiving module is used to receive the self-check results of the startup CPU and the protection CPU, and transmit them to the arbitration module and the monitoring module at the same time;

[0082] The co-verification module is used to verify the programs for starting the CPU and protecting the CPU transmission respectively, and transmit the verification results to the arbitration module and the monitoring module at the same time;

[0083] The self-repair module is used to receive self-repair instructions and send them to the startup CPU and the protection CPU to trigger their respective self-repair functions; here, self-repair includes program repair, data repair and system status recovery;

[0084] The monitoring module is used to receive and store feedback information from the receiving module, the co-verification module, and the self-repair module in real time to update the system status in real time; if the self-repair status is monitored to be successful, a recovery instruction is sent to the arbitration module, and the arbitration module controls the system status to return to normal; otherwise, an abnormal instruction is sent to the arbitration module, and the arbitration module generates a locking signal to control the system to enter a locking state, close the relay action output, avoid system malfunction, and send an alarm signal through the monitoring system.

[0085] Here, through the monitoring module, during the next round of self-test, the arbitration module can obtain the repaired self-test status from the monitoring module to ensure the normal operation of subsequent processes of the system and the reliability of the relay protection control device.

[0086] Here preferably, in some embodiments, the startup CPU and the protection CPU transfer the program to the co-verification module in a partition patrol manner, and in each interrupt control cycle, transfer the program of one partition in turn, and ensure that all program partitions are fully transmitted within the specified time.

[0087] Here, the program delivery and patrol methods are divided into multiple functional areas, each of which can be configured with different numbers based on the actual application scenario. During system verification, a hash value or checksum is generated, or other verification methods are used for comparison to ensure the integrity of the program and data. The verification methods are not limited to hash values ​​or checksums.

[0088] Here, the CPU program is preferably started to patrol four partitions: initialization code area, interrupt processing code area, system management code area, and data monitoring code area;

[0089] The five patrol partitions of the CPU program are: protection logic code area, real-time data processing area, fixed value parameter management area, interrupt task processing code area, and hidden fault monitoring area.

[0090] Here, preferably, in some embodiments, after receiving the program delivered by the partition patrol, the co-verification module generates a unique identifier for each partition as a snapshot, and compares it with the previous snapshot of each partition in a one-to-one correspondence, and outputs a verification result; at the same time, the co-verification module updates the snapshot of the current partition;

[0091] The verification result includes pass or fail. If the comparison is consistent, the verification result is pass, otherwise the verification result is fail.

[0092] Here, the snapshot data can be generated in various forms, including but not limited to hash values, checksums, encrypted signatures, or other data consistency verification methods.

[0093] Here preferably, in some embodiments, after the co-verification module receives the program transmitted by the partition patrol, it also stores and backs up the program in a partition manner for the self-repair module to call; after the self-repair module receives the self-repair instruction, it performs self-repair by calling the backed-up program in the co-verification module.

[0094] Here, since the program is stored in the co-verification module 7 in a partitioned manner, it is ensured that the partition-level program can be quickly restored by relying on the self-repair module 8 when an exception occurs, thereby avoiding large-scale program damage.

[0095] Here, the self-repair process can handle multiple error types, including but not limited to single-bit errors, multi-bit errors, and other forms of soft errors.

[0096] Here preferably, in some embodiments, the monitoring module is further used to identify hidden system faults and issue an alarm while ensuring that the system status is updated in real time.

[0097] Furthermore, in one embodiment, the arbitration module includes a consistency determination module, a decision module and an exception handling module;

[0098] The consistency judgment module is used to receive the signal data output by the receiving module and the co-verification module, and respectively judge whether the self-verification result of the startup CPU is consistent with the verification result of the co-verification module on the startup CPU program, and whether the self-verification result of the protection CPU is consistent with the verification result of the co-verification module on the protection CPU program; if the verification results are all consistent, a consistency signal is output to the decision module, otherwise an abnormal state signal is generated to the decision module;

[0099] The decision module performs arbitration based on the 2-out-of-2 principle based on consistency judgment, specifically: if the start relay and action relay corresponding to the start CPU and the protection CPU are both in the "output allowed" state, and the consistency judgment module outputs a consistency signal and generates an "export action allowed" instruction to control each relay to continue normal operation; otherwise, an activation instruction is sent to the exception handling module;

[0100] The exception handling module is used to generate a self-repair instruction after receiving the activation instruction, and transmit the self-repair instruction to the self-repair module.

[0101] Here preferably, in some embodiments, within a new interrupt control cycle, the consistency judgment module obtains the repaired / updated system status from the monitoring module 9 and continues to perform normal self-checking and arbitration operations to ensure continuous and stable operation of the system.

[0102] In one embodiment, a method for coordinated verification and reliable operation of soft errors in a relay protection control device is provided, the method comprising the following steps:

[0103] Step 1: The startup CPU 1 and the protection CPU 2 respectively perform real-time data self-checking and send the check results (including error detection flag, error type and repair status) to the co-processing CPU 3. At the same time, the startup CPU 1 and the protection CPU 2 send their respective programs to the co-processing CPU 3.

[0104] Step 2: The co-processor CPU 3 processes the received program, generates a corresponding snapshot, and compares the snapshot with the previous snapshot to generate a program verification result;

[0105] Step 3: The co-processor CPU 3 determines whether the self-check result of the startup CPU 1 is consistent with the check result of the co-processor CPU 3 on the startup CPU 1 program, and whether the self-check result of the protection CPU 2 is consistent with the check result of the co-processor CPU 3 on the protection CPU 2 program. If they are consistent, a consistency signal is generated; otherwise, an abnormal status signal is generated.

[0106] Step 4: The co-processing CPU 3 makes a blanking decision based on the signal generated in step 3: If step 3 outputs a consistency signal, and the start relay and action relay corresponding to the start CPU 1 and the protection CPU 2 are both in the "output allowed" state, the co-processing CPU 3 generates an "export action allowed" instruction to control each relay to continue normal operation, including driving the output relay to perform an action; otherwise, the co-processing CPU 3 generates an abnormal processing signal and goes to step 5;

[0107] Step 5: Generate a self-repair instruction to trigger the self-repair function of the startup CPU 1, protection CPU 2, and co-processing CPU 3; at the same time, monitor the self-repair result in real time. If the self-repair result is successful, update the snapshot data and feedback to step 1 to continue execution; otherwise, go to step 6;

[0108] Step 6: Enter the locked state, issue an alarm signal, and end the process.

[0109] Furthermore, in one embodiment, the method further comprises:

[0110] Execute before step 1: the startup CPU and the protection CPU back up the running data.

[0111] Preferably, in some embodiments, in step 1, the startup CPU and the protection CPU respectively perform real-time self-checking on the operation data required by the CPU during operation through their respective built-in RAMECC self-checking modules.

[0112] Preferably, in some embodiments, in step 1, the startup CPU and the protection CPU transfer the program code to the co-verification module of the co-processing CPU in a partition patrol manner. In each interrupt control cycle, the program code of each partition is transferred in turn to ensure that all program partitions are co-verified within the specified time.

[0113] Preferably, in some embodiments, the snapshot data in step 2 may be generated in a variety of forms, including but not limited to hash values, checksums, encrypted signatures, or other data consistency verification methods.

[0114] Preferably, in some embodiments, the self-repair in step 5 includes:

[0115] Program self-repair: The self-repair module of the co-processor CPU extracts the corresponding program partition from the backup program and replaces the damaged program code.

[0116] Data self-repair: The startup CPU and protection CPU each retrieve the correct backup data from the RAM storage unit, overwriting any damaged data. The backup data is updated before each run to ensure data integrity.

[0117] Further illustratively, in combination with the specific modules of the above-mentioned coordinated verification and reliable action system for soft error prevention of relay protection control devices, the method includes:

[0118] Step 1: Data self-verification

[0119] a. Start and protect data backup

[0120] Used to back up running data to the startup CPU and protect the CPU's internal RAM storage unit before performing data self-test.

[0121] b. Data verification between startup CPU and protection CPU

[0122] The startup CPU and protection CPU each perform real-time data self-checking. Each CPU uses its built-in RAM ECC self-check module to perform real-time self-checking of the operating data required by the CPU during operation. Data processed by the startup CPU includes initialization parameters, system status data, user configuration data, and log data; data processed by the protection CPU includes measurement data, protection setting parameters, and historical fault records.

[0123] ECC verification principle: For single-bit upsets, ECC self-checking can detect and repair single-bit errors. For multi-bit upsets (MBU), ECC self-checking can detect multi-bit errors. Although it cannot automatically repair them, it will generate an ECC self-repair exception signal, which will eventually be transmitted to the exception handling module of the co-processing CPU for subsequent repair.

[0124] c. Data self-calibration result transmission

[0125] While the startup CPU and protection CPU are performing data self-test, they will send the ECC check results (including error detection flag, error type and repair status) to the receiving module of the co-processing CPU for subsequent judgment and arbitration.

[0126] Step 2: Run the program to verify

[0127] a. Start CPU and protect CPU program patrol transmission

[0128] The startup CPU and protection CPU pass the program code to the co-processing CPU's co-verification module in a partition-by-partition manner. During each interrupt control cycle, the program code for each partition is passed in turn, ensuring that all program partitions are co-verified within the specified time.

[0129] Start the CPU program four rounds of patrol partitions: initialization code area, interrupt processing code area, system management code area, data monitoring code area;

[0130] The five patrol partitions of the CPU program are: protection logic code area, real-time data processing area, fixed value parameter management area, interrupt task processing code area, and hidden fault monitoring area.

[0131] b. Program snapshot generation and comparison

[0132] Snapshot generation: After receiving the program code, the co-verification module generates corresponding snapshot data for the received program code. The snapshot data can be generated in various forms, including but not limited to hash values, checksums, encrypted signatures, or other data consistency verification methods.

[0133] Snapshot comparison: The co-verification module compares the generated snapshot with the previous snapshot to ensure the integrity and correctness of the program. If the snapshots are consistent, the program is considered error-free; if not, an output exception signal is generated.

[0134] c. Program verification result transmission

[0135] The program co-verification results (including whether the comparison is consistent and the verification completion status) are passed to the consistency judgment module for further analysis, and are also passed to the monitoring module for real-time status monitoring.

[0136] Step 3: Consistency Judgment and Arbitration Decision

[0137] a.Consistency judgment

[0138] The consistency judgment module obtains the self-check status of the startup CPU and protection CPU transmitted from the receiving module, and at the same time receives the program cooperative check status transmitted from the cooperative check module to judge whether the exit check status results of the protection and startup CPUs are consistent.

[0139] If the status results are consistent, an output consistency signal is generated;

[0140] If the status results are inconsistent, an output abnormal state is generated and passed to the decision module.

[0141] b. 2-out-of-2 arbitration decision based on consistency judgment

[0142] The decision module arbitrates the signals of the startup CPU, protection CPU, and co-verification module based on the consistency judgment results, adopting the 2-out-of-2 principle: when the three signals are consistent and all allow output, the system generates an "allow output action" instruction to control the relay to continue normal operation; if the signals are inconsistent or an abnormality is detected, the exception handling process is entered.

[0143] Step 4: Exception handling and self-repair

[0144] a. The exception handling module triggers self-repair instructions

[0145] After receiving an exception status, the exception handling module generates a self-repair instruction. This instruction is passed to the self-repair module, triggering it to perform program self-repair and simultaneously sending data self-repair instructions to the boot CPU and protection CPU.

[0146] b. Program self-repair and data self-repair

[0147] Program self-repair: The self-repair module of the co-processor CPU extracts the corresponding program partition from the backup program and replaces the damaged program code.

[0148] Data self-repair: The startup CPU and protection CPU each retrieve the correct backup data from the RAM storage unit, overwriting any damaged data. The backup data is updated before each run to ensure data integrity.

[0149] c. Status monitoring after repair completion

[0150] The monitoring module monitors the repair results in real time:

[0151] If the self-repair is successful, the system status will be restored to normal and the snapshot data will be updated.

[0152] If self-repair fails, the system will enter a locked state and send an alarm signal through the monitoring system.

[0153] The present invention will be described in detail below through technically decomposed embodiments in conjunction with the accompanying drawings.

[0154] Example 1: A three-core collaborative verification and action exit execution method and system for soft error protection of relay protection control devices

[0155] This embodiment discloses a three-core coordinated verification and action export execution method and system for soft error protection of relay protection control devices, which is divided into the following parts: Figure 1 The three modules are: the protection CPU2, which is responsible for core protection logic calculation, data self-check and verification, co-processor transfer and relay protection control export; the startup CPU1, which is responsible for system startup, data self-check and verification, co-processor transfer and relay protection control export; the co-processor CPU3, which is also the key module in the "three-core collaborative architecture", is independent of the startup and protection CPUs. It is responsible for receiving the ECC self-check results and status, co-processor verification programs transmitted by the protection CPU2 and startup CPU1, and is also responsible for the consistency verification of the programs and data of the entire system, export arbitration decisions and some self-repair work.

[0156] In terms of architecture, coprocessor CPU 3 includes a monitoring and verification module 4 and an arbitration module 5. Furthermore, monitoring and verification module 4 includes a receiving module 6, a co-verification module 7, a self-repair module 8, and a monitoring module 9; arbitration module 5 includes a consistency determination module 10, a decision module 11, and an exception handling module 12.

[0157] The workflow mainly includes the following steps:

[0158] Step 1: Start self-test and program transfer of CPU1 and protection CPU2

[0159] The startup CPU1 and the protection CPU2 will perform real-time self-checks on the running data in their internal storage units during operation, and use the built-in ECC check module to complete data integrity detection.

[0160] During each interrupt control cycle, the startup CPU1 and protection CPU2 transfer programs to the coprocessor CPU3 in a partitioned round-robin manner. The startup CPU1's program partition includes the initialization code area, interrupt handling code area, system management and scheduling code area, and data management and monitoring code area. The protection CPU2's program partition includes the protection logic code area, real-time data processing area, parameter and constant value management area, interrupt handling code area, and invisible fault monitoring area.

[0161] Before delivering the program of each partition, the startup CPU 1 and the protection CPU 2 will back up the current data to the internal storage unit so as to perform data self-repair in subsequent steps.

[0162] Step 2: Collaboration between the receiving module and the co-verification module

[0163] The co-processor CPU 3 is composed of a monitoring and checking module 4 and an arbitration module 5. Furthermore, the monitoring and checking module 4 includes a receiving module 6, a co-checking module 7, a self-repairing module 8 and a monitoring module 9.

[0164] The receiving module 6 of the co-processing CPU 3 receives the self-test status results transmitted by the startup CPU 1 and the protection CPU 2. Part of these status results are transmitted to the consistency judgment module 10 in the arbitration module 5 for analysis, and the other part is directly transmitted to the monitoring module 9 in the monitoring and inspection module 4 for monitoring.

[0165] Co-verification module 7 receives the program code delivered by the patrol and compares it with the snapshot of the partition patrol program during the previous patrol. Co-verification module 7 generates a unique identifier (such as a hash value) for verification as a snapshot. By comparing the current partition code with the unique identifier of the previous snapshot, it determines whether the program has been tampered with or has errors.

[0166] If the verification is consistent, the co-verification module 7 updates the snapshot and sends the verification pass status to the consistency judgment module 10; if the verification is inconsistent, an abnormal status is generated and transmitted to the consistency judgment module 10 and the monitoring module 9.

[0167] Step 3: Consistency judgment and arbitration of decision modules

[0168] The consistency judgment module 10 receives the status results from the receiving module 6 and the co-verification module 7, and analyzes whether the data and programs transmitted from the startup CPU 1 and the protection CPU 2 are consistent during operation.

[0169] In the decision module 11, the output signals of the startup CPU1, the protection CPU2 and the co-verification module 7 are compared according to the 2-out-of-2 arbitration principle based on consistency judgment. If the three signals are consistent, an "allow exit action" instruction is generated and the system continues to operate normally; if the signals are inconsistent, the system enters an abnormal state and is passed to the exception handling module 12.

[0170] Step 4: Exception handling and self-repair operations

[0171] After detecting an abnormal state, the exception handling module 12 generates a self-repair instruction, which is transmitted to the self-repair module 8 .

[0172] After receiving the self-repair instruction, the self-repair module 8 starts the backup program of the co-verification module 7 to restore the damaged program; at the same time, it forwards the self-repair command to the startup CPU1 and the protection CPU2, so that the startup CPU1 and the protection CPU2 can restore the damaged data from their respective backup data.

[0173] After the self-repair is completed, the repair status is transmitted to the monitoring module 9 for updating the system status and ensuring stable operation of the system.

[0174] Step 5: System Arbitration and Reliable Relay Output

[0175] After the 2-out-of-2 arbitration principle based on consistency judgment in the decision module 11 is executed, if all signals are consistent, the system will allow the relay to operate normally and drive the output relay to perform the action.

[0176] When the self-repair module 8 completes the repair task, it passes the repair status to the monitoring module, and the monitoring module records the repair status so that in the next round of self-test, the consistency judgment module can obtain the repaired self-test status from the monitoring module to ensure the normal operation of the subsequent processes of the system and the reliability of the relay protection control device.

[0177] Example 2: Soft Error Multi-Level Checking Mechanism

[0178] This embodiment discloses a multi-level soft error checking mechanism for relay protection control devices, such as Figure 2 As shown in Figure 1, it mainly includes two verification levels: the first level is data self-verification, and the second level is program co-verification. This multi-level verification mechanism is designed to ensure the integrity and reliability of data and programs during the operation of the relay protection control device, especially when dealing with soft errors (such as single-bit flips and multi-bit flips).

[0179] Step 1: First-level data verification

[0180] The first level of verification is completed by the startup CPU1 and the protection CPU2, and mainly performs real-time verification on key data used by the system during operation.

[0181] Data verification process: The startup CPU1 and protection CPU2 perform self-checks on key data during operation through their respective built-in ECC verification modules. The self-check data includes initialization parameters, real-time measurement data, fixed value parameters, and log information.

[0182] ECC check: The ECC check module generates a check code (such as an ECC code) for each data block and compares it with the previously stored check code to detect whether the data block contains soft errors such as single-bit flips or multiple-bit flips.

[0183] Data Verification Result Transmission: After completing the data self-test, the startup CPU 1 and the protection CPU 2 transmit the self-test results to the receiving module 6 of the co-processing CPU 3 as basic information for further analysis. The receiving module records the data verification results and provides a reference for subsequent program verification.

[0184] Step 2: Second level program verification

[0185] The second level of verification is performed on the program code, using a partition patrol mechanism to ensure the integrity of the program during operation.

[0186] Program partition transfer and verification: The program address space of the boot CPU1 and protection CPU2 is divided into multiple partitions, and the program code of each partition is regularly transferred to the co-verification module 7 of the co-processing CPU3 through a patrol mechanism. During each interrupt control cycle, the boot CPU1 and protection CPU2 will each transfer a program partition to the co-verification module for verification.

[0187] Snapshot generation and comparison: After receiving the transferred program partition, the co-verification module 7 generates a unique identifier (such as a hash value, etc.) for the partition as a snapshot, and compares it with the last transferred snapshot of the same partition.

[0188] Verification Result Feedback: Verification Passed: If the snapshots match, there are no errors in the partition's program. Co-verification Module 7 updates the current partition's snapshot and reports the verification pass status to Monitoring Module 9 and Consistency Judgment Module 10. Verification Failed: If the snapshots do not match, the co-verification module records the partition's abnormal status and passes this information to Monitoring Module 9 and Consistency Judgment Module 10.

[0189] Step 3: Evaluate the results of multi-level verification

[0190] In a multi-level validation mechanism, the first and second layers generate independent validation results, yet together they provide comprehensive error detection capabilities. The receiving module 6 and the co-validation module 7 aggregate the data validation and program validation results, respectively, ensuring consistency across all layers.

[0191] Linked data and program verification: The first layer of data self-checking provides basic health information for system operation, while the second layer of program verification ensures that program code is error-free during execution. Together, these two layers enhance soft error protection at both the data and program levels.

[0192] Example 3: A system arbitration and self-repair method for a relay protection control device

[0193] This embodiment discloses a system arbitration and self-repair method for relay protection control devices, which mainly implements exception handling and self-repair processes for programs and data. This method uses the co-processing CPU to perform arbitration and self-repair operations, ensuring that the system can automatically recover when soft errors or exceptions occur, thereby ensuring the normal operation of the relay protection control device. The specific process is as follows: Figure 3 shown.

[0194] Step 1: Data and program backup

[0195] Data backup: Before starting CPU1 and protecting CPU2 to perform self-tests, they back up the running data, including initialization parameters, real-time measurement data, and fixed-value parameters. This data is saved in their respective internal storage units to ensure that the backup data can be called for recovery when a data anomaly is detected.

[0196] Program backup: After the startup CPU 1 and the protection CPU 2 transfer the program to the co-verification module 7 in a partition-by-partition patrol mode, the co-verification module 7 backs up the transferred program. Programs are stored in the co-verification module 7 by partition, ensuring that the self-repair module 8 can quickly restore the partition-level program in the event of an anomaly, preventing widespread program damage.

[0197] Step 2: Verification of data and program

[0198] Data Verification: The startup CPU 1 and the protection CPU 2 each verify the running data using their built-in ECC verification modules. The verification results are then transmitted to the co-processing CPU's receiving module 6. This module summarizes the data verification results and provides the basis for export arbitration decisions.

[0199] Program Verification: The startup CPU 1 and the protection CPU 2 transmit the program to the co-processing CPU's co-verification module 7 in a partition-by-partition round-robin manner. Co-verification module 7 verifies the transmitted program partition, generates a unique identifier (such as a hash value) for the program partition as a snapshot, and compares it with the snapshot of the same partition transmitted in the previous round-robin round-robin to check for anomalies. The verification result (pass or fail) is transmitted to the consistency judgment module 10 for judgment by the arbitration module.

[0200] Step 3: Consistency Judgment and Arbitration

[0201] Consistency judgment module 10: Receiving module 6 and co-verification module 7 transmit the data verification results and program verification results to consistency judgment module 10. Consistency judgment module 10 compares the verification status of receiving module 6 and co-verification module 7 with the self-repair status to determine whether the three are consistent.

[0202] Consistent signal output: If the verification results of the three are consistent, the consistency judgment module generates a consistent signal and transmits the signal to the decision module 11, indicating that the system can operate normally. Inconsistent signal output: If the verification results are inconsistent, an inconsistent signal is generated, an alarm is output, and the device is locked.

[0203] Decision Module 11 (Based on the 2-out-of-2 principle of consistency judgment): Decision Module 11 performs arbitration based on the signals from the consistency judgment module. Based on this principle, the decision module evaluates the status of the starter CPU 1, the protection CPU 2, and the relay output permission status in the consistency judgment module 10. If these three conditions are consistent, the relay is enabled and an "output operation permitted" signal is output to the action relay 16, allowing the system to continue normal operation. If an exception occurs, the exception handling process is initiated.

[0204] Step 4: Exception handling and self-repair

[0205] Exception handling module: When an inconsistent signal is detected, the exception handling module 12 is activated. The exception handling module generates a self-repair instruction and passes the instruction to the self-repair module 8. This module is responsible for directing subsequent self-repair operations.

[0206] Self-repair Module Operation: Repairing the Boot CPU and Protection CPU: After receiving the self-repair instruction from the exception handling module 12, the self-repair module 8 calls the backup data or program to overwrite the damaged program. Simultaneously, it sends the self-repair instruction to the boot CPU 1 and protection CPU 2, causing them to restore the corresponding abnormal partition using the backup data.

[0207] Self-repair status feedback: After the self-repair is completed, the repair status will be fed back to the monitoring module 9 to provide the repaired data or program status for subsequent verification.

[0208] Step 5: Monitoring and continuous operation of self-healing status

[0209] Monitoring Module 9: After self-repair is complete, Monitoring Module 9 continuously monitors the system's health. This module receives real-time feedback from Receiving Module 6, Co-verification Module 7, and Self-repair Module 8. This module ensures real-time system status updates and can identify hidden system faults.

[0210] Next self-test: In the next interrupt control cycle, the consistency judgment module 10 can obtain the repaired self-test status from the monitoring module 9 and continue to perform normal self-test and arbitration operations to ensure that the system can continue to run stably.

[0211] Example 4: Relay drive and execution circuit

[0212] This embodiment discloses a relay drive and execution circuit, the relay system includes a CPU system 13, a relay drive module 14, an actuator 15, an action relay 16, a start relay 17 and an operation box 18, etc., combined with Figure 4 Provide detailed explanation.

[0213] Step 1: Provide the starting power supply of the relay

[0214] The starting power supply provides voltage support to the entire drive circuit through the starting relay 17. When the system determines that an operation needs to be performed, the starting power supply is supplied through the starting relay 17 to ensure that the circuit can perform the operation smoothly.

[0215] Step 2: Logic Control of Relay Drive

[0216] The CPU system receives the exit action permission signal from the decision module 11 through the relay driver module and generates a control signal based on the logical judgment result. This control signal is used to control the operating state of the start relay 17 and the action relay 16, ensuring that the relay drive logic executes as designed.

[0217] Step 3: Driving and Operating the Relay

[0218] When the relay driver module controls the starter relay 17, it first connects the starter circuit, providing power to the action relay 16. Subsequently, the action relay 16 operates according to the set logic, controlling the operation box to execute subsequent operations. This process ensures that the drive and operation are effectively linked according to the system design.

[0219] Step 4: Actuator Motion Control

[0220] After receiving the action signal from the relay, the actuator 15 performs the corresponding mechanical operation.

[0221] In summary, the present invention significantly improves the soft error resistance of the relay protection control device through multi-level data and program verification combined with an automatic self-repair mechanism, ensuring the high reliability and safety of the system.

[0222] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only illustrative of the principles of the present invention. Without departing from the spirit and scope of the present invention, any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A coordinated verification and reliable action system for soft error prevention of protection and control equipment, characterized in that: The system includes a startup CPU, a protection CPU and a co-processing CPU built into the protection control device. Through the cooperation between the three, a multi-level verification and self-repair mechanism is formed to realize soft error protection and action export execution of the system; The system performs multi-level verification through the startup CPU, protection CPU and co-processing CPU, including: performing data self-verification through the startup CPU and protection CPU respectively, and transmitting the verification results to the co-processing CPU; performing program co-verification through the co-processing CPU; At the same time, the co-processing CPU makes arbitration decisions based on the verification results to determine the system exit action or perform exception processing; The self-repair mechanism specifically includes: triggering a self-repair instruction during the abnormal processing, and the system performs self-repair processing until it works normally.

2. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 1 is characterized in that: The startup CPU is responsible for system startup, data self-checking and relay protection control export startup control tasks, and has a built-in RAM ECC check module for real-time self-checking of the running data of the startup CPU; The protection CPU is responsible for the core relay protection control logic calculation, and has a built-in RAM ECC check module for real-time self-checking of the protection CPU's operating data; The startup CPU and the protection CPU are both equipped with a data backup module and a data self-repair module, which are used to back up and repair the running data of the startup CPU / protection CPU respectively; The startup CPU and the protection CPU back up the running data to the corresponding data backup modules respectively before performing data self-checking and transferring the program to the co-processing CPU.

3. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 1 is characterized in that: The co-processing CPU includes a monitoring and inspection module and an arbitration module; The monitoring and verification module is used to verify and monitor the data and programs for starting the CPU and protecting the CPU; The arbitration module is used to determine the system exit action or perform exception processing according to the output of the monitoring and inspection module.

4. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 3 is characterized in that: The monitoring and inspection module includes a receiving module, a co-verification module, a self-repair module and a monitoring module; The receiving module is used to receive the self-checking results of the startup CPU and the protection CPU, and transmit them to the arbitration module and the monitoring module at the same time; The co-verification module is used to verify the programs for starting the CPU and protecting the CPU transmission respectively, and transmit the verification results to the arbitration module and to the monitoring module at the same time; The self-repair module is used to receive the self-repair instruction, perform self-repair on the program, and send the self-repair instruction to the startup CPU and the protection CPU to trigger their respective self-repair functions; The monitoring module is used to receive and store feedback information from the receiving module, the co-verification module, and the self-repair module in real time to update the system status in real time; if it is monitored that the self-repair status of each module is successful, a recovery instruction is sent to the arbitration module, and the arbitration module controls the system status to return to normal; otherwise, an abnormal instruction is sent to the arbitration module, and the arbitration module generates a locking signal to control the system to enter a locking state, and an alarm signal is sent through the monitoring system.

5. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 4 is characterized in that: The startup CPU and the protection CPU transfer the program to the co-verification module in a partition patrol manner, and transfer the program of one partition in turn in each interrupt control cycle, and ensure that all program partitions are fully transmitted within the specified time.

6. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 5 is characterized in that: After receiving the program transmitted by the partition patrol, the co-verification module generates a unique identifier for each partition as a snapshot, and compares it with the previous snapshot of each partition in a one-to-one correspondence, and outputs the verification result; at the same time, the co-verification module will update the snapshot of the current partition; The verification result includes pass or fail. If the comparison is consistent, the verification result is pass, otherwise the verification result is fail; At the same time, after the co-verification module receives the program transmitted by the partition patrol, it also stores and backs up the program in a partition manner for the self-repair module to call; after the self-repair module receives the self-repair instruction, it performs self-repair by calling the backed-up program in the co-verification module.

7. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 4 is characterized in that: The monitoring module is also used to identify hidden system faults and issue an alarm while ensuring that the system status is updated in real time.

8. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 4 is characterized in that: The arbitration module includes a consistency judgment module, a decision module and an exception handling module; The consistency judgment module is used to receive the signal data output by the receiving module and the co-verification module, and respectively judge whether the self-verification result of the startup CPU is consistent with the verification result of the co-verification module on the startup CPU program, and whether the self-verification result of the protection CPU is consistent with the verification result of the co-verification module on the protection CPU program; If the verification results are all consistent, a consistency signal is output to the decision module, otherwise an abnormal state signal is generated to the decision module; The decision module performs arbitration based on the principle of more than one, specifically: if the start relay and the action relay corresponding to the start CPU and the protection CPU are both in the "output allowed" state, and the consistency judgment module outputs a consistency signal and generates an "export action allowed" instruction, control each relay to continue normal operation; otherwise, send an activation instruction to the exception handling module; The exception handling module is used to generate a self-repair instruction after receiving the activation instruction, and transmit the self-repair instruction to the self-repair module.

9. The coordinated verification and reliable action system for soft error prevention of protection and control equipment according to claim 8 is characterized in that: In the new interrupt control cycle, the consistency judgment module obtains the repaired / updated system status from the monitoring module and continues to perform normal self-checking and arbitration operations to ensure continuous and stable operation of the system.

10. A method for coordinated verification and reliable operation of soft error prevention of protection and control equipment based on the system according to any one of claims 1 to 9, characterized in that: The method comprises the following steps: Step 1, the startup CPU and the protection CPU respectively perform real-time data self-checking, and send the check results to the co-processing CPU, and at the same time, the startup CPU and the protection CPU send their respective programs to the co-processing CPU; Step 2, the co-processing CPU processes the received program, generates a corresponding snapshot, and compares the snapshot with the previous snapshot to generate a program verification result; Step 3, the co-processing CPU determines whether the self-check result of the startup CPU in step 1 is consistent with the check result of the startup CPU program by the co-processing CPU in step 2, and whether the self-check result of the protection CPU in step 1 is consistent with the check result of the protection CPU program by the co-processing CPU in step 2. If they are consistent, a consistency signal is generated; otherwise, an abnormal state signal is generated; Step 4, the co-processing CPU makes a blanking decision according to the signal generated in step 3: if step 3 outputs a consistency signal, and the start relay and the action relay corresponding to the start CPU and the protection CPU are both in the "output allowed" state, the co-processing CPU generates an "export action allowed" instruction to control each relay to continue to work normally, including driving the export relay to perform an action; otherwise, the co-processing CPU generates an abnormal processing signal and goes to step 5; Step 5, generating a self-repair instruction to trigger the self-repair function of the startup CPU, the protection CPU and the co-processing CPU; at the same time, monitoring the self-repair result in real time, if the self-repair result is successful, updating the snapshot data, and feeding back step 1 to continue execution, otherwise go to step 6; Step 6, enter the locked state, send out an alarm signal, and end the process.

Images