A multi-system heterogeneous protocol cooperation method and system based on two-vote state driving

Abstract

The application discloses a two-vote state driving-based multi-system heterogeneous protocol cooperation method and system, relates to hydropower station production operation management and data processing technology, and comprises the following steps: a state event semantic model facing a two-vote life cycle is constructed, and multiple key state nodes of the two votes are respectively mapped to corresponding state event types; a protocol semantic mapping library is constructed in a protocol adaptation layer, corresponding command semantic templates are defined in advance for the protocols adopted by each system of the hydropower station; in the case that a state transition of the two votes is detected, a state event record is generated according to the state event semantic model, and a corresponding command semantic rule is retrieved from the protocol semantic mapping library based on the state event record and is issued to each target system for cooperative execution. The application solves the problem of high coupling degree and poor expansibility of the existing two-vote driving-based multi-system heterogeneous protocol cooperation of the hydropower station.

Description

Technical Field

[0001] This application relates to the fields of hydropower station production operation management and data processing technology, and in particular to a multi-system heterogeneous protocol collaborative method and system based on two-ticket state-driven. Background Technology

[0002] The safety management of hydropower stations relies strictly on the "two-ticket" system. These tickets serve as written documentation and safety permits for operations such as operation, maintenance, and testing, and are used throughout the entire lifecycle of a task, from ticket drafting, review, approval, execution, to final archiving. The circulation of these tickets requires coordination with multiple heterogeneous automated systems within the power station. For example: When the status of both work permits transitions from "Permit to Commence Work" to "In Execution," a device tagging instruction needs to be simultaneously issued to the computer monitoring system to prevent remote misoperation; a channel authorization instruction needs to be issued to the access control system to allow personnel to enter the work area; an unlocking instruction needs to be issued to the safety tool management system to allow the removal of grounding wires, voltage detectors, and other tools; and a preset position recall instruction needs to be issued to the video surveillance system to point the camera at the work area. When the status of both work permits transitions from "In Execution" to "Application Termination," the authorization or tagging status of the above systems needs to be revoked, restoring the system to the safety lockout state.

[0003] Currently, cross-system collaborative operations are mainly achieved manually. After the status of the two tickets changes, the on-duty personnel manually perform operations such as tagging, authorization, and unlocking based on the information on the paper or electronic tickets, logging into the monitoring system, access control system, and tool management system. This method is inefficient and carries the risk of human error or oversight. Especially during peak operating periods, when multiple tickets are processed in parallel, manual coordination is highly susceptible to negligence, leading to inadequate implementation of safety measures and creating safety hazards. Summary of the Invention

[0004] This application provides a method and system for multi-system heterogeneous protocol collaboration based on two-ticket state-driven approach, which solves the problems of high coupling and poor scalability in existing power plant two-ticket driven multi-system heterogeneous protocol collaboration.

[0005] This application proposes a multi-system heterogeneous protocol collaboration method based on two-vote state-driven approach, including: A semantic model of state events oriented towards the lifecycle of two tickets is constructed, which maps multiple key state nodes of the two tickets to corresponding state event types, and associates a set of target system identifiers and communication triggering conditions with each state event type, wherein the key state nodes cover the lifecycle of the two tickets; A protocol semantic mapping library is built in the protocol adaptation layer. Corresponding command semantic templates are predefined for the protocols used by each system of the power plant. Each command semantic template contains the mapping relationship between protocol semantics and two-ticket status event semantics. The message queue for monitoring the status changes of two tickets in the two-ticket management system is used. When a status transition of two tickets is detected, the triggering conditions are determined according to the state event semantic model, and a status event record is generated. Based on the state event records, the corresponding command semantic rules are retrieved from the protocol semantic mapping library; The command semantic rules are parsed to obtain the target system, required protocol format, and field mapping method, and then sent to each target system for collaborative execution.

[0006] This application also proposes a multi-system heterogeneous protocol collaborative system based on two-vote state driving, including a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the steps of the aforementioned multi-system heterogeneous protocol collaborative method based on two-vote state driving.

[0007] This application constructs a state event semantic model and a state transition semantic mapping rule library to accurately associate the two-ticket state transition events with the collaborative workflow template, thereby decoupling business semantics from protocol instructions. In a specific example, by defining a collaborative workflow template with a DAG structure, the complex multi-system collaborative logic is arranged into a configurable atomic collaborative task graph, solving the problems of high coupling and poor scalability in the existing multi-system heterogeneous protocol collaboration driven by two-ticket power plants.

[0008] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0009] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the basic process of the multi-system heterogeneous protocol collaboration method based on two-vote state driving in this embodiment. Detailed Implementation

[0010] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0011] This application proposes a multi-system heterogeneous protocol collaboration method based on two-vote state-driven approach, such as... Figure 1 As shown, it includes the following steps: In step S101, a semantic model of state events oriented towards the lifecycle of the two tickets is constructed. Multiple key state nodes of the two tickets are mapped to corresponding state event types, and a set of target system identifiers and communication triggering conditions are associated with each state event type. The key state nodes cover the lifecycle of the two tickets. The associated target system identifier describes the target system that the state event needs to mobilize or modify, and the communication triggering conditions reflect whether control over the target system has been triggered.

[0012] In some embodiments, the two tickets may include operation tickets, work tickets (e.g., hot work tickets), etc., and the key status nodes include at least the following: pending approval, approved, permitted to commence work, in progress, interrupted, and finalized and archived. That is, the key status nodes are mapped to corresponding status event types using a status event semantic model.

[0013] In step S102, a protocol semantic mapping library is constructed in the protocol adaptation layer. Corresponding command semantic templates are predefined for the protocols used by each system in the power plant. Each command semantic template contains a mapping relationship between protocol semantics and the semantics of two-ticket status events. This application embodiment is mainly applied to power plant architectures including a two-ticket management system, a protocol collaboration middleware layer, a message queue, and other heterogeneous systems. These other heterogeneous systems include, for example, computer monitoring systems, access control systems, safety tool management systems, and video surveillance linkage systems. Each system can have different heterogeneous protocols.

[0014] In step S103, the message queue for status changes of the two tickets in the two-ticket management system is monitored. Upon detecting a status transition of the two tickets, the triggering conditions are determined according to the status event semantic model, and a status event record is generated. In some examples, the status event record may include the two ticket IDs, original status, target status, trigger timestamp, associated device code list, and work area code, etc., which can be set according to actual needs.

[0015] In step S104, based on the status event record, the corresponding command semantic rules are retrieved from the protocol semantic mapping library. For example, the retrieval is performed based on the target status and device / region code in the status event record, thereby retrieving the corresponding command semantic template from the protocol semantic mapping library to determine the protocol format and field mapping rules required to issue instructions to the associated device (corresponding to the target system type).

[0016] In step S105, the command semantic rules are parsed to obtain the target system, required protocol format and field mapping method, and then sent to each target system for collaborative execution.

[0017] This application constructs a state event semantic model and a state transition semantic mapping rule library to accurately associate the two-ticket state transition events with the collaborative workflow template, thereby decoupling business semantics from protocol instructions. This solves the problems of high coupling and poor scalability in the existing multi-system heterogeneous protocol collaboration of two-ticket driven power plants.

[0018] In some embodiments, the state event semantic model is used to describe the original event data structure generated when two states transition, and is defined as the semantic structure of a tuple event; The semantic structure incorporates event context tags, which describe the preceding and following states of the two tickets. In a specific example, the state transitions from "draft for review" to "approved." At this point, although the current state of the two tickets is "approved," it does not yet trigger on-site equipment operation in terms of business operations. Similarly, there are intermediate states when the state transitions from "permit to commence" to "in execution." This application further describes these states using event context tags.

[0019] In some embodiments, the state transition semantic mapping rule base includes matching conditions, semantic type enumeration values, and collaborative workflow templates, wherein, The matching conditions are logical combinations of the preceding and following states of the two tickets. For example, they may include permit commencement → in progress, in progress → interrupted, interrupted → application termination, in progress → application termination, etc.

[0020] The semantic type enumeration values ​​are enumerations of business semantic types corresponding to state transitions under the aforementioned logical combinations. Each of the aforementioned logical combinations corresponds to a business semantic type; for example, "Starting Work → Executing" corresponds to the semantic type "Starting Work Process," which is associated with a set of target systems. The same applies to others. For example, if the current state is "Executing," possible logical combinations include "Executing → Requesting Termination," "Executing → Interruption," etc., thus obtaining multiple sets of business semantic type enumerations.

[0021] The collaborative workflow template is used to present the coverage range of the semantic type enumeration values ​​based on a predefined directed acyclic graph (DAG). In some examples, a DAG can be drawn up for two work orders at a power plant. The DAG corresponds to the current work content of the two work orders. This application innovatively utilizes the DAG to only present the coverage range of the semantic type enumeration values, thereby intuitively displaying the work progress of the two work orders and the dynamic changes of related systems at any time. Especially when a two-work order or operation order has hundreds of operations or a long duration, and a two-work order may also be accompanied by multiple auxiliary operation orders, the local presentation effect of the DAG is particularly outstanding. It can intuitively express the current work priorities and the dynamic instructions of related systems, thereby greatly improving the assistance to operation and maintenance personnel and ensuring the overall safety of power plant operations.

[0022] In some embodiments, the collaborative workflow template specifically defines the collaborative task as a directed acyclic graph (DAG); The nodes of the DAG are represented as atomic collaborative tasks. The directed edges of the DAG define the execution dependencies from the source task node to the target task node. For example, the execution dependency Vi->Vj means that Vj can only be executed after Vi is executed successfully. For example, during the execution of a hot work permit, the fan control permission is only allowed to be unlocked when the SF6 gas concentration is detected to be normal.

[0023] In some embodiments, if an atomic cooperative task fails and a rollback operation is triggered, the method further includes: Traverse the successfully executed atomic cooperative tasks in reverse topological order of the DAG graph; For adjacent, successfully executed atomic collaborative tasks, a compensation protocol instruction is sent to the corresponding target system according to a predefined compensation protocol. Before sending the instruction, the current actual state of the target system is read. If the current actual state matches the target state specified in the compensation protocol instruction, the instruction is skipped. In a specific example, dynamic timeout adjustment is also set. In the complex network environment of a hydropower station, a fixed timeout can easily lead to misjudgments. The timeout duration can be adjusted by weighting the network jitter and historical response times.

[0024] In some embodiments, determining whether the triggering conditions are met based on the state event semantic model and generating a state event record includes: The system receives real-time status change information for both votes, which includes complete tuple event data. For example, it can subscribe to a two-vote status change topic. When a transition occurs between the states of the two votes, the two-vote management system publishes a message to this topic, which contains complete original six-tuple event data.

[0025] Parse the status change information and extract the fields containing the before and after states of the two votes.

[0026] The extracted fields are matched against the matching conditions of each rule in the state transition semantic mapping rule library.

[0027] If a matching rule exists, the triggering condition is determined; otherwise, the event is discarded. A state event record is generated based on the matching rule and the original event. Specifically, the state event record serves as the core data carrier describing the collaborative execution of two state transitions and multi-system protocols, containing all the key information required for subsequent protocol retrieval. The state event record can be obtained by combining relevant fields from the original event and associated fields from the matching rule, such as the business semantic type of this state transition and the collaborative workflow template (DGA) in the matching rule.

[0028] In some embodiments, retrieving the corresponding command semantic rules from the protocol semantic mapping library based on the state event records includes: Based on the status event records, the applicable device range is determined for the atomic collaborative task nodes in the DAG graph of the corresponding collaborative workflow template. According to the aforementioned embodiments, the nodes in the DAG graph are constructed based on tasks, and any task covers different ranges of devices, systems, etc., thus the applicable device range can be determined based on the task nodes.

[0029] Based on the applicable device range, a composite key is established for retrieving the protocol semantic mapping library, so as to perform retrieval in the protocol semantic mapping library using the composite key.

[0030] By establishing a more accurate composite key based on the device scope and the aforementioned status event records, the composite key can be used to accurately match and retrieve the protocol semantic mapping library, thereby obtaining the target system covered by the most accurate work ticket status and the corresponding protocol. Since the status event records may involve multiple target systems, the corresponding command semantic template can be independently retrieved for each atomic collaborative task, and the protocol message instantiation can be completed, which is then synchronously or asynchronously sent to each target system.

[0031] By defining a collaborative workflow template with a DAG structure, complex multi-system collaborative logic is orchestrated into a configurable atomic collaborative task graph, supporting precondition assertions and conditional dependencies, thus solving the problems of poor scalability and inability to adapt to complex working conditions in existing technologies. Through a protocol semantic mapping library and a composite key retrieval mechanism, a rapid conversion from abstract semantic actions to specific protocol messages is achieved, ensuring low-latency response to instantaneous state changes.

[0032] This application also proposes a multi-system heterogeneous protocol collaborative system based on two-vote state driving, including a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the steps of the aforementioned multi-system heterogeneous protocol collaborative method based on two-vote state driving.

[0033] Furthermore, although exemplary embodiments have been described herein, their scope includes any and all embodiments based on this disclosure that have equivalent elements, modifications, omissions, combinations (e.g., schemes involving intersections of various embodiments), adaptations, or changes. They are not limited to the examples described in this specification or during the implementation of this application, and such examples are to be construed as non-exclusive.

[0034] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more of them) can be used in combination with each other. Other embodiments can be used by those skilled in the art when reading the above description.

[0035] The above embodiments are merely exemplary embodiments of this disclosure. Those skilled in the art can make various modifications or equivalent substitutions to this invention within the scope of the disclosure, and such modifications or equivalent substitutions should also be considered to fall within the protection scope of this invention.

Claims

1. A multi-system heterogeneous protocol collaboration method based on two-vote state-driven approach, characterized in that, include: A semantic model of state events oriented towards the lifecycle of two tickets is constructed, which maps multiple key state nodes of the two tickets to corresponding state event types, and associates a set of target system identifiers and communication triggering conditions with each state event type, wherein the key state nodes cover the lifecycle of the two tickets; A protocol semantic mapping library is built in the protocol adaptation layer. Corresponding command semantic templates are predefined for the protocols used by each system of the power plant. Each command semantic template contains the mapping relationship between protocol semantics and two-ticket status event semantics. The message queue for monitoring the status changes of two tickets in the two-ticket management system is used. When a status transition of two tickets is detected, the triggering conditions are determined according to the state event semantic model, and a status event record is generated. Based on the state event records, the corresponding command semantic rules are retrieved from the protocol semantic mapping library; The command semantic rules are parsed to obtain the target system, required protocol format, and field mapping method, and then sent to each target system for collaborative execution.

2. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 1, characterized in that, The key status nodes include at least the following: draft ticket pending review, approved, permitted to commence work, in progress, interrupted, and finalized and archived.

3. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 2, characterized in that, The state event semantic model is used to describe the original event data structure generated when two states transition, and is defined as the semantic structure of a tuple event. The semantic structure includes event context tags, which are used to describe the state of the two votes before and after.

4. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 3, characterized in that, The state transition semantic mapping rule base includes matching conditions, semantic type enumeration values, and collaborative workflow templates, wherein... The matching condition is a logical combination of the previous and next states of the two votes; The semantic type enumeration value is an enumeration of business semantic types corresponding to the state transitions under the logical combination; The collaborative workflow template is used to present the coverage of the semantic type enumeration values ​​based on a predefined directed acyclic graph (DAG).

5. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 4, characterized in that, The collaborative workflow template specifically defines collaborative tasks as directed acyclic graphs (DAGs). The nodes of the DAG are represented as atomic collaborative tasks, and the directed edges of the DAG define the execution dependencies from the source task node to the target task node.

6. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 5, characterized in that, In the event that a certain atomic cooperative task fails and triggers a rollback operation, the method further includes: Traverse the successfully executed atomic cooperative tasks in reverse topological order of the DAG graph; For adjacent successfully executed atomic collaborative tasks, a compensation protocol instruction is sent to the corresponding target system according to a predefined compensation protocol. Before sending the compensation protocol instruction, the current actual state of the target system is read. If the current actual state is consistent with the target state of the compensation protocol instruction, the issuance of the compensation protocol instruction is skipped.

7. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 4, characterized in that, Based on the state event semantic model, determining whether the triggering conditions are met and generating state event records includes: Real-time reception of status change information for two votes, wherein the status change information contains complete tuple event data; Parse the status change information and extract the fields containing the before and after states of the two votes; Traverse the state transition semantic mapping rule base and match the extracted fields with the matching conditions of each rule in the state transition semantic mapping rule base; If a matching rule exists, the triggering condition is determined to be met; otherwise, the event is discarded. A status event record is generated based on the matching rules and the original event.

8. The multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in claim 7, characterized in that, Based on the aforementioned state event records, retrieving the corresponding command semantic rules from the protocol semantic mapping library includes: Based on the status event records, determine the applicable device range for the atomic collaborative task nodes in the DAG graph of the corresponding collaborative workflow template; Based on the applicable device range, a composite key is established for retrieving the protocol semantic mapping library, so as to perform retrieval in the protocol semantic mapping library using the composite key.

9. A multi-system heterogeneous protocol collaborative system based on two-vote state-driven architecture, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, which, when executed by the processor, implements the steps of the multi-system heterogeneous protocol collaboration method based on two-vote state-driven as described in any one of claims 1 to 8.

Images