System and method for automatically testing secondary equipment of power system

Abstract

The invention discloses an automatic test system and method for secondary equipment of a power system, and the system comprises an automatic test process scheduling control center which is used for the loading and unloading of task processes, the inter-process information forwarding, the test process information display and the automatic export of a test report; the test scheme module comprises a process scheduling directory template and a test scheme template; the execution process module comprises an auxiliary process and a test process; the auxiliary equipment provides a plurality of groups of normally-closed nodes to control the on-off of a power supply of the tested device, an output node and an input node are connected with the tested device, and GOOSE and SV message simulation is supported; the tested device is power system secondary equipment to be tested; according to the invention, concurrent testing can be carried out on a plurality of tested devices, in the testing process, through automatic uploading and downloading of the configuration file, the testing device is automatically restarted after power failure, the problems that the configuration file needs to be manually downloaded and the device needs to be restarted after power failure in the testing process are effectively solved, and the testing efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of secondary power equipment, and particularly relates to an automatic test system and method for secondary equipment of a power system. Background Art

[0002] With the rapid development of the power system and the continuous expansion of the power grid scale, the network structure of the power system is becoming increasingly complex, and the requirements for safe operation are also getting higher and higher. Secondary equipment of the power system such as relay protection and security and stability control, as the key guarantee for the safe and stable operation of the power grid, its reliability and performance directly affect the overall safety of the power system.

[0003] Currently, the automatic testing of secondary equipment of the power system mainly adopts a semi-automated testing scheme. The tester selects the corresponding test tasks according to the test plan and builds the test environment, including connecting test instruments, configuring parameters, etc. The test tool can automatically execute the preset test cases and complete tasks such as function verification and performance testing.

[0004] However, most of the existing automatic test tools lack the ability of concurrent testing and can only perform functional testing on a single device under test at a time. If multiple devices need to be tested, the tester must manually switch the connection lines during the test process and connect different devices to the test environment in sequence, and it is impossible to realize the synchronous testing of multiple devices. This serial testing method is not only inefficient but also increases the time and error risk of manual operation, and it is difficult to meet the requirements of high-efficiency testing of secondary equipment of large-scale power systems. Summary of the Invention

[0005] Object of the Invention: The object of the present invention is to provide an automatic test system for secondary equipment of a power system that can simultaneously control multiple devices under test for automatic testing and improve the testing efficiency of secondary equipment of the power system; on the other hand, to provide an automatic test method for secondary equipment of a power system.

[0006] Technical Solution: The automatic test system described in the present invention includes:

[0007] An automatic test process scheduling and control center for task process loading and unloading, information forwarding between processes, display of test process information, and automatic export of test reports;

[0008] A test plan module including a process scheduling directory template and a test plan template. The process scheduling directory template configures a task process list with devices as objects, and the test plan template contains test cases and parameters;

[0009] An execution process module including an auxiliary process and a test process. The auxiliary process communicates with auxiliary devices, and the test process communicates with devices under test;

[0010] An auxiliary device that provides multiple sets of normally closed nodes to control the power on / off of the device under test, connects the output and input nodes to the device under test, and supports the simulation of GOOSE and SV messages;

[0011] The device under test is a secondary device of the power system to be tested.

[0012] By constructing a complete test system that includes an automatic test process scheduling control center, a test plan module, an execution process module, an auxiliary device, and the device under test, the efficient and automated testing of secondary devices in the power system is achieved. Among them, the control center uniformly schedules the task processes and realizes information interaction, the test plan module provides standardized template configuration, the execution process module realizes real-time communication with the devices, the auxiliary device provides power control, signal acquisition, and communication simulation functions. The entire system can significantly improve the test efficiency, reduce manual intervention, and support concurrent testing of multiple devices and automated processing of complex test scenarios.

[0013] Preferably, the process scheduling directory template is an XML format file, including:

[0014] At least one device node, whose attributes include device name, IP address, and device type;

[0015] Under each device node, at least one test task node is configured, whose attributes include test task name, test plan path, process type, and start mode.

[0016] Adopting an XML format process scheduling directory template, through the hierarchical configuration of device nodes and test task nodes, the visual management and flexible scheduling of test tasks are realized. Among them, the device node contains key attributes such as device name, IP address, and type, and the test task node defines parameters such as task name, plan path, process type, and start mode. This structured template design not only facilitates the rapid configuration and modification of test tasks, but also supports the differentiated test requirements of different types of devices. At the same time, through the standardized XML format, the universality and scalability of system configuration are ensured, significantly improving the deployment efficiency and maintenance convenience of the test system.

[0017] Preferably, the auxiliary device includes:

[0018] Multiple sets of normally closed nodes are connected in series to the power supply circuit of the device under test, and the device is powered off and restarted by automatically closing after disconnection;

[0019] Multiple sets of output nodes are connected to the inputs of the device under test, and multiple sets of input nodes monitor the output status of the device under test;

[0020] GOOSE and SV message simulation functions for injecting subscribed signals into the device under test.

[0021] The intelligent power-off restart control of the device under test is realized through multiple groups of normally closed nodes integrated by the auxiliary device. The status interaction and real-time monitoring with the device under test are completed by using the output / input nodes, and the GOOSE / SV message simulation function is equipped to simulate the actual power grid communication environment. This integrated design not only realizes the automated coordination of power management, status monitoring, and communication simulation during the testing process, but also can accurately reproduce various working conditions of secondary equipment in the power system during actual operation, effectively solving the problems of the need for multiple devices to cooperate and cumbersome manual operations in traditional testing, and greatly improving the accuracy and reliability of testing.

[0022] Preferably, the automatic test process scheduling control center communicates with the test process and the auxiliary process through the pipe service, where: the test process and the auxiliary process do not directly interact, and requests and results need to be forwarded through the control center; the control center assigns a unique process ID to each task process and supports concurrent or blocking startup modes.

[0023] Through the centralized pipe communication mechanism constructed by the automatic test process scheduling control center, using the unique identification of the process ID and the request / result transfer architecture, the safe isolation and efficient coordination of the test process and the auxiliary process are realized. The control center, as the communication hub, not only ensures the decoupled operation between processes, but also supports concurrent or blocking startup modes through unified process management. This design not only effectively avoids resource conflicts that may be caused by direct coupling between processes, but also can flexibly configure execution strategies according to test requirements, significantly improving the efficiency and reliability of multi-task parallel processing while ensuring system stability.

[0024] Preferably, in the test plan template:

[0025] The test case consists of multiple test steps, and the test step names are consistent with the atomic operation keywords of the test process;

[0026] The common parameter node stores configurable parameters related to the environment.

[0027] Through the structured test plan template design, the test case is decomposed into a sequence of test steps that strictly correspond to the atomic operation keywords, and an independent common parameter node is set to centrally manage the environment configuration parameters. This modular design not only ensures the accurate matching of test steps and underlying function interfaces, but also realizes the separate management of test parameters and test logic, making the test plan highly reusable - it can be quickly adapted to different test environments by simply modifying the common parameters while keeping the core logic of the test case unchanged, significantly improving the development efficiency and cross-environment transplantation ability of the test plan, and providing a standardized and configurable test framework for the automated testing of secondary power equipment.

[0028] Preferably, the auxiliary process includes an operation stack module, which is used to receive operation requests from the test process and execute them in the first-in, first-out order; return the operation results to the test process through a pipeline, and process the requests in the stack in a loop.

[0029] By setting an operation stack module in the auxiliary process and adopting a first-in, first-out task processing mechanism, the orderly queuing and reliable execution of test requests are realized. This design establishes an asynchronous communication link with the test process through the pipeline service, ensuring both the order and integrity of operation instructions and the real-time feedback of execution results. This buffered task processing architecture effectively solves the problems of instruction conflicts and resource competition that may occur during the test process. At the same time, the loop processing mechanism ensures the system stability in high-concurrency test scenarios, significantly improving the reliability and execution efficiency of the automated test system.

[0030] The automatic test method of the present invention includes the following steps:

[0031] (1) The automatic test process scheduling control center loads the process scheduling directory template and parses the device list and corresponding test tasks;

[0032] (2) Assign a unique process ID to each test task, and start the corresponding auxiliary process and test process in the device order;

[0033] (3) The test process loads the test plan template and sequentially executes multiple atomic operation steps in the test case;

[0034] (4) When the test step requires an operation on the auxiliary device, forward the operation request to the corresponding auxiliary process for execution through the pipeline service;

[0035] (5) Real-time monitor the execution status of each test step and perform error handling on operations that do not respond within the timeout;

[0036] (6) Automatically generate a test report after the test is completed and exit the relevant processes;

[0037] (7) When it is necessary to replace the configuration file of the device under test, control the auxiliary device to perform a power-off restart operation on the device;

[0038] (8) After monitoring the device status and confirming a successful restart, continue to execute the subsequent test steps.

[0039] The intelligent scheduling and execution of test tasks are realized through the automatic test process scheduling control center. It adopts templatized configuration and process management, supports concurrent testing of multiple devices and automated processing of complex test scenarios. The efficient cooperation between the test process and the auxiliary process is achieved through the pipeline service. Combining the precise execution of atomic operation steps and real-time status monitoring ensures the reliability and integrity of the test process. The system automatically completes key operations such as replacing configuration files and restarting devices, and generates detailed test reports, significantly improving the automation level and execution efficiency of the secondary power equipment test, and solving the problems of excessive manual intervention and low efficiency in traditional testing.

[0040] Preferably, when the test process executes a test step, if auxiliary device operations are required, it first queries the corresponding auxiliary process for its initialization status, and then sends an operation instruction after confirming that the initialization is completed.

[0041] Through the initialization status confirmation mechanism between the test process and the auxiliary process, a reliable pre-check process for device operations is established. This design ensures that subsequent operation instructions are only executed after the auxiliary device is ready through mandatory initialization status queries, effectively avoiding instruction failure or system exceptions caused by unready devices. This defensive programming strategy significantly improves the stability and reliability of the automated test process. At the same time, it optimizes the execution efficiency of the test process through the state-driven instruction triggering mechanism, providing security guarantees for device collaborative operations in complex test scenarios.

[0042] Preferably, the pipeline service in step 4 works in the following way:

[0043] The test process sends a request containing the auxiliary process ID to the automatic test process scheduling control center;

[0044] The control center forwards the request to the corresponding auxiliary process;

[0045] After the auxiliary process finishes execution, it returns the result to the test process through the control center.

[0046] Through the pipeline service architecture with the control center as the transfer, adopting the standardized communication process of "request - forwarding - execution - return", the safe isolation and precise scheduling between the test process and the auxiliary process are realized. This design ensures the reliability and sequentiality of cross-process communication through process ID identification and centralized message routing, and avoids direct coupling between processes, making the system have good scalability and fault isolation capabilities. This centralized control communication mode effectively solves the timing control problem of process collaboration in a distributed test environment, and at the same time reduces the system complexity through a unified message forwarding mechanism, providing an efficient and stable inter-process communication guarantee for concurrent testing of multiple devices.

[0047] Preferably, step 7 specifically includes: setting the device under test to the maintenance state; downloading the configuration file to the specified directory through the communication protocol; controlling the auxiliary device to perform a power-off and restart operation; and monitoring the output node status of the device to confirm the completion of the restart.

[0048] Through the standardized configuration file replacement process, the full automation of the configuration update of the device under test is realized: First, the device is safely set to the maintenance state to ensure operation safety. Then, the configuration file is accurately downloaded to the specified location through the communication protocol. Next, the auxiliary device performs a reliable power-off and restart operation. Finally, the success of the restart is confirmed by real-time monitoring of the device status. This end-to-end automated processing flow not only completely eliminates the cumbersome manual intervention links in traditional testing, but also ensures the integrity and reliability of the configuration update through the status monitoring mechanism, significantly improving the testing efficiency while effectively avoiding human operation errors. It is particularly suitable for large-scale automated testing scenarios that require frequent configuration changes.

[0049] Advantages: Compared with the prior art, the present invention has the following remarkable advantages: 1. It can perform concurrent tests on multiple devices under test. During the test process, through the automatic upload and download of the configuration file and the automatic power-off and restart of the test device, the problems of manual download of the configuration file and power-off and restart of the device during the test are effectively solved, improving the testing efficiency; 2. Through the combined use of the process scheduling directory template and the test plan template, the automated configuration and execution of the test tasks are realized. The system can automatically parse the test steps, monitor the execution status, and perform intelligent error handling in case of anomalies, ensuring the reliability and stability of the test process and reducing the complexity and error probability of manual operations; 3. Adopting a modular design, it supports the testing requirements of different types of secondary devices. Through the pipe service to achieve inter-process communication, the decoupled design of the test process and the auxiliary process makes the system have good scalability and can easily add new test functions or device types; 4. It not only supports conventional functional tests, but also can simulate special communication protocols such as GOOSE and SV in the power system to achieve a comprehensive test of the communication functions of secondary devices. At the same time, through the automated processing of special test scenarios such as power-off and restart and configuration file replacement, the integrity and depth of the test are ensured. Brief Description of the Drawings

[0050] Figure 1 It is a schematic diagram of the system structure of the present invention;

[0051] Figure 2 It is a detailed block diagram of the system of the present invention;

[0052] Figure 3 It is a schematic diagram of the task scheduling directory configuration file of the present invention;

[0053] Figure 4 It is a wiring diagram of the restart of the test device of the present invention;

[0054] Figure 5 This is the flowchart for starting the task process of the present invention;

[0055] Figure 6 This is the schematic diagram of the test solution of the present invention;

[0056] Figure 7 This is the flowchart for executing the test solution of the present invention;

[0057] Figure 8 This is the flowchart for processing operations of the auxiliary process of the present invention;

[0058] Figure 9 This is the flowchart for the test task of the loading device of the present invention;

[0059] Figure 10 This is the schematic diagram of the automatic test case management directory of the present invention. Detailed implementation manners

[0060] The technical solution of the present invention will be further described below in conjunction with the accompanying drawings.

[0061] Step 1: As Figure 1 shown, the automatic test system and method for secondary power equipment include an automatic test process scheduling control center, a test solution, an execution process, auxiliary equipment, and a device under test. The automatic test process scheduling control center includes functions such as task process loading and unloading, information forwarding between processes, display of test process information, and automatic export of test reports. The test solution includes a process scheduling directory template and a test solution template. The execution process includes an auxiliary process and a test process. The test process can be divided into test processes of types such as setting values, IEC103, GOOSE, SV, IO, MMS, LCD, events / recording waves, etc. according to the functions of the secondary equipment. The system details are as Figure 2 shown.

[0062] The process scheduling directory template contains the auxiliary equipment, test equipment involved in the test system, and the task list included in the equipment; the process scheduling directory takes the equipment as the object, and the name of the task process to be started is configured under each equipment. The process scheduling directory can include multiple auxiliary equipment and devices under test. The automatic test process scheduling control center loads the process scheduling directory and loads the processes under the equipment respectively with the equipment as the object.

[0063] Step 2: Create an automatic test case management directory, as Figure 10As shown in the figure, the process scheduling directory template, auxiliary device 1 directory, test device 1 directory, and test device 2 directory are placed in the folder respectively. The auxiliary device function description file is placed in the auxiliary device 1 directory; in the test device 1 directory, GOOSE function test, SV function test, IO function test, and MMS function test directories are created according to the test functions. In the GOOSE function test directory, a configuration file directory, a GOOSE function test scheme script, and a download configuration / power-off restart test scheme script are placed. In the configuration file directory, configuration files related to the GOOSE function test are placed. In the test device 2 directory, function test scheme scripts related to the test device and supporting configuration files are placed.

[0064] Step 3: The process scheduling directory template describes the auxiliary devices, test devices, and the task list contained in the devices involved in the test system in an xml format file, as Figure 3 shown; each auxiliary device or test device in the test system corresponds to a <ied>< / ied> node. The name attribute of the Ied represents the name of the device, which must be unique in the process scheduling directory template. The ipAddr attribute represents the IP address attribute of the device, the addr attribute represents the device address of the device, and the deviceType attribute represents the device type. 0 represents a test device, and 1 represents an auxiliary device. Each test task under the Ied node corresponds to a <testsuite>< / testsuite> node. The name attribute of the TestSuite node represents the name of the test task, the subPath attribute represents the test scheme path corresponding to the test task, the procesName attribute represents the process name corresponding to the test task, processNum represents the ID corresponding to the test task, and the process ID of the test task is composed of the Ied's name attribute + processNum attribute to ensure uniqueness. The processType attribute represents the type of the process. 1 represents an auxiliary process, and 0 represents a test process. The processMode attribute represents the start mode of the process. 1 represents a concurrent mode, and 0 represents a blocking mode. In this embodiment, the process scheduling directory file contains 3 Ied nodes. The first Ied node corresponds to the auxiliary device, and the second and third Ied nodes correspond to test device 1 and test device 2 respectively.

[0065] Step 4: The auxiliary device provides multiple groups of normally closed nodes, and the normally closed nodes are connected in series to the power supply circuit of the device under test. After the normally closed nodes are controlled to disconnect, they automatically close after a set broadening time. By controlling the on / off of the normally closed contacts, the on / off of the power supply circuit of the device under test can be controlled, which plays a role in controlling the automatic power-off and restart of the device under test, as Figure 4As shown; the auxiliary device provides multiple sets of output nodes to connect to the input of the device under test; the auxiliary device provides multiple sets of input nodes for monitoring the output status of the device under test; the auxiliary device can simulate the GOOSE and SV subscription messages of the device under test.

[0066] Step 5: Set up an operation stack in the auxiliary process communicating with the auxiliary device to receive operation requests sent by the test process. Each operation request is first added to the operation stack, and the operation stack adopts the first-in, first-out method, as Figure 8 shown. Regularly take an operation request from the operation stack to perform operations such as opening and closing the remote control normally closed node, sending GOOSE and SV. After the operation is completed, send the corresponding operation result to the test process through the pipeline, and take the next operation command from the stack, and loop the operation until all the command requests in the operation stack are executed, and then continue to wait for the operation requests sent by the test process.

[0067] Step 6: The automatic test scheduling control center loads the process scheduling directory template, parses the process scheduling directory template to extract the device list and the task process list under the device. The automatic test scheduling control center needs to assign a unique process ID to each task process as the identifier of the process. The automatic test scheduling control center loads the task processes under each device in turn with the device as the object, as Figure 9 shown. The following parameters need to be passed to the task process when loading the task process: pipeline server name, process ID, associated auxiliary process ID, test scheme path, test device IP address, enable list of test cases.

[0068] When the automatic test scheduling control center loads the task process, it needs to judge the type of the process. If the process type is configured as the concurrent mode, after loading the task processes of the device and receiving the information that the initialization of the task process is successful, immediately start the next task process of the device; if the type of the process is configured as the blocking mode, after loading the task processes of the device, it needs to wait for the task process to send the result of the automatic test of the corresponding test scheme after the task process is executed, and then start the next task process of the device.

[0069] If the test task process needs to use the relevant auxiliary process to apply switch quantities and other operations to the device under test through the auxiliary device, the process ID of the used auxiliary process needs to be configured in the node attributes of the test task process, and the ID number of the process is automatically generated by the automatic test scheduling control center according to the device name and the task ID. For the convenience of management, in the test system, the nodes of the auxiliary device need to be configured before the nodes of the test device, and in the test device nodes, the processes performing auxiliary tasks need to be configured before the processes performing test tasks.

[0070] Step 7: The test process is responsible for communicating with the device under test, and the auxiliary process is responsible for communicating with the auxiliary device. The test process, the auxiliary process, and the automatic test process scheduling control center communicate through pipes. The automatic test process scheduling control center acts as the server of the pipe service, and both the test process and the auxiliary process act as the clients of the pipe service, as Figure 2 shown. There is no direct information interaction between the test process and the auxiliary process. The test process first passes the keyword information - auxiliary process ID to the automatic test process scheduling control center through the pipe. The automatic test process scheduling control center looks up the corresponding auxiliary process according to the auxiliary process ID, and then forwards the keyword information - test process ID to the corresponding auxiliary process through the pipe. After the auxiliary process finishes executing the operation command, it passes the operation result to the requesting test process through the automatic test process scheduling center.

[0071] After the auxiliary process is started, it needs to execute its own initialization interface function. If the test process needs to control the auxiliary device through the auxiliary process, it must wait until the auxiliary process is initialized. Therefore, before the test process issues a control instruction through the auxiliary process, it must first request the current initialization status of the auxiliary process from the auxiliary process. If the initialization is not completed, it needs to wait for a delay and then request the current initialization status of the auxiliary device again. After obtaining the completion of the auxiliary device initialization, it can send a control instruction to the auxiliary device. If the signal indicating the completion of the auxiliary device initialization has not been received after multiple requests and the number of requests exceeds the set maximum number, the test process needs to exit the test and send an alarm message of failed initialization of the auxiliary process to the automatic test process scheduling control center.

[0072] Step 8: When the task process starts, in the main function, it first extracts the pipe server name, process ID, associated auxiliary process ID, test scenario path, test device IP address, and the enable list of test cases from the parameters, then creates a pipe client object, connects to the pipe server through the pipe server name, loads the test scenario file according to the test scenario path, creates a test task object, and sends a signal indicating that the task process initialization is complete to the automatic test process scheduling control center through the pipe client. After receiving the signal indicating the completion of the initialization sent by the test process, the automatic test process scheduling control center will send a command to start the test to the test process through the pipe server, as Figure 5 shown.

[0073] Step 9: After the test process starts the test, it will execute each test case in turn according to the test case list in the test scenario, as Figure 7As shown, when executing a test case, first extract the list of test steps included in the test case, and execute each test step in sequence. According to the name of the test step, find and execute the corresponding function interface, obtain the response result of the device, and if it meets the expectation, execute the next test step. After each test step is executed, a timer needs to be added. If the operation result response is not received after the timeout, the error message will be passed to the automatic test process scheduling control center and the test will exit. If the test step is to send input signals such as GOOSE and SV to the test device through an auxiliary device, the parameters of the test step should include the ID name of the auxiliary process associated with this test step. After all the test steps under a test case are executed, the automatic test of the next test case will be executed until all the test cases in the test plan template are executed.

[0074] When the test process executes the test cases in the test plan, it needs to upload the test process and test process information to the automatic test process scheduling control center through the pipe service. The automatic test process scheduling control center displays the execution progress of the test task process currently being executed by a certain device in real time, as well as the process information. If it is found that the actual value is inconsistent with the expected value during the test process, in addition to uploading the error message, the test process should also upload the test case number and test step number where the exception occurs. The automatic test process scheduling control center needs to display the current test progress of the test process and the test step number where the exception occurs. If there are test processes of multiple devices executing test tasks, the automatic test process scheduling control center displays the test process information uploaded by the test process classified by the device name.

[0075] The test plan template includes a list of test cases corresponding to a certain type of function of the device under test and test parameters. Each test case consists of multiple test steps. The test step corresponds to the atomic operation behavior of the test operation. The name of the test step must be consistent with the keyword of the atomic operation behavior in the test case process. Each atomic operation behavior in the test case process corresponds to a fragment of function interface code. The format of the test plan is as Figure 6 shown.

[0076] The test process summarizes the supported test steps into a test step template list. When editing the test plan, select test steps from the test step template list according to the test requirements of the test case to form a test case that can be automatically executed by the test process, and combine the test cases of a certain type of function or service into a test plan template. In the test plan template, the parameters that need to be set for the test case and are related to the test environment need to be extracted and placed under a separate common parameter node. When editing the test plan templates of different test devices in different test environments, there is no need to write from scratch, just modify the corresponding parameters under the common parameter node, which can improve the editing efficiency and maintainability of the test plan template.

[0077] Step 10: If the device under test needs to replace the configuration file or power off and restart during the test, it is necessary to add a test task for downloading the configuration file under the corresponding device node in the process scheduling directory and place the relevant configuration files in the specified directory, such as Figure 10 shown. At the same time, the device under test needs to have a normally closed output node: the normally closed node is in the closed state when the device loses power, and the normally closed node is in the open state when the device is running normally. The input node of the auxiliary device is connected to the output node of the device under test, and the auxiliary device can judge the running state of the corresponding device under test by monitoring the state of the input node of this device.

[0078] After the test process for downloading the configuration file runs, first set the variable for controlling maintenance to 1 through the connection protocol with the device under test to make the device in the maintenance state, and then use the protocol for downloading files to download the configuration file to be downloaded configured in the test plan for downloading the configuration file to the specified board and directory of the device to be tested. After the download is completed, the test process for downloading the configuration file requests the auxiliary process to control the disconnection of the specified normally closed node through the pipe server to power off and then restart the device after power on. When the auxiliary process judges that the device under test has restarted and is running normally by monitoring the state of the specified input node of the auxiliary device, it notifies the test process for downloading the configuration file of the result through the pipe. After receiving the result of successful device restart, the test process for downloading the configuration file performs the next operation.

[0079] Step 11: After all the test cases in the test plan template loaded by the test process are executed, the test process sends a test completion signal and the statistical information on the passing situation of the executed test cases to the automatic test process scheduling control center through the pipe service. After receiving the test completion signal, the automatic test process scheduling control center generates the corresponding test report according to the test report template, and sends a process exit command to the corresponding test process through the pipe service to exit the test process. Find the device node to which it belongs according to the process ID, start the next test task process of the device node, and repeat Step 8 until all the test tasks under the device node are executed. When all the test tasks under all the devices in the process scheduling directory template are executed, the automatic test process scheduling control center prompts that all the test tasks in the test system have been executed, and notifies all the auxiliary processes and test processes that have not exited to exit the operation.

Claims

1. An automatic test system for secondary equipment of a power system, characterized in that, It includes: An automatic test process scheduling control center for task process loading and unloading, information forwarding between processes, test process information display, and automatic test report export; A test scheme module, including a process scheduling directory template and a test scheme template. The process scheduling directory template configures a task process list with devices as objects, and the test scheme template contains test cases and parameters; An execution process module, including an auxiliary process and a test process. The auxiliary process communicates with auxiliary devices, and the test process communicates with the device under test; Auxiliary devices that provide multiple groups of normally closed nodes to control the power on / off of the device under test, connect the output nodes and input nodes to the device under test, and support the simulation of GOOSE and SV messages; The device under test is a secondary device of the power system to be tested.

2. The automatic test system according to claim 1, wherein The process scheduling directory template is an XML format file, including: At least one device node, whose attributes include device name, IP address, and device type; At least one test task node is configured under each device node, and its attributes include test task name, test scheme path, process type, and start mode.

3. The automatic test system according to claim 1, characterized in that The auxiliary devices include: Multiple groups of normally closed nodes are connected in series in the power supply circuit of the device under test, and the device is powered off and restarted by automatically closing after disconnection; Multiple groups of output nodes are connected to the inputs of the device under test, and multiple groups of input nodes monitor the output states of the device under test; GOOSE and SV message simulation functions for injecting subscription signals into the device under test.

4. The automatic test system according to claim 1, wherein The automatic test process scheduling control center communicates with the test process and the auxiliary process through a pipe service. Among them: the test process and the auxiliary process do not directly interact, and requests and results need to be forwarded through the control center; the control center assigns a unique process ID to each task process and supports concurrent or blocking start modes.

5. The automatic test system according to claim 1, characterized in that, In the test scheme template: The test case consists of multiple test steps, and the test step names are the same as the atomic operation keywords of the test process; The common parameter node stores configurable parameters related to the environment.

6. The automatic test system according to claim 1, wherein The auxiliary process includes an operation stack module for receiving operation requests from the test process and executing them in a first-in, first-out order; returning operation results to the test process through a pipe and processing requests in the stack in a loop.

7. An automatic testing method for secondary equipment of a power system, characterized in that, It includes the following steps: (1) The automatic test process scheduling control center loads the process scheduling directory template and parses the device list and corresponding test tasks; (2) Assign a unique process ID to each test task and start the corresponding auxiliary process and test process in the order of devices; (3) The test process loads the test scheme template and sequentially executes multiple atomic operation steps in the test case; (4) When the test step requires an operation of the auxiliary device, forward the operation request to the corresponding auxiliary process for execution through the pipe service; (5) Real-time monitor the execution status of each test step and perform error handling on operations that do not respond in time; (6) Automatically generate a test report after the test is completed and exit the relevant processes; (7) When it is necessary to replace the configuration file of the device under test, control the auxiliary device to perform a power-off and restart operation on the device; (8) After monitoring the device status and confirming a successful restart, continue to execute the subsequent test steps.

8. The automatic test method according to claim 6, wherein When the test process executes the test steps, if the operation of auxiliary equipment is required, it first queries the initialization status from the corresponding auxiliary process, and then sends an operation instruction after confirming that the initialization is completed.

9. The automatic test method according to claim 6, characterized in that The pipeline service described in step 4 works in the following way: The test process sends a request containing the auxiliary process ID to the automatic test process scheduling control center; The control center forwards the request to the corresponding auxiliary process; After the auxiliary process finishes execution, it returns the result to the test process through the control center.

10. The automatic test method according to claim 6, characterized in that, Step 7 specifically includes: setting the device under test to the maintenance state; downloading the configuration file to the specified directory through the communication protocol; controlling the auxiliary equipment to perform a power-off restart operation; and monitoring the output node status of the device to confirm the completion of the restart.

Images