Key link self-checking method and system of relay protection device

Abstract

The invention relates to the technical field of relay protection device detection, and provides a relay protection device key link self-checking method and system, and the method comprises the steps: obtaining a recording file of a specific fault action; renaming the wave recording file and storing the wave recording file in a fixed directory of a device file system; triggering CPU virtual fault injection through an HMI interface of the device or the device; the tested CPU reads the sampling files and calculates and ranks the sampling files; the double CPUs are switched into an independent working state; the tested CPU transmits the virtual fault sampling points to the FPGA point by point; the FPGA replaces the actual sampling value in the sampling value message transmitted to the tested CPU with the virtual sampling value; the tested CPU verifies the virtual fault injection data message and generates a target virtual fault action; and the tested CPU sends a virtual outlet message and checks and replies, the tested CPU records a check and action log, and the double CPUs return to a normal state. According to the invention, the reliability of the device can be detected on line without abandoning the protection function.

Description

Technical Field

[0001] This invention relates to the field of relay protection device testing technology, and in particular to a self-testing method and system for critical links of relay protection devices. Background Technology

[0002] Relay protection devices play a crucial role in power systems, serving as a vital guarantee for their safe and stable operation. Well-functioning relay protection devices can monitor the power system's status in real time, promptly detect anomalies and handle faults, effectively controlling the scope of power grid safety incidents and maximizing the stability and continuity of power supply, minimizing the impact of faults on power system operation and residents' lives. With rapid socio-economic development, residents' lives and industrial production require a more stable and secure power supply, and the scale and complexity of power systems are constantly increasing, placing higher demands on the reliability of relay protection devices. If a relay protection device malfunctions or fails to operate, it can cause large-scale power outages, significantly impacting residents' lives and industrial production, resulting in severe losses. Therefore, ensuring the reliability of relay protection devices is a necessary measure for the safe and stable operation of power systems, and conducting reliability testing on relay protection devices is the first step in correctly identifying the device's condition.

[0003] Currently, the reliability testing of relay protection devices mainly includes the following methods: in-plant integrated testing, in-station planned maintenance (periodic maintenance), and uninterrupted power supply verification. In-plant integrated testing primarily involves centralized commissioning by the manufacturer to ensure the relay protection device is free of inherent defects and guarantees product quality. Specifically, it involves using a relay protection tester to test the accuracy of the device's operation while it is offline. Because it is not yet in use, it does not cause any impact such as power outages. In-station planned maintenance (periodic maintenance) mainly involves comprehensive maintenance of the relay protection device according to a pre-set fixed cycle. Regardless of the device's actual operating status, whether it is in normal use, or differences in its working environment and equipment quality, the maintenance procedure is initiated as soon as the maintenance time arrives. However, with the increasing number of substations, there is a shortage of front-line operators. Using sampling testing methods cannot fully represent the reliability status of operating relay protection devices. If a fault occurs in an untested device, it will still leave hidden dangers. The core idea of ​​uninterrupted power line verification is to perform reliability testing while the relay protection device is operating. This allows for testing without affecting the protection's operation, avoiding power outages and minimizing the impact of the test. However, due to different sampling methods, this approach is currently mainly used in smart substations, and traditional substations find it difficult to adopt. Furthermore, most current methods rely on software setting rather than verifying the actual sampling points and protection algorithms, making their reliability questionable. Summary of the Invention

[0004] The purpose of this invention is to solve at least one technical problem in the background art and to provide a method and system for self-testing critical links of relay protection devices.

[0005] To achieve the above objectives, the present invention provides a self-testing method for critical links of a relay protection device, comprising: Obtain COMTRADE waveform recordings of specific fault actions in a dual-CPU architecture relay protection device; Rename the COMTRADE waveform recording file and save it to a fixed directory in the device file system. Virtual fault injection is triggered periodically by the device's HMI human-machine interface or by the device itself. After receiving the trigger command, the CPU under test parses the name of the action to be triggered and finds the COMTRADE waveform file to be parsed and calculated according to the action name. The sampling points in the COMTRADE file are calculated according to the COMTRADE format to form the actual sampled value data area. The CPU under test reassembles the actual sampled value channel order, with the target order being the sampled value message order transmitted from the FPGA to the CPU. The reassembled sampled data is virtual fault injection data. The dual CPUs switch from the protection + startup cooperative working state to the independent working state. The CPU not under test enters the independent working state before the CPU under test. The CPU under test sets the FPGA virtual fault injection flag. The CPU under test transmits virtual fault injection data to the FPGA point by point in the form of virtual fault sampling points according to the agreed sampling cycle. After the FPGA determines that the virtual fault injection flag is set, it replaces the actual sampled value in the sampled value message transmitted to the CPU under test with the virtual sampled value, and sets the virtual fault injection flag in the sampled value message to inform the CPU under test that the message is a virtual fault injection data message. The tested CPU verifies the virtual fault injection data packet, generates the target virtual fault action, pops up a window in the HMI interface, and records the injection time and result in the log. If the device has an I / O output, a virtual I / O output message is agreed upon. After receiving the virtual I / O output message, the I / O board does not perform an actual output, but instead sends a reply message to the CPU, indicating that the actual output can be performed after calculation. If the device has a GOOSE output, it is agreed with the FPGA to return the GOOSE message to the CPU. The CPU performs verification and discards the message. All verification results are recorded in the log. The dual CPUs exit the virtual fault injection state and return to the normal state. After the CPU not under test exits the independent working state, the CPU under test exits the independent working state.

[0006] According to one aspect of the present invention, the CPU under test transmits virtual fault injection data to the FPGA point by point in the form of virtual fault sampling points according to a predetermined sampling cycle: After parsing the COMTRADE waveform file, the CPU under test transmits the parsed virtual fault injection data to the FPGA point by point in the form of virtual fault sampling points, according to the sampling frequency agreed upon with the FPGA.

[0007] According to one aspect of the invention, the FPGA replaces the actual sampled values ​​in the sampled value message transmitted to the CPU under test with virtual sampled values: While the FPGA is acquiring real sampled values ​​normally, it adds judgment logic. If virtual fault injection begins, the actual sampled values ​​sent to the CPU will be replaced with virtual sampled values.

[0008] According to one aspect of the present invention, during a transmission cycle, the CPU under test transmits a virtual fault injection data to the FPGA while simultaneously acquiring a virtual fault injection data message from the FPGA.

[0009] According to one aspect of the present invention, it further includes: the CPU under test verifying its own detection results, including: Verify CPU-FPGA sampling messages, verify the correctness of protection actions, verify protection action time, verify protection action accuracy, and verify output messages.

[0010] According to one aspect of the present invention, the CPU-FPGA sampling message is verified by the CPU under test verifying its own sampling data and the virtual fault injection data message returned by the FPGA to determine whether the communication process between the two is abnormal. The correctness of the protection action is verified as follows: when the virtual fault quantity is set to 1.05 times / 0.95 times the target value, the protection logic operates reliably; when the virtual fault quantity is set to 0.95 times / 1.05 times the target value, the protection logic does not operate reliably. The protection action time is verified by setting the virtual fault quantity to 1.2 times / 0.8 times the predetermined value, recording the time from the injection of the fault to the receipt of the feedback message, and obtaining the level of the protection instantaneous trip action time. Verifying the accuracy of protection actions involves adjusting the ratio between the virtual fault quantity and the predetermined set value, finding the fault action threshold, and obtaining the accuracy level of the protection set value. The verification output message is as follows: After the device takes action, it sends a virtual IO message and a virtual GOOSE message. The CPU under test must receive the IO virtual message reply and correctly verify the virtual GOOSE message.

[0011] To achieve the above objectives, the present invention also provides a critical link self-testing system for relay protection devices, comprising: The waveform recording file acquisition module acquires COMTRADE waveform recording files of specific fault actions of relay protection devices with dual-CPU architecture. The waveform recording file renaming and storage module renames and stores the COMTRADE waveform recording file in a fixed directory of the device file system. The actual sample value acquisition module injects virtual faults through the device's HMI human-machine interface or by the device automatically and periodically. After receiving the trigger command, the CPU under test parses the name of the action to be triggered and finds the COMTRADE waveform file that needs to be parsed and calculated according to the action name. It then calculates the sampling points in the COMTRADE format to form the actual sample value data area. The channel sequence reordering module reorders the actual sampled value channel sequence of the CPU under test. The target sequence is the sampled value message sequence transmitted from the FPGA to the CPU. The reordered sampled data is virtual fault injection data. The virtual fault injection flag setting module switches the dual CPUs from the protection + startup cooperative working state to the independent working state. The CPU not under test enters the independent working state before the CPU under test. The CPU under test sets the FPGA virtual fault injection flag. The virtual fault sampling data transmission module transmits virtual fault injection data to the FPGA point by point in the form of virtual fault sampling points according to the agreed sampling cycle of the CPU under test. The virtual fault injection data message transmission module, after the FPGA determines that the virtual fault injection flag is set, replaces the actual sampled value in the sampled value message transmitted to the CPU under test with the virtual sampled value, and sets the virtual fault injection flag in the sampled value message to inform the CPU under test that the message is a virtual fault injection data message. The virtual fault action generation module verifies the virtual fault injection data packet of the CPU under test, generates the target virtual fault action, pops up a window in the HMI interface, and records the injection time and result in the log. For the device output module, if the device has an IO output, a virtual output IO message is agreed upon. After receiving the virtual output message, the IO board does not perform an actual output, but instead sends a reply message to the CPU, indicating that the actual output can be performed after calculation. If the device has a GOOSE output, it is agreed with the FPGA to return the GOOSE message to the CPU. The CPU performs verification and discards the message. All verification results are recorded in the log. Once the module is tested, both CPUs exit the virtual fault injection state and return to normal. After the CPU not being tested exits the independent working state, the CPU being tested exits the independent working state.

[0012] To achieve the above objectives, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the critical link self-test method of the relay protection device as described above.

[0013] To achieve the above objectives, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the critical link self-test method for relay protection devices as described above.

[0014] According to the solution of the present invention, the present invention can realize reliability detection while maintaining the device protection function, without having to disconnect and disassemble the device each time, which can greatly reduce the impact of detection on the normal operation of the power system.

[0015] Compared to existing software setting methods, this invention covers key data links and protection stages such as CPU message reception, protection logic calculation, and protection action output, enabling more comprehensive detection of device reliability.

[0016] This invention simplifies testing requirements, allowing the relay protection device itself to complete the test, reducing the need for relay protection testers and artificially constructed environments, and lowering testing costs.

[0017] This invention enables regular automatic testing on-site, recording and uploading the results of each reliability test to the backend, facilitating management by on-site personnel, reducing their workload, and improving testing efficiency. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a critical link self-testing method for a relay protection device according to an embodiment of the present invention; Figure 2 The diagram illustrates the structure of a relay protection device according to one embodiment of the present invention. Detailed Implementation

[0019] The invention will now be discussed with reference to exemplary embodiments. It should be understood that the described embodiments are merely intended to enable those skilled in the art to better understand and thus implement the invention, and are not intended to imply any limitation on the scope of the invention.

[0020] As used herein, the term "comprising" and its variations are to be interpreted as open-ended terms meaning "including but not limited to". The term "based on" is to be interpreted as "at least partially based on". The terms "one embodiment" and "an embodiment" are to be interpreted as "at least one embodiment".

[0021] Figure 1 This is a schematic flowchart illustrating a critical link self-test method for a relay protection device according to an embodiment of the present invention. Figure 1 As shown, in this embodiment, the critical link self-test method of the relay protection device includes: Obtain a dual-CPU architecture (such as Figure 2 The COMTRADE waveform recording file (sample file) of the relay protection device for a specific fault operation (as shown); Rename the COMTRADE waveform recording file and save it to a fixed directory in the device file system. Virtual fault injection (fault injection) is automatically and periodically triggered by the device's HMI human-machine interface or by the device. After receiving the trigger command, the CPU under test parses the name of the action to be triggered, finds the COMTRADE waveform file that needs to be parsed and calculated according to the action name, and calculates the sampling points in the COMTRADE format to form the actual sampled value data area. The CPU under test reassembles the actual sampled value channel order, with the target order being the sampled value message order transmitted from the FPGA to the CPU. The reassembled sampled data is virtual fault injection data. The dual CPUs switch from the protection + startup cooperative working state to the independent working state. The CPU not under test enters the independent working state before the CPU under test. The CPU under test sets the FPGA virtual fault injection flag. The CPU under test transmits virtual fault sampling points (virtual sampling data) to the FPGA point by point according to the agreed sampling cycle. After the FPGA determines that the virtual fault injection flag is set, it replaces the actual sampled value in the sampled value message transmitted to the CPU under test with the virtual sampled value, and sets the virtual fault injection flag in the sampled value message to inform the CPU under test that the message is a virtual fault injection data message. The tested CPU verifies the virtual fault injection data packet, generates the target virtual fault action, pops up a window in the HMI interface, and records the injection time and result in the log. If the device has an I / O output, a virtual I / O output message is agreed upon. After receiving the virtual I / O output message, the I / O board does not perform an actual output, but instead sends a reply message to the CPU, indicating that the actual output can be performed after calculation. If the device has a GOOSE output, it is agreed with the FPGA to return the GOOSE message to the CPU. The CPU performs verification and discards the message. All verification results are recorded in the log. The dual CPUs exit the virtual fault injection state and return to the normal state. After the CPU not under test exits the independent working state, the CPU under test exits the independent working state.

[0022] In this implementation, CPU independent operation means that the two CPUs no longer care about each other's protection status. The protection triggering logic only cares about the input of this board, and other CPUs have no impact on the CPU of this board. The CPU under test executes the protection function independently, and the other CPU no longer performs protection output.

[0023] In this embodiment, the order in which the dual CPUs enter and exit the tested state is as follows: the CPU not under test enters the independent working state before the CPU under test, and then exits the independent working state after the CPU under test, ensuring that there is no vacuum period when the protection function exits.

[0024] Furthermore, according to one embodiment of the present invention, the CPU under test transmits the virtual fault sampling points to the FPGA point by point according to a predetermined sampling cycle: After parsing the COMTRADE waveform file, the CPU under test transmits the parsed sampled data to the FPGA point by point according to the sampling frequency agreed upon with the FPGA.

[0025] Furthermore, according to one embodiment of the present invention, the FPGA replaces the actual sampled values ​​in the sampled value message transmitted to the CPU under test with virtual sampled values: While the FPGA is acquiring real sampled values ​​normally, it adds judgment logic. If virtual fault injection begins, the actual sampled values ​​sent to the CPU will be replaced with virtual sampled values.

[0026] Furthermore, according to one embodiment of the present invention, within one transmission cycle, the CPU under test transmits a virtual fault injection data to the FPGA while simultaneously acquiring a virtual fault injection data message from the FPGA.

[0027] Furthermore, according to one embodiment of the present invention, the method further includes: the CPU under test verifying its own detection results, including: Verify CPU-FPGA sampling messages, verify the correctness of protection actions, verify protection action time, verify protection action accuracy, and verify output messages.

[0028] Furthermore, according to one embodiment of the present invention, the CPU-FPGA sampling message is verified as follows: the CPU under test verifies its own sampling data and the virtual fault injection data message returned by the FPGA to determine whether the communication process between the two is abnormal. The correctness of the protection action is verified as follows: when the virtual fault quantity is set to 1.05 times (over-protection) / 0.95 times (under-protection) of the target value, the protection logic should operate reliably; when the virtual fault quantity is set to 0.95 times (over-protection) / 1.05 times (under-protection) of the target value, the protection logic should not operate reliably. The protection action time is verified by setting the virtual fault quantity to 1.2 times (over-protection) / 0.8 times (under-protection) of the predetermined value, recording the time from the injection of the fault to the receipt of the feedback message, and obtaining the level of the protection instantaneous trip action time, which can be compared with the device action time under normal conditions. Verifying the accuracy of protection actions involves adjusting the ratio between the virtual fault quantity and the predetermined set value, finding the fault action threshold, obtaining the accuracy level related to the protection set value, and comparing it with the device accuracy performance under normal conditions. The verification output message is as follows: After the device takes action, it sends a virtual IO message and a virtual GOOSE message. It should correctly receive the IO virtual message reply and correctly verify the virtual GOOSE message.

[0029] According to the solution of the present invention, the present invention can realize reliability detection while maintaining the device protection function, without having to disconnect and disassemble the device each time, which can greatly reduce the impact of detection on the normal operation of the power system.

[0030] Compared to existing software setting methods, this invention covers key data links and protection stages such as CPU message reception, protection logic calculation, and protection action output, enabling more comprehensive detection of device reliability.

[0031] This invention simplifies testing requirements, allowing the relay protection device itself to complete the test, reducing the need for relay protection testers and artificially constructed environments, and lowering testing costs.

[0032] This invention enables regular automatic testing on-site, recording and uploading the results of each reliability test to the backend, facilitating management by on-site personnel, reducing their workload, and improving testing efficiency.

[0033] Furthermore, to achieve the above objectives, the present invention also provides a critical link self-testing system for relay protection devices, comprising: The waveform recording file acquisition module acquires COMTRADE waveform recording files of specific fault actions of relay protection devices with dual-CPU architecture. The waveform recording file renaming and storage module renames and stores the COMTRADE waveform recording file in a fixed directory of the device file system. The actual sample value acquisition module injects virtual faults through the device's HMI human-machine interface or by the device automatically and periodically. After receiving the trigger command, the CPU under test parses the name of the action to be triggered and finds the COMTRADE waveform file that needs to be parsed and calculated according to the action name. It then calculates the sampling points in the COMTRADE format to form the actual sample value data area. The channel sequence reordering module reorders the actual sampled value channel sequence of the CPU under test. The target sequence is the sampled value message sequence transmitted from the FPGA to the CPU. The reordered sampled data is virtual fault injection data. The virtual fault injection flag setting module switches the dual CPUs from the protection + startup cooperative working state to the independent working state. The CPU not under test enters the independent working state before the CPU under test. The CPU under test sets the FPGA virtual fault injection flag. The virtual fault sampling data transmission module transmits virtual fault sampling points to the FPGA one by one according to the agreed sampling cycle. The virtual fault injection data message transmission module, after the FPGA determines that the virtual fault injection flag is set, replaces the actual sampled value in the sampled value message transmitted to the CPU under test with the virtual sampled value, and sets the virtual fault injection flag in the sampled value message to inform the CPU under test that the message is a virtual fault injection data message. The virtual fault action generation module verifies the virtual fault injection data packet of the CPU under test, generates the target virtual fault action, pops up a window in the HMI interface, and records the injection time and result in the log. For the device output module, if the device has an IO output, a virtual output IO message is agreed upon. After receiving the virtual output message, the IO board does not perform an actual output, but instead sends a reply message to the CPU, indicating that the actual output can be performed after calculation. If the device has a GOOSE output, it is agreed with the FPGA to return the GOOSE message to the CPU. The CPU performs verification and discards the message. All verification results are recorded in the log. Once the module is tested, both CPUs exit the virtual fault injection state and return to normal. After the CPU not being tested exits the independent working state, the CPU being tested exits the independent working state.

[0034] In this implementation, CPU independent operation means that the two CPUs no longer care about each other's protection status. The protection triggering logic only cares about the input of this board, and other CPUs have no impact on the CPU of this board. The CPU under test executes the protection function independently, and the other CPU no longer performs protection output.

[0035] In this embodiment, the order in which the dual CPUs enter and exit the tested state is as follows: the CPU not under test enters the independent working state before the CPU under test, and then exits the independent working state after the CPU under test, ensuring that there is no vacuum period when the protection function exits.

[0036] Furthermore, according to one embodiment of the present invention, the CPU under test transmits the virtual fault sampling points to the FPGA point by point according to a predetermined sampling cycle: After parsing the COMTRADE waveform file, the CPU under test transmits the parsed sampled data to the FPGA point by point according to the sampling frequency agreed upon with the FPGA.

[0037] Furthermore, according to one embodiment of the present invention, the FPGA replaces the actual sampled values ​​in the sampled value message transmitted to the CPU under test with virtual sampled values: While the FPGA is acquiring real sampled values ​​normally, it adds judgment logic. If virtual fault injection begins, the actual sampled values ​​sent to the CPU will be replaced with virtual sampled values.

[0038] Furthermore, according to one embodiment of the present invention, within one transmission cycle, the CPU under test transmits a virtual fault injection data to the FPGA while simultaneously acquiring a virtual fault injection data message from the FPGA.

[0039] Furthermore, according to one embodiment of the present invention, the method further includes: the CPU under test verifying its own detection results, including: Verify CPU-FPGA sampling messages, verify the correctness of protection actions, verify protection action time, verify protection action accuracy, and verify output messages.

[0040] Furthermore, according to one embodiment of the present invention, the CPU-FPGA sampling message is verified as follows: the CPU under test verifies its own sampling data and the virtual fault injection data message returned by the FPGA to determine whether the communication process between the two is abnormal. The correctness of the protection action is verified as follows: when the virtual fault quantity is set to 1.05 times (over-protection) / 0.95 times (under-protection) of the target value, the protection logic should operate reliably; when the virtual fault quantity is set to 0.95 times (over-protection) / 1.05 times (under-protection) of the target value, the protection logic should not operate reliably. The protection action time is verified by setting the virtual fault quantity to 1.2 times (over-protection) / 0.8 times (under-protection) of the predetermined value, recording the time from the injection of the fault to the receipt of the feedback message, and obtaining the level of the protection instantaneous trip action time, which can be compared with the device action time under normal conditions. Verifying the accuracy of protection actions involves adjusting the ratio between the virtual fault quantity and the predetermined set value, finding the fault action threshold, obtaining the accuracy level related to the protection set value, and comparing it with the device accuracy performance under normal conditions. The verification output message is as follows: After the device takes action, it sends a virtual IO message and a virtual GOOSE message. It should correctly receive the IO virtual message reply and correctly verify the virtual GOOSE message.

[0041] According to the solution of the present invention, the present invention can realize reliability detection while maintaining the device protection function, without having to disconnect and disassemble the device each time, which can greatly reduce the impact of detection on the normal operation of the power system.

[0042] Compared to existing software setting methods, this invention covers key data links and protection stages such as CPU message reception, protection logic calculation, and protection action output, enabling more comprehensive detection of device reliability.

[0043] This invention simplifies testing requirements, allowing the relay protection device itself to complete the test, reducing the need for relay protection testers and artificially constructed environments, and lowering testing costs.

[0044] This invention enables regular automatic testing on-site, recording and uploading the results of each reliability test to the backend, facilitating management by on-site personnel, reducing their workload, and improving testing efficiency.

[0045] Furthermore, to achieve the above objectives, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the critical link self-test method of the relay protection device as described above.

[0046] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the critical link self-test method for relay protection devices as described above.

[0047] Those skilled in the art will recognize that the modules and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0048] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and equipment can be referred to the corresponding process in the foregoing method implementation, and will not be repeated here.

[0049] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0050] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the objectives of the embodiments of the present invention, depending on actual needs.

[0051] In addition, the functional modules in the embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0052] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the sending / receiving methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0053] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in this application.

[0054] It should be understood that the sequence number of each step in the invention and its embodiments does not absolutely imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

Claims

1. A method for self-checking of critical links of a protection device, characterized in that, The method comprises the following steps: obtaining a COMTRADE recording file of a specific fault action of a double-CPU architecture relay protection device; storing the COMTRADE recording file in a fixed directory of a device file system after renaming the COMTRADE recording file; triggering a virtual fault injection through a device HMI man-machine interactive interface or a device automatic periodic trigger, after receiving the trigger instruction, the measured CPU analyzes the action name to be triggered, finds the COMTRADE recording file to be analyzed and calculated according to the action name, calculates the sampling points in the COMTRADE recording file according to the COMTRADE format, and forms an actual sampling value data area; the measured CPU recombines the actual sampling value channels in sequence, and the target sequence is the sampling value message sequence transmitted to the CPU by the FPGA, and the recombined sampling data is virtual fault injection data; the double-CPU switches from a protection + start cooperative working state to an independent working state, the unmeasured CPU enters the independent working state before the measured CPU, and the measured CPU sets a virtual fault injection flag position; the measured CPU transmits the virtual fault injection data to the FPGA in the form of virtual fault sampling points according to the agreed sampling period; after the FPGA judges that the virtual fault injection flag position is set, the actual sampling value in the sampling value message transmitted to the measured CPU is replaced by a virtual sampling value, and the virtual fault injection flag position in the sampling value message is set, so as to inform the measured CPU that the message is a virtual fault injection data message; the measured CPU checks the virtual fault injection data message, generates a target virtual fault action, pops up a window on the HMI interface, and records the injection time and result in a log; if the device has an IO outlet, an agreement is made on a virtual outlet IO message, after receiving the virtual outlet message, the IO board does not perform an actual outlet, but sends a reply message to the CPU, indicating that the actual outlet can be performed after operation; if the device has a GOOSE outlet, an agreement is made on the GOOSE message returned to the CPU, and the CPU discards the message after checking; all checking results are recorded in a log; the double-CPU exits the virtual fault injection state and returns to the normal state, and the unmeasured CPU exits the independent working state after the measured CPU.

2. The method of claim 1, wherein, the measured CPU transmits the virtual fault injection data to the FPGA in the form of virtual fault sampling points according to the agreed sampling period is: after analyzing the COMTRADE recording file, the measured CPU transmits the virtual fault injection data in the form of virtual fault sampling points to the FPGA according to the sampling frequency agreed with the FPGA.

3. The method of claim 1, wherein the method further comprises: the FPGA replaces the actual sampling value in the sampling value message transmitted to the measured CPU with a virtual sampling value is: the FPGA adds a judgment logic while normally obtaining the real sampling value, and if the virtual fault injection starts, the actual sampling value sent to the CPU is replaced by a virtual sampling value.

4. The method of claim 1, wherein the method further comprises: in one transmission period, the measured CPU transmits one virtual fault injection data to the FPGA, and at the same time, obtains one virtual fault injection data message from the FPGA.

5. The method of claim 1, wherein, the measured CPU checks its own detection result, including: ​ Check CPU-FPGA sampling message, check protection action correctness, check protection action time, check protection action accuracy, check export message.

6. The relay protection device key link self-checking method according to claim 5, characterized in that, the CPU-FPGA sampling message checking is that the measured CPU checks the sampling data of itself and the virtual fault injection data message returned by the FPGA, and judges whether the communication process is abnormal; the protection action correctness checking is that when the virtual fault quantity is set to 1.05 times / 0.95 times of the target setting value, the protection logic reliably acts, and when the virtual fault quantity is set to 0.95 times / 1.05 times of the target setting value, the protection logic reliably does not act; the protection action time checking is that when the virtual fault quantity is set to 1.2 times / 0.8 times of the given setting value, the time from fault injection to receiving the opening feedback message is recorded to obtain the level of the protection speed breaking action time; the protection action accuracy checking is that the multiple relationship between the virtual fault quantity and the given setting value is adjusted to find the action threshold of the fault to obtain the accuracy level of the protection setting value; the export message checking is that the device sends out virtual IO messages and virtual GOOSE messages after acting, and the measured CPU must receive the IO virtual message reply and correctly check the virtual GOOSE message.

7. A system for self-checking critical links of a protective relay, characterized by, It comprises: a wave recording file acquisition module that acquires the COMTRADE wave recording file of the specific fault action of the double-CPU architecture relay protection device; a wave recording file renaming and storage module that renames the COMTRADE wave recording file and stores it in the fixed directory of the device file system; an actual sampling value acquisition module that triggers the virtual fault injection through the device HMI human-computer interaction interface or the device automatic periodic triggering, and after the measured CPU receives the triggering instruction, analyzes the action name to be triggered, finds the COMTRADE wave recording file to be analyzed and calculated according to the action name, calculates the sampling points in the COMTRADE format, and forms the actual sampling value data area; a channel sequence reorganization module that reorganizes the actual sampling value channel sequence by the measured CPU, and the target sequence is the sampling value message sequence transmitted by the FPGA to the CPU, and the reorganized sampling data is the virtual fault injection data; a virtual fault injection flag position setting module that switches the double-CPU from the protection + start cooperative working state to the independent working state, and the non-measured CPU enters the independent working state earlier than the measured CPU, and the measured CPU sets the FPGA virtual fault injection flag position; a virtual fault sampling data transmission module that transmits the virtual fault injection data to the FPGA in the form of virtual fault sampling points according to the agreed sampling period by the measured CPU; a virtual fault injection data message transmission module that replaces the actual sampling value in the sampling value message transmitted to the measured CPU with the virtual sampling value after the FPGA judges that the virtual fault injection flag position is set, sets the virtual fault injection flag position in the sampling value message, and informs the measured CPU that the message is a virtual fault injection data message; The virtual fault action forming module checks the virtual fault injection data packet of the measured CPU, generates a target virtual fault action, and pops up a window on the HMI interface and records the injection time and result in a log; The device outlet module, if the device has an IO outlet, agrees on a virtual outlet IO packet, the IO board does not perform actual export after receiving the virtual export packet, but sends a reply packet to the CPU, indicating that the actual export can be performed after operation; if the device has a GOOSE outlet, the FPGA agrees to return the GOOSE packet to the CPU, and the CPU discards the packet after checking, and all checking results are recorded in a log; The detection completion module, the double CPU exits the virtual fault injection state and returns to the normal state, and the unmeasured CPU exits the independent working state after the measured CPU.

8. An electronic device, characterized by The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the key link self-checking method of the relay protection device.

9. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the key link self-checking method of the relay protection device.

Images