Test scheduling system for electric power material detection task cooperation and data acquisition

Abstract

The invention relates to the field of electric power material quality detection, and discloses a test scheduling system for detection task collaboration and data acquisition, which comprises a task construction module, a state collaboration module, a graph reasoning module and a data acquisition module. And the task construction module generates a standardized test task packet including a task identifier, a project code, a target equipment identifier, an environment requirement parameter and a two-dimensional code according to the test rule base and the resource configuration state, and pushes the standardized test task packet to corresponding test equipment through a Web Service interface. And the state collaboration module receives an equipment state feedback event, constructs an event time sequence flow graph based on the task identifier and generates a task state sequence with a timestamp. The atlas reasoning module takes the state sequence and the environmental parameters as input, constructs a test atlas structure and generates an optimization execution path. And the data acquisition module controls the test equipment to complete a detection task according to the path, acquires test data and environmental parameters, and encapsulates the test data and the environmental parameters to form a structured task data packet, thereby realizing data collection and task tracing.

Description

Technical Field

[0001] This invention relates to the field of power material quality inspection technology, and in particular to a test scheduling system for power material inspection task collaboration and data acquisition. Background Technology

[0002] In existing technologies, the quality inspection of materials in power systems generally relies on manual assignment of inspection tasks, manual control of testing equipment, and single-point data collection for management. Although some testing institutions have deployed host computer software or basic information platforms to monitor the operating status of testing equipment and record data, most systems are still equipment-centric, lacking a unified task coordination mechanism, and the linkage and traceability between various links in the inspection process are weak.

[0003] However, existing testing systems still have many problems in task scheduling, status feedback, and data collection. For example, the lack of standardized templates for task issuance can easily lead to inconsistent equipment configurations or incorrect command execution; the test status feedback mechanism lacks event timing correlation capabilities, making it difficult to support the logical consistency of process control; data acquisition usually relies on manual export, lacking structured encapsulation and corresponding records of process environment parameters, making it difficult to meet the requirements for accuracy and reproducibility of test results. These problems are particularly prominent in scenarios involving multi-device collaboration and multi-task parallelism, and have become important factors restricting the improvement of the intelligence level of power testing systems.

[0004] Therefore, there is an urgent need to propose an experimental scheduling system that can realize standardized task distribution, collaborative modeling of state events, and full-process data collection and aggregation. Summary of the Invention

[0005] This application provides a test scheduling system for collaborative power material testing tasks and data acquisition, in order to improve the standardization, automation and traceability of the testing process.

[0006] This application provides a test scheduling system for collaborative power material inspection tasks and data acquisition, including:

[0007] The task construction module is used to generate standardized test task packages based on a preset test rule base and resource configuration status, and push them to the host computer software corresponding to the target device through a Web Service interface. The test task package includes a task identifier, project code, target device identifier, environmental requirement parameters, and QR code mark.

[0008] The state coordination module is used to receive the test state event stream fed back by the host computer software, associate the state based on the task identifier in the test task package, construct an event time sequence flow graph for each test task node, and obtain a set of task state sequences with timestamps.

[0009] The graph reasoning module is used to receive the task state sequence and the environmental requirement parameters in the test task package, construct a test graph structure containing task nodes, equipment state edges and environmental factor edges, and generate the optimized execution path of the current test task based on the graph reasoning mechanism.

[0010] The data acquisition module is used to control each test device to complete the test items in the scheduled order according to the optimized execution path, and to collect structural electrical parameters, mechanical response data, image data and environmental data after each task node is completed, and encapsulate them into a structured task data package. The task data package inherits the task identifier of the test task package for subsequent disturbance analysis.

[0011] The beneficial effects of this application mainly include: (1) By combining the test rule base and resource configuration status with the task construction module, a unified format test task package is generated, and the Web Service interface is used for automatic push, which significantly improves the accuracy and efficiency of task issuance and reduces human configuration errors and inconsistencies in task information. (2) By constructing an event time sequence flow graph and generating a time-stamped state sequence through the state coordination module, the state tracking and process synchronization of each node of the test task are realized, providing a reliable basis for process control and result review. (3) By introducing a graph reasoning module to construct a task graph structure and generate an optimized execution path, the task order and cycle time can be dynamically adjusted based on equipment status and environmental conditions, realizing optimal resource allocation and maximizing task execution efficiency, which is suitable for the parallel test scheduling needs under complex working conditions. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a test scheduling system for collaborative power material testing tasks and data acquisition, provided in the first embodiment of this application. Detailed Implementation

[0013] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0014] The first embodiment of this application provides a test scheduling system for collaborative power material testing tasks and data acquisition. Please refer to [link / reference]. Figure 1 This figure is a schematic diagram of the first embodiment of this application. The following is in conjunction with... Figure 1 The first embodiment of this application provides a test scheduling system for collaborative power material testing tasks and data acquisition.

[0015] The test scheduling system for power material testing task collaboration and data acquisition includes a task construction module 101, a state collaboration module 102, a graph reasoning module 103, and a data acquisition module 104.

[0016] The task construction module 101 is used to generate standardized test task packages based on a preset test rule base and resource configuration status, and push them to the host computer software corresponding to the target device through a Web Service interface. The test task package includes a task identifier, project code, target device identifier, environmental requirement parameters, and QR code mark.

[0017] The task construction module 101 is the key starting module for realizing intelligent test scheduling and standardized task execution in this invention. Its functions include generating test tasks, standardizing and packaging them, and effectively pushing them to the host computer of the target device. Its implementation needs to fully consider the diversity of test projects, the differences in power materials, and the dynamic configuration of on-site resources to ensure that the system has stability, scalability and engineering adaptability in practical applications.

[0018] Specifically, the task construction module 101 first performs task matching and assembly based on the pre-set test rule base within the system. This rule base can be stored in a database structure or a configuration file structure, and includes, but is not limited to, information such as the types of test items required for each type of power material, the test equipment required for each test item, the range of test parameters, the necessary environmental conditions, the test duration, the pass criteria, and the safety boundary values. When a testing requirement is proposed, the task construction module 101 retrieves the corresponding test process template from the rule base according to the selected material type, testing level, and testing target, and adapts the task by combining it with the real-time resource configuration status (such as equipment availability, workstation occupancy status, personnel arrangement, etc.).

[0019] After matching is complete, the task construction module 101 will build a standardized test task package. This task package includes five core fields: First, the task identifier, which must be unique and is recommended to use a combination of timestamp and device identifier encoding to support subsequent traceability and related queries; second, the project code, which indicates the business type to which the testing task belongs and its specific test items, facilitating automatic classification by the system during the data processing stage; third, the target device identifier, which indicates which test device the task will be assigned to for execution. The system should call the device resource configuration interface to dynamically obtain the device number and verify its status as "executable"; fourth, environmental requirement parameters, which describe the constraints of the task on external conditions such as temperature, humidity, and electromagnetic environment in a structured form for comparison by the subsequent environmental monitoring module; and fifth, a QR code mark, which the task construction module 101 encodes the above field information to generate a QR code image file, which can be bound to the device screen or workstation terminal to enable on-site operators to quickly identify the task and perform manual verification.

[0020] The task construction module 101 pushes the completed task package to the host computer software of the designated test device using a standard Web Service interface format. The push process includes interface calls, parameter packaging, and response parsing. The system should use a REST or SOAP protocol structure and encapsulate the task content using a JSON or XML standard format to ensure clear information structure and consistent field naming. Before pushing, the module should confirm the target device's status and perform connection tests through the device management submodule to avoid task command loss due to network failures or device malfunctions. Once the push is successful, the module needs to record the push log and task issuance time as a reference for the subsequent status coordination module to construct the node time flow graph.

[0021] It is worth emphasizing that the task building module 101 should also support redundancy strategies and failure rollback mechanisms for task assignment. For example, when the target device experiences connection failures or the task assignment fails more than three times, the system should suspend the task and send an alarm to the operations and maintenance personnel; or, based on a priority list, reassign the task to a backup device. In multi-task scheduling scenarios, the module also needs to have the ability to assign tasks in batches and control priorities to ensure that critical tasks are allocated resources first and to avoid device overload.

[0022] In addition, the task construction module 101 can be linked with the system's permission management mechanism to record the operator's account, operation time and operation device during the task generation and distribution process, so as to achieve security control and audit traceability of the entire task process.

[0023] The host computer software corresponding to the target device is a test instruction receiving and data uploading program deployed on the control terminal of various test equipment. Its main functions include receiving test task packages pushed by the task construction module 101, parsing the task content, triggering the local test process, collecting the device execution status, and feeding back task status information through a standard interface. This host computer software can be developed using languages ​​such as C++, C#, or Python, and runs on an industrial computer or embedded controller with serial port, CAN bus, or Ethernet communication capabilities. Its core modules include a task receiving and parsing module, an instruction scheduling module, a device interface driver module, a status feedback module, and a communication protocol adaptation layer. The communication protocol is recommended to follow the RESTful architecture or SOAP standard. When receiving a task package, JSON / XML format data is written to the local task queue via HTTP POST. During task execution, the instruction scheduling module calls the device interface driver module to execute specific operations according to the item code and parameter requirements in the task package. Device status information such as "task started," "stage completed," and "test abnormality" is sent to the status coordination module in real time through the status feedback module, forming an event stream. To achieve scalability, the host computer software should support a task identifier parsing and verification mechanism to ensure consistency with the task package format generated by the task building module. It should also be able to adapt to the instruction sets of different types of test equipment through configuration files or parameter mapping tables, thereby achieving heterogeneous equipment compatibility under a unified interface.

[0024] Through the synergy of the aforementioned specific mechanisms, the task construction module 101 not only achieves standardized construction and accurate distribution of experimental tasks, but also provides a unified data entry point and logical starting point for subsequent status monitoring, path reasoning and data acquisition modules, ensuring that the entire experimental scheduling system operates on an orderly, controllable and efficient basis.

[0025] Furthermore, the task construction module is specifically used for:

[0026] Based on the preset test rule base and resource configuration status, multiple test item combination schemes that match the target power material type and test purpose are retrieved, and a candidate test path set containing multiple task nodes, equipment dependencies and environmental requirement parameters is constructed from them.

[0027] Perform parameter consistency verification on the task nodes in the candidate detection path set, identify the task execution conflict relationships, including conflicts in test voltage and current levels between devices, incompatible environmental requirements parameters, or overlapping device switching windows, and perform parameter adjustment and path replacement operations on the conflicting paths to obtain the detection path map after conflict resolution.

[0028] Based on the current resource configuration status, each task node in the detection path map is matched with equipment resources and time window constraints are calculated. Under the premise of satisfying the conditions of equipment idle status, scheduling priority and workstation distribution, a set of task nodes with spatiotemporal executability is generated as the basis for the task scheduling template.

[0029] The information of each task node in the task scheduling template and the updated environmental requirement parameters in the detection path map are encapsulated into a standardized task data structure. A standardized test task package containing task identifier, project code, target device identifier, environmental requirement parameters and QR code mark is constructed. A binding hash digest is generated for the task path and parameter fields through a traceability coding algorithm to achieve unique identification and subsequent node-level state consistency traceability throughout the task process.

[0030] In the test scheduling system for power material testing task collaboration and data acquisition involved in this invention, the task construction module plays the role of the starting point of the testing process. Its technical solution is not only the basis for the collaborative operation of various modules within the system, but also a key link to ensure the standardization of testing tasks, the feasibility of scheduling paths, and the traceability of execution.

[0031] In the initial stage of system operation, the task construction module first receives power material testing requests submitted by users through the scheduling terminal or backend system. These requests must include at least the type code of the material to be tested, the testing objective, the expected completion time, and the required testing level. The task construction module then retrieves the corresponding testing item combination scheme from the system's built-in test rule base. The test rule base is constructed using structured rule tables or hierarchical rule trees. Each rule item must include at least the applicable material type, applicable testing level, recommended testing item sequence, execution order dependencies for each item, required and optional attributes, recommended test equipment type, standard test parameter range, and environmental adaptability requirements. The rule base can be organized using an SQL database, XML configuration structure, or YAML configuration file. Its retrieval method typically combines index matching with conditional filtering. After matching multiple candidate rules, the system converts them into multiple testing path schemes. These path schemes are described using a directed acyclic graph structure, where nodes represent testing task steps, edges represent equipment dependencies or sequence constraints, and each node records the required equipment type, test parameter template, preset environmental requirements, expected execution time, and maximum tolerance error.

[0032] After obtaining the initial set of candidate detection paths, the task construction module enters the parameter consistency verification phase. The core of this phase is to eliminate conflicts within the paths, ensuring the physical feasibility of the test process in the actual system deployment environment. Conflict types mainly include parameter-level contradictions (e.g., the voltage levels required by two detection items cannot be supported by the same equipment), incompatible environmental parameters (e.g., partial discharge testing requires low humidity, while the subsequent withstand voltage test has specific temperature range limitations), and overlapping equipment switching windows (e.g., equipment A requires forced cooling for 30 minutes after the test, while equipment B requires it to be online within 15 minutes). The system establishes a conflict matrix for the parameter relationships between nodes in each candidate path and analyzes whether conflicting paths exist using a logical judgment model. For detected conflicts, the module automatically calls the conflict handling submodule to perform parameter adjustment or path replacement operations. Parameter adjustment includes modifying test parameters within permissible limits to adapt to compatible equipment, such as adjusting the 5kV withstand voltage to 4.8kV to meet the capabilities of existing equipment; path replacement involves finding functionally equivalent alternative detection paths or reordering independent task nodes to avoid conflicts. After completing the above adjustments, the module will output a detection path map after conflict resolution. Each task node in the map structure meets the requirements of consistency of execution parameters, resource compatibility and environmental non-conflict, and has the basic conditions to enter the scheduling stage.

[0033] The task construction module then adapts the detection path graph to constraints based on the current resource configuration status. The resource configuration status is provided in real-time by the system's resource awareness module, including equipment availability and operational status (e.g., whether the equipment is under maintenance or performing other tasks), a workstation distribution table (the workstation numbers and location relationships of equipment in the physical space), personnel scheduling information (some detection tasks require manual intervention), and energy usage restrictions (e.g., restrictions on power or cooling systems when large testing equipment is running concurrently). The task construction module performs resource constraint calculations for each task node in the path graph, determining whether the equipment it depends on is idle within the target time period, and evaluates the scheduling window based on the equipment's workload prediction and maintenance schedule. During the scheduling window evaluation, the system prioritizes task nodes with higher execution priority, using the earliest feasible time or shortest scheduling interval as the sorting criterion when scheduling time is limited. Within resource limits, the system will minimize the number of equipment switches between nodes, shorten the total path execution time, and maximize equipment utilization. During the node selection process, the system will generate a set of task nodes that are schedulable, have clear time windows, and are fully bound to devices. This set can be regarded as the time dimension expansion of the scheduling path, forming the basis for subsequent task scheduling templates.

[0034] After acquiring the set of schedulable task nodes, the task construction module enters the task encapsulation stage. In this stage, the system needs to structure the above information into a standardized test task package for unified parsing by subsequent modules (including the state coordination module, graph reasoning module, and data acquisition module). The task package is described using structured JSON or XML format and includes the following fields: task identifier (a unique code, typically constructed using a combination of "project code-material code-timestamp"), project code (representing the detection type, such as IRR, VLT, PD, etc.), target equipment identifier (MAC address, serial number, or workstation number), environmental requirement parameters (structured fields representing temperature range, humidity range, electromagnetic noise limits, etc.), scheduling time window (start and end timestamps), task node order, test parameter template, and QR code marker. The QR code marker is generated by the system calling the image encoding interface; its content is a summary of the task package structure, for on-site equipment to scan and load, or for maintenance personnel to verify the consistency of the task package.

[0035] To enhance the traceability and execution integrity of task packages within the system, the task construction module further introduces a traceability coding algorithm. This algorithm performs field concatenation on all parameter fields in the experimental task package (including the order of experimental items, environmental requirements, target device, scheduling window, and task identifier), and calls a hash algorithm (such as SHA-256 or BLAKE2) to generate a set of binding hash digests. This digest is appended to the verification field of the task package, becoming the basis for verifying consistency among modules during task execution. For example, when the status coordination module receives a status event from a device, it synchronously verifies whether the task identifier and hash digest corresponding to the event are consistent with the original task package, preventing instruction tampering or execution disconnection.

[0036] Throughout the entire task building module's operation, it is essential to ensure that the four steps are logically strictly dependent, data flow is unambiguous, the module can be deployed independently, and it can interface with other modules in the system. It is recommended that the module implementation adopt a layered structure design, with each processing stage running as an independent service interface, equipped with input validation, exception handling, logging, and retry mechanisms. For example, if an unresolvable conflict is found in the candidate path during the conflict identification stage (e.g., the rule base does not cover a certain specific device type), the system can call a manual assistance interface to prompt engineers to intervene and correct it. During resource adaptation, if all candidate nodes are found to be occupied by resources, the module can enter a "task waiting" state and periodically refresh the resource status until the scheduling window is released. To ensure system response speed, it is recommended to use a concurrent asynchronous architecture to perform node parameter calculation and resource allocation matching; during the task encapsulation stage, a synchronous approach should be used to ensure the integrity and version consistency of the task package.

[0037] The task building module also needs to interface with a unified permission authentication and auditing module. Each task building process should record the operating user, building time, task content summary, and building version number for operations and maintenance personnel to verify the process and track issues. In large-scale task batch generation scenarios, the module should support the reuse of task building templates and the combined building of multi-target tasks. For example, a single build may contain multiple cable sample detection paths, with each sample task package sharing a unified scheduling strategy but having an independent identifier.

[0038] Through the above design, the task construction module can not only achieve path graph scheduling, dynamic resolution of parameter conflicts and intelligent resource adaptation that traditional task configuration systems cannot support, but also strengthen the verifiability of the task execution process and the ability to track the entire process through traceability mechanism and QR code marking, ensuring that the entire power detection task management system has engineering adaptability for complex objects, cross-module collaboration capability and real-time recovery capability to cope with disturbance changes.

[0039] The state coordination module 102 is used to receive the test state event stream fed back by the host computer software, perform state association based on the task identifier in the test task package, construct an event time sequence flow graph for each test task node, and obtain a set of task state sequences with timestamps.

[0040] The state coordination module 102 is mainly used to track the state of the test task at different execution stages, synchronize the process, and process the time sequence. It is a key component to ensure the consistency of the entire scheduling system's operating logic, the orderliness of the process, and the traceability of the data. The input of this module comes from the state event information transmitted back in real time by the target device's host computer software during the test execution. The output is a set of task state sequences arranged in chronological order and bound to task identifiers, which are used by the subsequent graph reasoning module to construct the path decision logic.

[0041] In its implementation, the state coordination module 102 establishes a state feedback interface connection with each host computer software through a registration-based listening mechanism. After receiving the test task package pushed by the task construction module 101, each host computer software executes task scheduling locally. At key nodes, such as "test initialization," "device startup," "parameter loading," "test execution," "abnormal termination," and "test completion," it pushes state events in a structured data format (such as JSON) to the state coordination module via a RESTful interface or lightweight protocols like MQTT when the state changes. Each event data entry should at least include fields such as task identifier, event type, event trigger time, event description, and current device status. This module automatically parses and verifies whether the task identifier field in the event matches the currently active task in the system, ensuring that the state stream does not interfere with other task channels.

[0042] To achieve high-precision state evolution modeling, the state coordination module sorts all state events according to their trigger times, constructing a unified task event time-series graph. This graph uses task identifiers as indices, event types as nodes, and time sequence as edges, completely recording every state change from task issuance to experiment completion. This process can be standardized by introducing a logical clock mechanism to avoid state sequence disorder caused by device clock drift. Simultaneously, the system supports abnormal state marking and path branch modeling. For example, when an event node such as "experiment interrupted" or "parameter abnormal" occurs in a task flow, the node is automatically marked in the event flow graph, and through collaboration with the graph inference module, dynamic adjustments to subsequent execution paths are achieved.

[0043] In addition, the state coordination module should have the capability to detect and compensate for event loss. When a state node does not receive the corresponding event feedback within a specified time window, the module will trigger a timeout warning mechanism and record a "state loss" flag for system administrator review; it can also proactively query the host computer for state progress via polling. The system supports persistently saving state event records to the task log database, forming a complete task state lifecycle archive for easy auditing and subsequent data reuse.

[0044] The entire state coordination module operates based on a message-driven architecture and asynchronous processing mechanism, enabling concurrent management of the state streams of multiple test tasks and exhibiting good scalability and robustness. Those skilled in the art can, in conjunction with actual deployment scenarios and based on the type of test equipment and communication interface protocols, encapsulate the state event acquisition logic into microservices or modular SDK components to achieve rapid interface and integration with equipment from different vendors. This ensures that the entire test task process is controllable, nodes are clear, and data is consistent, meeting the high-reliability industrial scheduling and management requirements.

[0045] Taking the breakdown voltage test of insulating oil in power transformers as an example, when the task construction module 101 generates a standardized test task package containing the task identifier "BT-20250713-001", project code "INS-OIL-BDV", and target device identifier "TX-DV-08", and successfully pushes it to the host computer software of the corresponding test equipment via the Web Service interface, the state coordination module 102 begins the task status monitoring process. After the test personnel scan the code to confirm the task on the device terminal, the device initialization process starts. After the test equipment completes its power-on self-test, the host computer software immediately sends the first status event to the state coordination module. The event type is "Test Start", the timestamp is "2025-07-13 10:02:14", and it contains the task identifier "BT-20250713-001". The state coordination module parses the event and writes it into the event flow graph of the current task, marking it as the first node.

[0046] As the test progresses, when the breakdown voltage reaches the preset test level and the measurement is completed, the host computer will automatically report a "Test Complete" event with a timestamp of "2025-07-13 10:04:27". This event is added to the event flow graph as the second node and connected to the "Test Start" node through system logic to form a complete test execution path. When the state coordination module finds that the interval between the "Test Complete" event and the previous state is reasonable and uninterrupted, it pushes the event state sequence to the graph reasoning module as the basis for path decision-making.

[0047] During this process, if the "experiment complete" status is not received within the set maximum waiting time, the status coordination module will trigger timeout detection logic and record the "status loss" node. Simultaneously, it will send a status review request to the host computer and mark the anomaly in the system log for subsequent data review and scheduling optimization. Through this process, the status coordination module 102 not only achieves full-process capture and modeling of the experimental task's status but also provides a traceable and verifiable status information foundation for the scheduling process, ensuring the stable operation of the system scheduling logic.

[0048] Furthermore, the state coordination module is specifically used for:

[0049] The system receives the test status event stream periodically reported by the host computer software during the test execution process, performs task identifier verification and node type parsing on each status event, extracts the event type, trigger time, corresponding task node number and device feedback status, and forms a structured status record set.

[0050] The structured state record set is sorted according to the event time order, and the state records are aggregated based on the task identifier to construct an event time sequence flow graph corresponding to the order of the test task nodes. Each node includes state type, state duration, references to preceding and following dependent nodes, and source device identifier.

[0051] Perform a state continuity check operation on the event sequence flow graph to determine whether there are abnormal interruptions, repetitions, loss, or time intervals exceeding the limit in the state transmission between task nodes. For the detected abnormal nodes, construct a state repair request and send it to the corresponding host computer software. At the same time, insert placeholder nodes in the graph structure to record the abnormal type and repair time window.

[0052] Based on the state continuity verification results and the final event time sequence flow graph, a set of timestamped task state sequences is generated for the graph inference module input. Each state entry includes a verification label, device number, task node index, start and end timestamps, which serve as the state input basis for subsequent experimental path optimization.

[0053] In the test scheduling system for power material testing task coordination and data acquisition of this invention, the state coordination module undertakes the core functions of state perception, timing modeling and event consistency maintenance during the test process. It is a key bridge to realize closed-loop control of the entire process from task construction to test execution.

[0054] The starting point for the status coordination module is receiving status event streams reported in real-time or periodically from the host computer software of the test equipment. These event streams are typically transmitted in standardized JSON structures, Protobuf data structures, or custom field formats. The event data includes at least five core fields: task identifier, event type, trigger time, task node number, and equipment feedback status. The task identifier serves as a unique identifier for each independent detection task in the system and must be completely consistent with the identifier in the task package generated by the task construction module. The event type is usually a string or enumeration value, identifying states such as "test initialization," "parameter loading," "test start," "test completion," and "task interruption." The trigger time uses a standard UTC timestamp with an accuracy of at least milliseconds. The task node number indicates the subtask step to which the current status event belongs; for example, "PD-02-03" represents the third subtask step of the partial discharge test. The equipment feedback status is used to transmit the real-time operating status of the equipment, such as operating temperature, power supply voltage, communication stability, and diagnostic information.

[0055] The primary task of the state coordination module is to perform task identifier verification and node type parsing for each state event. Upon receiving an event, the system first verifies the integrity of the event structure, ensuring that the number, format, and encoding range of fields conform to the system communication standards. Subsequently, the state coordination module extracts the task identifier field from the event and checks the validity and timeliness of the identifier in the system's currently active task list. If the identifier is invalid or the task has terminated, the module discards the event and records it as a communication anomaly for the system audit module to archive and track. For valid task identifiers, the module further reads the task node structure information of the corresponding task package in the task construction module to confirm whether the node number indicated in the event exists in the task flow; if it does not exist, it indicates that the event is misaligned or falsely triggered, and the system will automatically send an error feedback request to the host computer. Through this series of logical processes, the module extracts the event data that conforms to the format and semantic specifications into a set of structured state records. These records include standardized fields: task identifier, node number, event type, device ID, timestamp, original state data, and state parsing results, used for subsequent state aggregation operations.

[0056] After collecting continuous state events, the state coordination module sorts the structured state record set in chronological order and performs state aggregation processing. The sorting employs a stable sorting algorithm, typically using merge sort or quicksort based on timestamp fields. The sorting result ensures that all state records in the system can construct state paths according to their occurrence order, avoiding scheduling misjudgments caused by event lag, out-of-order, or duplication. Within the sorted state set, the module aggregates events based on task identifiers, with each task identifier corresponding to an independent set of state events. Within the same set, the module categorizes events based on task node numbers and aligns them with the nodes in the original flowchart of the task construction module, subsequently generating an event sequence flow graph. The core structure of this graph is a directed node graph, where each node represents the state of a task sub-step within a certain time period. Its internal data structure includes: node type (initialization, in execution, completed, etc.), state duration (calculated from the timestamps of adjacent state events), dependency references (predecessor node number and successor node number), and source device identifier (indicating which device executes the current node). The edges in the graph record the event triggering order, used by the subsequent graph reasoning module to identify path optimization opportunities.

[0057] After completing the state sequence diagram construction, the state coordination module continues to perform state continuity verification. This verification operation is a crucial step in ensuring the correctness of task execution logic. The system will check whether the task state changes conform to the normal test flow logic node by node. The main detection items include: missing nodes, i.e., a state node that should appear does not appear in the record set; duplicate states, such as two adjacent states both being "test completed"; state interruption, i.e., a state begins and there are no subsequent events for a long time and the task is not declared to be terminated; time interval exceeding the limit, i.e., the time interval between two states exceeds the maximum allowed execution time for this type of task (for example, a high-voltage withstand voltage test usually does not exceed 5 minutes, and if it continues for 10 minutes without completion, it is considered an anomaly). For any of the above types of anomalies, the state coordination module will immediately generate an anomaly node marker and construct a state repair request. The repair request includes the task identifier, node number, anomaly type, suggested response method, maximum waiting window, etc., and is sent to the host computer software of the corresponding device through the Web Service interface or MQTT protocol, prompting the device to re-report the state, supplement the report, or respond to the task interruption.

[0058] Meanwhile, to ensure the integrity of subsequent module processing flows, the state coordination module inserts placeholder nodes into the event sequence diagram to identify the location of the anomaly and its repair status. These placeholder nodes are structurally identical to normal nodes, but their status type field is marked as "abnormal placeholder." The duration of this status is determined by the system's default waiting window; for example, if repair data is not received within 5 minutes, it is recorded as permanently missing. The placeholder node also contains a repair status flag. When the system receives a repair event for this task node again, it replaces the placeholder node with this repair event and updates its status duration and timestamp fields, enabling dynamic data structure backfilling.

[0059] After the state continuity verification is completed, the state coordination module will construct the final usable task state sequence, which serves as the direct source of input for the path reasoning module. Each state entry is a structured data item containing a task identifier, task node index, state type, state start timestamp, state end timestamp, device number, and state validity label (such as "normal," "effective after repair," "placeholder," etc.). The system can also add a node confidence score field to score the reliability of each node based on parameters such as the completeness of the state data source, device diagnostic stability, and historical task success rate, providing information for subsequent path decision-making and path priority adjustment. The final generated task state sequence uses the task identifier as the primary key index and maintains a one-to-one correspondence with the task package data structure, ensuring that the subsequent reasoning module and data acquisition module can process data according to unified task semantics.

[0060] The entire state coordination module is recommended to be implemented using an asynchronous event-driven architecture. The core processes include an event receiving channel, a state parsing engine, a graph building engine, a continuity checker, and a state repair service. All modules should support high-concurrency event processing capabilities, state persistence, and high fault tolerance mechanisms. In multi-task concurrent execution scenarios, distributed queues and timestamp correction mechanisms should be used to ensure events are entered into the graph in logical order. It is recommended to combine components such as Kafka, Redis Stream, or RabbitMQ to implement message buffering and event order maintenance. In scenarios with low device response frequency or unstable networks, a polling-based state acquisition mechanism can be enabled to periodically pull state patch information from the device to enhance system stability.

[0061] In summary, the state coordination module, through a complete set of well-structured, logically rigorous, and closed-loop processing procedures, achieves precise control over the entire process of experimental state events, from analysis to mapping, from anomaly identification to repair control, and from data aggregation to inference input. This not only ensures the integrity and consistency of the experimental scheduling process but also provides a solid foundation for dynamic optimization of task paths and data traceability.

[0062] The graph reasoning module 103 is used to receive the task state sequence and the environmental requirement parameters in the test task package, construct a test graph structure containing task nodes, equipment state edges and environmental factor edges, and generate an optimized execution path for the current test task based on the graph reasoning mechanism.

[0063] The graph reasoning module 103 plays a core role in this system, connecting state evolution and execution scheduling. Its function is to jointly model the task state sequence generated by the preceding modules with environmental requirement parameters, construct a structured task execution graph, and output a practically executable optimized path through graph reasoning mechanisms for use by the subsequent data acquisition module for scheduling and control. The core idea of ​​the graph reasoning module is to replace linear process scheduling with graph structure modeling, thereby addressing the complexities commonly encountered in power material testing tasks, such as heterogeneous test projects, equipment condition fluctuations, and overlapping environmental constraints.

[0064] In the specific implementation process, the module first receives a time-ordered sequence of task states output from the state coordination module 102. This sequence records the state nodes experienced by each experimental task from its start to the current stage, and includes the corresponding timestamps and task identifiers. At the same time, the graph inference module also synchronously parses the environmental requirement parameters contained in the experimental task package, including temperature and humidity range, electromagnetic interference restrictions, cleanliness requirements, etc., for use in the subsequent graph construction stage edge weight assignment.

[0065] During the graph construction phase, the graph reasoning module treats each task state node as a node unit in the graph, using the temporal logic of task state changes as the main edge connection. At the same time, it introduces two types of supplementary edge structures: one is the device state edge, which describes the reachability relationship between different devices or between different states of the same device. This relationship is automatically generated based on the device resource mapping table and scheduling status within the system. The other is the environmental factor edge, which expresses the dependency relationship of a certain state node on specific environmental constraints. The edge weight can be dynamically assigned according to the deviation between the measured value of the current environmental parameter and the required range. The larger the value, the less suitable it is to execute.

[0066] After the graph is constructed, the graph inference module inputs the entire task graph into the graph inference engine for path optimization. Inference methods can employ graph search-based A algorithm, heuristic pruning shortest path algorithms, or learning-based inference models based on graph neural networks (such as GAT or GCN). In specific industrial deployments, to ensure interpretability and real-time performance, the weighted rule-based A-path optimization algorithm is preferred. This algorithm combines three factors—task execution priority, equipment switching costs, and environmental fluctuations—to calculate a comprehensive cost function and output the optimal execution path that satisfies the constraints.

[0067] The optimized execution path output is an ordered list of paths, where each path node corresponds to a test task step, including fields such as target device number, execution instruction number, expected time window, and execution priority. This path result not only serves as a direct input for the data acquisition module 104, but can also be used to guide on-site dispatchers in reviewing and adjusting the test execution order.

[0068] During system operation, the graph inference module should have dynamic update capabilities. When the state coordination module detects a new state event stream or the environmental monitoring module reports abnormal parameters, the graph inference module should immediately reconstruct the relevant graph structure and trigger path recalculation logic to ensure that the system can maintain the rationality of the scheduling path and the effectiveness of task execution under real-time interference or execution offset.

[0069] Through the above mechanism, the graph reasoning module 103 can make flexible, dynamic and adaptive test process scheduling decisions in the face of power detection scenarios with multiple tasks, multiple devices and multiple conditions. This not only ensures the overall operating efficiency of the system, but also provides a clear and stable path framework and process basis for subsequent data acquisition and disturbance analysis.

[0070] The following is a specific example illustrating the complete workflow of the graph reasoning module 103 in the test scheduling system.

[0071] In a power equipment testing task, three sub-items need to be completed on a certain type of high-voltage cable sample: insulation resistance test, partial discharge test, and withstand voltage test. The task construction module 101 has generated a standardized task package with the test task identifier "HV-CABLE-20250713-005". The specified target equipment are IR-TEST-01 (insulation resistance tester), PD-TEST-03 (partial discharge test platform), and HV-TEST-06 (withstand voltage test system). The environmental requirements are set as follows: temperature 20℃±2℃, humidity not exceeding 50%, and no strong electromagnetic interference.

[0072] After the task is pushed out, the status event stream fed back by the device's host computer is processed by the status coordination module 102 to generate the following task status sequence:

[0073] (T1)10:00:00 — “Test initialization complete”;

[0074] (T2)10:00:45—“Insulation resistance test started”;

[0075] (T3)10:03:20—“Insulation resistance test completed”;

[0076] (T4)10:05:00—“Partial discharge test started”;

[0077] (T5)10:08:10—“Partial discharge test terminated abnormally”;

[0078] (T6)10:10:00—“Partial discharge test restart”.

[0079] Upon receiving the aforementioned task state sequence and environmental parameters from the task package, the graph reasoning module 103 begins constructing the task graph. First, the module models each state node from T1 to T6 as a graph node, with each node containing fields such as task identifier, node type (startup / completion / abnormal, etc.), device number, state timestamp, and dependent environment requirements. The sequential relationships between nodes are constructed using main path edges based on time sequence, such as T1→T2, T2→T3, T3→T4, etc. Since T5 is an abnormal state, the module marks the T4→T5 edge as "failed" and adds a "retry" edge for T5→T6. Simultaneously, device state edges represent device switching between task nodes, such as switching from IR-TEST-01 to PD-TEST-03, with resource status appended to the edges, such as device preparation time, device priority, and current availability.

[0080] Environmental factor edges are generated based on feedback values ​​from the current environmental monitoring module. For example, if the ambient temperature is 21.2℃ and the humidity is 48% during the T2 node period, the system determines that the node matches the environmental requirements and assigns a weight of 0. However, if the temperature is detected to rise to 24.1℃ during the T4 node period, exceeding the range set by the task package, the system will introduce an environmental deviation edge at the T4 node with a weight of 0.8, indicating a high-risk execution point.

[0081] After the graph is constructed, the graph reasoning module calls the built-in heuristic graph search algorithm (such as the A* algorithm) to evaluate the path cost step by step, starting from T1, with task completion as the target node. The cost function design takes into account the following factors: (1) equipment switching cost (e.g., a 5-minute cooling time is required for switching between different test equipment, which is counted as +1), (2) environmental mismatch penalty (e.g., a deviation of more than 2℃ is counted as +2), (3) node abnormal penalty (e.g., an abnormal termination node increases by +5), and (4) task priority weight. In this example, the algorithm finds that the environmental risk of node T4 is too high, and the abnormal interruption penalty of T5 is high, but T6 is a retry node, and the equipment can still be recovered. Therefore, the optimized path planned by the system is:

[0082] T1 (Initialization) → T2 (Insulation Resistance Startup) → T3 (Insulation Resistance Completion) → T6 (Partial Discharge Retry) → … → HV Test (Pending)

[0083] Finally, the graph inference module outputs the optimized path as a structured path sequence, including the target device number, execution time period suggestion, environment matching level and switchover preparation time for each task node, and pushes it to the data acquisition module 104 for execution scheduling.

[0084] Throughout the process, the graph reasoning module not only achieved dynamic fusion modeling between states and resources, but also dynamically adjusted path directions through the graph structure to cope with disturbances caused by local anomalies and environmental changes. This mechanism enables test scheduling to have flexible, intelligent, and closed-loop decision-making capabilities, significantly improving the stability of the detection process and the efficiency of resource utilization.

[0085] Furthermore, the graph reasoning module is specifically used for:

[0086] The task state sequence obtained by the state coordination module is subjected to time-continuous clustering processing. Based on the state start timestamp of the task node and the device identifier, adjacent task nodes are segmented and clustered to generate a set of time-clustered task node segments, which are used to identify potential task concurrency windows and device schedulable intervals.

[0087] Based on the time-clustered task node segments and the environmental requirement parameters in the test task package, a test graph structure is constructed that includes task nodes, device state edges, and environmental factor edges. The device state edges are used to represent the resource dependencies between task nodes, and the edge weights are dynamically assigned based on device switching consumption, cooling requirements, and resource conflict probability. The environmental factor edges are used to describe the sensitivity of task nodes to external environmental conditions, and the edge weights are set based on the deviation between the current environmental parameters and the environmental requirement parameters.

[0088] Based on the experimental graph structure, the path cost evaluation process is performed. According to the multi-objective path cost function set by the system, all reachable paths from the task start node to the end node in the graph are scored. The path cost function considers at least the number of device switching, the total execution time, the deviation of environmental parameters and the matching degree of task priority order, and outputs the candidate path sequence after the path cost is sorted.

[0089] In the candidate path sequence, path segments containing abnormal status marker nodes are identified, and a local path replacement mechanism is invoked. Under the premise of maintaining the order of task node dependencies and resource constraints, the abnormal path segments are replaced with alternative path segments with functional equivalence in the task graph structure. The final optimized execution path with optimal schedulability and structural stability is output as the control input basis for the data acquisition module.

[0090] The graph reasoning module operates around the collaborative optimization of task states and equipment resources within the experimental scheduling system. Its goal is to express the resource dependencies and environmental coupling relationships between experimental task nodes through a multi-dimensional graph structure, thereby generating optimal execution paths with schedulability and stability. In practical applications, experimental tasks often contain multiple related task nodes. These nodes not only have sequential and functional dependencies but are also affected by the state of the experimental equipment, resource availability, and changes in environmental conditions. To achieve efficient task execution under complex conditions, the graph reasoning module first performs temporal continuous clustering on the task state sequence output by the state coordination module to identify potential task concurrency windows and equipment schedulable intervals.

[0091] During the temporal continuity clustering phase, the system receives a sequence of task states organized by the state coordination module. Each state record in this sequence contains a task identifier, device number, node index, and start and end timestamps. To capture potential concurrency characteristics during task execution, the graph inference module employs a density-based time-segment clustering algorithm based on the temporal distribution characteristics of the state records. This algorithm groups temporally adjacent task nodes that use the same device into the same cluster segment. Specifically, the system sets a time interval threshold and resource consistency rules. When the start time difference between two adjacent nodes is within the set range and they use the same device, they are grouped into the same time-segmented task node segment. This process not only improves the efficiency of scheduling path construction but also provides data support for path segmentation in subsequent graph structure modeling.

[0092] After obtaining the time-clustered task node segments, the system enters the experimental graph structure construction phase. This phase establishes a polygon graph structure based on the task state sequence and environmental requirement parameters in the experimental task package. Nodes in the graph represent various experimental task nodes, and edges are divided into two categories: device state edges and environmental factor edges. Device state edges describe the resource scheduling dependencies between task nodes. Their edge weights are not fixed but calculated based on dynamic indicators such as energy consumption, cooling time, and resource conflict probability required for device switching. For example, if a task node requires electrical equipment reconfiguration after execution, and the cooling process for this reconfiguration takes 20 minutes, the system will assign a higher edge value to this path according to the current resource scheduling strategy to guide the graph reasoning process to avoid this path. Environmental factor edges express the sensitivity between task nodes and environmental variables such as external temperature, humidity, and electromagnetic fields. If a node is sensitive to humidity during execution, and the current ambient humidity exceeds the threshold set by the task package, the edge weight of this environmental factor edge will also increase, thereby reducing the priority of this path in reasoning.

[0093] After the graph structure is built, the graph reasoning module performs a path cost evaluation process on the structure. This process starts from the task's starting node in the graph, traverses all reachable terminal node paths, and applies a multi-objective path cost function defined by the system to score each path. The path cost function has multi-dimensional constraints, considering at least the following factors simultaneously: first, the number of device switching between task nodes; the higher the switching frequency, the greater the path cost; second, the total execution time of all task nodes in the entire path, including intermediate cooling and waiting times; third, the deviation of environmental factor edges in the path, i.e., the degree of difference between the current environment and the desired environment for the task; and fourth, whether the task node arrangement order conforms to the task priority strategy; if higher-priority tasks are delayed, the cost of the corresponding path will increase. Through the quantitative calculation of these comprehensive factors, the system can output a sorted candidate path sequence for all paths, providing the scheduling system with a basis for selecting the path with the lowest cost and optimal resources.

[0094] After obtaining the candidate path sequence, the system does not directly output the path as the scheduling result, but instead enters the local path replacement stage. During task execution, some task nodes may be marked as abnormal by the state coordination module, for example, due to equipment failure, data drift, or environmental fluctuations. When reviewing the candidate path sequence, the graph reasoning module scans the path for nodes marked as abnormal and processes these abnormal path segments. To ensure that the task dependency order and resource constraints are not violated, the system searches for alternative node paths in the task graph structure that are functionally equivalent to the abnormal nodes, have compatible resource usage, and acceptable scheduling time. This local path replacement mechanism uses a deep matching algorithm for structural comparison and resource verification, ensuring that the replaced path has consistent task effects and output parameters with the original path, avoiding result deviations due to path changes. Finally, the system replaces the abnormal segments in the original path with alternative segments and performs a consistency check on the overall path, generating the final execution path with the highest structural stability and optimal schedulability. This path will serve as the input for the data acquisition module, guiding it to control each experimental device to perform task execution and data acquisition in a predetermined order.

[0095] In practical applications, the graph structure and path results constructed by the graph reasoning module not only guide the execution of single-trial tasks but can also be stored by the system and used as experience templates for subsequent task scheduling optimization. The system continuously collects deviations, scheduling bottlenecks, and environmental sensitivities during task execution, dynamically adjusting the graph edge weight calculation model and path cost function to make subsequent graph reasoning results more stable and accurate, thus forming a scheduling optimization system with self-evolutionary capabilities.

[0096] For example, in an electrical withstand voltage and thermal aging test of a batch of transformer insulation materials, the system received multiple task packages. Some task nodes required a 15-minute voltage loading using high-voltage power supply equipment, followed by 30 minutes of operation at a specific temperature in a temperature-controlled chamber, and finally surface degradation analysis by image recognition equipment. After analyzing the state sequence, the graph inference module found that the same high-voltage equipment needed to serve multiple tasks within a short period, and the temperature adjustment time in the temperature-controlled chamber was a bottleneck for the overall scheduling. In graph structure modeling, this module assigned high-weight equipment state edges to the high-voltage power supply to avoid reusing the equipment in the path. Simultaneously, it established highly sensitive environmental factor edges for relevant nodes in the temperature-controlled chamber to guide the inference process to avoid this path segment when environmental changes are drastic. Ultimately, the system's output scheduling path avoided resource contention during peak hours, improving the overall task completion rate and data acquisition stability.

[0097] The data acquisition module 104 is used to control each test device to complete the test project in the scheduled order according to the optimized execution path, and to collect structural electrical parameters, mechanical response data, image data and environmental data after each task node is completed, and encapsulate them into a structured task data package, wherein the task data package inherits the task identifier of the test task package for subsequent disturbance analysis.

[0098] The data acquisition module 104 undertakes the key functions of execution control and information acquisition in the test scheduling system. Its functions include not only controlling the orderly implementation of test tasks according to the optimized execution path provided by the graph reasoning module 103, but also accurately collecting, formatting and encapsulating, and structurally binding the data generated in various test processes with task identifiers to ensure the data integrity, timing consistency and subsequent traceability of the entire testing process.

[0099] During system operation, after the optimized execution path generated by the graph inference module is transmitted to the data acquisition module, the module first executes the scheduling instructions one by one according to the task nodes marked in the path. Each path node typically includes fields such as the unique identifier of the target device, the recommended start and end execution time window, the task step identifier, and the execution priority. The data acquisition module triggers the test equipment to perform corresponding operations sequentially through the control interface of the device's host computer. For example, when the path instruction requires performing a partial discharge test on the "PD-TEST-03" device, the data acquisition module will issue a "start test" command to the device and enter a status monitoring mode to monitor the running status and execution feedback returned by the device in real time, ensuring that the device is indeed in the "task execution" state before proceeding to the next step.

[0100] When the equipment completes the execution of a certain test node, it typically generates several raw data outputs in the local buffer or interface buffer. These data may include electrical measurements (such as voltage, current, and resistance), mechanical responses (such as displacement, stress, and vibration), image or video recordings (for surface defect detection or thermal imaging analysis), and test environment parameters (such as temperature, humidity, wind speed, and electromagnetic field strength). The data acquisition module reads the data at high speed through the device driver interface or based on protocols such as Modbus, CAN, and OPC-UA, and performs preliminary cleaning and structural mapping according to a predefined format.

[0101] The data acquisition module uniformly encapsulates all acquired data into a structured task data package. This data package must fully inherit the task identifier from the experimental task package to ensure the consistency of the task execution trajectory. It also includes metadata such as the source device number, acquisition timestamp, physical unit, and sampling frequency for each sub-data item, facilitating subsequent verification, comparison, and statistical analysis of the experimental results by system modules or personnel. To enhance data integrity and transmission security, it is recommended to use JSON or Protocol Buffers structures for data encapsulation, supplemented by SHA-256 or CRC checksum mechanisms for data integrity verification.

[0102] In multi-device parallel testing scenarios, the data acquisition module must possess scheduling and coordination capabilities, supporting asynchronous or multi-threaded acquisition mechanisms to ensure that data from different devices do not overlap or experience delays, and can dynamically adjust the execution order based on task priority. During the acquisition process, if abnormal device status, data latency exceeding the allowable range, abnormal fluctuations in sampling frequency, or missing acquired data are detected, the module should automatically record alarm logs and mark the abnormal status in the diagnostic field of the current task data packet, so that the system can perform quality filtering or trigger a retest mechanism in subsequent analysis.

[0103] In addition, the data acquisition module is also responsible for interfacing with the system's task archiving and database interfaces, uploading structured task data packages to the central data management platform or cloud database, and completing task-level data aggregation. The module should support task identifier-based indexing mechanisms, distributed storage support, and batch data synchronization strategies to ensure that the system maintains high throughput and low latency data management capabilities even in large-scale task processing scenarios.

[0104] In summary, the data acquisition module 104, by accurately executing path scheduling instructions, meticulously collecting various types of test data, and uniformly encapsulating and binding task identifiers, not only completes the information collection task of the test phase, but also lays the data foundation for subsequent analysis, evaluation, and intelligent scheduling optimization of the entire system. It plays an irreplaceable and important role in improving detection quality control and end-to-end traceability.

[0105] The following is a specific example to fully illustrate the workflow of the data acquisition module 104.

[0106] Assume the current system-scheduled task is to perform routine testing on a certain type of 10kV outdoor cable, with the task identifier "CBL-20250713-017". The task construction module 101 has generated a test task package, which includes the project code "VLT-DCIR-PD" (representing insulation resistance test, DC withstand voltage test, and partial discharge test, respectively). The target equipment is three test devices: IR-01, HVDC-02, and PD-03. The ambient temperature is required to be controlled between 20℃ and 25℃, and the humidity is required to be below 50%.

[0107] After the task is pushed to the device's host computer, it undergoes modeling and path optimization by the state coordination module 102 and the graph reasoning module 103. The output execution path is as follows:

[0108] Step 1: Perform insulation resistance test on the IR-01 device. The recommended time window is 10:00:00–10:02:30.

[0109] Step 2: Perform DC withstand voltage test on the HVDC-02 equipment, with a time window of 10:03:00–10:07:00;

[0110] Step 3: Perform a partial discharge test on the PD-03 device within the time window of 10:08:00–10:12:00.

[0111] Upon receiving the optimized path, the data acquisition module 104 immediately controls the device to execute it in sequence. First, the module sends a "Start Test" command to the host computer of IR-01. After confirming the device's "Ready" status, it starts the insulation resistance test program. After completing steps such as applying voltage, stabilizing charging, and current sampling, the device generates measurement results, for example, an insulation resistance value of 96.4 MΩ and a test duration of 128 seconds. The data acquisition module accesses the IR-01 device via the Modbus TCP interface, reading the corresponding data fields from its internal registers, including voltage (V), current (μA), insulation resistance (MΩ), leakage trend curve data, and device temperature rise. The sampling period is every 200ms, collecting a total of 640 time-point data points. The module packages this data segment into an "Electrical Parameter Sub-Data Block," formatted as JSON, and marks the source device as "IR-01," with the sampling time as "2025-07-13 10:00:00–10:02:08."

[0112] Subsequently, the module automatically switches to the HVDC-02 device according to the path scheduling logic. The control interface issues a DC withstand voltage test start command. The device first boosts the voltage to 5kV, maintains it for 90 seconds, then boosts it to 10kV and maintains it for 2 minutes, recording whether breakdown occurs and the current change trend. The data acquisition module continuously reads parameters such as applied voltage, current response, withstand voltage maintenance time, and insulation loss power from the device control unit, and marks data anomalies (such as current surges) in real time. To assist in the judgment, the module also simultaneously reads the cabin temperature and humidity data (temperature 22.6℃, humidity 43.5%) collected by the environmental monitoring system, and appends it to this data packet to form a "withstand voltage sub-data block".

[0113] Finally, during the partial discharge testing phase, the module connects to the PD-03 host computer to control the partial discharge detection platform to inject high-frequency pulses and acquire discharge spectrum images. The module will obtain two types of data: first, numerical data, such as discharge initiation voltage, discharge quantity (pC), cumulative discharge count, frequency distribution, etc.; second, image data, including two-dimensional grayscale distribution map, PRPD spectrum, and local time domain waveform map. After acquisition, the module packages the numerical data and image data in structured data format and Base64 image format respectively, and uses all the information from this stage as a "partial discharge sub-data block".

[0114] After the three sub-data blocks are collected, the data acquisition module encapsulates them sequentially into a unified structured task data packet, inheriting the task identifier "CBL-20250713-017" for the entire task. The data packet structure explicitly marks the sub-task execution order, device number, data sampling time, anomaly flags, environment snapshot information, and version control fields. The data acquisition module also performs hash verification (e.g., SHA-256) on the entire data packet and generates a unique digest value to ensure data integrity verification during subsequent uploads.

[0115] The data acquisition module then uploads the data packets to the detection job gateway server via an HTTPS interface and writes the upload record to the log system for auditing. The system database automatically archives the data using the task identifier as an index. If any data loss, communication interruption, or sampling error (such as unstable sampling interval) occurs during any subtask acquisition, the module will immediately record the error information and add the exception field "flag_missing_segment" to the data packet for the subsequent analysis module to evaluate whether to trigger the supplementary acquisition mechanism.

[0116] Through this example, the data acquisition module 104 fully realizes the entire process of operation from sending device control commands, judging status, acquiring multi-dimensional data, format encapsulation, binding identifiers to uploading and archiving, fully demonstrating its core role in connecting execution control and data collection in the whole system.

[0117] Furthermore, the data acquisition module is specifically used for:

[0118] Based on the task node scheduling order in the optimized execution path generated by the graph inference module, a collection task instruction set for each task node is dynamically generated. The collection task instruction set includes target device collection channel configuration parameters, target data type identifier, and expected collection time window. The collection task instruction set is synchronously sent to the test device corresponding to the task node and a collection task listening thread is established.

[0119] The raw data stream fed back by the test equipment after executing the collection task instruction set is parsed in real time and mapped in structure. The structural electrical parameters, mechanical response data, image data and environmental data are extracted respectively. The data segments are marked and bound based on the task node index in the optimized execution path to generate a preliminary collection result set with associated identifiers. Each data record contains a collection timestamp, task identifier and equipment number.

[0120] The preliminary collection result set is subjected to data integrity detection and time sequence consistency verification. Based on the preset parameter range, frequency threshold and time window overlap rules, the collection data with missing, abnormal jumps or duplicate records is identified, and a set of structured anomaly reports is generated. The anomaly reports will be sent back to the task construction module for future collection task adjustment and equipment maintenance strategy optimization.

[0121] Based on the data records that have passed the integrity test, the structural electrical parameters, mechanical response data, image data and environmental data are structurally encapsulated according to the task node dimension to form a standardized task data package. The task data package inherits the task identifier of the test task package and establishes a mapping relationship with the output path of the graph inference module through a hash digest function, so as to realize the full-process traceability of the acquisition results and the consistency guarantee of the disturbance analysis basis.

[0122] In the test scheduling system for collaborative testing and data acquisition of power materials, the data acquisition module undertakes multiple key functions throughout the system operation, including equipment scheduling and control, raw data reception, data cleaning and verification, and structured encapsulation and output. Its technical essence is not just a simple data capture behavior, but a multi-level, highly integrated data interaction and semantic binding process. It must ensure consistency and traceability between the data acquisition and the test task package and the graph inference results while maintaining the real-time and accuracy of the data acquisition.

[0123] The data acquisition module first determines the order of all task nodes in this round of task scheduling based on the optimized execution path generated by the graph inference module. Then, based on the task number, target device identifier, and environmental parameter requirements of each task node, it generates a precise corresponding acquisition task instruction set. The instruction set is constructed based on the test device type and functional modules bound to each task node in the scheduling results, combined with the target data type and environmental requirement parameters indicated in the test task package. It extracts the data acquisition channel information supported by the target device and sets specific channel parameters, such as voltage level, current sensor channel number, mechanical stress-strain sampling rate, image resolution, and infrared thermal imaging threshold, to ensure that the acquisition instructions can be accurately recognized and efficiently executed by the device. Each set of acquisition task instructions also includes a desired acquisition time window to control the start and end times of device acquisition and synchronize the execution window of the corresponding task node, avoiding problems such as data overwriting, signal drift, or data gaps caused by time mismatch. The system sends the generated acquisition task instruction set to each corresponding test device one by one through the scheduling control interface, and establishes an acquisition task listening thread for each active task node in the system backend. The listening thread is responsible for receiving real-time feedback from the device, monitoring changes in the acquisition task status, acquisition completion signals, abnormal interruption events, and hardware status reports, and writing the device feedback information into the task status database to support subsequent analysis by the status coordination module and the graph inference module.

[0124] After the raw data acquisition is completed, the data acquisition module performs real-time protocol parsing on the multi-source raw data streams returned from the devices. Considering the different communication protocols used by various test devices, including but not limited to Modbus, CAN, 485, Ethernet / IP, and GPIB, the system uses a multi-protocol adapter for unified parsing. Each raw data stream, after decoding, is mapped according to channel number and task node index into four categories: structural electrical parameters (such as on-resistance, breakdown voltage, leakage current, and power frequency withstand voltage), mechanical response data (such as deformation, maximum load, and yield point), image data (such as microscopic defect maps and thermal imaging frame sequences), and environmental data (such as temperature, humidity, wind speed, and vibration acceleration). The system automatically adds acquisition timestamps, task identifiers, and device numbers to each parsed data record, forming a preliminary, correlated acquisition result set. This process not only completes the mapping from physical signals to semantic data but also implements a dual-binding mechanism between tasks and devices, providing technical support for subsequent multi-dimensional task tracking and fault location.

[0125] Subsequently, the data acquisition module performs integrity checks and timing consistency verification on the initial acquisition result set to identify data loss, jumps, drifts, or duplications caused by equipment failure, communication interruptions, or parameter setting errors. Integrity checks include, but are not limited to: 1) verifying the completeness of fields in each data segment, such as the presence of missing or invalid values; 2) verifying that the acquisition frequency matches the preset sampling rate; and 3) checking whether the data timestamps cover the acquisition time window specified by the task node. Timing consistency verification focuses on determining whether the time interval of data records is stable and whether there are data packet delays or errors. For detected abnormal data segments, the system automatically generates a structured anomaly report. The report includes the anomaly type (e.g., "sampling frequency too low," "data field missing," "data jump exceeding limits"), the anomaly time period, the affected task node number, the device number, and a suggested handling strategy. This anomaly report is not only used for archiving the execution status of this round of tasks but also fed back to the task construction module through the system's internal event channel to assist it in dynamically adjusting the acquisition strategy, device configuration, and sampling parameters during subsequent task generation, enabling system self-learning and strategy evolution. At the same time, some serious abnormal information (such as frequent abnormalities of the same equipment) will also be synchronized to the equipment maintenance management interface as basic data for equipment health status analysis and maintenance cycle optimization.

[0126] For data records that pass integrity and consistency checks, the data acquisition module merges and integrates them according to the task node dimension to construct standardized structured task data packages. Each task data package contains four subsets of data records, corresponding to structural electrical parameters, mechanical response, image data, and environmental data, respectively, and retains semantic fields such as acquisition timestamp, task identifier, device number, and task node index. This data package not only serves as the basic unit for data storage and retrieval but also establishes a one-to-one mapping relationship with the optimized execution path generated in the graph inference module through a hash digest function. The hash digest is generated by sequentially concatenating the task node index, device number, sampling window start and end time, task identifier, and experimental task package encoding fields in the task path and then processing them with SHA-256. This effectively avoids path confusion caused by duplicate paths or shared devices, enabling full-process traceability of acquisition results. After the data package is generated, it is automatically stored in the task database for the disturbance perception module to perform subsequent data difference analysis and scheduling strategy rollback. At the same time, the acquisition module also supports sending data packages to edge analysis nodes or cloud analysis platforms in real time via MQTT or HTTP push mechanisms, improving the overall data processing efficiency of the system.

[0127] In practical implementation, if the task path generated by the graph inference module contains multiple task nodes falling within the same time window, the data acquisition module will perform resource scheduling based on the device's concurrency capabilities and channel reuse strategies. For example, if two task nodes are bound to the same device but have different acquisition channels, the system will attempt concurrent scheduling to maximize system throughput. This type of concurrent processing requires dynamic judgment in conjunction with the channel isolation parameters generated by the task construction module and the device performance library to ensure data accuracy is not compromised. Furthermore, for image data acquisition and processing, the system supports GPU-accelerated image preprocessing mechanisms, including image denoising, contrast enhancement, edge recognition, and target annotation, which can significantly improve the accuracy and stability of downstream recognition algorithms.

[0128] Overall, the data acquisition module in this invention is not a passive data transmission interface between devices and systems in the traditional sense, but rather an intelligent core module with composite capabilities such as scheduling awareness, protocol adaptation, semantic parsing, anomaly detection, data binding, and path mapping. It not only supports efficient data acquisition and task execution control of the system, but also achieves closed-loop optimization and intelligent evolution of the experimental scheduling system through deep integration with the graph inference module, task construction module, and state coordination module.

[0129] Furthermore, the aforementioned test scheduling system for collaborative power material testing tasks and data acquisition also includes:

[0130] The disturbance perception and rescheduling module receives structured task data packets generated by the data acquisition module, analyzes the equipment feedback anomalies, data drift characteristics, and environmental deviations contained therein, constructs a disturbance scoring model, and when the score exceeds a preset threshold, performs local path re-inference and scheduling rollback operations based on the original test graph structure, and updates the task state sequence in the state coordination module and the optimized execution path in the graph inference module.

[0131] To address unforeseen disturbances such as equipment malfunctions, test result deviations, or environmental fluctuations that may occur during power material testing, the system further includes a disturbance perception and rescheduling module. This module enhances the stability, robustness, and intelligent response capabilities of the overall scheduling system. Closely connected to the data acquisition module, this module receives structured task data packets as input, extracts multiple key feature dimensions related to the disturbance, and triggers a dynamic adjustment mechanism to automatically correct task paths and adaptively optimize scheduling strategies.

[0132] Specifically, the disturbance perception and rescheduling module begins operation immediately after the data acquisition module uploads the data packet. It first parses the device feedback information in the task data packet, including indicators such as device self-diagnostic status, runtime, power consumption changes, and action response time, identifying behaviors that may reflect device aging, communication anomalies, or reduced execution efficiency. Simultaneously, this module performs statistical analysis on the collected measurement data ontology, extracting typical data drift characteristics, such as increased variance of continuous measurements, deviation between the expected and actual observed distributions, and increased outlier frequency. These may indicate that the detection process has been interfered with by internal or external disturbances. Furthermore, the system also analyzes the environmental parameters bound to the task packet, such as whether drift beyond the critical value occurred during partial discharge testing under preset temperature and humidity conditions, or whether environmental parameters fluctuated drastically during the test. All this information is mapped into a disturbance feature vector for subsequent disturbance scoring modeling.

[0133] The disturbance scoring model is the core component of the disturbance perception module. It typically employs a weighted logical scoring mechanism, assigning different weights to equipment anomaly factors, data stability factors, and environmental deviation factors, and setting scoring thresholds based on scheduling strategies and task sensitivity. For example, if data drift exceeds 2σ, equipment response time exceeds the normal range by 30%, and environmental humidity deviates from the target value by more than 10%, the overall disturbance score may exceed a set threshold (e.g., 0.75). Once the disturbance score exceeds the threshold, the system considers the detection task to have a definite risk of interruption or execution anomaly and should immediately initiate a rescheduling process.

[0134] The rescheduling process is not simply a matter of task termination and restart; rather, it involves local path re-inference based on the original experimental graph structure of the current task. The disturbance perception module first marks affected nodes and path edges in the current graph structure. For example, if data drift and environmental deviation are detected at the "partial discharge test second segment" node, the node and its adjacent edges are temporarily removed from the graph or their weights are reduced. Then, the graph inference module is invoked to re-evaluate alternative path nodes and execution sequences. Where conditions permit, the system may select a backup device with similar functionality or postpone the execution time of the task node, recombining execution paths to form a new execution sequence with similar costs to the original path but lower disturbance risk.

[0135] After path reconstruction is completed, the perturbation perception and rescheduling module writes the new path results back to the graph inference module and replaces the original optimized execution path. At the same time, this module also submits the updated task state sequence to the state coordination module, inserting marker events such as "path rollback", "task adjustment" or "node replacement" to ensure the continuity and traceability of the task state flow graph.

[0136] For example, during an insulation resistance test, the current change trend collected by the data acquisition module suddenly became abnormal. The device reported a "poor internal contact" self-diagnostic status, and environmental parameters showed that the humidity rapidly increased from 45% to 65%. Under these circumstances, the disturbance scoring model evaluation result reached 0.82, exceeding the set threshold of 0.70. The system immediately suspended the execution of the current node, called the graph inference module to find an idle backup device IR-02, and rescheduled it to supplement the task in the next available time period. At the same time, the status coordination module recorded the "test interruption" and "path replacement" events to ensure that the entire data chain remained unbroken. The graph inference module also immediately replaced the execution path for the data acquisition module to execute subsequently.

[0137] Through the above processing methods, the disturbance perception and rescheduling module effectively realizes real-time response and structured correction of disturbance factors during the detection task. This not only significantly reduces the task failure rate and the risk of resource waste, but also enables the entire scheduling system to have intelligent diagnosis, adaptive reconstruction and closed-loop operation capabilities, providing a solid technical guarantee for the stability and controllability of power material detection in complex environments.

[0138] Furthermore, the disturbance sensing and rescheduling module is specifically used for:

[0139] The structured task data packets generated by the data acquisition module are parsed, and the abnormal equipment feedback information, the time-series drift characteristics of structural electrical parameters, the abnormal mechanical response patterns, the image recognition error index, and the deviation between environmental parameters and standard deviation are quantified. Each type of abnormal data is assigned a disturbance factor label, and the disturbance factor label is bound one by one with the task node index, equipment number, and timestamp field to form an initial disturbance mapping matrix.

[0140] A disturbance scoring modeling operation is performed on the initial disturbance mapping matrix. Based on the type, weight, and propagation influence factor of each disturbance factor label in the task node path, a four-dimensional disturbance risk function is constructed, which includes node importance, equipment replacement difficulty, path reconstruction cost, and environmental dependence. The disturbance risk score of each task path node is calculated through the four-dimensional disturbance risk function, and a disturbance risk vector containing all risk scores is generated.

[0141] The disturbance risk vector is subjected to global and local anomaly detection. First, it is determined whether any node score exceeds the preset disturbance response threshold. If so, the rescheduling logic is triggered. At the same time, the critical path segments within the affected range are determined. The task graph structure established in the graph reasoning module is called. Local path re-reasoning operation is performed within the affected path segments. Sub-paths are regenerated based on the availability of alternative equipment and the compatibility of environmental conditions. The original path segments are replaced while maintaining the consistency of the global task dependency order.

[0142] After updating and replacing the task node index, device number and time window data corresponding to the sub-path, the corrected task status sequence entries are pushed to the status coordination module, the path reconstruction behavior is marked and the status continuity verification label is updated. At the same time, the structural information of the repaired path segment is sent back to the graph inference module to realize the synchronous update of the optimized execution path, and ultimately ensure that the test task still has the executability and optimal resource allocation capability under disturbance conditions.

[0143] In the experimental scheduling system for power material inspection task coordination and data acquisition described in this invention, the disturbance perception and rescheduling module is a key component to ensure the reliability of task execution and the ability to dynamically adjust scheduling. Its operating mechanism relies on the accurate identification, quantitative evaluation, risk determination, and local path replacement and update of disturbance signals in the acquired data, so as to ensure that the system maintains scheduling feasibility and optimal resource allocation when facing uncertain interference.

[0144] During actual system operation, the data acquisition module generates a structured task data package upon completion of each task node. This data package contains various types of experimental data, including structural electrical parameters, mechanical response data, image acquisition results, and environmental monitoring data. Furthermore, the data package records equipment operating status feedback, such as equipment self-diagnosis results, measurement channel anomaly reports, signal noise interference warnings, and equipment temperature control status. All data is tagged with a task identifier, node index, acquisition timestamp, and equipment number. The disturbance perception and rescheduling module reads and semantically decodes the structured data item by item by calling a standard data parsing program, extracting data dimension fields that can be used for anomaly analysis and classifying them according to field type.

[0145] During the data preprocessing stage, the module abstracts and categorizes different types of anomalies into disturbance factor tags. Specifically, the drift characteristics of structural electrical parameters typically manifest as a continuous deviation from the set range within a short time window, rather than a single abrupt change; mechanical response anomalies are mainly manifested as nonlinear response behavior of vibration acceleration or force signals at specific load points; in image data, image sharpness, boundary matching degree, and noise density can be calculated using an image recognition residual comparison model; environmental parameter deviations are determined by comparing each field with the preset environmental requirement parameters in the task package to obtain the deviation magnitude between the actual measured value and the standard value. In all processed data records, the system binds a disturbance factor tag to each anomaly data, including disturbance type, anomaly degree, trigger timestamp, and task node number, and integrates all disturbance information to form a disturbance mapping matrix, where each row represents an anomaly event and each column is a disturbance dimension attribute field.

[0146] After obtaining the perturbation mapping matrix, the module further performs perturbation scoring modeling. The goal of this process is to assign a perturbation risk score to each perturbed task node, reflecting the degree of threat that the node's current state poses to the overall stability of the experimental path. In this system, the calculation of the perturbation risk score relies on four key parameters. First is node importance, determined by the dependency hierarchy, priority order, and path branch influence of nodes in the task path structure provided by the graph inference module. For example, if a node is the convergence point of multiple subsequent sub-paths, its importance score will be significantly higher than other linear path nodes. The second parameter is the difficulty of equipment replacement, with specific evaluation indicators including whether there are parallel alternative resources for the current equipment, the initialization time required to switch to a replacement device, and the required environmental readjustment time. The third parameter is the path reconstruction cost, reflecting the indirect losses such as scheduling time delays, resource conflicts, and path rollback that may occur if the path segment containing the node is re-inferred. The last parameter is the degree of environmental dependence, mainly based on the sensitivity of the task node's execution process to specific environmental conditions (such as temperature, humidity, electromagnetic fields, and vibration interference). For example, some high-precision mechanical experiments have extremely high requirements for temperature stability.

[0147] After integrating data from these four dimensions for each task node, the module calculates the disturbance risk score for that node using a rule-based weighted summation strategy. This score is a numerical quantification result, which can be filtered and judged based on the disturbance response threshold set by the system. By calculating the risk scores of all nodes one by one, the system finally generates a disturbance risk vector. This vector is arranged in the order in which the nodes appear in the task path, allowing for rapid identification of risk hotspots and disturbance propagation paths through visualization.

[0148] After obtaining the complete disturbance risk vector, the system will perform anomaly detection and rescheduling trigger judgment. During this process, the module first traverses and scans all scores. If any node's disturbance score exceeds the set disturbance response threshold (this threshold can be dynamically adjusted based on system operating experience), the rescheduling logic is triggered. The module will automatically lock the path segment containing the high-risk node and call the pre-stored task graph structure in the graph inference module to determine the contextual dependencies, alternative path branches, and resource consumption of the current path segment. The local path re-inference operation will be based on the principle of minimum path modification, searching for functionally equivalent alternative sub-paths within the limited affected path segment.

[0149] During the alternative path generation process, the module needs to consider not only scheduling feasibility but also multi-dimensional constraints such as the overall resource distribution of the system, the execution order of nodes, and the adaptability of environmental parameters. This re-inference process typically employs a graph traversal-first search strategy, combining scheduling priority, device idle status, and environmental condition matching to comprehensively score and select the optimal candidate path. After finding a sub-path that meets the constraints, the module replaces the original path segment to form a new experimental task execution path, and renumbers each task node in the new path, updating the device identifier and time window fields.

[0150] After the path replacement is completed, the module will push a batch of corrected task state sequence entries to the state coordination module, including the start time, estimated end time, node index, and device identifier for each new task node. In addition, it needs to mark the path reconstruction event type, associate the index mapping relationship between the original and new nodes, and regenerate state continuity labels to facilitate the state connection judgment of subsequent nodes. Simultaneously, the module will also feed back the replaced path segment structure information to the graph inference module, ensuring that all subsequent inference, path scoring, and scheduling control based on the path structure use the latest path as input.

[0151] Through the complete process described above, the disturbance perception and rescheduling module not only has the ability to identify abnormal disturbances in the experimental process in real time, but also can realize rapid local reconstruction of the experimental path through data-driven means, and keep the state synchronized with each module of the system, so as to ensure that the task can still be executed stably and meet the optimal scheduling conditions under dynamic disturbance conditions.

[0152] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A test scheduling system for collaborative power material inspection tasks and data acquisition, characterized in that, include: The task construction module is used to generate standardized test task packages based on a preset test rule base and resource configuration status, and push them to the host computer software corresponding to the target device through a Web Service interface. The test task package includes a task identifier, project code, target device identifier, environmental requirement parameters, and QR code mark. The state coordination module is used to receive the test state event stream fed back by the host computer software, associate the state based on the task identifier in the test task package, construct an event time sequence flow graph for each test task node, and obtain a set of task state sequences with timestamps. The graph reasoning module is used to receive the task state sequence and the environmental requirement parameters in the test task package, construct a test graph structure containing task nodes, equipment state edges and environmental factor edges, and generate the optimized execution path of the current test task based on the graph reasoning mechanism. The data acquisition module is used to control each test device to complete the test items in the scheduled order according to the optimized execution path, and to collect structural electrical parameters, mechanical response data, image data and environmental data after each task node is completed, and encapsulate them into a structured task data package. The task data package inherits the task identifier of the test task package for subsequent disturbance analysis.

2. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 1, characterized in that, Also includes: The disturbance perception and rescheduling module receives structured task data packets generated by the data acquisition module, analyzes the equipment feedback anomalies, data drift characteristics, and environmental deviations contained therein, constructs a disturbance scoring model, and when the score exceeds a preset threshold, performs local path re-inference and scheduling rollback operations based on the original test graph structure, and updates the task state sequence in the state coordination module and the optimized execution path in the graph inference module.

3. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 1, characterized in that, The task construction module is specifically used for: Based on the preset test rule base and resource configuration status, multiple test item combination schemes that match the target power material type and test purpose are retrieved, and a candidate test path set containing multiple task nodes, equipment dependencies and environmental requirement parameters is constructed from them. Perform parameter consistency verification on the task nodes in the candidate detection path set, identify the task execution conflict relationships, including conflicts in test voltage and current levels between devices, incompatible environmental requirements parameters, or overlapping device switching windows, and perform parameter adjustment and path replacement operations on the conflicting paths to obtain the detection path map after conflict resolution. Based on the current resource configuration status, each task node in the detection path map is matched with equipment resources and time window constraints are calculated. Under the premise of satisfying the conditions of equipment idle status, scheduling priority and workstation distribution, a set of task nodes with spatiotemporal executability is generated as the basis for the task scheduling template. The information of each task node in the task scheduling template and the updated environmental requirement parameters in the detection path map are encapsulated into a standardized task data structure. A standardized test task package containing task identifier, project code, target device identifier, environmental requirement parameters and QR code mark is constructed. A binding hash digest is generated for the task path and parameter fields through a traceability coding algorithm to achieve unique identification and subsequent node-level state consistency traceability throughout the task process.

4. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 1, characterized in that, The state coordination module is specifically used for: The system receives the test status event stream periodically reported by the host computer software during the test execution process, performs task identifier verification and node type parsing on each status event, extracts the event type, trigger time, corresponding task node number and device feedback status, and forms a structured status record set. The structured state record set is sorted according to the event time order, and the state records are aggregated based on the task identifier to construct an event time sequence flow graph corresponding to the order of the test task nodes. Each node includes state type, state duration, references to preceding and following dependent nodes, and source device identifier. Perform a state continuity check operation on the event sequence flow graph to determine whether there are abnormal interruptions, repetitions, loss, or time intervals exceeding the limit in the state transmission between task nodes. For the detected abnormal nodes, construct a state repair request and send it to the corresponding host computer software. At the same time, insert placeholder nodes in the graph structure to record the abnormal type and repair time window. Based on the state continuity verification results and the final event time sequence flow graph, a set of timestamped task state sequences is generated for the graph inference module input. Each state entry includes a verification label, device number, task node index, start and end timestamps, which serve as the state input basis for subsequent experimental path optimization.

5. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 1, characterized in that, The graph reasoning module is specifically used for: The task state sequence obtained by the state coordination module is subjected to time-continuous clustering processing. Based on the state start timestamp of the task node and the device identifier, adjacent task nodes are segmented and clustered to generate a set of time-clustered task node segments, which are used to identify potential task concurrency windows and device schedulable intervals. Based on the time-clustered task node segments and the environmental requirement parameters in the test task package, a test graph structure is constructed that includes task nodes, device state edges, and environmental factor edges. The device state edges are used to represent the resource dependencies between task nodes, and the edge weights are dynamically assigned based on device switching consumption, cooling requirements, and resource conflict probability. The environmental factor edges are used to describe the sensitivity of task nodes to external environmental conditions, and the edge weights are set based on the deviation between the current environmental parameters and the environmental requirement parameters. Based on the experimental graph structure, the path cost evaluation process is performed. According to the multi-objective path cost function set by the system, all reachable paths from the task start node to the end node in the graph are scored. The path cost function considers at least the number of device switching, the total execution time, the deviation of environmental parameters and the matching degree of task priority order, and outputs the candidate path sequence after the path cost is sorted. In the candidate path sequence, path segments containing abnormal status marker nodes are identified, and a local path replacement mechanism is invoked. Under the premise of maintaining the order of task node dependencies and resource constraints, the abnormal path segments are replaced with alternative path segments with functional equivalence in the task graph structure. The final optimized execution path with optimal schedulability and structural stability is output as the control input basis for the data acquisition module.

6. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 1, characterized in that, The data acquisition module is specifically used for: Based on the task node scheduling order in the optimized execution path generated by the graph inference module, a collection task instruction set for each task node is dynamically generated. The collection task instruction set includes target device collection channel configuration parameters, target data type identifier, and expected collection time window. The collection task instruction set is synchronously sent to the test device corresponding to the task node and a collection task listening thread is established. The raw data stream fed back by the test equipment after executing the collection task instruction set is parsed in real time and mapped in structure. The structural electrical parameters, mechanical response data, image data and environmental data are extracted respectively. The data segments are marked and bound based on the task node index in the optimized execution path to generate a preliminary collection result set with associated identifiers. Each data record contains a collection timestamp, task identifier and equipment number. The preliminary collection result set is subjected to data integrity detection and time sequence consistency verification. Based on the preset parameter range, frequency threshold and time window overlap rules, the collection data with missing, abnormal jumps or duplicate records is identified, and a set of structured anomaly reports is generated. The anomaly reports will be sent back to the task construction module for future collection task adjustment and equipment maintenance strategy optimization. Based on the data records that have passed the integrity test, the structural electrical parameters, mechanical response data, image data and environmental data are structurally encapsulated according to the task node dimension to form a standardized task data package. The task data package inherits the task identifier of the test task package and establishes a mapping relationship with the output path of the graph inference module through a hash digest function, so as to realize the full-process traceability of the acquisition results and the consistency guarantee of the disturbance analysis basis.

7. The test scheduling system for collaborative power material inspection tasks and data acquisition as described in claim 2, characterized in that, The disturbance sensing and rescheduling module is specifically used for: The structured task data packets generated by the data acquisition module are parsed, and the abnormal equipment feedback information, the time-series drift characteristics of structural electrical parameters, the abnormal mechanical response patterns, the image recognition error index, and the deviation between environmental parameters and standard deviation are quantified. Each type of abnormal data is assigned a disturbance factor label, and the disturbance factor label is bound one by one with the task node index, equipment number, and timestamp field to form an initial disturbance mapping matrix. A disturbance scoring modeling operation is performed on the initial disturbance mapping matrix. Based on the type, weight, and propagation influence factor of each disturbance factor label in the task node path, a four-dimensional disturbance risk function is constructed, which includes node importance, equipment replacement difficulty, path reconstruction cost, and environmental dependence. The disturbance risk score of each task path node is calculated through the four-dimensional disturbance risk function, and a disturbance risk vector containing all risk scores is generated. The disturbance risk vector is subjected to global and local anomaly detection. First, it is determined whether any node score exceeds the preset disturbance response threshold. If so, the rescheduling logic is triggered. At the same time, the critical path segments within the affected range are determined. The task graph structure established in the graph reasoning module is called. Local path re-reasoning operation is performed within the affected path segments. Sub-paths are regenerated based on the availability of alternative equipment and the compatibility of environmental conditions. The original path segments are replaced while maintaining the consistency of the global task dependency order. After updating and replacing the task node index, device number and time window data corresponding to the sub-path, the corrected task status sequence entries are pushed to the status coordination module, the path reconstruction behavior is marked and the status continuity verification label is updated. At the same time, the structural information of the repaired path segment is sent back to the graph inference module to realize the synchronous update of the optimized execution path, and ultimately ensure that the test task still has the executability and optimal resource allocation capability under disturbance conditions.

Images