Multi-agent driven secondary system operation intelligent collaborative control method, device and system

Abstract

The present application relates to the technical field of electric digital data processing, and particularly relates to a kind of secondary system operation intelligent collaborative control method, device and system driven by multiple intelligent agents;The method comprises: defining the data structure of several job activities, and the data structure encapsulates standard output data object. According to the mapping relationship of the preset resource mapping strategy, the association index between the fact instance, the material resource and the intelligent capability unit is established. The defined data structure is imported into the routing engine to construct the business operation template, and the job activity instance is distributed to the corresponding responsible subject according to the association index. In response to the update operation of the job activity instance on the standard output data object, the downstream job activity instance subscribed to the standard output data object is retrieved, and the cross-process data object transfer is performed. In this way, the technical problem that the configuration accuracy is insufficient due to the multiple breakpoints in the electric digital processing link of the existing secondary system debugging collaboration is solved.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a method, apparatus and system for intelligent collaborative control of secondary system operations driven by multiple agents. Background Technology

[0002] Secondary system commissioning is a typical complex electrical digital data processing scenario, involving collaboration among multiple stakeholders such as integrators, equipment manufacturers, operation managers, and acceptance personnel. It requires the circulation and management of multiple types of model files, such as Intelligent Electronic Device Capability Description (ICD) and Substation Configuration Description (SCD). It also covers multiple stages of operations, including secondary circuit verification, device commissioning, and configuration verification, which places high demands on the flexibility of process control, the standardization of data management, and the efficiency of collaborative operations.

[0003] In existing technologies, most on-site commissioning collaboration solutions still rely on fixed process engines, general document sharing tools, and social software communication to achieve multi-party collaboration. These solutions generally suffer from drawbacks such as difficulty in process adjustment, inconsistent document versions, and inconvenient information traceability. To address these issues, existing technology (application publication number CN120235382A) discloses a method for mobile control of substation secondary equipment. This method constructs a control information database integrating personnel information, substation information, secondary equipment ledgers, commissioning tool information, and task information. It can automatically load standardized operating procedures based on preset task types and achieve automatic synchronization of the entire task execution process with the ledger, thereby improving the standardization and timeliness of commissioning operations to a certain extent. However, this solution still has significant limitations in terms of dynamic adaptation and data linkage processing of electrical digital processes: On the one hand, its workflow is generated entirely based on preset fixed task types, which cannot adapt to the dynamic needs such as temporary changes and abnormal handling commonly encountered during on-site debugging. If the work nodes need to be adjusted, the task template must be manually reconstructed, resulting in insufficient flexibility of the digital workflow and difficulty in matching real-time changes in on-site operations. On the other hand, its model files are only archived as static data in the information database, without establishing a dynamic association mechanism between file status and work process nodes. File circulation and task execution are disconnected, which can easily lead to problems such as file version mismatch and inability to associate operation records with corresponding data. The traceability of debugging data still needs to be improved. In addition, the configuration consistency verification process relies on manual retrieval of different versions of files for comparison, which does not achieve automatic connection between the verification process and the overall debugging process. The degree of automation of electrical digital processing is insufficient, which can easily lead to verification omissions. Due to the combined effect of the above-mentioned defects, the existing secondary system debugging and coordination digital processing link has multiple breakpoints, which cannot simultaneously meet the process flexibility, data standardization and operation efficiency requirements of multiple scenarios such as new station debugging, completion acceptance, and renovation and expansion implementation. Ultimately, this results in low debugging efficiency and insufficient configuration accuracy. Summary of the Invention

[0004] To address the aforementioned shortcomings or deficiencies, this invention provides a multi-agent driven intelligent collaborative control method, device, and system for secondary system operations. This solution addresses the technical problem of insufficient configuration accuracy in existing secondary systems due to multiple breakpoints in the electrical digital processing link for debugging and collaboration.

[0005] This invention provides a multi-agent driven intelligent collaborative control method for secondary system operations, comprising: defining a data structure for several operation activities based on preset debugging operation logic rules, wherein the data structure encapsulates a standard output data object, and the debugging operation logic rules define the dependency relationships and state transition conditions between the input and output data objects of each operation activity; constructing mapping relationships according to a preset resource mapping strategy to establish an association index between event instances, material resources, and intelligent capability units; importing the defined data structure into a routing engine to construct a business operation template, and distributing operation activity instances to corresponding responsible entities according to the association index; and responding to the operation activity instances of the responsible entities by performing update operations on the standard output data object, retrieving downstream operation activity instances that subscribe to the standard output data object, and performing cross-process data object transfer.

[0006] According to a second aspect, this invention provides a multi-agent-driven intelligent collaborative control system for secondary system operations. This system is deployed on a distributed computing node cluster, which includes routing engine nodes, global data plane nodes, and security control nodes. The system includes a processing unit and a storage unit. The storage unit stores executable instructions. When the executable instructions are invoked by the processing unit, they implement any of the multi-agent-driven intelligent collaborative control methods for secondary system operations in this invention's embodiments.

[0007] According to a third aspect, the present invention provides a power device comprising: at least one processing unit; and a storage unit communicatively connected to the at least one processing unit. The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes it to execute any of the multi-agent driven intelligent cooperative control methods for secondary system operations in the embodiments of the present invention.

[0008] According to another aspect of the present invention, a medium for storing executable instructions is provided, wherein the computer instructions are used to cause a computer to execute any of the multi-agent driven secondary system operation intelligent cooperative control methods in the embodiments of the present invention.

[0009] The present invention provides a multi-agent driven intelligent collaborative control method for secondary system operations, which is achieved through four core steps: data structure definition, resource mapping construction, business template generation, and cross-process data transfer. This system defines data structures for several work activities based on preset debugging operation logic rules, and encapsulates standard output data objects within these structures, providing a standardized data foundation for the full-process digital management and control of debugging operations. By defining the dependencies and state transition conditions between input and output data objects for each work activity, rigid constraints on data flow across multiple work stages are established, preventing data misordering and logical conflicts from the source. Mapping relationships are constructed based on preset resource mapping strategies to establish association indexes between event instances, physical resources, and intelligent capability units, breaking down data silos between physical equipment, business tasks, and operational logic in traditional debugging, and realizing the digital association of multi-dimensional debugging elements. The defined data structures are imported into the routing engine to build business operation templates, and work activity instances are distributed to corresponding responsible entities based on association indexes, achieving automated orchestration and precise dispatch of debugging tasks. In response to the work activity instances of the responsible entities, update operations are performed on standard output data objects, downstream work activity instances subscribed to standard output data objects are retrieved, and cross-process data object transfer is executed, constructing a data state-driven event response mechanism.

[0010] In this technical solution, the present invention addresses the shortcomings of the background technology, such as rigid collaborative processes caused by reliance on fixed process engines, insufficient configuration accuracy due to the separation of documents and processes, and difficulties in information traceability. By introducing data structure encapsulation and dependency definition, debugging operations are abstracted into programmable and transferable data objects, thus providing flexible data-level support for solving the problem of rigid processes. By establishing an association index for event instances, material resources, and intelligent capability units, scattered physical model files, logical tasks, and manual operations are indexed into a unified digital space, solving the fundamental problem of the disconnect between document management and work processes. Through a cross-process data transfer mechanism based on standard output data object update operations, automatic linkage and triggering of upstream and downstream work links at the data level are achieved, replacing the fragmented collaboration mode that relies on traditional manual communication or social software. Therefore, the technical solution of the present invention solves the technical problem of insufficient configuration accuracy caused by multiple breakpoints in the electrical digital processing link of existing secondary systems during debugging collaboration, improving the automation level, data consistency, and process controllability of substation secondary system debugging operations at the electrical digital data processing level. Attached Figure Description

[0011] Figure 1 This is a flowchart of a multi-agent driven intelligent collaborative control method for secondary system operations according to an embodiment of the present invention; Figure 2A schematic diagram of an integrated debugging service dynamic scheduling architecture based on a routing engine in another embodiment of the present invention; Figure 3 A schematic diagram of the collaborative scheduling architecture for job tool invocation and business activity status based on the routing engine in the same embodiment of the present invention; Figure 4 This is a block diagram of an electrical device used to implement embodiments of the present invention. Detailed Implementation

[0012] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] During the development of this invention, researchers conducted numerous experiments and data analysis, discovering a strong causal relationship between the state changes of standard output data objects for job activities and the start-up readiness conditions of downstream job instances: when the upstream job output's full-site system configuration description file or device configuration file completes a version update and its status flag jumps to a valid value range, all downstream job activity instances dependent on that file immediately possess the preconditions for execution. Based on this relationship, this invention innovatively proposes this technical solution, utilizing standardized data objects encapsulated in data structures as information carriers. It defines a data dependency graph through preset debugging job logic rules and combines this with the routing engine's real-time retrieval mechanism of the subscription registry, thereby achieving automatic cross-process data object transfer and chain-like triggering of job instances, embodying the core concept of "data-driven" collaborative scheduling.

[0014] Specifically, the invention team discovered through experiments that traditional debugging collaboration methods have technical flaws: they rely on fixed process engines for task flow, failing to perceive changes in the state of underlying model files, leading to a disconnect between process nodes and actual data states. Furthermore, cross-process communication relies on manual intervention, resulting in information delays and errors. However, the data structure encapsulation mechanism proposed in this invention maps debugging files from the physical world into digital objects with unique resource identifiers and state identifiers within the global data plane, improving the controllability and traceability of data flow. By constructing an association index between event instances, physical resources, and intelligent capability units, unified modeling and precise association of debugging tasks, physical devices, and operational logic in the digital space can be achieved. By responding to update operations of standard output data objects to execute cross-process data object transfers and automatically retrieving downstream operational activity instances based on preset dependencies, the efficiency bottlenecks and misjudgment risks associated with manual coordination are completely eliminated.

[0015] Therefore, this invention provides a multi-agent driven intelligent collaborative control method for secondary system operations, applicable to a multi-agent driven intelligent collaborative control system for secondary system operations (hereinafter referred to as the "system"). This system can complete the entire process of substation secondary system commissioning through the collaborative scheduling of routing engine nodes, global data plane nodes, and safety control nodes in a distributed computing node cluster. It enables the definition of operation activity data structures, the construction of association indexes between event instances, material resources, and intelligent capability units, the generation of business operation templates, and the transfer of cross-process data objects. Specifically, this system can be deployed in various hardware environments, including but not limited to: industrial-grade field commissioning terminals equipped with multi-core processors, substation local gateway devices with edge computing capabilities (real-time computing mode on the side close to the data source), virtualized server clusters deployed in private cloud environments, security-certified portable field operation computers, and remote collaboration servers on the integrator and equipment manufacturer sides. Figure 1 As shown, the method may include: Step S110: Define the data structure of several job activities according to the preset debugging job logic rules.

[0016] The data structure encapsulates standard output data objects. The debugging operation logic rules define the dependencies and state transition conditions between the input and output data objects of each operation activity. An operation activity refers to an atomic task unit with clear start and end boundaries and logical functions during the debugging of the secondary system of a smart substation, such as the creation of a system configuration description file (SCD) for the entire station and the download of equipment configuration. A standard output data object refers to a data entity with a standardized format and multi-dimensional status identifier generated after the operation activity is completed, such as an SCD file in the "approved" state. Dependencies refer to the logical constraints that the output data of the upstream operation activity serves as a necessary prerequisite for the execution of the downstream operation activity. State transition conditions refer to the Boolean logic expressions that must be satisfied when the status identifier (such as pending review, downloaded, or verified as consistent) of a data object changes under the drive of an operation activity.

[0017] Specifically, the system can use a structured definition engine to read pre-set debugging process cards and abstract the "SCD production" operation into a data structure containing input and output ports. The system assigns a unique globally unique identifier (UUID) to this data structure and binds it to the standard output data object "SCD file" at the output port. It also pre-sets an "approval status" attribute field for this object, with values ​​limited to {0: pending approval, 1: approved, 2: rejected}.

[0018] For example, the system defines a data structure for the "SCD Review" job activity, stipulating that the input data object of this structure must be an "SCD file," and its real-time status flag must be equal to 1 (i.e., review passed); simultaneously, it defines its output data objects as "review comments" and the updated "SCD file." In the scenario of commissioning a new site, the system, through the above definition, enforces that the "device configuration download" stage can only proceed after the "SCD creation" is completed, effectively avoiding the risk of skipping steps in the process due to human error in traditional operations.

[0019] Step S120: Construct mapping relationships according to the preset resource mapping strategy to establish an association index between event instances, object resources and intelligent capability units.

[0020] Among them, the resource mapping strategy refers to the set of rules used to associate and align debugging elements in the physical world with abstract models in the digital space; the event instance refers to the instantiation of a specific debugging project (such as "new construction project of a 220 kV substation") into an independent process context in the digital space, which contains all data objects and task states related to the project; the physical resources refer to the digital mapping of physical entities or logical files involved in the debugging process, including intelligent electronic devices (IEDs), whole-station system configuration description files, intelligent electronic device capability description files (ICDs), etc.; the intelligent capability unit refers to a callable microservice interface that encapsulates the operation permissions of debugging personnel and the execution logic of professional tools, such as "SCD automatic verification tool interface" or "configuration download execution permissions"; the association index refers to a hash table (a data structure that stores data through key-value pairs) built between the event instance, physical resources, and intelligent capability unit, used to achieve fast addressing and binding of the three.

[0021] Specifically, the system can scan the current project instance and extract the project name as the primary key of the instance; traverse the .scd and .icd files in the project directory, assign resource identifiers to them and establish an object resource index; at the same time, read the permission configuration file, bind the debugging personnel account holding a specific digital certificate to the "SCD Audit" intelligent capability unit, and generate an associated index entry containing three-dimensional information of "personnel-permissions-tools".

[0022] For example, the system establishes a case instance index key of "Project_220kV_001" for the "New Construction Project of a 220kV Substation"; maps the "line_protection.icd" file under this project to the material resource ID "IED_Line_01"; and binds the engineer account "Engineer_A" with advanced privileges to the intelligent capability unit "SCD_Modify_V2.0". When the engineer logs into the system, the system automatically filters and displays only the project files and tool menus that the engineer is authorized to operate by querying the above-mentioned associated index, thus realizing fine-grained access control based on digital identity.

[0023] Step S130: Import the defined data structure into the routing engine to build the business operation template, and distribute the job activity instance to the corresponding responsible entity according to the associated index.

[0024] Among them, the routing engine refers to the task scheduling kernel based on a Directed Acyclic Graph (DAG, a data structure consisting of vertices and directed edges without loops), which is responsible for resolving the dependencies between job activities and planning execution paths; the business operation template refers to the executable workflow definition composed of several job activity data structures linked according to dependencies; the job activity instance refers to the specific task item generated after the business operation template is instantiated in the project, which includes specific execution parameters, deadlines, and current status; the responsible entity refers to the natural person or automated agent program bound in the associated index that has the authority to execute specific intelligent capability units.

[0025] Specifically, the system can input a predefined job activity data structure (such as "Data Collection" -> "SCD Production" -> "SCD Review") into the routing engine. The engine parses the dependencies (such as "SCD Review" depending on the output of "SCD Production") and constructs a DAG-style business operation template. When the project starts, the routing engine queries the responsible entity bound to the "SCD Review" intelligent capability unit based on the association index and writes the job activity instance to the head of the responsible entity's message queue (a middleware for communication between applications).

[0026] For example, the system loads the "New Station Debugging" service template and parses out that the "Equipment Configuration Download" node must be executed after "SCD Approval". When the status of the "SCD Approval" job activity instance is updated to "Completed", the routing engine immediately searches the associated index and finds that "Maintenance Team B" is bound as the responsible entity of the "Equipment Configuration Download" intelligent capability unit. Then, it automatically pushes a work order task containing a specific list of devices to be downloaded (such as the #1 main transformer protection device) to the mobile terminal of "Maintenance Team B", so as to achieve accurate task dispatch without manual intervention.

[0027] Step S140: In response to the job activity instance of the responsible entity performing an update operation on the standard output data object, retrieve downstream job activity instances that subscribe to the standard output data object, and perform cross-process data object transfer.

[0028] Among them, update operation refers to an atomic transaction that modifies the binary content of the standard output data object or assigns a value to its status identifier field; subscription refers to the listening intent of a downstream job activity instance registered in the routing engine for a specific data object or its specific state change; downstream job activity instance refers to a subsequent task item that depends on the current standard output data object as input; cross-process data object transfer refers to serialized data transmission between different operating system processes (such as human-computer interaction process and background computing process) through inter-process communication (IPC, such as sockets or shared memory mechanisms).

[0029] Specifically, the system can monitor changes in the status identifiers of standard output data objects in the global data plane. Once the status identifier of the "SCD file" changes from "pending review" to "approved," the routing engine immediately scans the subscription registry to locate the "Device Configuration Download List Generation" job activity instance that has subscribed to this status change. The system then calls the serialization interface to encapsulate the updated "SCD file" object into a cross-process message payload, transmits it to the process space where the "Device Configuration Download List Generation" instance resides via the IPC mechanism, and triggers that instance to enter the ready state.

[0030] For example, when an auditor clicks the "Approve" button on the human-computer interaction interface, updating the status flag of "SCD File V2.1" to 1 (approved), the system captures this update operation. The routing engine searches and finds that the "Device Configuration Download List Generation" instance has subscribed to the "approved" event. It then automatically pulls "SCD File V2.1" and the previous version "SCD File_V2.0" for binary differential comparison, generating a "Download List.json" file containing a list of differing devices. This file is then used as the standard output data object and transmitted to the background comparison process via IPC mechanism. The entire process takes less than 200 milliseconds, realizing a data-driven business closed loop.

[0031] The technical solution of this embodiment provides a multi-agent driven intelligent collaborative control method for secondary system operations. This method is achieved through four core steps: data structure definition, resource mapping construction, business template generation, and cross-process data transfer. This system defines data structures for several work activities based on preset debugging operation logic rules, and encapsulates standard output data objects within these structures, providing a standardized data foundation for the full-process digital management and control of debugging operations. By defining the dependencies and state transition conditions between input and output data objects for each work activity, rigid constraints on data flow across multiple work stages are established, preventing data misordering and logical conflicts from the source. Mapping relationships are constructed based on preset resource mapping strategies to establish association indexes between event instances, physical resources, and intelligent capability units, breaking down data silos between physical equipment, business tasks, and operational logic in traditional debugging, and realizing the digital association of multi-dimensional debugging elements. The defined data structures are imported into the routing engine to build business operation templates, and work activity instances are distributed to corresponding responsible entities based on association indexes, achieving automated orchestration and precise dispatch of debugging tasks. In response to the work activity instances of the responsible entities, update operations are performed on standard output data objects, downstream work activity instances subscribed to standard output data objects are retrieved, and cross-process data object transfer is executed, constructing a data state-driven event response mechanism.

[0032] In this technical solution, this embodiment addresses the shortcomings of the background technology, such as rigid collaborative processes, insufficient configuration accuracy due to the reliance on fixed process engines, and difficulties in information traceability. By introducing data structure encapsulation and dependency definition, debugging operations are abstracted into programmable and transferable data objects, thus providing flexible data-level support for solving the problem of rigid processes. By establishing an association index for event instances, material resources, and intelligent capability units, scattered physical model files, logical tasks, and manual operations are indexed into a unified digital space, solving the fundamental problem of the disconnect between document management and work processes. Through a cross-process data transfer mechanism based on standard output data object update operations, automatic linkage and triggering of upstream and downstream work links at the data level are achieved, replacing the fragmented collaboration mode that relies on traditional manual communication or social software. Therefore, the technical solution of this embodiment solves the technical problem of insufficient configuration accuracy caused by multiple breakpoints in the electrical digital processing link of existing secondary systems during debugging collaboration, improving the automation level, data consistency, and process controllability of substation secondary system debugging operations at the electrical digital data processing level.

[0033] In another embodiment, Table 1 below shows the integrated commissioning business process operation activity mapping table, which defines in detail the specific flow nodes, operation specifications and data status change logic of electrical digital data in the entire life cycle of substation secondary system commissioning.

[0034] Specifically, Table 1 breaks down the complex commissioning project into eight core operational activities, covering everything from initial data collection, basic information extraction, full lifecycle management of SCD files (creation, review, download, and verification), equipment configuration change comparison, to final test verification. Each operational activity clearly defines the specific execution actions, input / output data objects, and state transition conditions in the global data plane. By parsing this mapping table, the system can automatically construct the corresponding finite state machine model and generate standardized operation instructions and data verification rules for each node, thereby achieving digital modeling and automated control of commissioning operations. To more clearly illustrate the application of the above mapping table in actual business scenarios, this embodiment uses the "220 kV line protection commissioning project" as an example for detailed explanation. When the commissioning project starts, the system first triggers the "Data Collection" operational activity (Sequence 1), automatically capturing original data such as secondary drawings, main wiring diagrams, and protection device manuals to form the initial data source. Subsequently, it proceeds to "Substation Information Extraction" (Sequence 2), where the system automatically generates the substation logical node topology structure required for the SCD file based on the drawings. Next, the commissioning personnel performed step 3, "SCD Creation," to complete the initial file setup. In step 4, "SCD Review," an expert team reviewed the virtual loop connections. If errors were found, a modification process was triggered until the review was approved. During the equipment arrival phase, the system performed step 5, "Equipment Configuration Download List Generation," accurately calculating which protection devices (such as line protection device A) had changed CID files and needed to be re-downloaded by comparing the old and new SCD files. Subsequently, step 6, "Equipment Configuration Download," distributed the new configuration to the physical equipment and received the download confirmation message. To ensure everything went smoothly, the system further performed step 7, "Equipment Configuration Consistency Verification," deeply comparing the actual operating status of the field equipment with the SCD file. If discrepancies were found, it was determined whether to modify the SCD or re-download it. Finally, the system performed step 8, "Equipment Testing and Verification," continuously monitoring data during load testing and handling all potential configuration issues in a closed-loop manner, thereby ensuring data consistency and system reliability throughout the commissioning process.

[0035] In another embodiment, Table 2 below shows the data flow mapping table for the entire lifecycle of integrated commissioning services. This mapping table defines in detail the specific input sources, output objects, and state transition identifiers of electrical digital data in the entire lifecycle of substation secondary system commissioning.

[0036] Specifically, Table 2 breaks down the complex commissioning project into eight core operational activities. By parsing this mapping table, the system can automatically construct the corresponding finite state machine model and generate standardized work instructions and data verification rules for each node, thereby achieving digital modeling and automated management of commissioning operations. To more clearly illustrate the application of the above mapping table in actual business scenarios, this embodiment uses the "220 kV line protection commissioning project" as an example for detailed explanation. When the commissioning project starts, the system first triggers the "Data Collection" operation (Section 1), automatically capturing original data such as secondary drawings, main wiring diagrams, and protection device manuals to form the initial data source. Then, it proceeds to "Substation Information Extraction" (Section 2), where the system automatically generates the substation logical node topology structure required for the SCD file based on the drawings. Next, the commissioning personnel execute "SCD Creation" (Section 3), completing the initial file construction. In the "SCD Review" (Section 4), an expert team reviews the virtual loop connections. If errors are found, a modification process is triggered until the review is passed. During the equipment arrival phase, the system executes step 5, "Equipment Configuration Download List Generation," which compares the old and new versions of the SCD file to accurately calculate which protection devices (such as line protection device A) have changed their CID files and need to be re-downloaded. Subsequently, step 6, "Equipment Configuration Download," sends the new configuration to the physical equipment and receives the download confirmation message. To ensure everything goes smoothly, the system further executes step 7, "Equipment Configuration Consistency Verification," which performs a deep comparison between the actual operating status of the field equipment and the SCD file. If discrepancies are found, it determines whether to modify the SCD or re-download the entire system. Finally, the system executes step 8, "Equipment Testing and Verification," continuously monitoring data during load testing and handling all potential configuration issues in a closed-loop manner, thereby ensuring data consistency and system reliability throughout the commissioning process.

[0037] In another embodiment, as follows: Figure 2 The diagram shows a dynamic scheduling architecture for integrated debugging services based on a routing engine. This architecture achieves efficient flow and accurate distribution of electrical digital data in complex debugging processes through modular design.

[0038] Specifically, the core hub of the system is the routing engine, which integrates a business template parsing module, a business activity instance management module, and a message management module. These three modules work together to support upper-layer business operations. The business template parsing module is mainly responsible for the structured parsing of the integrated debugging business templates that have been accessed, transforming them into a machine-executable logical framework. The business activity instance management module is responsible for responding to external business instantiation instructions (such as creating projects and setting up operators) and generating specific job activity instances within the system. The message management module is responsible for the asynchronous distribution of task status change notifications and anomaly alarms. To more clearly illustrate the application of the above architecture in actual business scenarios, this embodiment uses the "220 kV line protection debugging project" as an example for detailed explanation. When the person in charge of debugging uploads the "220 kV line protection integrated debugging business template" on the human-machine interface, the template first enters the business template parsing module inside the routing engine. The business template parsing module performs in-depth analysis of the standardized data objects, intelligent capability unit mapping relationships, and state transition conditions in the template, and registers them to the system's global data plane, constructing the initial business logic skeleton. Subsequently, the debugging supervisor triggers the "Create Project" command and designates "Debugging Team A" as the responsible entity for the current task. This command is forwarded to the Business Activity Instance Management module via the routing engine. Based on the parsed business logic skeleton and the configured operator permission mapping table, the Business Activity Instance Management module instantiates a series of specific task activity instances in memory, such as "SCD File Generation," "Virtual Terminal Connection Verification," and "Protection Setting Download," and strongly binds these instances to the ownership identifier of "Debugging Team A." During the debugging execution phase, if the "Virtual Terminal Connection Verification" task activity instance completes successfully, the Business Activity Instance Management module triggers a state transition in its internal state machine and sends the state change event to the Message Management module. The Message Management module, based on pre-established message queue mapping rules, accurately pushes the notification message "Verification complete, please download settings" to the message queue bound to "Debugging Team A," thereby driving the automatic triggering of downstream tasks. If an anomaly occurs during execution, the Message Management module is also responsible for pushing the anomaly alarm information to the terminals of the relevant responsible persons in real time, ensuring closed-loop control of the debugging process and timely anomaly response.

[0039] In another embodiment, as follows: Figure 3 The diagram shows a collaborative scheduling architecture for job tool invocation and business activity status based on a routing engine. This architecture enables efficient flow and accurate distribution of electronic digital data in complex debugging processes through standardized interfaces and data broadcasting mechanisms.

[0040] Specifically, the core hub of the system is the routing engine, which integrates a standard Application Programming Interface (API) layer, a business activity instance management module, and a message management module. The standard API layer serves as the unified entry point for system interaction with the outside world, responsible for receiving external call requests and distributing execution results. The business activity instance management module contains specific business activity instances (such as business activity instance A and business activity instance B), a data broadcast analysis submodule, and underlying business activity management components, primarily responsible for business process instantiation, state transitions, and data sharing analysis. The message management module is responsible for the asynchronous distribution of task status change notifications and anomaly alarms. To more clearly illustrate the application of this architecture in actual business scenarios, this embodiment uses the specific operation of "downloading protection settings for a 220 kV main transformer" as an example for detailed explanation. When the commissioning personnel need to perform the setting download operation on the front-end interface, the front-end system initiates a "tool call" request through the standard API layer of the routing engine. This request carries the unique identifier (Uniform Resource Identifier, URI) "Tool_Download_Protect" of the target operation tool and the identifier of the current operation's associated operation activity instance A. After receiving a request, the routing engine authenticates and verifies its parameters using the standard API layer. If the verification is successful, the call instruction is forwarded to Business Activity Instance A in the Business Activity Instance Management module. Business Activity Instance A responds to the call instruction, activating the underlying fixed-value download tool and beginning the logic for reading and downloading fixed-value data. During tool execution, Business Activity Instance A feeds back its current execution progress (e.g., "Progress 30%, verifying the integrity of the fixed-value sheet") and intermediate results to the data broadcast analysis submodule via the internal communication bus. The data broadcast analysis submodule parses and evaluates the received progress information. Once it confirms that the current progress meets the preset transition conditions, it triggers a state transition from Business Activity Instance A to Business Activity Instance B, and simultaneously returns the latest progress results to the front-end system via the standard API layer, allowing debugging personnel to monitor the job status in real time. Meanwhile, when Business Activity Instance B receives the transferred control, if it detects an anomaly such as a communication timeout during the fixed-value download process, Business Activity Instance B will immediately send the anomaly event to the message management module. Based on pre-established message queue mapping rules, the message management module accurately pushes the alarm message "Failed to download fixed value, please check network connection" to the mobile terminal of the person in charge of debugging, ensuring that abnormal situations can be handled in a timely manner, thereby driving the closed-loop control of the entire debugging process and the timeliness of abnormal response.

[0041] In some embodiments, a mapping relationship is constructed according to a preset resource mapping strategy to establish an association index between event instances, object resources, and intelligent capability units, including: Based on the preset access control policy, establish a permission mapping table between collaborative entities and intelligent capability units, and configure the corresponding identity authentication credentials.

[0042] The access control policy refers to a set of role-based access control (RBAC) rules that define the boundaries of access permissions for different roles to intelligent capability units; the collaborating entity refers to the natural persons or automated services participating in debugging, including integrator engineers and equipment manufacturer debugging terminals; the permission mapping table is a set of key-value pairs with the collaborating entity's identity identifier as the primary key and the list of allowed intelligent capability units as the value domain; and the identity authentication credential refers to a digital certificate or dynamic token issued by a certificate authority, used to verify the legitimate identity of the collaborating entity.

[0043] Specifically, the system can read pre-set role and permission configuration files, extract the correspondence between the identity identifier of the collaborating entity and its assigned role, and then generate a permission mapping table based on the list of intelligent capability units associated with each role. Simultaneously, it issues a digital certificate with an 8-hour validity period as authentication credentials to the collaborating entity. For example, an integrator's debugging engineer account "INT_Debug_05" is authorized to access two intelligent capability units, "SCD Automatic Verification Tool" and "ICD File Parsing Tool," through the permission mapping table. The system issues an X.509 format digital certificate for this account, containing a hash value of the allowed list of intelligent capability units. The certificate validity is verified each time the tools are accessed to prevent unauthorized operations.

[0044] The debugging job instance is parsed into a hierarchical subtask list, the logical execution body of each subtask is encapsulated into an intelligent capability unit, and a call binding relationship is established between the subtask list and the intelligent capability unit.

[0045] Among them, the hierarchical subtask list refers to a directed linked list of subtasks nested according to their dependencies, with the root job as the head node and each node corresponding to an atomic subtask; the logical execution body refers to the executable code block or manual operation specification corresponding to the subtask; the call binding relationship refers to storing the resource locator (Uniform Resource Locator, or URL for short) of the corresponding intelligent capability unit in the node of the subtask list, which is used for addressing when triggering execution.

[0046] Specifically, the system can recursively parse the work decomposition structure of debugging job instances, breaking down the top-level "secondary system debugging" job into first-level subtasks such as "data collection," "SCD creation," and "equipment download." "SCD creation" is further broken down into second-level subtasks such as "ICD file import" and "virtual loop configuration," forming a hierarchical subtask list containing 12 first-level subtasks and 37 second-level subtasks. Simultaneously, the logical execution body of "virtual loop configuration" is encapsulated as a callable microservice interface, serving as an intelligent capability unit. The resource locator "http: / / 10.10.1.20:8080 / api / XXXX" is written into the "virtual loop configuration" node of the subtask list, completing the call binding. For example, in the debugging scenario of a "220 kV substation construction project," the subtask list generated by the system explicitly marks the "equipment download" subtask as dependent on the "SCD approval passed" status. The call binding relationship ensures that only intelligent capability units with the corresponding permissions can be triggered, avoiding task out-of-order execution.

[0047] Build an event-driven architecture, listen to the state variables of object resources, and broadcast a state update event to the intelligent capability units that subscribe to the version identifier when the version identifier of the model file changes.

[0048] Among them, event-driven architecture refers to an asynchronous communication architecture based on the publish-subscribe pattern, which consists of three parts: event producers, event channels, and event consumers; state variables refer to the core attribute fields of material resources, including the version number and modification timestamp of the model file; version identifier refers to the unique version string of the model file, in the format of "major version number.minor version number.revision number"; state update event refers to a structured message containing the unique identifier of the material resource, the state before the change, the state after the change, and the change timestamp.

[0049] Specifically, the system can register state variable listeners in the object resource table of the global data plane. When a write operation is detected in the version identifier field of a model file, a state update event containing change details is automatically generated. This event is then pushed to all intelligent capability units that have subscribed to the unique identifier of that model file via a distributed message queue. For example, if a debugger uploads a new version of the "line_protection.icd" file, updating the version identifier from "V1.0.2" to "V1.0.3", the system, upon detecting this change, immediately broadcasts the state update event to the "SCD Automatic Verification Tool" intelligent capability unit that has subscribed to the unique identifier of that ICD file. Upon receiving the event, the tool automatically triggers a compliance verification of the new ICD file, eliminating the need for manual verification. The event broadcast delay is less than 50 milliseconds.

[0050] Establish a context association mechanism for unstructured data, bind communication sessions with unique identifiers of job activity instances, and parse semantic features in communication sessions to generate structured pending instructions.

[0051] Among them, unstructured data refers to communication content that does not have a fixed format, including instant messages and voice call records; the context association mechanism refers to the indexing rules that attach unique identifiers of associated business objects when storing unstructured data; semantic features refer to key information extracted from unstructured text that conforms to predefined intents, including task content, execution time, and associated data objects; and structured to-do instructions refer to standardized task items that conform to the system task format and include the execution subject, deadline, and associated data objects.

[0052] Specifically, the system can embed an interception plugin into the message storage interface of the instant messaging module to extract the unique identifier of the job activity instance to which each communication session belongs, and store it as an extended attribute of the message. Simultaneously, it uses a Natural Language Processing (NLP) model to segment and identify the intent of the communication content. When semantic features containing task requests are identified, a structured pending instruction containing the unique identifier of the corresponding job activity instance and the associated data object is automatically generated and written to the task queue of the responsible entity. For example, if an integrator engineer sends the message "Complete the virtual loop verification of the #1 main transformer SCD file before 10:00 AM tomorrow" in a chat session for the "Project_220kV_001" project, the system identifies the unique identifier of the job activity instance associated with this session as "ACT_SCD_CHECK_001," extracts the time "10:00 AM tomorrow," the task content "virtual loop verification," and the associated object "#1 main transformer SCD file" from the semantic features, and automatically generates a pending instruction to be written to the task queue of the corresponding commissioning personnel, avoiding task omissions due to message overload.

[0053] Therefore, according to the above implementation method, the system can realize the unified digital modeling of collaborative subjects, work tasks, physical resources and operation logic in the entire debugging process, complete fine-grained access control through permission mapping table, realize automated task scheduling through the binding of sub-task chain list and intelligent capability unit, realize seamless connection from data change to task triggering through event-driven architecture, realize the structured transformation of fragmented information through context association and semantic parsing of unstructured data, break through the breakpoint of electrical digital processing link in the secondary system debugging scenario, and improve the efficiency of electrical digital data flow and control accuracy.

[0054] In some embodiments, the defined data structure is imported into the routing engine to build a business operation template, and job activity instances are distributed to the corresponding responsible entities according to the associated index, including: The input and output data objects in the data structure are mounted to the global data plane, and each data object is assigned a unique resource identifier and access control metadata.

[0055] The global data plane refers to a unified data access layer deployed on top of distributed memory (a pool of memory resources aggregated across multiple physical machines), providing standardized data read and write interfaces for the upper-layer routing engine and various intelligent capability units. The unique resource identifier refers to a globally unique string generated in accordance with the Uniform Resource Name (URN) specification, a string format for permanently identifying digital resources, defined as "urn:sgcc:ds:ObjectType:UUID", used to accurately locate data objects in the network. Access control metadata refers to the permission label attached to the header of the data object, including the data owner, the list of intelligent capability units allowed to read and write, and the data validity period field.

[0056] Specifically, the system can call the registration interface of the global data plane to mount the input data object of the "Full Station System Configuration Description File" to the memory address space, generating a unique resource identifier "urn:sgcc:ds:SCD:8a7b6c5d-4e3f-2a1b-9c8d-7e6f5a4b3c2d". Simultaneously, it writes to the access control metadata to allow the "SCD verification tool" and "configuration download tool" to perform read operations, and to allow the "SCD editing tool" to perform write operations. For example, in the "220kV Xinqu Substation" project, the system mounts the collected "Line Protection.icd" file to the global data plane, assigns a unique resource identifier, and sets the time-to-live (TTL) in the access control metadata to 72 hours. After the TTL expires, the system automatically triggers a data cleanup mechanism to release memory resources, ensuring that sensitive configuration files are not permanently stored on the terminal.

[0057] The dependency topology of the subtask chain is parsed, and the data production and consumption binding relationship between intelligent capability units and unique resource identifiers is established based on the association index, so as to compile and generate the business operation template.

[0058] Among them, dependency topology refers to the sequential constraint relationship formed between nodes in the subtask chain based on the data flow direction, which is represented by the in-degree and out-degree relationship in a directed acyclic graph; data production and consumption binding relationship refers to the subscription and publication contract between intelligent capability units and data objects established in the compilation stage, which clearly specifies under what conditions (such as data update or state change) a certain intelligent capability unit (consumer) will be triggered to execute and consume specific data objects, while producing new data objects for downstream consumption.

[0059] Specifically, the system can traverse the hierarchical subtask list, parse out the "device configuration download" node's input port which depends on the "approved" status of the "SCD file" data object, then query the associated index to locate the intelligent capability unit responsible for producing the "SCD file" as the "SCD generation tool," and the intelligent capability unit responsible for consuming the file as the "configuration download agent." It then establishes a data production-consumption binding relationship between the two, addressed by a unique resource identifier, and solidifies this relationship into the configuration file of the business operation template. For example, the system parses and finds that the "virtual terminal connection verification" subtask must be executed after the "SCD file version update," so it establishes a binding relationship: when the unique resource identifier "urn:sgcc:ds:SCD:..." is written, the "virtual terminal verification tool" intelligent capability unit is automatically awakened, and this unique resource identifier is passed as an input parameter to the verification tool. The compiled business operation template is stored in YAML (YAML Ain't MarkupLanguage, a human-readable data serialization language) format, with a file size of approximately 15 kilobytes.

[0060] In response to the project instantiation request, the business operation template is loaded and a set of job activity instances is generated. The ownership identifier of each job activity instance is resolved according to the permission mapping table.

[0061] Among them, the engineering instantiation request refers to the control command triggered by the user in the human-computer interaction interface, carrying specific engineering parameters (such as substation name and voltage level); the work activity instance set refers to the runtime state set of the business operation template in a specific engineering scenario, including specific execution timestamps, responsible person fields and real-time progress pointers; the attribution identifier refers to the unique code of the collaborating subject bound to a specific work activity instance, which is obtained from the permission mapping table, and is usually the user group identifier or equipment identifier in the work order system.

[0062] Specifically, after receiving a request for engineering instantiation of the "220 kV New Area Substation", the system loads the pre-compiled "New Station Commissioning" service template, copies all nodes in the template to generate a set of work activity instances, and then iterates through each node in the instance set, extracts the corresponding intelligent capability unit code, queries the permission mapping table, obtains the code of the collaborating entity authorized to execute the intelligent capability unit, and writes the code into the attribution identifier field of the work activity instance. For example, after loading the template, for the work activity instance "Relay Protection Setting Verification", the system queries the permission mapping table and finds that only the team with the attribution identifier "PROTECTION_TEAM_01" has the execution permission. The system then assigns the attribution identifier field of the work activity instance to "PROTECTION_TEAM_01" and sets the planned start time to 2024-10-26 09:00:00.

[0063] Authentication matching is performed based on the ownership identifier, and the authenticated job activity instance is written to the message queue corresponding to the ownership identifier.

[0064] Among them, authentication matching refers to the verification process that verifies whether the identity of the current requesting entity is consistent with the ownership identifier of the job activity instance it is trying to access; message queue refers to an asynchronous communication buffer (such as RabbitMQ or Kafka) deployed at the application layer to decouple task producers and consumers and ensure the orderly distribution of tasks in high-concurrency scenarios.

[0065] Specifically, the system initiates a task distribution daemon process, periodically scans the set of job activity instances, filters out instances in the "ready" state with a non-empty attribution identifier, calls the identity authentication service to verify the digital certificate of the target collaborating entity, and after successful verification, serializes the job activity instance into a JSON (JavaScript Object Notation, a lightweight data exchange format) string and pushes it to the topic partition corresponding to the attribution identifier via a message queue protocol. For example, when the engineer of the "PROTECTION_TEAM_01" team logs into the system and passes certificate authentication, the system performs authentication matching to confirm that the engineer's identity matches the attribution identifier of the "Relay Protection Setting Verification" instance. The system then encapsulates the instance's detailed information (including equipment list and verification standards) into a message payload and writes it to a message queue named "Queue.Protection.Team01". The engineer's mobile terminal receives work order pushes in real time by subscribing to this queue, with end-to-end push latency controlled within 300 milliseconds.

[0066] Therefore, according to the above implementation method, the system can construct a data-driven and event-triggered electro-digital processing pipeline, achieve cross-process data sharing and unified management through a global data plane, establish a strict data dependency topology through compile-time production-consumption binding, and achieve precise task dispatch and secure isolation through engineering instantiation and authentication matching. This implementation method effectively solves the problems of data silos, rigid processes, and chaotic permissions in traditional debugging modes, and improves the electro-digital processing efficiency and data flow security of secondary system debugging operations in complex power grid scenarios.

[0067] In some embodiments, retrieving downstream job activity instances that subscribe to standard output data objects and performing cross-process data object transfer steps includes: Scan the subscription registry maintained by the business operation template to locate downstream intelligent capability units that have data dependencies with unique resource identifiers in order to determine the target job activity instance.

[0068] The subscription registry refers to a relational data table maintained within the business operation template that records the triple of "data object unique resource identifier - subscriber intelligent capability unit - trigger condition". It is stored in an in-memory database (a database system that stores data in memory to improve read and write speed, referred to as an in-memory database) and supports millisecond-level query response.

[0069] Specifically, the system initiates a subscription scanning thread, periodically polling the subscription registry for all subscription records matching the currently changed unique resource identifier. It extracts the downstream intelligent capability unit code bound to the subscription record, then uses the associated index to look up the corresponding job activity instance for that intelligent capability unit, marking instances in the "waiting for data" state as target job activity instances. For example, when the global system configuration description file with the unique resource identifier "urn:sgcc:ds:SCD:8a7b6c5d-4e3f-2a1b-9c8d-7e6f5a4b3c2d" in the global data plane is updated, the system scans the subscription registry and finds two subscription records: one corresponding to the "Configuration Download Agent" intelligent capability unit, with the associated target job activity instance being "#1 Main Transformer Protection Device Download Task"; the other corresponding to the "Virtual Loop Verification Tool" intelligent capability unit, with the associated target job activity instance being "Global Virtual Loop Consistency Verification Task".

[0070] Extract the status identifier of the standard output data object and verify whether the status identifier meets the preset input preconditions of the target operation activity instance.

[0071] Among them, the input preconditions refer to the Boolean logic expressions that must be satisfied before the target job activity instance is started and executed. They are predefined by the debugging job logic rules and include hard constraints on the range of values ​​of the status identifier of the input data object and the results of data integrity verification.

[0072] Specifically, the system reads the configuration fields of the target job activity instance, extracts the preset input precondition expression, parses the status flag field involved in the expression, compares the value with the status flag carried by the current standard output data object, and calls the hash check interface to verify the integrity of the data object. Verification is considered successful only if the status flag meets the value requirements and the data integrity verification passes. For example, the input precondition expression for "#1 main transformer protection device installation task" is "Status_Flag == 1 && CRC32_Check == Pass". The system extracts the status flag of the updated global system configuration description file as 1 (corresponding to the "approved" status), and calculates the file's Cyclic Redundancy Check (CRC32) value as 0x9F4A2B1C, which matches the preset check value. Therefore, verification is considered successful, and the process can proceed to the next step.

[0073] When the verification passes, the standard output data object is serialized into a cross-process message payload based on the data production and consumption binding relationship.

[0074] Among them, cross-process message payload refers to a structured data packet that follows the system's internal communication protocol, encapsulates the binary stream of standard output data objects and metadata (such as data source, version number, and priority), and is serialized using Protocol Buffers (an efficient structured data storage and exchange format, abbreviated as ProtoBuf). Compared with the common JSON format, the data volume is reduced by more than 60%, and the parsing speed is improved by 3 times.

[0075] Specifically, based on the data format agreed upon in the data production-consumption binding relationship, the system encapsulates the binary stream of the standard output data object, the current version number, and the unique resource identifier of the data source into a ProtoBuf format message structure. The system then sorts the messages according to preset priority tags to generate a cross-process message payload to be delivered. For example, the system will include the updated global system configuration description file's binary stream (approximately 2.4 megabytes in size), version number "V1.0.3", and source identifier. The message payload, encapsulated as “urn:sgcc:ds:SCD:8a7b6c5d-4e3f-2a1b-9c8d-7e6f5a4b3c2d” in ProtoBuf format with the priority tag set to “high”, is only 960 kilobytes in size after serialization, which is 1.44 megabytes smaller than the JSON format.

[0076] The inter-process communication interface is invoked to deliver the message payload to the message queue bound to the target job activity instance, and the version metadata of the corresponding data object in the global data plane is updated.

[0077] Version metadata refers to a collection of key-value pairs attached to a data object that records the version iteration history. It includes fields such as current version number, parent version number, modifier, and modification timestamp. It is stored in the object header of the global data plane and is used to realize data traceability and version rollback.

[0078] Specifically, the system calls the local inter-process communication interface (a communication mechanism for transferring data between different processes within the same physical machine, referred to as the local IPC interface) to deliver the cross-process message payload to the topic partition of the message queue bound to the target job activity instance. After the successful delivery callback signal is returned, the version metadata of the corresponding data object in the global data plane is updated, the current version number is written to the parent version field, the newly generated version number is written to the current version field, and the modification timestamp is updated. For example, the system calls the Unix domain socket (an efficient local inter-process communication mechanism, referred to as UDS) interface to deliver the message payload to the message queue partition named "Queue.Download.Protect". After successful delivery, the version metadata of the entire system configuration description file in the global data plane is updated: the parent version number is updated to "V1.0.2", the current version number is updated to "V1.0.3", and the modification timestamp is updated to 2024-10-26 14:30:00. The end-to-end latency of the entire delivery and update process is less than 80 milliseconds.

[0079] Therefore, according to the above implementation method, the system can construct a cross-process electro-digital transfer mechanism driven by data state. It achieves precise matching of data changes with downstream tasks through a registry subscription, ensures compliance of data transfer through precondition verification, achieves low-latency data delivery through efficient serialization and local inter-process communication, and enables full-process data traceability through version metadata updates. This implementation method effectively eliminates breakpoints in the electro-digital processing link during secondary system debugging scenarios, reducing errors and delays caused by manual data transmission.

[0080] In some embodiments, the steps for constructing the dependencies between input data objects and output data objects of each job activity and the state transition conditions include: Define several standard data objects, and construct a finite state machine model for each standard data object, including the review status, download status, and verification status.

[0081] Among them, the finite state machine model refers to a mathematical computational model used to describe the life cycle of a data object, which consists of a set of discrete states, a set of input events, and state transition rules; the review status refers to the stage identifier of the standard data object in the manual or automatic review process, with a value range of integers {0: pending review, 1: review passed, 2: review failed}; the download status refers to the process identifier of the secondary equipment configuration file being downloaded from the system to the physical device, with a value range of integers {0: pending download, 1: downloading in progress, 2: downloaded, 3: download failed}; the verification status refers to the result identifier of the consistency comparison between the actual operating configuration of the equipment and the system archive file, with a value range of integers {0: pending verification, 1: verification matches, 2: verification does not match}.

[0082] Specifically, the system can use an Extensible Markup Language (XML) schema definition file to declare the structure of standard data objects, reserving a 3-byte status field in the object header, corresponding to the review status, download status, and verification status, respectively. During system initialization, a newly created site-wide system configuration description file is instantiated, and its review status, download status, and verification status are initialized to 0. For example, the system defines a standard data object named "SCD_Object" and constructs a finite state machine model for it. When an operations and maintenance personnel click the "Submit for Review" button on the interface, the system captures this input event, triggers a state transition, changes the review status field value of "SCD_Object" from 0 to 1, and simultaneously writes this status change event to the system log, recording the operator and timestamp.

[0083] The version coupling constraints between the system configuration description file and the intelligent power device capability description file are analyzed to establish a one-way reference relationship between upstream data objects and downstream data objects.

[0084] Among them, version coupling constraint refers to the mandatory logical relationship that the generation of the version of the downstream data object must depend on the existence of a specific version of the upstream data object in the same project instance; unidirectional reference relationship refers to storing the unique resource identifier and version hash value of the upstream data object in the metadata of the downstream data object, thereby forming an irreversible dependency chain to ensure the accuracy of data traceability.

[0085] Specifically, the system parses the header information of the smart power device capability description file, extracts the manufacturer version number and CRC32 (Cyclic Redundancy Check, a technique for calculating a short, fixed-length checksum based on data content) value, and adds an "ExtRef" extended reference node to the private data segment of the whole-station system configuration description file. The unique resource identifier and version hash value of the smart power device capability description file are written to this node, establishing a strong association. For example, when integrating "Line Protection.icd" (version V2.1, CRC32=0x8A2B4C6D) into the whole-station system configuration description file, the system parses the version coupling constraint between the two and adds the version hash value to the whole-station system configuration description file. <ied>Write under the tag <private> <extref URI="urn:sgcc:ds:ICD:Line_Protec_V2.1" Hash="8A2B4C6D" / > < / private> Subsequently, if an attempt is made to import an ICD file that is not version V2.1, the system will detect a hash value mismatch, block the import operation, and report an error to prevent version mixing.

[0086] The consistency verification logic between the system configuration description file and the device configuration file is analyzed, and data integrity verification rules are constructed.

[0087] Among them, the consistency verification logic refers to the set of algorithms used to compare whether the virtual loop connection relationship described in the system configuration description file matches the actual operating configuration in the physical device; the data integrity verification rules refer to the set of logical expressions that define the allowable error range, the mandatory nature of key fields, and data type constraints, used to determine whether the data is valid during the verification process.

[0088] Specifically, the system constructs a comparison rule base centered on virtual terminal connection relationships. It extracts the internal and external terminal mapping relationships from the "ExtRef" node in the system configuration description file as a baseline template, and extracts the actually effective "DataSet" and "Input" nodes from the device configuration file as comparison objects. It then constructs verification rules that include exact string matching and numerical range tolerance (e.g., voltage accuracy ±0.2%). For example, the system constructs a rule: the "A-phase current" virtual terminal in the system configuration description file must be mapped to the "Ia" channel in the device configuration file. When performing consistency verification, the system parses the system configuration description file to obtain the baseline path "LD0 / LPHD / PhsA" and parses the device configuration file to obtain the actual path "LD0 / LPHD / PhsA". If the two strings match exactly, the data is considered complete. If the actual path is "PhsB", a data integrity verification failure alarm is triggered.

[0089] Based on the finite state machine model, a state transition function is defined. The state transition function determines the set of legal states of a standard data object before and after the execution of a job activity, according to version coupling constraints and data integrity verification rules.

[0090] The state transition function is a mathematical mapping relationship that describes which new state the system should transition to given the current state and input conditions. It is usually expressed as F(current state, input event) = new state. The set of legal states refers to the combination of state values ​​that conforms to business logic and physical laws, excluding state combinations that are logically impossible (such as "not downloaded" but "verified consistent").

[0091] Specifically, the system defines state transition functions using a decision table. For example, a rule is defined: when the current review status is 1 (approved) and the input event is "generate download list," the new download status is set to 0 (pending download). The system has a built-in constraint checker that rejects any state transition requests that violate version coupling constraints, such as prohibiting data objects with a review status of 2 (approved) from directly transitioning to a download status of 1 (downloading). For example, for the "device configuration consistency verification" activity, the system defines a state transition function: if the data integrity verification rule returns "True," the verification status is updated to 1 (verified consistent), and the download status is locked to 2 (downloaded); if it returns "False," the verification status is updated to 2 (verified inconsistent), and a reverse process is triggered, requiring the entire system configuration description file to be modified. Through this function, the system ensures a closed-loop logic for the chain "SCD file approved" -> "device download" -> "configuration consistency verification," eliminating the possibility of human intervention skipping critical steps.

[0092] Therefore, based on the above implementation method, the system can construct a rigorous electrical digital data governance framework. It achieves digital modeling of the entire lifecycle of core debugging files through a finite state machine model, ensures the uniqueness and accuracy of data sources through version coupling constraints and unidirectional reference relationships, and ensures the compliance of cross-file data flow through consistency verification logic and data integrity verification rules. This implementation method transforms complex power debugging business logic into computer-executable deterministic rules, solving the debugging errors caused by chaotic data versions and opaque states in the traditional model.

[0093] In some embodiments, the above method further includes standardized access steps for debugging tools: In response to the registration request of the debugging tool, the attribute information of the tool to be registered is extracted, and a mapping relationship between the tool identifier and the task identifier is established. The task identifier is associated with the corresponding project instance and job activity instance.

[0094] The tool identifier is a digital fingerprint string used to uniquely identify the debugging tool, usually generated in UUID format, such as "Tool_SCDCheck_001"; the attribute information is a set of metadata describing the functional characteristics and operating environment of the debugging tool, including the tool name, version number, compatible chip type, and maximum supported file size fields; the task identifier is a unique code of the job activity instance in the business operation template, used to associate specific debugging tasks; the mapping relationship is a hash table structure with the tool identifier as the primary key and the list of task identifiers as the value field, stored in the system registry center, used to realize the dynamic binding of tools and tasks.

[0095] Specifically, the system receives registration requests from debugging tools via the Hypertext Transfer Protocol Secure (HTTPS) interface, parses the JSON message in the request payload, extracts attribute information such as the tool name "SCD_AutoCheck_V3.2", version number "3.2.1", and compatible chip type "PX40 series", and generates a 36-bit tool identifier. Simultaneously, it queries the currently active project instance and job activity instance, extracts the unique identifier of the job activity instance as the task identifier, and writes the correspondence between the two into a mapping table. For example, when an equipment manufacturer uploads registration information for an "ICD parsing tool", the system extracts the attribute information "Supported file format: .icd / .cid" and "Maximum parsing depth: 10 layers" to generate the tool identifier "Tool_ICDParse_005". The system retrieved an instance of the "ICD file import" activity in the current "220 kV New Area Substation" project, with the task identifier "Task_ICD_Import_001". Therefore, a mapping relationship was established: when the "Task_ICD_Import_001" instance is started, the tool with the identifier "Tool_ICDParse_005" will be called first for processing.

[0096] In response to a call request from a debugging tool, the system verifies the caller's authentication credentials. Once the verification is successful, a session token is issued to establish a secure session channel between the debugging tool and the job activity instance.

[0097] Among them, the authentication credential refers to the identity verification file carried by the debugging tool when initiating the call request. It is usually a JSON Web Token (JWT) generated based on an asymmetric encryption algorithm, which includes the issuer, expiration time, and permission scope declaration. The session token is a short-term valid credential issued after successful verification. It is usually set to expire automatically after 15 minutes and is used to control the access permissions of the debugging tool within the current call cycle. The secure session channel refers to an encrypted communication link established based on the Transport Layer Security (TLS 1.3) protocol to prevent data from being eavesdropped on or tampered with during transmission.

[0098] Specifically, the system intercepts the debugging tool's call request, extracts the Authorization field from the HTTP header, verifies the signature and validity period of the JWT token, parses the permission scope declaration in the token, and confirms that the tool has the permission to access the corresponding job activity instance. After successful verification, the system generates a new session token, which encapsulates a list of unique resource identifiers for the allowed data objects, and sends it to the debugging tool via a TLS 1.3 encrypted channel. For example, the debugging tool "Tool_SCDCheck_001" initiates a call request carrying the JWT token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...". The system verifies that the token signature is valid and has not expired, parses out the permission scope as "read-only SCD file", and then generates a session token "Session_a1b2c3d4e5" in memory, valid for 900 seconds, and binds this token to the unique resource identifier "urn:sgcc:ds:SCD:8a7b..." in the site-wide system configuration description file. With this session token, the debugging tool can read the specified SCD file through the secure session channel for 900 seconds, but cannot modify or access other files.

[0099] Receive job progress information reported by the debugging tool based on the session token, associate the job progress information with the corresponding job activity instance, and trigger the status update operation of the job activity instance.

[0100] Among them, the job progress information refers to the quantitative data describing the execution status of the debugging tool, including the progress percentage (integer, range 0~100), the description of the current execution step, and the estimated remaining time field; the status update operation refers to modifying the status identifier of the job activity instance in the global data plane according to the progress information, such as changing it from "in execution" to "completed" or "execution failed".

[0101] Specifically, during the debugging process, the debugging tool reports a JSON message containing the progress percentage to the system every 5 seconds through a secure session channel. Upon receiving the message, the system extracts the session token and verifies its validity. Based on the task identifier bound to the token, it locates the corresponding job activity instance and writes the progress percentage to the progress field of that instance. When the progress percentage reaches 100%, the system automatically triggers a status update operation, updating the verification status field value of the job activity instance from 0 (pending verification) to 1 (verification consistent). For example, the configuration consistency verification tool continuously reports progress during processing: {"progress":30,"step":"Read device CID file"}, {"progress": 75,"step":"Compare virtual loop connections"}. When the system receives {"progress": 100,"step":"Generate difference report"}, it automatically locates the job activity instance corresponding to the task identifier "Task_Check_001", updates its status identifier to "Completed", and triggers the downstream data transmission process. If the system does not receive progress information within three consecutive reporting cycles, it will determine that the tool is offline, automatically update the job activity instance status to "execution failed" and issue an alarm.

[0102] The system calls the preset verification model library and graph topology vector difference analysis algorithm to perform a structured comparison between the system configuration description file and the device configuration file, generate a difference report, and encapsulate the difference report into a standard output data object.

[0103] Among them, the verification model library refers to a database that stores standard configuration templates and logical rules for various power equipment, including constraint models such as bay type, protection principle, and pressure plate setting; the graph topology vector difference analysis algorithm refers to a mathematical algorithm that abstracts the virtual loop connection relationship in the whole station system configuration description file and equipment configuration file into a directed graph, and quantifies the configuration deviation by calculating the difference in the eigenvalues ​​of the adjacency matrix of the two graphs; the difference report refers to a structured document described in XML or JSON format, containing the difference location, difference type, and severity; and the standard output data object refers to a data entity that conforms to the system data encapsulation specification and carries the difference report content and status identifier.

[0104] Specifically, the system loads the bay model corresponding to "220 kV line protection" from the verification model library, extracts the virtual loop directed graph G1 defined in the whole station system configuration description file and the actual installed directed graph G2 extracted from the equipment configuration file. The algorithm calculates the difference matrix ΔA = A1 - A2 between the adjacency matrices A1 and A2 of G1 and G2. When the number of non-zero elements in ΔA exceeds a preset threshold (e.g., 5), a significant difference is determined. The system fills the difference location (e.g., "LD0 / LLN0.PhsA"), difference type (e.g., "virtual terminal missing") into a predefined JSON template, generates a difference report, and encapsulates the report into a standard output data object with the status marked "pending review". For example, the system calls the graph topology vector difference analysis algorithm and finds that "phase A current" in the whole station system configuration description file is connected to "Ia", while it is actually connected to "Ib" in the equipment configuration file. The algorithm calculates that the difference value of the adjacency matrix at the corresponding position is 1, which is determined to be "virtual terminal misalignment". The system generates a discrepancy report with the content {"DiffType":"ConnectionError","Location":" / IED / LD0 / LPHD / PhsA","Expected":"Ia","Actual":"Ib","Severity":"High"}. The system then encapsulates this JSON string into a standard output data object with a unique resource identifier of "urn:sgcc:ds:Report:Diff_20241026_001", sets the status to 0 (pending review), and pushes it to the reviewer's task queue.

[0105] Therefore, according to the above implementation method, the system can build an open and secure ecosystem of electronic digital tools. It realizes plug-and-play and identity authentication of heterogeneous debugging tools through standardized registration and authentication mechanisms, ensures data security during tool invocation through session tokens and encrypted channels, realizes closed-loop automated management and control of the work process through real-time progress reporting and status linkage, and realizes accurate comparison and anomaly location of configuration data through verification model library and graph topology vector difference analysis algorithm.

[0106] In some embodiments, the above method further includes a data security management step: A distributed persistent storage layer is used to store model files and device configuration files, and sensitive fields in the model files and device configuration files are anonymized.

[0107] The distributed persistent storage layer refers to a unified storage architecture built on erasure coding (a distributed storage technology that divides data into blocks and adds redundant check blocks to achieve fault tolerance of nodes) and deployed on local servers in substations and storage clusters in the central control center. The default configuration is a redundancy strategy of 6 data blocks plus 3 check blocks, allowing up to 3 storage nodes to go offline without losing data. Sensitive fields refer to information segments in model files and device configuration files that involve power grid operation security and privacy, including the Internet protocol address of smart power devices, operation and maintenance account passwords, precise geographical coordinates of substations, and device setting parameters. Anonymization conversion refers to processing sensitive fields using format-preserving encryption (FPE, an encryption technology whose encrypted output format is completely consistent with the plaintext structure) to ensure that the encrypted fields can still be parsed normally by existing power business systems, while the original plaintext cannot be deduced.

[0108] Specifically, the system calls the write interface of the distributed persistent storage layer to store the system configuration description file, intelligent power device capability description file, and equipment configuration file categorized by engineering dimension. It traverses the file's Extensible Markup Language (Extreme Markup Language) node tree, locates all sensitive field nodes, and calls the FPE encryption algorithm to convert the field values. The encryption key is periodically rotated by the power dedicated key management system, and the key length is set to 256 bits. After encryption, the system assigns a globally unique resource identifier to the stored file and writes the encryption marker into the file header metadata. For example, in the "220 kV New Area Substation Construction Project", the system stores the full-station system configuration description file, which contains the Internet Protocol addresses of 10 protection devices and the passwords of 3 sets of operation and maintenance accounts, in the distributed persistent storage layer under the path " / secure / sgcc / 2024 / 10 / 26 / ". Sensitive fields such as "192.168.1.10" and "Admin@123" are encrypted using FPE, and the encrypted fields are "172.16.3.25" and "Xy7#9zQw" respectively. The redundancy of the storage file is configured as 6+3, so that the data can be automatically recovered from the remaining nodes when a single storage node fails, without affecting the debugging and operation of the business.

[0109] In response to the project completion instruction, a data cleanup instruction is issued to the terminal of the designated responsible party to perform an irreversible overwrite and erase operation on the core configuration file stored locally.

[0110] Among them, the project completion instruction refers to the control message that is signed and confirmed by the on-site commissioning supervisor through a digital certificate, marking the official end of the commissioning task. It includes the project's unique identifier, completion timestamp, and the identity information of the confirmer. The data cleanup instruction refers to the structured control message generated by the system based on the project completion instruction, carrying the path of the file to be cleaned, the number of erasures, and the verification rules. The irreversible overwrite and erase operation refers to a three-stage overwrite process based on the DoD 5220.22-M standard, which conforms to GB / T 39276-2020 "Information Security Technology - Data Destruction Technical Requirements": the first time, all-zero binary data is written to the storage sector; the second time, all-one binary data is written; and the third time, random binary data conforming to the NIST SP 800-22 standard is written. After each overwrite, the cyclic redundancy check value of the storage sector is calculated, and the erase is deemed valid only after it is confirmed to be consistent with the expected value.

[0111] Specifically, after receiving the project completion instruction and completing signature verification, the system iterates through the list of all responsible terminals involved in the commissioning process, including on-site commissioning laptops, portable commissioning terminals, and substation local gateway devices. It then generates a data cleanup instruction containing the paths to the corresponding core configuration files and sends it to each terminal via an encrypted channel. After the terminal performs the erase operation, it generates an erase log containing the original file hash value, the erased hash value, and the operation timestamp. This log is then uploaded back to the system audit server for archiving, with an archiving period set to 3 years, complying with power industry audit requirements. For example, after project completion, the system sends a data cleanup instruction to the maintenance team's commissioning laptop, performing three overwrite erasures on the core configuration files stored locally on that terminal, such as "line_protection.cid" and "busbar_scd.xml": the first write is all zeros, resulting in a hash value of 0x00000000; the second write is all one values, resulting in a hash value of 0xFFFFFFFF; and the third write is random data, with a hash value consistent with the expected value generated by the preset random seed. After the erasure is complete, the terminal sends back the erasure log. Once the system confirms that all core configuration files have been irreversibly erased, it closes the debug access permissions for the project.

[0112] During the cross-process data object transfer process, a secure transport protocol is invoked to serialize and encapsulate the data object, and authentication and verification are performed based on access control metadata.

[0113] The secure transmission protocol refers to an encrypted transmission protocol compliant with the TLS 1.3 standard, supporting X25519 key exchange and AES-256-GCM symmetric encryption algorithm. The data encryption strength during transmission meets the security protection requirements of the power monitoring system. Serialization encapsulation refers to using Protocol Buffers (a high-efficiency structured data serialization format, abbreviated as ProtoBuf) to package the binary stream, version number, and access control metadata of standard output data objects into a fixed-format message payload. Compared to the common JSON format, the data size is reduced by more than 60%, and the parsing speed is increased by 3 times. Access control metadata refers to the permission tag attached to the header of the data object, containing a list of allowed intelligent capability units, data validity period, and operation permission bits, which are predefined during the system initialization phase. Authentication verification refers to the verification process that checks whether the data receiver's session token is in the allowed list of access control metadata, whether the token is within its validity period, and whether the token signature is valid.

[0114] Specifically, before transmitting data across processes, the system first extracts the access control metadata of the data object to obtain a list of allowed smart capability units. When the receiver initiates a data acquisition request, the system extracts the session token carried by the receiver and sequentially verifies whether the token's signature validity, validity period, and ownership permissions match the access control metadata. After all verifications pass, the system calls the TLS 1.3 protocol to establish an encrypted transmission channel, encapsulates the data object into a ProtoBuf format message payload, and transmits it to the receiver's process space via Unix domain sockets (an efficient local inter-process communication mechanism). For example, if the routing engine needs to pass the updated global system configuration description file to the configuration download tool, it first extracts the access control metadata of the file to confirm that the "configuration download tool" smart capability unit is allowed to read it. When the receiver initiates a request, it carries a session token "Session_a1b2c3d4e5". The system verifies that the token signature is valid, the remaining validity period is 300 seconds, and the ownership permissions match. Then, it calls the TLS 1.3 protocol to establish an encrypted channel. The binary stream of the entire system configuration description file, the version number "V1.0.3", and the access control metadata are encapsulated into a ProtoBuf message payload and transmitted to the configuration download tool process through a Unix domain socket. The end-to-end latency of the entire transmission process is less than 50 milliseconds. Even if the data is intercepted in the middle, the content cannot be decrypted without the corresponding private key.

[0115] Therefore, based on the above implementation method, the system can construct an electrical digital security protection system covering the entire data lifecycle. Through distributed persistent storage and sensitive field anonymization conversion, it ensures the confidentiality and availability of statically stored data; through an irreversible write-and-erase mechanism compliant with national standards, it eliminates the risk of leakage caused by residual debugging data on the terminal; and through secure transmission protocols, serialization encapsulation, and strict authentication verification, it ensures the integrity and controllability of data during dynamic transmission. This implementation method effectively solves the problems of chaotic file management, sensitive data leakage, and lack of transmission security in traditional substation secondary system debugging.

[0116] In some embodiments, the above method further includes: In response to the type identifier of the engineering instance being identified as an expansion or renovation operation, an impact scope analysis sub-process is injected before the creation node of the system configuration description file for the entire site.

[0117] The impact scope analysis sub-process refers to the calculation process that determines the physical devices and logical links affected by the configuration change based on graph data structure comparison.

[0118] Specifically, the system retrieves two versions of the substation configuration model stored in the global data plane. It abstracts the virtual loop connections of each bay within the substation (referring to the entirety of a group of interconnected electrical equipment and conductors in the substation, such as a 110kV line bay including circuit breakers, disconnectors, and current transformers) into a directed graph. The system determines the change impact domain by calculating the difference between the graph's topology vectors. For example, for the expansion project of the #2 main transformer in a 500kV smart substation, the system loads a baseline full-station system configuration description file (version V1.0) and a pending full-station system configuration description file (version V2.0). The virtual loop weight matrix W is set to a 16×16 identity matrix, and the vector difference is calculated. When the value of an element in ΔG is greater than 0, it is determined that the virtual circuit corresponding to that element has been changed.

[0119] Read the baseline full-site system configuration description file and the full-site system configuration description file to be reviewed, parse the graph topology vector differences between the baseline full-site system configuration description file and the full-site system configuration description file to be reviewed, and extract the affected interval identifiers and virtual loop indexes.

[0120] Among them, the interval identifier refers to the string code used to uniquely identify the electrical interval within the substation, and the virtual loop index refers to the memory offset pointing to the specific logical connection path.

[0121] Specifically, the system traverses the graph topology vector difference matrix, locates the coordinates of non-zero elements, and uses these coordinates to look up the equipment hierarchy structure tree in the substation configuration model to determine the unique code of the physical bay and its corresponding logical node reference. For example, if the system detects that the value of the element in the 8th row and 12th column of the graph topology vector difference matrix changes from 0 to 1, and then looks up the equipment hierarchy structure tree, it determines that the bay identifier is "5051 bay" and the virtual loop index is "GOOSE_LD0 / LN0SPCSOSPCSO1", indicating that the tripping logic of this bay has changed.

[0122] Construct a differential dataset containing the configuration download range, transmission range, and security isolation range. Mount the differential dataset to the global data plane to obtain the input data for creating the system configuration description file for the entire site.

[0123] Among them, the difference dataset refers to the binary data stream encapsulated according to a predefined data structure, the configuration download range refers to the set of Internet Protocol (IP) addresses of smart power devices that need to update configuration files, the transmission range refers to the set of secondary devices that need to perform analog input, and the safety isolation range refers to the list of ports that need to be logically disconnected.

[0124] Specifically, based on the extracted virtual loop index, the system recursively queries all smart power devices that have a data flow dependency with that index, generates a hash table containing the aforementioned range, and serializes the hash table into a JSON format data stream and stores it in the shared memory area of ​​the global data plane. For example, based on the virtual loop index "GOOSE_LD0 / LN0SPCSOSPCSO1", the system recursively queries the affected relay protection device A (IP address: 192.168.1.101) and smart terminal B (IP address: 192.168.1.102), constructs a difference dataset {"Downloaded IP":["192.168.1.101","192.168.1.102"],"Transmission Interval":["5051 Interval"],"Isolation Port":["ETH1","ETH2"]}, and writes this dataset into the shared memory block at memory address 0x7FFD2A3B.

[0125] Based on the isolation range of the safety measures, a set of safety measure pre-drill instructions is generated, and the transmission range parameter is called during the equipment test and verification phase to limit the scope of the test cases.

[0126] Among them, the Ancuo pre-rehearsal instruction set refers to the Modbus TCP protocol message set used to control the state of the soft pressure plate, and the scope of the test case refers to the maximum number of times the test script is executed in a loop or the address range of a specific device.

[0127] Specifically, before the equipment testing and verification process begins, the system reads the port list within the safety isolation range, generates a set or reset command message, and sends it to the corresponding smart power device to forcibly lock the relevant ports. During test execution, the system reads the transmission range parameter and uses this parameter as a filter condition to pass to the execution engine of the test case, applying excitation signals only to devices within the transmission range. For example, the system generates a message sequence based on the safety isolation range: 010300000001840A (hexadecimal, meaning reading the ETH1 port status), and during the equipment testing and verification phase, it calls the transmission range parameter "5051 interval" to set the scope of the test case to send a 50 Hz sine wave sampling value message only to the merging unit corresponding to the 5051 interval, thereby avoiding accidental activation of adjacent operating intervals.

[0128] Therefore, according to the above implementation method, the system can accurately define the intrusion boundary of the renovation and expansion work on the existing system based on the quantitative calculation results of graph topology vectors, and realize the precise scheduling of test resources and the automatic generation of security isolation strategies.

[0129] According to a second aspect, this invention provides a multi-agent-driven intelligent collaborative control system for secondary system operations. This system is deployed on a distributed computing node cluster, which includes routing engine nodes, global data plane nodes, and security control nodes. The system includes a processing unit and a storage unit. The storage unit stores executable instructions. When the executable instructions are invoked by the processing unit, they implement any of the multi-agent-driven intelligent collaborative control methods for secondary system operations in this invention's embodiments.

[0130] According to a third aspect, the present invention provides a power device comprising: at least one processing unit; and a storage unit communicatively connected to the at least one processing unit. The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes it to execute any of the multi-agent driven intelligent cooperative control methods for secondary system operations in the embodiments of the present invention.

[0131] According to another aspect of the present invention, a medium for storing executable instructions is provided, wherein the computer instructions are used to cause a computer to execute any of the multi-agent driven secondary system operation intelligent cooperative control methods in the embodiments of the present invention.

[0132] Figure 4 A schematic block diagram of a power device 600 that can be used to implement embodiments of the present invention is shown. The power device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The power device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0133] like Figure 4 As shown, the power device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the power device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0134] Multiple components in the power device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a disk, optical disk, etc.; and a communication unit 609, such as a network card, modem, wireless transceiver, etc. The communication unit 609 allows the power device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0135] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as a multi-agent driven intelligent cooperative control method for secondary system operations. For example, in some embodiments, a multi-agent driven intelligent cooperative control method for secondary system operations can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the power device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the multi-agent driven intelligent cooperative control method for secondary system operations described above can be performed. Alternatively, in other embodiments, computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a multi-agent driven secondary system operation intelligent cooperative control method.

[0136] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0137] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0138] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0139] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0140] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0141] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0142] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0143] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.< / ied>

Claims

1. A multi-agent driven intelligent cooperative control method for secondary system operations, characterized in that, include: Based on preset debugging operation logic rules, several operation data structures are defined. The data structures encapsulate standard output data objects. The debugging operation logic rules define the dependency relationships and state transition conditions between the input data objects and output data objects of each operation. Mapping relationships are constructed based on a preset resource mapping strategy to establish an association index between event instances, object resources, and intelligent capability units; Import the defined data structure into the routing engine to build a business operation template, and distribute job activity instances to the corresponding responsible entities according to the associated index; In response to the job activity instance of the responsible entity performing an update operation on the standard output data object, downstream job activity instances that subscribe to the standard output data object are retrieved, and cross-process data object transfer is performed.

2. The method according to claim 1, characterized in that, The step of constructing mapping relationships according to a preset resource mapping strategy to establish an association index between event instances, object resources, and intelligent capability units includes: Based on the preset access control policy, establish a permission mapping table between collaborative entities and intelligent capability units, and configure the corresponding identity authentication credentials. The debugging job instance is parsed into a hierarchical subtask list, the logical execution body of each subtask is encapsulated into an intelligent capability unit, and a call binding relationship is established between the subtask list and the intelligent capability unit. Build an event-driven architecture, listen to the state variables of material resources, and broadcast a state update event to the intelligent capability units that subscribe to the version identifier when the version identifier of the model file changes. Establish a context association mechanism for unstructured data, bind communication sessions with unique identifiers of job activity instances, and parse semantic features in communication sessions to generate structured pending instructions.

3. The method according to claim 2, characterized in that, The step of importing the defined data structure into the routing engine to build a business operation template, and distributing job activity instances to corresponding responsible entities according to the associated index, includes: The input and output data objects in the data structure are attached to the global data plane, and each data object is assigned a unique resource identifier and access control metadata. The dependency topology of the subtask chain is parsed, and a data production and consumption binding relationship between the intelligent capability unit and the unique resource identifier is established based on the association index, so as to compile and generate the business operation template; In response to the project instantiation request, the business operation template is loaded and a set of job activity instances is generated. The ownership identifier of each job activity instance is parsed according to the permission mapping table. Authentication matching is performed based on the ownership identifier, and the authenticated job activity instance is written to the message queue corresponding to the ownership identifier.

4. The method according to claim 3, characterized in that, The steps of retrieving and subscribing to downstream job activity instances of the standard output data object and performing cross-process data object transfer include: Scan the subscription registry maintained by the business operation template to locate the downstream intelligent capability unit that has a data dependency relationship with the unique resource identifier, so as to determine the target job activity instance; Extract the status identifier of the standard output data object and verify whether the status identifier meets the preset input preconditions of the target operation activity instance; When the verification is successful, the standard output data object is serialized into a cross-process message payload based on the data production and consumption binding relationship. The inter-process communication interface is invoked to deliver the message payload to the message queue bound to the target job activity instance, and the version metadata of the corresponding data object in the global data plane is updated.

5. The method according to claim 1, characterized in that, The steps for constructing the dependencies between input and output data objects and the state transition conditions for each task activity include: Define several standard data objects, and construct a finite state machine model for each of the standard data objects, including the review status, download status, and verification status. The version coupling constraints between the system configuration description file and the intelligent power device capability description file are analyzed, and a one-way reference relationship between upstream data objects and downstream data objects is established. Analyze the consistency verification logic between the system configuration description file and the device configuration file, and construct data integrity verification rules; Based on the finite state machine model, a state transition function is defined. The state transition function determines the set of legal states of the standard data object before and after the execution of the job activity, according to the version coupling constraint and the data integrity verification rule.

6. The method according to claim 3, characterized in that, The method also includes standardized access steps for debugging tools: In response to the registration request of the debugging tool, the attribute information of the tool to be registered is extracted, and a mapping relationship between the tool identifier and the task identifier is established. The task identifier is associated with the corresponding project instance and job activity instance. In response to the call request from the debugging tool, the authentication credentials of the caller are verified. Once the verification is successful, a session token is issued to establish a secure session channel between the debugging tool and the job activity instance. Receive job progress information reported by the debugging tool based on the session token, associate the job progress information with the corresponding job activity instance, and trigger the status update operation of the job activity instance; The system calls the preset verification model library and graph topology vector difference analysis algorithm to perform a structured comparison between the system configuration description file and the device configuration file, generate a difference report, and encapsulate the difference report into a standard output data object.

7. The method according to claim 1, characterized in that, The method also includes data security control steps: A distributed persistent storage layer is used to store model files and device configuration files, and sensitive fields in the model files and device configuration files are anonymized. In response to the project completion instruction, a data cleanup instruction is issued to the terminal of the designated responsible party to perform an irreversible overwrite and erase operation on the core configuration file stored locally; During the cross-process data object transfer process, a secure transport protocol is invoked to serialize and encapsulate the data object, and authentication and verification are performed based on access control metadata.

8. The method according to claim 1, characterized in that, The method further includes: In response to the type identifier of the engineering instance being identified as an expansion or renovation operation, an impact scope analysis sub-process is injected before the configuration description file creation node of the entire system. Read the baseline full-site system configuration description file and the full-site system configuration description file to be reviewed, parse the graph topology vector differences between the baseline full-site system configuration description file and the full-site system configuration description file to be reviewed, and extract the affected interval identifiers and virtual loop indexes; Construct a differential dataset containing the configuration download range, transmission range, and security isolation range, and mount the differential dataset to the global data plane to obtain the input data for creating the full-site system configuration description file; Based on the isolation range of the safety measures, a set of safety measure pre-drill instructions is generated, and the transmission range parameter is called during the equipment test and verification phase to limit the scope of the test cases.

9. A multi-agent driven intelligent collaborative control system for secondary system operations, characterized in that, The system is deployed on a distributed computing node cluster, which includes routing engine nodes, global data plane nodes, and security management nodes. The system includes a processing unit and a storage unit. The storage unit stores executable instructions. When the executable instructions are invoked by the processing unit, the multi-agent driven intelligent collaborative control method for secondary system operations as described in any one of claims 1 to 8 is executed.

10. An electric device, characterized in that, include: At least one processing unit; and a storage unit communicatively connected to the at least one processing unit; The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the method as described in any one of claims 1 to 8.

Images