A patrol system and an automated simulation test method thereof

Abstract

The application relates to a patrol system and an automatic simulation test method thereof, and belongs to the technical field of power systems. According to a target business scene in a to-be-tested patrol system, a test case library of the target business scene is determined. Each test case in the test case library is traversed, and simulation test is performed according to each test case. During the simulation test, test results of each test case are obtained according to test interaction data. According to the test results of all the test cases, a test report of the target business scene in the to-be-tested patrol system is generated, and integrated simulation test of a full business process of the patrol system from data collection, intelligent analysis to task scheduling is realized.

Description

Technical Field

[0001] This invention relates to an inspection system and its automated simulation testing method, belonging to the field of power system technology. Background Technology

[0002] With the continuous development of smart grid technology, the use of intelligent equipment such as inspection robots, drones, and high-definition video systems to replace or assist manual labor in substation inspections has become a trend. These intelligent devices work in conjunction with remote intelligent inspection systems for substations, realizing the automation and intelligence of substation operation and maintenance. However, before the inspection system is officially put into operation, it must undergo thorough and rigorous testing to verify its functionality, performance, and reliability.

[0003] Existing inspection system testing technologies generally suffer from the following prominent problems: 1. Insufficient test coverage, making it difficult to achieve full business process verification. That is, during the testing process, many hidden "vulnerabilities" are only exposed when data jumps between systems, and existing inspection systems cannot be linked with other systems (such as production management systems and fault repair systems); 2. Low simulation realism, making it difficult to reproduce special and abnormal working conditions, such as extreme environmental interference and extreme electromagnetic / communication anomalies; 3. Low level of automation and intelligence, resulting in low testing efficiency and strong subjectivity. That is, existing inspection systems still require tester intervention and lack a unified automated evaluation script; 4. Lack of long-term, continuous, and extreme testing capabilities.

[0004] In summary, existing technologies lack a testing scheme for inspection systems that can achieve full-link coverage, high-fidelity simulation, and high automation, especially for substation inspection systems. This has become a key bottleneck restricting the large-scale promotion and application of intelligent inspection technology. Summary of the Invention

[0005] The purpose of this invention is to provide an inspection system and its automated simulation testing method to solve the problems of insufficient test coverage, low simulation realism, and low testing efficiency of existing inspection systems (such as substation inspection systems).

[0006] To address the aforementioned technical problems, the first aspect of this invention provides an automated simulation testing method for an inspection system, comprising the following steps: 1) Determine the test case library for the target business scenario based on the target business scenario in the inspection system under test; 2) Traverse each test case in the test case library and execute simulation tests for each test case. During simulation testing, obtain the test results for each test case based on the test interaction data. 3) Based on the test results of all test cases, generate a test report for the target business scenario in the inspection system under test.

[0007] In one possible implementation, when the simulation test is an uplink data stream test, the response message returned by the system under test after receiving the simulated uplink data is monitored and captured. The response message is compared with the predefined expected response model in the corresponding test case; If the comparison is consistent, the uplink data processing function of the inspection system under test is normal in the corresponding test case; If the comparison is inconsistent, a problem summary record will be generated.

[0008] In one possible implementation, the response message includes any one of the following: acknowledgment of receipt, processing result, error code, and database update notification.

[0009] In one possible implementation, the problem summary record includes any of the following: the identifier of the failed test case, the content of the sent uplink simulation data, the actual return message of the SUT, the difference analysis from the expected model, the failure timestamp, and any preliminary inference of possible causes of failure.

[0010] In one possible implementation, when the simulation test is a downlink data stream test, downlink control commands issued by the inspection system under test are received and captured; Automatically compare downlink control command messages with predefined control messages in the corresponding test cases; If the comparison is consistent, then perform task control testing; If the comparison is inconsistent, the control command is determined to be correct, and a problem summary record is generated when the control command is incorrect.

[0011] In one possible implementation, after the task control test is performed, it is also determined whether there are any failed items in the task control process. If there are failed items, the failed items are retested until all items have been tested.

[0012] In one possible implementation, when there are no failed items, a response message is returned and a test report is generated.

[0013] In one possible implementation, test resources are released in response to the completion of test execution.

[0014] To address the aforementioned technical problems, a second aspect of the present invention provides an inspection system, including a processor, which executes a computer program to implement the steps of the method described below: 1) Determine the test case library for the target business scenario based on the target business scenario in the inspection system under test; 2) Traverse each test case in the test case library and execute simulation tests for each test case. During simulation testing, obtain the test results for each test case based on the test interaction data. 3) Based on the test results of all test cases, generate a test report for the target business scenario in the inspection system under test.

[0015] In one possible implementation, when the simulation test is an uplink data stream test, the response message returned by the system under test after receiving the simulated uplink data is monitored and captured. The response message is compared with the predefined expected response model in the corresponding test case; If the comparison is consistent, the uplink data processing function of the inspection system under test is normal in the corresponding test case; If the comparison is inconsistent, a problem summary record will be generated.

[0016] In one possible implementation, the response message includes any one of the following: acknowledgment of receipt, processing result, error code, and database update notification.

[0017] In one possible implementation, the problem summary record includes any of the following: the identifier of the failed test case, the content of the sent uplink simulation data, the actual return message of the SUT, the difference analysis from the expected model, the failure timestamp, and any preliminary inference of possible causes of failure.

[0018] In one possible implementation, when the simulation test is a downlink data stream test, downlink control commands issued by the inspection system under test are received and captured; Automatically compare downlink control command messages with predefined control messages in the corresponding test cases; If the comparison is consistent, then perform task control testing; If the comparison is inconsistent, the control command is determined to be correct, and a problem summary record is generated when the control command is incorrect.

[0019] In one possible implementation, after the task control test is performed, it is also determined whether there are any failed items in the task control process. If there are failed items, the failed items are retested until all items have been tested.

[0020] In one possible implementation, when there are no failed items, a response message is returned and a test report is generated.

[0021] In one possible implementation, test resources are released in response to the completion of test execution.

[0022] The beneficial effects of this invention are as follows: Based on the target business scenario in the inspection system under test, a test case library for the target business scenario is determined; each test case in the test case library is traversed, and simulation testing is performed according to each test case. During the simulation test, the test results of each test case are obtained based on the test interaction data; based on the test results of all test cases, a test report of the target business scenario in the inspection system under test is generated, thereby realizing integrated simulation testing of the entire business process of the inspection system from data collection and intelligent analysis to task scheduling. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the automated simulation testing process of upstream data in a substation application scenario, based on an automated simulation testing method for an inspection system proposed in this invention. Figure 2 This is a flowchart illustrating the automated simulation testing process of downlink data in a substation application scenario, based on the automated simulation testing method for an inspection system proposed in this invention. Figure 3 This is a structural diagram of a patrol system proposed in this invention in a practical application scenario; Figure 4 This is a schematic diagram of the logical flow within a patrol business simulation unit of a patrol system proposed in this invention in a practical application scenario; Figure 5 This is a schematic diagram of the logical flow within the task execution management unit of a patrol system proposed in this invention in a practical application scenario. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0025] The inventive concept of this invention lies in addressing the lack of full-link coverage, high-fidelity simulation, and highly automated inspection system testing in existing technologies. This invention provides integrated simulation testing of the entire business process of the inspection system, including data acquisition, intelligent analysis, and task scheduling; it accurately simulates special inspection scenarios (such as partial discharge detection and maintenance avoidance) in the tested area (such as substations) and the complex uplink and downlink command and data interactions with on-site inspection equipment (robots, drones); it automatically verifies the consistency between command issuance and data reporting, replacing manual judgment, improving testing efficiency and accuracy, meeting batch testing requirements, achieving full-link functional coverage, improving the realism of scenario simulation, and realizing automated verification.

[0026] Detailed implementation method 1: Preferably, the automated simulation testing method for an inspection system proposed in this invention includes the following steps (1) to (5): (1) Test environment configuration steps: Configure the network parameters and access credentials of the inspection system under test, and select the business scenario to be tested. It should be noted that the same inspection system contains multiple different business scenarios, and the combination of devices called, inspection routes, and photo parameters are different for each business scenario.

[0027] (2) Simulation data construction steps: Based on the selected business scenario, construct or load the corresponding simulation data sample library and equipment behavior model.

[0028] (3) Automated test-driven steps: a. Based on the simulation data sample library and equipment behavior model of the selected business scenario, start the simulation operation to generate simulated uplink and downlink data streams and command streams.

[0029] b. During the simulation operation, capture all interactive data between the tested inspection system and the simulation module in real time.

[0030] (4) Interaction logic verification steps: The real-time captured interaction data is automatically compared with the pre-trained interaction logic model to verify its compliance.

[0031] (5) Test report generation steps: Integrate all verification results and process data to automatically generate a detailed test analysis report of the tested inspection system.

[0032] Through steps (1) to (5) above, the testing of the complete business chain of data collection, analysis, and task management is integrated with the instruction interaction testing between modules, solving the problems of traditional test block segmentation and incomplete coverage, and realizing full-chain coverage, high-fidelity simulation, high automation, and accurate matching standards: High-fidelity simulation: By constructing a precise "digital twin" simulation environment, it is possible to reproduce special scenarios and abnormal operating conditions that are difficult to simulate using traditional methods, making the test results closer to actual operation and effectively exposing potential problems.

[0033] High degree of automation: It realizes full-process automation from test case execution to result analysis and judgment, especially the automatic verification of the consistency of complex command interaction, which greatly improves the testing efficiency and objectivity, and provides quality assurance for the large-scale deployment of the inspection system.

[0034] Precise matching standards: The system design strictly follows the relevant standards for substation automation systems, ensuring the standardization and universality of testing.

[0035] Method Detailed Implementation 2: The following section explains the automated simulation testing method for an inspection system proposed in this invention, starting from the application scenario of substations. Specifically, for substations, the following settings are implemented: 1) a maintenance point avoidance mechanism in the substation; 2) partial discharge detection audio recognition (secondary judgment); 3) full-process simulation coverage of multiple data types (infrared / visible light / video / audio); 4) simulation of abnormal alarms from inspection devices. These settings enhance the realism and coverage of the test, accurately verifying the robustness of the substation under special operating conditions. The specific process includes the following steps: When testing substations, data flow is divided into two types: uplink data and downlink data. The uplink data generation process is as follows: the inspection device actively reports data to the inspection host. Here, the inspection device includes, but is not limited to, various types such as robot and / or drone inspection modules. Robots and drones are two different inspection devices, but they use the same transmission protocol and have no essential difference. Preferably, in this specific embodiment, the inspection device is a robot and drone inspection module.

[0036] After receiving the reported data, the inspection host sends a response message to the robot and drone inspection module. The process of generating downlink data is as follows: the inspection host actively initiates a control request to the robot and drone inspection module, and after receiving the control request, the robot and drone inspection module executes the corresponding action and sends a response message to the inspection host.

[0037] Different test methods were established for different types of data streams. The specific flow of each type of data stream and its test method is as follows. It should be noted that when the System Under Test (SUT) performs automated simulation testing of its uplink data reception and processing functions, the business simulation core module is driven by the test flow control module.

[0038] like Figure 1 The diagram shows the automated simulation test flowchart of the inspection system's uplink data in a substation application scenario, as proposed in this invention. It includes steps 1 through 10, specifically: Step 1 Test Initialization: The test process control module starts a specific test task, allocates resources for uplink data testing, and initializes the logging system; this step ensures that the test environment is in a ready state.

[0039] Step 2: Automatic Simulation Environment Construction: The core business simulation module automatically loads or generates the required simulation environment parameters and data models based on test case requirements (here, test case requirements refer to a set of strict, quantifiable input conditions, operation steps, environmental states, and their results pre-defined during the testing process to verify characteristic business functions, performance indicators, or reliability boundaries). This includes: equipment models of the substation under test, a simulated inspection point library, a simulation data sample library (such as images, audio, video, numerical results, etc.), and configuration of the communication link with the SUT.

[0040] Step 3: Select Upstream Data Test Cases: The test flow control module selects one or more test cases for the upstream data stream from the test case library. Each test case for the upstream data stream defines: Simulated data types include: visible light images, infrared temperature measurement data, partial discharge detection audio reported by simulated robots, or video streams directly uploaded by simulated cameras.

[0041] Data content and format: Correct data that conforms to the protocol specifications, or incorrect data used for anomaly testing (such as incomplete data packets, excessive values, incorrect formats, etc.).

[0042] Expected outcome: The SUT should respond correctly upon receiving correct / incorrect data, such as correctly parsing the stored data or accurately alerting and discarding it.

[0043] Step 4: Start Automated Testing: The test process control module drives the business simulation core module to start executing tests. Based on the selected test cases, the business simulation core module simulates one or more data acquisition sources (such as robots or drones) and actively sends simulated uplink data packets to the SUT.

[0044] Step 5: Receiving the response message: The interactive consistency verification module listens for and captures the response message returned by the SUT after receiving the simulation uplink data in real time. This message may be an acknowledgment of receipt, processing result, error code, or database update notification, etc.

[0045] Step 6: Determine if the returned message is correct: The interaction consistency verification module automatically compares the actual received SUT returned message with the predefined expected response model in the test case.

[0046] Judgment result: If the returned message is correct (i.e., consistent with the expected model in logic and timing), it indicates that the SUT's uplink data processing function is normal and the process proceeds to step 9; if the returned message is incorrect or there is no response (timeout), it indicates that there is a defect in the SUT function and the process proceeds to step 7.

[0047] Step 7: Generate Issue Summary: When a test fails, generate a detailed issue summary record. The record includes: the identifier of the failed test case, the content of the sent uplink simulation data, the actual return message from the SUT, the difference analysis from the expected model, the failure timestamp, and a preliminary inference of possible causes of failure.

[0048] Step 8: Determine if failed items need to be retested: After the current test is completed, the system checks whether there are any previously failed test cases in the entire test task queue.

[0049] Determining the outcome: If the project needs to be retested, proceed to step 4 to prepare to re-execute these tests to confirm whether the problem is intermittent or permanent; if the project does not need to be retested, proceed to step 9 to prepare to generate the final report.

[0050] Step 9: Generate a test report Once all test cases (including retest cases) have been executed, the test report generation module automatically aggregates the data from the entire testing process (including the number of pass / fail test cases, issue summary, performance metrics, timing logs, etc.) to generate a structured and detailed test analysis report.

[0051] Step 10: Test complete After the test process control module confirms the report is generated, it releases the test resources, and the automated simulation test of the uplink data officially ends.

[0052] Through the above, automated simulation testing of all uplink data test cases can be achieved.

[0053] like Figure 2 The diagram shows the automated simulation test flowchart for downlink data in a substation application scenario, based on the automated simulation test method for an inspection system proposed in this invention. The flowchart includes steps 1 to 15, specifically: Step 1 Test Initialization: The test process control module starts the downlink command test task, allocates resources for downlink data testing, and initializes the logging system; this step ensures that the test environment is in a ready state.

[0054] Step 2: Automatically build the simulation environment: The core business simulation module automatically loads or generates the required simulation environment parameters and data models according to the test case requirements. This includes: the equipment model of the substation under test, the simulated inspection point library, the simulation data sample library (such as images, audio, video, numerical results, etc.), and the configuration of the communication link with the SUT.

[0055] Step 3: Select Downlink Data Use Case The test process control module selects one or more downlink data test cases from the test case library. Each downlink data test case is explicitly defined as follows: Downlink commands include commands such as "robot body moves forward", "turn on visible light camera", "execute equipment operation (such as turn on the lights)", and "one-click return".

[0056] Command format: Correct commands that conform to the protocol specifications, or illegal commands used for negative testing (such as commands with out-of-bounds parameters, verification errors, or commands with unexpected timing).

[0057] Expected behavior: The correct response and behavior that the SUT should have upon receiving the instruction, such as executing it immediately, returning an acknowledgment message, or refusing to execute it and returning an error code.

[0058] Step 4: Start Automated Testing: The test process control module drives the business simulation core module to begin executing the test. The SUT issues the selected downlink control command.

[0059] Step 5: Receive downlink control commands This step specifically refers to the test system itself (through the interactive consistency verification module) receiving and capturing the downlink control command issued by the SUT; this message is the primary basis for determining whether the command has been correctly received and processed.

[0060] Step 6: Determine if the instruction is a task control instruction. The core module of business simulation automatically compares the downlink control command messages issued by the SUT with the predefined control messages in the test cases.

[0061] Judgment result: If it is a task control instruction, the test process control module directly calls the task execution management unit to make a task control judgment, and the process proceeds to step 11.

[0062] If it is not a task control instruction, the test flow control module calls the instruction response simulation unit, and the process proceeds to step 7.

[0063] Step 7: Determine if the instruction is correct: The interactive consistency verification module automatically compares the actual received SUT control message with the predefined expected model in the test case.

[0064] Judgment result: If the returned message is correct (i.e., consistent with the expected model in logic and timing), it indicates that the SUT's downlink data processing function is normal and the process proceeds to step 8; if the returned message is incorrect, it indicates that the SUT function has a defect and the process proceeds to step 9.

[0065] Step 8: Return response message: The instruction response unit sends a return response message to the SUT. After completion, the process proceeds to step 14.

[0066] Step 9: Generate Issue Summary. When a test fails, the system automatically generates a detailed issue summary record. The record includes: the identifier of the failed test case, the content of the sent uplink simulation data, the actual return message from the SUT, the difference analysis from the expected model, the failure timestamp, and a preliminary inference of possible causes of failure.

[0067] Step 10: Determine if failed items need to be retested: After the current test is completed, the system checks whether there are any previously failed test cases in the entire test task queue.

[0068] Result: If the project needs to be retested, proceed to step 4 to prepare to re-execute these tests to confirm whether the problem is intermittent or permanent; if the project does not need to be retested, proceed to step 14 to prepare to generate a test report.

[0069] Step 11: Invoke the task control management process: When the SUT issues a task control instruction, the task execution management unit is invoked to perform task control testing. Refer to the task execution management unit process in the specific implementation method 3 of the system for the process; after the process is completed, proceed to step 12.

[0070] Step 12: Determine if there are any failed items in the task control process.

[0071] Judgment result: If there are failed items, the process proceeds to step 13 to check whether the failed items need to be retested; if there are no untested items, the process proceeds to step 14 to prepare to generate a test report.

[0072] Step 13: Determine if failed items need to be retested: After the current test is completed, the system checks whether there are any previously failed test cases in the entire test task queue.

[0073] Determine the outcome: If the project needs to be retested, proceed to step 11 to prepare to re-execute these tests to confirm whether the problem is intermittent or permanent; if the project does not need to be retested, proceed to step 14 to prepare to generate the final report.

[0074] Step 14: Generate a test report Once all test cases (including retest cases) have been executed, the test report generation module automatically aggregates the data from the entire testing process (including the number of pass / fail test cases, issue summary, performance metrics, timing logs, etc.) to generate a structured and detailed test analysis report.

[0075] Step 15: Test complete After the test process control module confirms the report is generated, it releases the test resources, and the automated simulation test of the uplink data officially ends.

[0076] Through the above, automated simulation testing of all downlink data use cases can be achieved.

[0077] System Specific Implementation Method 1: The preferred inspection system proposed in this invention includes a test process control module, a business simulation core module, an interaction consistency verification module, and a test report generation module.

[0078] The test process control module serves as the control center of the inspection system, managing the lifecycle of test cases and possessing functions such as automatic generation of test cases, scheduling and execution control of test tasks, and preliminary aggregation of test results.

[0079] The core module of the business simulation is used to simulate the external interactive environment and object behavior of the substation inspection system with high fidelity. It mainly achieves high fidelity simulation of the external environment through the collaboration of four units: environmental data simulation unit, inspection business simulation unit, task execution management unit, and abnormal working condition injection unit. The system comprises an environmental data simulation unit, an inspection operation simulation unit, a task execution management unit, and an abnormal condition injection unit. The environmental data simulation unit simulates the substation's on-site environmental data and the status data of the inspection devices (including various types such as inspection robots and drones, all sharing the same transmission protocol), and responds to data acquisition requests from the tested inspection system. The inspection operation simulation unit simulates the entire process of executing an inspection task, such as receiving inspection task instructions, parsing task content, simulating the generation and uploading of various inspection data generated during task execution. The task execution management unit receives inspection tasks issued by the substation inspection system, parses the task content, and uploads the corresponding inspection equipment coordinates, inspection routes, task status, and inspection results to the substation inspection system according to different locations. The abnormal condition injection unit actively simulates communication interruptions, instruction loss, and data anomaly failure scenarios to verify the robustness of the tested system.

[0080] The interaction consistency verification module is used to monitor and capture all communication interactions between the business simulation core module and the substation inspection system under test in real time. It is configured to automatically verify the logical consistency and timing compliance between downlink commands and uplink data based on predefined business rules.

[0081] The test report generation module is used to automatically aggregate all logs, performance indicators and verification results generated during the test process, automatically generate structured test reports based on predefined rules, clearly identify the continuity status of test items and provide diagnostic conclusions.

[0082] System Specific Implementation Method 2: Following the specific implementation method 1 of the system described above, the patrol operation simulation unit is further configured as follows: The system initializes and loads a preset inspection point model; it iterates through each point in the inspection point model; for the current point, it reads the value of its acquisition file type field and enters different processing branches based on the value: if it is an infrared image, it calls the preset infrared spectrum sample library; if it is visible light, it calls the preset visible light sample library; if it is video, it calls the preset video sample library; if it is audio, it further extracts the value of the identification type field of the point for secondary judgment: if the identification type is partial discharge detection, it calls the partial discharge detection dedicated audio sample library, otherwise it calls the ordinary audio sample library; finally, the simulation data obtained from the corresponding sample library and the metadata of the point are encapsulated to construct a standard format simulation sample and output it.

[0083] The task execution management unit is further configured to: receive inspection task instructions issued by the inspection system of the substation under test; The system checks the correctness of the task instruction message. If incorrect, it generates a problem summary and terminates the process. If correct, it parses the inspection point information. It iterates through each point included in the inspection task. It checks if the current point exists within the maintenance area. If it does, it temporarily removes or ignores the maintenance point from the current inspection task sequence. For normal points that are not under maintenance, it sequentially sends the inspection route, inspection coordinates, status, and inspection results for the current task. After each sending action, it receives and judges the return message from the substation inspection system. If the return message is incorrect, it generates a problem summary. If correct, it marks the test item for that point as passed. After all points have been processed, it summarizes the test items and generates a task execution report.

[0084] The verification of the interaction consistency verification module includes automated simulation testing of uplink data and automated simulation testing of downlink data; The automated simulation test for uplink data includes: a business simulation core module simulating a data acquisition source and actively sending simulated uplink data packets to the system under test; an interaction consistency verification module capturing the response packets returned by the system under test and automatically comparing them with the predefined expected response model in the test cases; the automated simulation test for downlink data includes: a test process control module inducing the system under test to actively generate and issue control commands; a business simulation core module receiving the commands, simulating the controlled device to execute and generate simulated response packets; and an interaction consistency verification module capturing the original commands and simulated response packets issued by the system under test and automatically comparing them to verify their logical and timing relationships.

[0085] System Implementation Method 3: The following description, in conjunction with the accompanying drawings, explains the inspection system proposed in this invention.

[0086] like Figure 3 The diagram shown illustrates the structure of a patrol system proposed in this invention in a practical application scenario. The system includes: a test process control module, a business simulation core module, an interaction consistency verification module, and a test report generation module. Specifically: Test process control module: As the system's central controller, it receives user test commands or initiates test tasks according to a pre-defined plan. This module is responsible for parsing test requirements, forming specific test case sequences, and sequentially scheduling the corresponding units in the business simulation core module for execution. Finally, it controls the test report generation module to output the corresponding test report. It controls the rhythm (start, pause, stop) and logical loop of the entire test process.

[0087] The core module of business simulation is the "specific executor" of the simulation behavior. According to the scheduling of the test process control module, it calls one or more of the following units to simulate the real environment: Environmental data simulation unit: It is configured to simulate the environmental data of the substation site and the status data of the inspection device itself, and respond to the data acquisition requests of the system under test.

[0088] The patrol operation simulation unit is configured to simulate the entire process of performing patrol tasks, including: receiving patrol task instructions, parsing task content, simulating the generation and uploading of various patrol data generated during task execution (such as visible light images, infrared spectra, audio, video and partial discharge analysis data).

[0089] Task Execution Management Unit: Receives inspection tasks issued by the substation inspection system, parses the task content, and then sends the corresponding inspection equipment coordinates, inspection route, task status, and inspection results to the substation inspection system according to different locations.

[0090] Abnormal operating condition injection unit: It is configured to actively simulate fault scenarios such as communication interruption, instruction loss, and data anomaly in order to verify the robustness of the system under test.

[0091] Command Interaction Verification Module (i.e., Interaction Consistency Verification Module): This module monitors and captures all command and data interactions between the inspection device simulation module and the inspection system under test in real time. It is configured to automatically compare the logical consistency and timing relationship between downlink commands (such as from the inspection system to the inspection device) and uplink data (such as from the inspection device to the inspection system). For example, it verifies whether the inspection system can correctly handle logical relationships when it receives a message with an incorrect transmission sequence number.

[0092] The results analysis and report module (also known as the test report generation module) automatically collects all data generated during the test, including instruction interaction logs (instruction content, data content, timestamps, and exception information), the accuracy of simulated data, and abnormal test results. Based on predefined rules and thresholds, it automatically generates structured test reports, clearly identifies successful and failed items, and provides preliminary diagnostic suggestions.

[0093] like Figure 4 The diagram shown illustrates the logical flow within a patrol business simulation unit of the patrol system proposed in this invention, in a practical application scenario. The specific implementation steps of the patrol business simulation unit are as follows: Step 1: System Initialization and Model Loading: The inspection data simulation unit starts and loads the preset "inspection point model" from the configuration file or database. This model contains all the equipment point information to be simulated. Each point has predefined key attribute fields, mainly including: point unique identifier (ID), equipment name, acquisition file type, identification type, etc.

[0094] Step 2: Iterate through the inspection points in a loop: The unit enters the loop control logic and processes each point in the inspection point model sequentially. Iterators or loop statements are used to ensure that each point is processed exactly once, until all points have been traversed.

[0095] Step 3: Extract and determine the type of collected files: For the currently being processed inspection point, read the value of its "Collection File Type" field. Based on the value of this field, proceed to different processing branches: If it is an "infrared image": proceed to step 4 (A); if it is "visible light": proceed to step 4 (B); if it is "video": proceed to step 4 (C); if it is "audio": proceed to step 4 (D).

[0096] Step 4: Call the corresponding sample library (multi-path branching) Branch A (Infrared Image): Directly calls the preset infrared image sample library. This sample library contains simulated infrared thermal images and their temperature data of various devices under different operating conditions.

[0097] Branch B (Visible Light): Directly calls the preset visible light sample library. This sample library contains visible light images of simulated meter readings, device appearance, indicator status, etc.

[0098] Branch C (Video): Directly calls the preset video sample library. This sample library contains dynamic video data such as simulated equipment operation processes.

[0099] Branch D (Audio): This is the key decision point. The process does not directly call the audio sample library, but first executes step five.

[0100] Step 5: Secondary determination of audio type (core logic) Once the file type is determined to be "audio", the unit further extracts the value of the "recognition type" field for that location.

[0101] Secondary branch judgment: If the value of the "Identification Type" field is partial discharge detection type, the process proceeds to step 6 (A) and calls the dedicated sample library; otherwise (i.e., the "Identification Type" is other values), the process proceeds to step 6 (B) and calls the general sample library.

[0102] Step 6: Call the audio sample library (final branch) Branch A (Partial Discharge Detection): Calls a dedicated audio sample library for partial discharge detection. This library stores characteristic audio signals (such as buzzing and crackling sounds) of partial discharge in simulated transformers, circuit breakers, and other equipment.

[0103] Branch B (Normal Audio): Calls the normal audio sample library. This library stores simulated ambient noise, the humming sound of equipment running normally, etc.

[0104] Step 7: Constructing simulation samples: Regardless of which branch path is taken, the unit will eventually encapsulate the simulation data (such as images, video file paths, audio data streams, structured data, etc.) obtained from the corresponding sample library with the metadata of the point (point ID, equipment information, timestamp, etc.) to construct a simulation sample in a standard format.

[0105] Output: This simulation sample is the simulated inspection data that can be identified and processed by the substation inspection system.

[0106] Step 8: Loop Judgment and End: After completing the construction of the simulation sample for the current point, the unit judges whether there are any unprocessed points in the inspection point model; if there is a next point, the process returns to step 2 and continues to process the next point; if all points have been processed, the entire process ends and the inspection data simulation unit enters standby state.

[0107] like Figure 5 The diagram shown illustrates the logical flow within the task execution management unit of the patrol system proposed in this invention in a practical application scenario. The specific implementation steps of the task execution management unit are as follows: Step 1: Accepting the Inspection Task: The task execution management unit receives the inspection task instruction issued by the inspection system of the substation under test through the communication interface. This instruction includes information such as the task ID, task type (e.g., routine inspection, special inspection), and a list of points to be inspected.

[0108] Step 2: Determine if the message is correct: The unit parses and verifies the received task instruction message, checking its format integrity and protocol compliance.

[0109] Result assessment: If the message is incorrect or cannot be parsed, the process proceeds to step 3, generates a problem summary, records the error type (such as checksum error, data length mismatch, etc.), and terminates the current task processing flow. If the message is correct, the process proceeds to step 4 for further processing.

[0110] Step 3: Generate a problem summary: Record the error types and error messages.

[0111] Step 4: Parse the inspection point information: Extract detailed inspection point information from the correct task instruction message. Each point's information includes, but is not limited to: unique point ID, device type, device name, data type to be collected (e.g., visible light, infrared, audio), and preset location information.

[0112] Step 5: Traverse the points included in the inspection task: The unit enters the loop control logic and processes each point included in the inspection task in turn.

[0113] Step 6: Determine if there are maintenance points: For the currently being inspected points, the unit queries the system's preset maintenance area configuration information.

[0114] Judgment result: If the current location is within the maintenance area, the process proceeds to step 7. If the current location is not a maintenance location, the process proceeds to step 8, and the normal inspection process is executed.

[0115] Step 7: Remove the maintenance point from the test task: Temporarily remove or ignore the current maintenance point from the current inspection task sequence. This means that the robot or related data acquisition equipment will not go to this point to perform inspections, thus automatically avoiding the risk area and complying with safety procedures. After completion, the process proceeds to step 6.

[0116] Step 8: Submit the inspection route for this task: For non-maintenance, normal locations, the unit first submits the overall inspection route map planned for completing this task to the substation inspection system. This allows the inspection system to have a macroscopic understanding of the robot's expected movement path.

[0117] Step 9: Upload the inspection coordinates of the point: The unit uploads the precise coordinate information of the current point (such as coordinates in the station coordinate system or the orientation relative to a specific device) to the inspection system, and displays the real-time accurate location information of the inspection equipment (such as a robot).

[0118] Step 10: Upload the status of the location: The unit uploads the current location's patrol task status information (such as patrol task status, patrol task progress, and other simulated data) to the patrol system to provide context for subsequent data analysis.

[0119] Step 11: Upload the inspection results for this location: The inspection business simulation unit uploads the generated simulated inspection result data (such as simulated instrument reading images, infrared spectra, equipment appearance photos, etc.) to the inspection system.

[0120] Steps 12-14: Receiving and Judging Return Messages: After each upload action in steps 8-11, the unit will synchronously receive a return message or response from the substation inspection system. The unit will judge each return message (steps 12, 13, 14): If the return message is correct, it indicates that the interaction in this step was successful, and the process continues to step 15. If any return message is incorrect or there is no response, the process will return to step 3, generate a problem summary, and record the points and reasons for the interaction failure.

[0121] Step 15 Test Item: Successfully complete all the predetermined interaction steps (route, coordinates, status, result submission and response verification) for the current location, and mark the test item for this location as passed.

[0122] Step 16: Determine if there are any other points: After processing the current point, the unit determines whether there are any unprocessed points in the patrol task list.

[0123] Result: If a next point exists, the process returns to step 5 to continue processing the next point. If all points have been processed, the process proceeds to step 17.

[0124] Step 17 Test Item Summary: The unit summarizes the test execution status of all points in this round of inspection mission, and counts the number of points that passed, the number of points that failed, and the reasons for failure.

[0125] Step 18: Determine if the task has been completed: Based on the summary results, generate the final task execution report and end the current task processing flow.

[0126] In summary, the inspection system and its automated simulation testing method proposed in this invention solve the problems of insufficient test coverage, low simulation realism, and low testing efficiency of existing inspection systems (such as substation inspection systems) through an automated testing process.

Claims

1. An automated simulation testing method for an inspection system, characterized in that, Includes the following steps: 1) Determine the test case library for the target business scenario based on the target business scenario in the inspection system under test; 2) Traverse each test case in the test case library and execute simulation tests for each test case. During simulation testing, obtain the test results for each test case based on the test interaction data. 3) Based on the test results of all test cases, generate a test report for the target business scenario in the inspection system under test.

2. The automated simulation testing method for the inspection system according to claim 1, characterized in that, When the simulation test is an uplink data stream test, listen to and capture the response message returned by the system under test after receiving the simulated uplink data; The response message is compared with the predefined expected response model in the corresponding test case; If the comparison is consistent, the uplink data processing function of the inspection system under test is normal in the corresponding test case; If the comparison is inconsistent, a problem summary record will be generated.

3. The automated simulation testing method for the patrol system according to claim 2, characterized in that, The response message includes any one of the following: confirmation of receipt, processing result, error code, or database update notification.

4. The automated simulation testing method for the inspection system according to claim 2, characterized in that, The problem summary record includes any of the following: the identifier of the failed test case, the content of the sent uplink simulation data, the actual return message of the SUT, the difference analysis with the expected model, the failure timestamp, and any item from the preliminary inference of possible causes of failure.

5. The automated simulation testing method for the inspection system according to claim 1, characterized in that, When the simulation test is a downlink data stream test, the downlink control command issued by the inspection system under test is received and captured; Automatically compare downlink control command messages with predefined control messages in the corresponding test cases; If the comparison is consistent, then perform task control testing; If the comparison is inconsistent, the control command is determined to be correct, and a problem summary record is generated when the control command is incorrect.

6. The automated simulation testing method for the inspection system according to claim 5, characterized in that, After conducting task control testing, it is also determined whether there are any failed items in the task control process. If there are any failed items, they are retested until all items have been tested.

7. The automated simulation testing method for the inspection system according to claim 6, characterized in that, If no failed items are found, a response message is returned and a test report is generated.

8. The automated simulation testing method for the inspection system according to claim 1, characterized in that, Release test resources upon completion of test execution.

9. A patrol system, comprising a processor, characterized in that, The processor executes a computer program to implement the steps of the method according to any one of claims 1 to 8.

Images