A unified event chain control device for an automation system

Abstract

The application discloses a unified event chain control device of an automation system, relates to the technical field of automation systems, and is used for improving the safety of the automation system.In the device, the unified event chain control device declares the logical precedent of each event node when the event node is generated, and the existence is strictly checked through a precedent dependency checking module, so that the internal logical continuity of the event chain is ensured.The topological integrity of the whole business process is checked through an event chain construction and closed loop judgment module, and the safety of the high-consequence automation system is improved.

Description

Technical Field

[0001] This application relates to the field of automation system technology, and in particular to a unified event chain control device for automation systems. Background Technology

[0002] With the rapid development of the Industrial Internet and automation control technologies, high-consequence automation systems are increasingly being applied in key sectors such as energy, transportation, and intelligent manufacturing. In these systems, various control activities (such as judgment, governance, rule verification, formal submission, execution control, review, and result feedback) directly impact production safety and equipment stability. To ensure the traceability of critical business activities, the clarity of responsibility, and the overall compliance of the automation system, it is necessary to record and manage data from each control node and business execution stage.

[0003] High-consequence automated systems typically employ distributed log auditing systems or state machine mechanisms to record critical activities. Specifically, these technologies usually treat activities such as judgment, governance, verification, submission, execution, and review as independent states or actions, recording them as distributed text logs, timestamps, message messages, database records, or discrete state bits. When it's necessary to connect the entire control flow, these technologies primarily use post-event queries, relying on the proximity of the generation times of various records, the physical adjacency of log entries, index inference from specific business serial numbers, or text matching of local fields to attempt to reconstruct the sequence of events. This implementation is essentially based on a discrete fact retention mechanism where events are recorded as they occur. The records of each control action are independent at the time of generation, and subsequent result nodes rely only on their own local states when generating their own records, forming a free and loosely coupled model that does not require structured, strongly correlated preceding node states.

[0004] However, under the higher security requirements of high-consequence automated systems, when there are bypass operations where the execution result has occurred but the necessary preceding events are missing, or when intermediate events are improperly added, backfilled, or inserted in reverse order afterward, the relevant technologies will still generate isolated records according to their local occurrence state. In subsequent tests based on time adjacency or field matching, these improperly pieced-together nodes will be identified as a seemingly complete process, thus reducing the security of the automated system. Summary of the Invention

[0005] This application provides a unified event chain control device for automated systems to improve the security of automated systems.

[0006] Firstly, a unified event chain control device for an automated system is provided, characterized by comprising: a control activity normalization module, used to acquire the current control activity in the automated system, generate a corresponding current event node based on the current control activity, and assign the current event node a corresponding node type identifier and a preceding reference identifier pointing to a preceding event; a preceding dependency verification module, used to determine the set of preceding node types necessary for the current event node to be established based on the node type identifier and preset event dependency rules, and to perform an existence search in the formal path event database based on the preceding reference identifier, outputting a preceding verification passed status when a necessary preceding event corresponding to the preceding node type set is found, otherwise outputting a preceding verification failed status; and an event chain construction and closed-loop determination module, used to be triggered when the preceding dependency verification module outputs a preceding verification passed status, write the preceding reference identifier as a strong association anchor point into the current event node, and append the current event node to the candidate event chain of the business to which it belongs. If the node type identifier of the current event node indicates that it belongs to an intermediate process event, then the candidate event chain is given intermediate validity to continue flowing. When the node type identifier of the current event node indicates that it belongs to a result event or a receipt event, a path closure determination is triggered to further verify whether the candidate event chain after adding the current event node completely and continuously contains the starting event, necessary intermediate events, and ending event of the system instruction in the logical topology. If so, the closure is passed; otherwise, the closure is not passed. The formal path validity control module is used to determine that the candidate event chain does not meet the conditions for being a formal control instruction delivery path when the preceding verification fails or when the path closure determination of the result event or receipt event is not closed. It strips the candidate event chain of its validity as a formal control instruction delivery path and simultaneously issues abnormal diversion, blocking, or controlled physical degradation control instructions to the bottom hardware layer.

[0007] By adopting the above technical solution, the unified event chain control device declares the logical preorder of each event node at the time of its generation and performs strict existence checks through the preorder dependency verification module, ensuring the inherent logical continuity of the event chain. Furthermore, the event chain construction and closed-loop determination module verifies the topological integrity of the entire business process, preventing pseudo-compliant event chains with missing or out-of-order intermediate links from being accepted. When any verification fails, the formal path effectiveness control module can proactively intervene and issue physical control commands, thereby improving the security of the high-consequence automation system.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the control activity normalization module specifically includes: a heterogeneous signal parsing unit, used to receive the current control activity across the information management network layer and the industrial control hardware layer; when the current control activity is a control command message issued by the upper layer, it extracts logical signaling features; when the current control activity is a potential change or position feedback signal from the lower layer sensor, it extracts physical state features; and a unified identifier mapping unit, used to uniformly convert the logical signaling features or physical state features into the current event node based on a preset event mapping matrix, and extract a prefix identifier according to the network security domain to which the current control activity belongs, and generate a node type identifier.

[0009] By adopting the above technical solution and setting up a heterogeneous signal parsing unit and a unified identifier mapping unit, it is possible to handle control activities from various sources and formats from the information management network layer and the industrial control hardware layer.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the preceding dependency verification module specifically includes: a time decay verification unit, used to read the dynamic lifetime window bound to the necessary preceding event when a necessary preceding event is retrieved in the formal path event library, and compare whether the current system time exceeds the dynamic lifetime window; if it exceeds the window, output a preceding state aging failure flag; a mutual exclusion state overwrite verification unit, used to search backward in the formal path event library for whether there is an overwrite event node that is mutually exclusive with the necessary preceding event; if an overwrite event node is found, output a preceding state reversal failure flag; and an existence determination unit, used to output a preceding verification passed status only when a necessary preceding event is retrieved and no preceding state aging failure flag or preceding state reversal failure flag is received.

[0011] By employing the above technical solutions, the time decay check unit ensures that the system will not rely on a prior state that has become invalid due to excessive time. The mutual exclusion state overwrite check unit prevents a prior event's state from being incorrectly treated as a valid dependency even after it has been invalidated by a conflicting operation. The existence determination unit integrates the results of these two deep checks, ensuring that the validity determination of prior dependencies considers not only existence but also timeliness and state consistency. This allows for more accurate identification and rejection of prior dependencies that appear to exist but are actually invalid, further enhancing the system's security.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the event chain construction and closed-loop determination module specifically includes: a topology model loading unit, used to call the corresponding preset path graph model as the standard path topology matrix according to the business type associated with the current control activity; and a continuity comparison unit, used to fold all event nodes contained in the candidate event chain into actual execution vectors according to the time sequence, and project the actual execution vectors onto the standard path topology matrix to calculate the node coverage matching degree. If the coverage matching degree indicates that the actual execution vectors completely cover the necessary key nodes in the standard path topology matrix and there are no jump anomalies, then it is determined that the preset closed-loop condition is met, and an identifier indicating that the path closed-loop status has been verified is output.

[0013] By adopting the above technical solution, the topology model loading unit provides a preset standard flowchart for each business type, while the coherence comparison unit accurately compares the actual executed event sequence with this standard model. This comparison method based on the topology matrix ensures that only event chains that fully conform to the preset business logic can be identified as formal paths, thereby improving the compliance of process execution.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the formal path effectiveness control module further includes a dual-chain conflict identification unit, used to determine that a dual-chain conflict phenomenon of inconsistent execution state has occurred between the application layer logic approval link and the underlying hardware state change link of the automation system when the node type identifier extracted by the control activity normalization module indicates that the current event node is a result event from the industrial control hardware layer, and the preceding dependency verification module outputs a preceding verification failure status, or the path closure determination of the result event is not closed; when a dual-chain conflict is triggered, the current control activity is marked as a physical bypass intrusion event that bypasses software logic approval and is directly initiated at the hardware end, and a blocking control command is triggered to be output.

[0015] By adopting the above technical solution, when the status feedback of the underlying hardware is inconsistent with the authorization record of the upper-layer application logic, the dual-chain conflict identification unit can determine that a dual-chain conflict has occurred and characterize this behavior as a physical intrusion event that bypasses software approval. This enables the system to discover deeper security threats from seemingly isolated hardware status changes and trigger a high-level blocking response, thereby enhancing the system's ability to resist physical attacks.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the operation of the formal path effectiveness control module triggering blocking control instructions or controlled degradation control instructions specifically includes: a physical enable blocking unit, used to generate a blocking control instruction when a physical bypass intrusion event is determined to exist, the blocking control instruction being used to cut off the power enable channel of the underlying controlled hardware corresponding to the current control activity; a gray-scale degradation operation unit, used to determine a non-intrusive event absence when a pre-verification failure state is determined to occur, and no corresponding event node input is received within a preset time, and the underlying controlled hardware does not report contradictory action execution feedback, and generate a controlled degradation control instruction, the controlled degradation control instruction being used to strip the formal write library permission of the candidate event chain containing the current event node, and redirect the instruction data packet and communication session corresponding to the candidate event chain to the network isolation sandbox environment for observation and interception.

[0017] By adopting the above technical solutions, for high-risk physical bypass intrusions, the physical enable blocking unit performs hard blocking by cutting off the power to enable the channel. For event absences caused by non-malicious factors such as network latency, the gray-scale degradation operation unit adopts a flexible isolation measure of redirecting suspicious sessions to a sandbox, which not only prevents potential risks but also avoids the possibility of interrupting normal business due to overreaction. This makes security control more intelligent and efficient.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the event chain construction and closed-loop determination module further includes an anti-tampering anchoring unit, which is used to extract the digital signature features, current control parameters and timestamp of the preceding event when the preceding reference identifier is written to the current event node, and calculate and generate a chain feature verification code through an irreversible encryption algorithm, and solidify the chain feature verification code into the chain head verification field of the candidate event chain after the current event node is appended.

[0019] By adopting the above technical solution, introducing tamper-proof anchoring units, and using irreversible encryption algorithms to generate chain-like feature verification codes, each event node is strongly bound to its preceding events at the cryptographic level, making the entire event chain form a tamper-proof data structure. Any illegal modification or insertion of any historical node in the chain will destroy the verification code at the head of the chain, thereby improving the reliability of audit traceability.

[0020] In conjunction with some embodiments of the first aspect, some embodiments further include a suspended event timeout cleanup module connected to the event chain construction and closed-loop determination module. This module is used to read pre-configured hardware rated action delay parameters and calculate the maximum reasonable time threshold for the occurrence of the result event downstream of the candidate event chain after the event chain construction and closed-loop determination module adds the current event node that belongs to the necessary intermediate event to the candidate event chain. If the maximum reasonable time threshold is exceeded and the corresponding verification receipt input is still not detected, it is determined that an execution fault anomaly has occurred, and the chain identifier of the candidate event chain is extracted and actively destroyed.

[0021] By adopting the above technical solution and setting up a suspended event timeout cleanup module, it is possible to proactively manage and clean up suspended event chains in the system caused by execution interruption or loss of feedback. By setting reasonable timeout thresholds, invalid process instances that have issued instructions but have not received results for a long time can be promptly detected and destroyed, thus avoiding waste of system resources and bloat of the state database.

[0022] In conjunction with some embodiments of the first aspect, some embodiments further include a cross-domain collaborative verification module, which is used to send an asynchronous verification probe to the peer physical domain according to the pre-reference identifier when the node type identifier indicates that the current control activity involves transmission across physical isolation domains, and temporarily place the candidate event chain containing the current event node in a cross-domain pending state if no matching result is obtained when performing an existence search locally; if no verification pass synchronous acknowledgment is received from the response probe within a preset tolerance transmission time limit, the candidate event chain in the pending state is marked as a cross-domain chain breakage anomaly, and the cross-domain chain breakage anomaly is fed back to the formal path effectiveness control module.

[0023] By adopting the above technical solution, when the preceding sequence of an event depends on isolation devices such as network gateways, the cross-domain collaborative verification module solves the problem of event chain interruption caused by network isolation in complex network environments such as IT / OT convergence through the mechanism of asynchronous probes and synchronous receipts. Thus, the integrity and continuity verification of the event chain can still be effectively performed in complex business processes across security domains.

[0024] In conjunction with some embodiments of the first aspect, some embodiments further include an event chain state rollback module, specifically including: a closed-loop anomaly response unit, used to trigger when the formal path effectiveness control module determines that the path closed-loop state of the result event or receipt event is not closed-loop and the candidate event chain effectiveness is stripped, extracting the most recent lossless event node group with a complete closed-loop state from the formal path event library in descending order of time; and a reverse tracing compensation unit, used to compare the changed action variables in the currently failed candidate event chain based on the state parameters of the lossless event node group, generate a corresponding reverse undo event instruction set, issue the reverse undo event instruction set to perform action compensation, and revert the system logical state to the most recent compliance and security baseline.

[0025] By adopting the above technical solution, the closed-loop anomaly response unit can quickly locate the nearest safety status baseline, and the reverse tracing and compensation unit can automatically generate compensation instructions based on this baseline to revert the system from an illegal or inconsistent state to a known compliant state, thereby shortening the anomaly handling time.

[0026] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0027] 1. The unified event chain control device declares the logical preorder of each event node upon generation and performs rigorous existence checks through a preorder dependency verification module, ensuring the inherent logical continuity of the event chain. Furthermore, the event chain construction and closed-loop determination module verifies the topological integrity of the entire business process, preventing pseudo-compliant event chains with missing or out-of-order intermediate links from being accepted. When any verification fails, the formal path effectiveness control module can proactively intervene and issue physical control commands, thereby enhancing the security of the high-consequence automation system.

[0028] 2. The time-decrease check unit ensures that the system will not depend on a prior state that has become invalid due to excessive time. The mutual exclusion state overwrite check unit prevents a prior event's state from being incorrectly treated as a valid dependency after it has been invalidated by a conflicting operation. The existence determination unit combines the results of these two deep checks, ensuring that the validity determination of prior dependencies considers not only existence but also timeliness and state consistency. This allows for more accurate identification and rejection of prior dependencies that appear to exist but are actually invalid, further enhancing the system's security.

[0029] 3. The closed-loop anomaly response unit can quickly locate the nearest safety status baseline, and the reverse tracing and compensation unit can automatically generate compensation instructions based on this baseline to roll back the system from an illegal or inconsistent state to a known compliant state, thereby shortening the anomaly handling time. Attached Figure Description

[0030] Figure 1 This is a module architecture diagram of the unified event chain control device in the embodiments of this application.

[0031] Figure 2 This is a schematic diagram of the control activity normalization module of the unified event chain control device in this application embodiment.

[0032] Figure 3 This is a schematic diagram of the pre-process dependency verification module of the unified event chain control device in this application embodiment.

[0033] Figure 4This is a schematic diagram of the event chain construction and closed-loop determination module of the unified event chain control device in this application embodiment. Detailed Implementation

[0034] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0035] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0036] This application provides a unified event chain control device for automated systems to improve the security of automated systems.

[0037] Please see Figure 1 This is a module architecture diagram of the unified event chain control device in the embodiments of this application.

[0038] The unified event chain control device includes:

[0039] The control activity normalization module 101 is used to obtain the current control activity in the automation system, generate the corresponding current event node based on the current control activity, and assign the current event node the corresponding node type identifier and the preceding reference identifier pointing to the preceding event.

[0040] In this context, an automation system refers to an integrated system in fields such as industrial production, energy management, and traffic control that integrates information technology and operational technology to automatically monitor, control, and manage physical processes. Current control activity refers to any instantaneous operation, state change, or information interaction that can be captured within the automation system, such as production work order instructions from a manufacturing execution system, logical steps executed by a programmable logic controller, or changes in physical quantities reported by field sensors. A current event node is a structured data unit formed by standardizing the aforementioned raw, heterogeneous control activities; this data unit is the basic link in the event chain. A node type identifier is a classification label assigned to the current event node, indicating the nature and source of the event; for example, it can be categorized as an instruction issuance event, a manual approval event, or an equipment status feedback event. A preceding reference identifier is a directional data element carried within the current event node, typically a unique identifier (such as a hash value or globally unique ID) of the preceding logically related event, used to declare the preceding stage that the current event logically depends on.

[0041] Specifically, the control activity normalization module 101 continuously monitors or receives activity signals from various levels of the system in real time. Once a new control activity is captured, regardless of whether it comes from an instruction message from the upper-level management software or a physical signal from the lower-level hardware, the primary responsibility of this module is to perform normalization processing, that is, to eliminate the differences in format, protocol, and semantics between activities from different sources. This module parses the inherent meaning of the control activity and encapsulates it into a current event node in a unified format. In the process of generating the current event node, this module assigns a node type identifier and a preceding reference identifier to the current event node according to preset business logic rules. The preceding reference identifier does not point to an event that has already occurred, but rather to the identifier of the preceding event that the current event depends on, according to the business process definition.

[0042] In some embodiments, the functionality of the control activity normalization module can be implemented in several ways: Optionally, a message bus-based adapter architecture can be adopted. First, dedicated adapter plugins are developed for different types of control activity sources (such as OPC UA servers, Modbus devices, and database logs). Second, all adapters push the captured raw activity information to a central message queue (such as Kafka or RabbitMQ). Finally, a normalization processing service subscribes to the message queue, consumes messages in the queue, and, based on the message's source and content, calls the corresponding parsing and mapping logic to generate standardized event nodes containing node type identifiers and preorder reference identifiers. Optionally, an edge computing gateway-based implementation can also be adopted. First, a smart gateway device is deployed at the edge of the industrial network close to the data source. Second, an event definition script is configured on the gateway, which describes how to extract key information from local protocol messages and construct them into standard event nodes. Finally, when the gateway detects a qualified local control activity, it performs normalization processing directly at the edge and securely uploads the generated event node to the central control device.

[0043] The prerequisite dependency verification module 102 is used to determine the set of prerequisite node types necessary for the current event node to be established based on the node type identifier in the preset event dependency rules, and to perform an existence search in the formal path event database based on the prerequisite reference identifier. When a necessary prerequisite event corresponding to the prerequisite node type set is found, the prerequisite verification is output as passed; otherwise, the prerequisite verification is output as failed.

[0044] The node type identifier refers to the classification label assigned to the current event node by the control activity normalization module 101. The preset event dependency rule refers to a pre-configured rule base or relation matrix that defines the logically correct sequence and dependency relationships between different types of event nodes. For example, it stipulates that a completed event must be preceded by a starting event. The set of preceding node types represents the combination of one or more preceding event types that must exist for a specific type of current event node to be valid, according to the aforementioned dependency rules. The preceding reference identifier is a unique identifier contained in the current event node that points to its declared logical preceding event. The formal path event library is a database or trusted storage area used to store event nodes that have passed all verifications and been confirmed as valid and legal. The events recorded therein constitute the formal trajectory of system operation. The necessary preceding event refers to the verified event that is actually retrieved from the formal path event library according to the preceding reference identifier and has a dependency relationship with the current event node. The preceding verification pass / fail status is a binary judgment result output by this module, used to indicate whether the preceding dependency relationship declared by the current event node has been satisfied.

[0045] Specifically, the prerequisite dependency verification module 102 reads the node type identifier of the current event node and uses it as an index to query the set of prerequisite node types required for that type of event in the preset event dependency rules. Then, the prerequisite dependency verification module uses the prerequisite reference identifier carried in the current event node to perform a precise search in the trusted historical record of the formal path event library to find if there is an event with a unique identifier that matches it; this found event is the necessary prerequisite event. Finally, the prerequisite dependency verification module compares the type of the retrieved necessary prerequisite event with the set of prerequisite node types determined in the first step. If the necessary prerequisite event is successfully found in the formal path event library, and its type also meets the requirements of the dependency rules, the prerequisite verification passes. Conversely, if no corresponding event can be found based on the prerequisite reference identifier, or if the found event type does not match, the prerequisite verification fails.

[0046] In some embodiments, the functionality of the preceding dependency verification module can be implemented in several ways: Optionally, firstly, the preset event dependency rules are stored in a relational table, with fields including "current node type" and the required preceding node type. Secondly, the formal path event library is an indexed event table, where each event node is assigned a unique hash value as its identifier upon entry into the library; the preceding reference identifier is the hash value of the target preceding event. Finally, during verification, the required preceding type is obtained by querying the dependency rule table based on the type of the current event node, and then the preceding reference identifier (hash value) is used to retrieve the event type from the event table, comparing whether the event type of the retrieved result matches the requirement. Optionally, the entire preset event dependency rule can also be modeled as a directed graph, where nodes represent event types and edges represent dependencies. Secondly, the formal path event library itself is a continuously growing event instance graph, where each verified event is an instance node. Finally, the verification process is transformed into a graph query: verifying whether the dependency edges declared by the current event node and defined by the preceding reference identifier can connect to existing parent nodes in the graph whose node types conform to the dependency rule graph model.

[0047] The event chain construction and closed-loop determination module 103 is triggered when the preceding dependency verification module outputs the preceding verification pass status. It writes the preceding reference identifier as a strong association anchor point into the current event node and appends the current event node to the candidate event chain of the business. If the node type identifier of the current event node indicates that it belongs to the intermediate process event, it gives the candidate event chain the intermediate effect of continuing to flow. When the node type identifier of the current event node indicates that it belongs to the result event or the receipt event, it triggers the path closed-loop determination and further verifies whether the candidate event chain after appending the current event node completely and continuously contains the starting event, necessary intermediate events and ending events of the system instruction in the logical topology. If so, the closed loop passes; otherwise, the closed loop fails.

[0048] Strongly correlated anchors refer to the immutable structured data that solidifies the preceding reference identifier, which has passed the preceding verification, into the current event node, forming a strong binding relationship with the preceding event based on cryptography or data structure guarantees. A candidate event chain represents a sequence of event nodes being added chronologically for a specific business process (such as a complete switch operation). This chain is in a candidate state until the business process completes its closed-loop determination. Intermediate process events are events that are neither the start nor the end point of a business process, serving as a bridge between preceding and following events, such as approval approval or execution. Intermediate validity grants a temporary legitimacy to a candidate event chain, allowing subsequent events related to the business process to continue generating and joining the chain, but the chain has not yet been confirmed as the final, complete, and official record. Result events or receipt events are events that signify the final result of a business operation in the physical world or at the logical level, such as sensor feedback indicating a fully open valve (result event) or a confirmation message from the system confirming receipt of the execution result (receipt event). Path closed-loop determination is the final review of the completeness and logical coherence of a candidate event chain. Logical topology completeness and continuity means that the sequence of nodes in the event chain is not only continuous in time, but also strictly follows the predefined business process model in logic, without missing necessary links or illegal jumps.

[0049] Specifically, the event chain construction and loop closure determination module 103 is triggered after the preceding dependency verification module 102 outputs the preceding verification pass status. The event chain construction and loop closure determination module first writes the preceding reference identifier into the structure of the current event node as a strong association anchor. Then, based on the business identifier to which the current event node belongs, it appends it to the end of the corresponding candidate event chain. Next, the event chain construction and loop closure determination module determines the type of the current event node. If it is an intermediate process event, it means the business process has not yet ended, and the event chain construction and loop closure determination module confirms the intermediate validity of the candidate event chain, allowing the process to continue flowing downwards. However, when the appended current event node is a result event or a receipt event, this usually marks the end of a business process, and the path loop closure determination mechanism is immediately triggered. The event chain construction and loop closure determination module calls the standard process model corresponding to the business to comprehensively review the entire candidate event chain containing the newly added endpoint event, verifying whether the chain contains all necessary intermediate events from the starting event to the current endpoint event in the correct order and completely. If a complete match is found, the loop closure is considered successful, and the candidate event chain is converted into a formal path, with its event nodes persisted to the formal path event library. If a key link is missing or the sequence is incorrect, the loop closure is considered unsuccessful.

[0050] In some embodiments, the function of the event chain construction and loop closure determination module can be implemented in several ways: Optionally, a finite state machine (FSM) model can be pre-designed for each business type, defining all states (corresponding to event node types) and legal state transition paths. A candidate event chain corresponds to the execution trajectory of a state machine instance. Each additional event node is equivalent to a state transition of the state machine. Finally, when the endpoint event triggering the loop closure determination arrives, it is checked whether the state machine instance has reached the preset terminal state and whether its state transition path is one of the legal paths allowed in the model. Optionally, the standard process of each business can also be defined as an ordered template containing all necessary event node types. The types of all event nodes in the candidate event chain are extracted in chronological order to form an actual execution sequence. Finally, during loop closure determination, this actual execution sequence is compared with the corresponding business process template, for example, using string matching or sequence alignment algorithms, to determine whether the actual sequence completely and unorderedly covers all necessary nodes defined in the template.

[0051] In some embodiments, the event chain construction and closed-loop determination module 103 further includes an anti-tampering anchoring unit. This unit is used to extract the digital signature features, current control parameters, and timestamp of the preceding event when writing the preceding reference identifier to the current event node, and to calculate and generate a chain-like feature verification code using an irreversible encryption algorithm (such as SHA-256). The chain-like feature verification code is then embedded into the head verification field of the candidate event chain after the current event node is appended. The digital signature feature can be the hash value of the preceding event node or a signature of its specific content. The chain-like feature verification code is a value obtained by hashing the verification code of the previous stage and the key information of the current stage, ensuring the continuity and immutability of the event chain. Specifically, when a current event node passes the preceding verification, the anti-tampering anchoring unit is activated before being appended to the candidate event chain. The unit first obtains the digital signature characteristics of its predecessor event node (e.g., the hash value of the entire preceding event node's data block), and combines this with the current event node's key control parameters (such as operation instructions and target values) and the current system timestamp. This data is then input as a whole into a one-way, irreversible encryption algorithm to calculate a new hash value, i.e., the chain-feature checksum. Subsequently, the unit updates the head of the candidate event chain or a dedicated metadata field with this newly generated chain-feature checksum. In this way, each newly added node is strongly bound to the previous node through a cryptographic mechanism. Any tampering with historical nodes in the chain will invalidate the checksums of all subsequent nodes, thereby enhancing the event chain's tamper-proof capability.

[0052] In some embodiments, the device further includes a suspended event timeout cleanup module connected to the event chain construction and loop closure determination module 103. This module is used to, after the event chain construction and loop closure determination module 103 adds a current event node belonging to a necessary intermediate event to the candidate event chain, read a pre-configured hardware rated action delay parameter, calculate the maximum reasonable time threshold for the occurrence of a result event downstream of the candidate event chain, and if no corresponding verification receipt input is detected after exceeding the maximum reasonable time threshold, determine that an execution breakdown anomaly has occurred, and extract the chain identifier of the candidate event chain for proactive destruction. The hardware rated action delay parameter is the standard time required for a physical device to complete an action, set according to the device manual or empirical values. An execution breakdown anomaly refers to a state where a control command has been issued, but no result feedback has been received within the expected physical response time. Specifically, when an intermediate event node representing command issuance or process initiation is successfully added to the candidate event chain, the event chain construction and loop closure determination module 103 notifies the suspended event timeout cleanup module. This module immediately starts a timer associated with the candidate event chain. The timer's duration is a maximum reasonable time threshold dynamically calculated based on the hardware's rated action delay parameters associated with the operation. If the system receives the expected result event or acknowledgment event (and successfully establishes a closed loop) before the timer expires, the timer is canceled normally. Conversely, if the timer expires and the corresponding result event has not yet occurred, the module determines that an execution breakout anomaly has occurred, assuming that the control flow has been interrupted or lost at the execution level. In this case, the module extracts the unique identifier of the dangling candidate event chain, marks it as an anomaly, and triggers destruction or archiving operations. Simultaneously, it can generate an alarm event to notify the upper-level system to prevent invalid candidate event chains from permanently occupying system resources and causing state chaos.

[0053] The formal path effectiveness control module 104 is used to determine that the candidate event chain does not meet the conditions for being a formal control instruction delivery path when the preceding verification fails or when the path closure of the result event or receipt event is not closed. It then strips the candidate event chain of its effectiveness as a formal control instruction delivery path and simultaneously issues abnormal diversion, blocking, or controlled physical degradation control instructions to the bottom hardware layer.

[0054] In this context, the formal control command delivery path refers to a fully verified and confirmed event chain from command issuance to result feedback. Stripping effect refers to disqualifying a candidate event chain as a formal path, rendering it no longer considered a legitimate control flow record, and its contained commands and data will not be adopted or executed by the system. The bottom hardware layer refers to the field device layer in an automation system that is closest to the physical world, including actuators (such as motors and valves), sensors, and field controllers. Anomaly diversion, blocking, or controlled physical degradation control commands are intervention commands actively generated and issued to the underlying hardware by this module when an anomaly is detected. For example, a blocking command can cut off the power or communication of a device, a diversion command can redirect suspicious data streams to an isolated environment, and controlled degradation refers to limiting the device's function or performance to operate in a lower mode while ensuring basic safety.

[0055] Specifically, the formal path effectiveness control module 104 is the decision-making and execution terminal of this device, and it is triggered in two key scenarios: first, when the preceding dependency verification module 102 directly outputs a preceding verification failure status; second, when the event chain construction and closed-loop determination module 103 determines that a candidate event chain containing result / receipt events has failed to close the loop. In either case, it means that an anomaly has occurred in the current system state that seriously violates the preset logic rules. Once triggered, the formal path effectiveness control module first determines that the current problematic candidate event chain does not meet the conditions for becoming a formal control instruction delivery path. Immediately afterwards, the formal path effectiveness control module marks the candidate event chain as invalid or illegal at the system level, prevents it from being written into the formal path event library, and cancels any control intent represented by the chain. It will also immediately send specific control instructions with physical intervention capabilities to the bottom hardware layer to proactively curb the risks that the anomaly may bring. The specific content of the instruction (whether it is blocking, diverting, or downgrading) depends on the analysis of the anomaly type and the preset security policy. Its purpose is to pull the system back from an inconsistent or insecure state to a known and controllable secure state.

[0056] In some embodiments, the formal path effectiveness control module 104 further includes a dual-chain conflict identification unit. This unit is used to determine that a dual-chain conflict occurs between the application layer logic approval link and the underlying hardware state change link of the automation system when the node type identifier extracted by the control activity normalization module indicates that the current event node is a result event from the industrial control hardware layer, and the preceding dependency verification module outputs a preceding verification failure status, or the path closure determination of the result event is not closed; when a dual-chain conflict is triggered, the current control activity is marked as a physical bypass intrusion event that bypasses software logic approval and is directly initiated at the hardware end, and a blocking control command is triggered to be output.

[0057] The application-layer logical approval chain refers to the sequence of events from instruction issuance to approval confirmation at the software level. The underlying hardware state change chain refers to the sequence of events consisting of the actual actions and state feedback of physical devices. The double-chain conflict phenomenon refers to a mismatch or contradiction between these two chains that should be consistent.

[0058] Specifically, when a status feedback from the underlying hardware (such as a valve being open) is processed as a result event, if the preceding dependency verification or closed-loop determination fails (e.g., no corresponding valve-opening instruction event is found), the dual-chain conflict identification unit is triggered. This unit determines that this situation is a typical dual-chain conflict: the underlying hardware state (valve open) has changed, but there is no such authorization record on the upper-layer application logic approval link. This indicates that there is an unauthorized physical bypass operation. At this time, the unit will characterize this hardware result event of unknown origin as a physical bypass intrusion event and immediately pass this high-risk determination result to the formal path effectiveness control module 104, triggering a high-priority response, namely generating and issuing a blocking control command.

[0059] In some embodiments, the formal path effectiveness control module 104 triggers blocking control commands or controlled degradation control commands, specifically including a physical enable blocking unit and a grayscale degradation operation unit. The physical enable blocking unit generates a blocking control command when a physical bypass intrusion event is detected. This blocking control command is used to cut off the power enable channel of the underlying controlled hardware corresponding to the current control activity. Specifically, when the dual-chain conflict identification unit determines that a physical bypass intrusion has occurred, the physical enable blocking unit generates a targeted blocking control command. This command is not issued through the conventional logic control path, but through an independent, high-security channel (e.g., connected to a safety relay or a dedicated safety PLC's I / O interface). This command directly acts on the target hardware's power enable channel or safety torque shutdown input, physically cutting off its power source or execution capability to achieve the fastest and most reliable device blocking, preventing the continuation of illegal operations. The gray-scale degradation operation unit is used to determine a non-intrusive event absence when a pre-processing verification fails, no corresponding event node input is received within a preset time, and the underlying controlled hardware does not report contradictory action execution feedback. It then generates a controlled degradation control command, which strips the candidate event chain containing the current event node of its formal write permissions and redirects the corresponding command data packets and communication sessions to a network isolation sandbox environment for observation and interception. Specifically, when the formal path effectiveness control module 104 determines that the anomaly is not due to a high-risk bypass intrusion, but rather a non-malicious event loss possibly caused by network jitter (e.g., the preceding event has not yet arrived), the gray-scale degradation operation unit is activated. The generated controlled degradation control command is a relatively mild handling measure. First, it causes the candidate event chain containing the current event node to lose its write permissions to the formal path event database, preventing it from polluting trusted records. Simultaneously, it coordinates with network devices (such as firewalls or SDN controllers) to redirect data streams (such as source IPs and ports) related to the candidate event chain to an isolated network sandbox environment. Within the sandbox, this data can be analyzed and observed in depth without affecting the operation of the main system, enabling controlled isolation of suspicious activities without completely blocking business operations.

[0060] In some embodiments, the unified event chain control device further includes a cross-domain collaborative verification module, which, when a node type identifier indicates that the current control activity involves transmission across physical isolation domains, if no matching result is obtained when performing an existence retrieval locally, sends an asynchronous verification probe to the peer physical domain based on the preceding reference identifier, and temporarily places the candidate event chain containing the current event node in a cross-domain pending state; if no verification pass synchronous acknowledgment is received from the response probe within a preset tolerance transmission time limit, the candidate event chain in the pending state is marked as a cross-domain chain breakage exception, and the cross-domain chain breakage exception is fed back to the formal path validity control module. Here, a physical isolation domain typically refers to two independent networks separated by network isolation devices (such as network gateways), such as an OT domain and an IT domain. An asynchronous verification probe is a cross-domain query request message used to request the peer domain to verify the existence and validity of an event. Specifically, when the preceding dependency verification module 102 processes a current event node that declares its preceding event occurred in another physical isolation domain, the retrieval in the local formal path event database will naturally fail. At this time, the request is passed to the cross-domain collaborative verification module. Based on the pre-reference identifier and target domain information, this module encapsulates an asynchronous verification probe and sends it to the peer domain via a specified cross-domain communication channel (such as through a whitelist protocol of a gateway). After sending the probe, the module places the candidate event chain containing the current event node into a temporary cross-domain pending state and starts a timer (with a preset tolerance transmission time limit). Upon receiving the probe, the local device instance in the peer domain performs local pre-dependency verification and encapsulates the result into a synchronous receipt and returns it. If the local domain receives a verified receipt within the time limit, it restores the candidate event chain to the normal state and continues the subsequent process. If no receipt is received after the timeout, or if a verification failure receipt is received, the candidate event chain is marked as a cross-domain chain break anomaly, and the formal path effectiveness control module 104 is notified to perform corresponding anomaly handling.

[0061] In some embodiments, the device further includes an event chain state rollback module, which specifically includes: a closed-loop anomaly response unit, used to extract the most recent lossless event node group with a complete closed-loop state from the formal path event library in descending time order based on the path closed-loop state of the result event or receipt event determined by the formal path effectiveness control module, and a reverse tracing compensation unit, used to compare the changed action variables in the currently failed candidate event chain based on the state parameters of the lossless event node group, generate a corresponding reverse undo event instruction set, and issue the reverse undo event instruction set to perform action compensation, so that the system logical state reverts to the most recent compliance and security baseline. Specifically, when the formal path effectiveness control module 104 strips the effectiveness of a candidate event chain due to failure to close the loop, the closed-loop anomaly response unit is triggered. It immediately accesses the official path event database, searching in reverse timestamp order from the current time until it finds all event nodes corresponding to the most recently successfully marked closed-loop business process. This group of event nodes is the lossless event node group, representing the system's most recent confirmed compliance status. Subsequently, the reverse tracing and compensation unit receives this group of lossless event nodes and compares it with the current candidate event chain judged as failed. Through comparison, it identifies which states or physical devices in the system have changed since the last compliance status. Based on these changed action variables, the unit automatically generates a series of logically opposite reverse undo event instructions (e.g., generating a valve-closing instruction if the failure chain includes a valve-opening action), and sends this instruction set to the control system for execution, thereby attempting to automatically roll back the system state to the most recent safe baseline and minimize the impact of abnormal states.

[0062] The above describes the module architecture diagram of the unified event chain control device in the embodiments of this application. The following describes each module.

[0063] Please refer to the following: Figure 2 This is a schematic diagram of the control activity normalization module of the unified event chain control device in this application embodiment.

[0064] Control activity normalization module 101 includes:

[0065] The heterogeneous signal parsing unit 1011 is used to receive the current control activity across the information management network layer and the industrial control hardware layer. When the current control activity is a control command message issued by the upper layer, it extracts the logical signaling features. When the current control activity is a potential change or position feedback signal from the lower layer sensor, it extracts the physical state features.

[0066] The information management network layer typically refers to the network environment of IT systems such as Enterprise Resource Planning (ERP) and Manufacturing Execution Systems (MES) located above the automation system. The industrial control hardware layer refers to the underlying operational technology network environment, including field devices such as PLCs, DCSs, sensors, and actuators. Logical signaling characteristics refer to key information extracted from upper-layer instruction messages that represents the instruction intent, parameters, and context, such as opcodes, target device addresses, user identities, and business serial numbers. Physical state characteristics refer to key information extracted from lower-level sensor signals that reflects the actual state of the physical world, such as the rising or falling edge of digital signals, the value of analog signals, and encoder position readings.

[0067] Specifically, when a control activity occurs, the heterogeneous signal parsing unit first determines its source. If the activity originates from the information management network layer, it typically manifests as structured or semi-structured data packets (such as XML, JSON, or proprietary TCP / UDP packets). In this case, the heterogeneous signal parsing unit activates the corresponding packet parser to extract logical signaling features such as instruction type, operation object, and execution parameters. If the activity originates from the industrial control hardware layer, it may take the form of a raw electrical signal change, such as a limit switch changing from 0V to 24V, or a temperature sensor reporting a real-time temperature value via a 4-20mA current signal. In this case, the heterogeneous signal parsing unit captures these signals through a data acquisition card or protocol gateway and extracts physical state features representing changes in device status. The output of the heterogeneous signal parsing unit, i.e., the extracted logical signaling features or physical state features, is intermediate data that is not uniformly formatted but already contains core semantics. This data is then passed to the unified identifier mapping unit 1012 for further processing.

[0068] In some embodiments, the heterogeneous signal parsing unit can be implemented in several ways: Optionally, the heterogeneous signal parsing unit integrates a protocol library containing parsing logic for various industrial and IT protocols. When a data stream is received, the heterogeneous signal parsing unit can identify its protocol type by the port number or the start characteristic byte of the data packet. Finally, the corresponding protocol parser is called to perform syntax analysis on the data packet and extract key fields in the payload as logical signaling features or physical status features. Optionally, for control activities appearing in the form of text logs, regular expression matching patterns can be predefined for different types of log entries. The heterogeneous signal parsing unit continuously monitors or receives log streams. When a new log entry appears, the heterogeneous signal parsing unit uses all preset regular expressions for matching. Once a match is successful, the corresponding value is extracted from the capture group of the matching result as a signaling or status feature.

[0069] The unified identifier mapping unit 1012 is used to convert logical signaling features or physical status features into current event nodes based on a preset event mapping matrix, and extract prefix identifiers according to the network security domain to which the current control activity belongs, and generate node type identifiers.

[0070] The preset event mapping matrix is ​​a lookup table or a set of mapping rules that defines the conversion relationship between various logical signaling characteristics or physical state characteristics and standardized current event nodes. A network security domain refers to a logical or physical network area divided according to security policies. Different security domains have clear access control boundaries; for example, they can be divided into IT domains, OT domains, and DMZs (Discretionary Zones). The prefix identifier is a short string or code generated based on the network security domain from which the event originated. It is appended to the node type identifier to quickly identify and distinguish the event's origin, such as IT or OT.

[0071] Specifically, the unified identifier mapping unit 1012 is triggered after the heterogeneous signal parsing unit 1011 completes feature extraction. This unit receives extracted logical signaling features or physical state features, but whose format and semantics may still vary. The unified identifier mapping unit converts the logical signaling features or physical state features into the current event node based on a preset event mapping matrix. For example, the preset event mapping matrix specifies that a logical signaling feature containing a specific opcode should be converted into an event node of type REMOTE COMMAND, and specifies which parameters should be included. Similarly, a physical state feature representing a valve in the correct position should be converted into an event node of type DEVICE FEEDBACK OPEN. During the conversion process, the unified identifier mapping unit also analyzes the source of the control activity (this information usually accompanies the original signal) to determine its network security domain. Then, based on this security domain, a predefined prefix identifier is extracted and concatenated with the basic type identifier obtained through the mapping matrix to generate the final node type identifier with the security domain context. For example, a startup command from an IT network might be generated as IT domain-command-start, while a startup feedback from a field PLC might be generated as OT domain-feedback-start.

[0072] Please refer to the following: Figure 3 This is a schematic diagram of the pre-order dependency verification module of the unified event chain control device in this application embodiment.

[0073] Precursor dependency verification module 102 includes:

[0074] The time decay verification unit 1021 is used to read the dynamic lifetime window bound to the necessary preceding event when the necessary preceding event is retrieved in the formal path event library, and compare whether the current system time exceeds the dynamic lifetime window. If it exceeds the window, the preceding state aging failure flag is output.

[0075] Among them, the necessary preceding event refers to the logical preceding event retrieved by the preceding dependency verification module 102 from the formal path event library based on the preceding reference identifier of the current event node. The dynamic lifetime window refers to the time interval associated with an event node that defines its validity. The starting point of this interval is usually the occurrence time of the event, and its length (i.e., lifetime) can be fixed or dynamically adjusted according to the event type or system state. The preceding status aging failure flag is a specific signal or status flag output by this unit when it discovers that a preceding event has exceeded its valid lifetime, used to notify the existence determination unit that although the preceding event exists, it is no longer valid.

[0076] Specifically, when a necessary preceding event is retrieved, the time-degradation verification unit immediately reads the dynamic lifetime window information stored with the event. This time window defines how long the preceding event's state is considered reliable. Subsequently, the time-degradation verification unit takes the current system time and compares it with the occurrence time of the preceding event plus its lifetime. If the current system time falls outside the dynamic lifetime window (i.e., the current time is later than the occurrence time plus the lifetime), it indicates that although the preceding event exists in the record, the state or authorization it represents has expired due to excessive time. In this case, the time-degradation verification unit generates and outputs a preceding state aging failure flag, explicitly indicating that the preceding dependency cannot be satisfied due to time-degradation issues.

[0077] The mutual exclusion state overwrite verification unit 1022 is used to search backward in the formal path event library for whether there is an overwrite event node that is mutually exclusive with the necessary preceding event. If an overwrite event node is found, a preceding state reversal failure flag is output.

[0078] Operation mutual exclusion refers to two or more events or operations that cannot logically be true simultaneously or cancel each other out in effect. For example, opening and closing a valve are a pair of mutually exclusive operations. Overriding an event node refers to a new event occurring in the system after a necessary preceding event has occurred but before the current event node arrives. This new event logically or physically changes or invalidates the state of the preceding event. For example, the preceding event might be authorization execution, and the overriding event might be authorization revocation. A preceding state reversal invalidation flag is a specific signal output by the unit after discovering such an overriding event node, indicating that although the preceding event existed and may be within its validity period, it has been invalidated by a subsequent new event.

[0079] Specifically, the mutual exclusion state overlay verification unit 1022 is also a verification enhancement component within the preceding dependency verification module 102. It works in parallel or sequentially with the time-decrease verification unit, and its execution occurs after the necessary preceding events are retrieved. This unit aims to address a scenario where a valid preceding event has occurred, but during the time gap between it and the current event, another conflicting event occurs, rendering the state foundation established by the preceding event invalid. To perform the verification, after retrieving the necessary preceding event, the mutual exclusion state overlay verification unit performs a backward time-range search in the formal path event database, starting from the occurrence time of the necessary preceding event and ending with the current system time. The goal of the search is to find any overriding event nodes within this time period that logically mutually exclude the necessary preceding event. For example, if the necessary preceding event is that process A has been approved, this unit will search for events after which process A has been revoked or suspended. If such an overwrite event node is retrieved, it proves that the state of the preceding event has been overwritten or reversed by a later, higher-priority event. At this time, the unit will output a preceding state reversal failure flag.

[0080] The existence determination unit 1023 is used to output the preceding verification pass status only when the necessary preceding event is retrieved and the preceding state aging failure flag and the preceding state reversal failure flag are not received.

[0081] Among them, the necessary preceding event refers to the verified event retrieved from the formal path event library that is declared as dependent on the current event node. The preceding state aging failure flag is a signal output by the time-decay verification unit 1021, indicating that the preceding event has timed out. The preceding state reversal failure flag is a signal output by the mutual exclusion state overwrite verification unit 1022, indicating that the state of the preceding event has been overwritten by a subsequent event. The preceding verification passed state is the final result of this unit's assessment of the validity of the preceding dependency relationship.

[0082] Specifically, the existence determination unit 1023 will only output a preceding verification passed status if all prerequisite verification conditions are met simultaneously. These conditions are: First, the basic existence verification must pass, meaning the declared necessary preceding events must be successfully retrieved in the formal path event database. Second, in the timeliness verification, this unit cannot receive a preceding state aging failure flag from the timeliness decay check unit 1021. Third, in the state consistency verification, this unit cannot receive a preceding state reversal failure flag from the mutual exclusion state overwrite check unit 1022, ensuring that the state of the preceding events has not been tampered with or revoked midway. Only when these three conditions are met simultaneously will the existence determination unit consider the preceding dependencies of the current event node to be valid and output the final preceding verification passed status. The absence or failure to meet any one of the conditions will cause the unit to output a preceding verification failed status.

[0083] Please refer to the following: Figure 4 This is a schematic diagram of the event chain construction and closed-loop determination module of the unified event chain control device in this application embodiment.

[0084] Event chain construction and closed-loop determination module 103 includes:

[0085] The topology model loading unit 1031 is used to call the corresponding preset path graph model as the standard path topology matrix according to the business type associated with the current control activity.

[0086] The business type associated with the current control activity refers to the business process category to which the initial control activity that triggered the event chain belongs, such as equipment start-up / shutdown, material transfer, or quality inspection processes. A pre-defined path graph model is a standardized process template describing how a specific business type should be executed correctly. It typically defines the start and end points of the process, all necessary intermediate steps (event nodes), and the logical order and dependencies between these steps graphically. A standard path topology matrix is ​​a mathematical representation of the pre-defined path graph model, such as an adjacency matrix or an affinity matrix. The elements of the matrix define the connection relationships and path weights between different types of event nodes, thus accurately describing the network topology of the process.

[0087] Specifically, the topology model loading unit 1031 is the first executor of the event chain construction and closed-loop determination module 103 when performing path closed-loop determination. When the arrival of a result event or receipt event triggers the closed-loop determination process, a standard is needed to measure whether the current candidate event chain is qualified. This unit provides this standard based on the context of the current business. First, the unit identifies the business type of the currently being determined candidate event chain or its associated business context. Then, using this business type as a key, it searches in a library that pre-stores all standard process models and calls up the preset path graph model that completely corresponds to the business type. Finally, the unit converts or loads this graphical, potentially complex path graph model into a data structure suitable for calculation and comparison, namely the standard path topology matrix, and provides it to the coherence comparison unit 1032.

[0088] The coherence comparison unit 1032 is used to fold all event nodes in the candidate event chain into actual execution vectors according to the time sequence, and project the actual execution vectors onto the standard path topology matrix to calculate the node coverage matching degree. If the coverage matching degree indicates that the actual execution vector completely covers the necessary key nodes in the standard path topology matrix and there is no jump anomaly, it is determined that the preset closed loop condition is met, and the path closed loop status identifier indicating that the verification has passed is output.

[0089] The actual execution vector refers to an ordered data sequence formed by arranging all event nodes in the candidate event chain according to their chronological order and extracting key information (such as node type identifier) ​​for each node. This sequence records the actual execution trajectory of the business process. Projection refers to the calculation process of mapping and comparing the actual execution vector with the standard path topology matrix. Node coverage matching degree is a quantitative indicator used to measure the extent to which the actual execution vector conforms to the requirements of the standard path topology matrix. Essential critical nodes are event nodes marked as indispensable in the standard path topology matrix. Skip anomalies refer to two temporally consecutive event nodes in the actual execution vector whose corresponding node types are not directly reachable in the standard path topology matrix, indicating a missing necessary step. The path closure status identifier is the final comparison result output by this unit, clearly indicating whether the closure determination is successful or unsuccessful.

[0090] Specifically, the coherence comparison unit 1032 is triggered after the topology model loading unit 1031 provides the standard path topology matrix, and is used to execute the core comparison logic for loop closure determination. First, this unit processes the received candidate event chain, extracting the node type identifier of each event node in the order of timestamps, thereby constructing an ordered actual execution vector. Subsequently, this unit compares this actual execution vector with the standard path topology matrix to calculate the node coverage matching degree. This comparison process specifically includes two dimensions of verification: First, verifying the coverage integrity, that is, traversing all the necessary key nodes defined in the standard path topology matrix and checking whether the types of these nodes all appear in the actual execution vector. Second, verifying the sequence coherence, that is, traversing all adjacent event node pairs in the actual execution vector. For each pair of nodes, according to the standard path topology matrix, it queries whether there is a direct and legal transition path from the type of the previous node to the type of the next node. If no such path exists, it is determined that a jump anomaly has occurred. The unit determines that the preset closed-loop conditions are met and outputs a path closed-loop status flag indicating that the verification has passed, only if the coverage integrity check shows that all necessary nodes are covered and the sequence continuity check finds no jump anomalies. If any check item fails to meet the conditions, the unit is determined to have failed the closed-loop test and outputs the corresponding status flag.

[0091] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0092] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0093] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A unified event chain control device for an automated system, characterized in that, include: The control activity normalization module is used to obtain the current control activity in the automation system, generate the corresponding current event node based on the current control activity, and assign the current event node the corresponding node type identifier and the preceding reference identifier pointing to the preceding event. The preceding dependency verification module is used to determine the set of preceding node types necessary for the current event node to be established based on the node type identifier in the preset event dependency rules, and to perform an existence search in the formal path event database based on the preceding reference identifier. When a necessary preceding event corresponding to the preceding node type set is found, the preceding verification is output as passed; otherwise, the preceding verification is output as failed. The event chain construction and closed-loop determination module is triggered when the preceding dependency verification module outputs the preceding verification pass status. It writes the preceding reference identifier as a strong association anchor point into the current event node and appends the current event node to the candidate event chain of the business. If the node type identifier of the current event node indicates that it belongs to the intermediate process event, the candidate event chain is given the intermediate effect to continue to flow. When the node type identifier of the current event node indicates that it belongs to the result event or the receipt event, the path closed-loop determination is triggered to further verify whether the candidate event chain after appending the current event node completely and continuously contains the starting event, necessary intermediate events and ending events of the system instruction in the logical topology. If so, the closed loop passes; if not, the closed loop fails. The formal path effectiveness control module is used to determine that the candidate event chain does not meet the conditions for being a formal control instruction delivery path when the preceding verification fails or when the path closure determination of the result event or receipt event is not closed, strip the candidate event chain of its effectiveness as a formal control instruction delivery path, and simultaneously issue abnormal diversion, blocking or controlled physical degradation control instructions to the bottom hardware layer.

2. The unified event chain control device according to claim 1, characterized in that, The control activity normalization module specifically includes: The heterogeneous signal parsing unit is used to receive the current control activity across the information management network layer and the industrial control hardware layer. When the current control activity is a control command message issued by the upper layer, it extracts logical signaling features. When the current control activity is a potential change or position feedback signal from the lower layer sensor, it extracts physical state features. A unified identifier mapping unit is used to convert the logical signaling features or the physical state features into the current event node based on a preset event mapping matrix, and to extract the prefix identifier according to the network security domain to which the current control activity belongs, and generate the node type identifier.

3. The unified event chain control device according to claim 1, characterized in that, The preceding dependency verification module specifically includes: The time decay verification unit is used to read the dynamic survival time window bound to the necessary preceding event when the necessary preceding event is retrieved in the formal path event library, and compare whether the current system time exceeds the dynamic survival time window. If it exceeds the window, the preceding state aging failure flag is output. The mutual exclusion state overwrite verification unit is used to search backward in the formal path event library for whether there is an overwrite event node that is mutually exclusive with the necessary preceding event. If the overwrite event node is found, a preceding state reversal failure flag is output. The existence determination unit is used to output the preceding verification pass status only when the necessary preceding event is retrieved and the preceding state aging failure flag and the preceding state reversal failure flag are not received.

4. The unified event chain control device according to claim 1, characterized in that, The event chain construction and closed-loop determination module specifically includes: The topology model loading unit is used to call the corresponding preset path graph model as the standard path topology matrix according to the business type associated with the current control activity. The coherence comparison unit is used to fold all event nodes contained in the candidate event chain into actual execution vectors according to the time sequence, and project the actual execution vectors onto the standard path topology matrix to calculate the node coverage matching degree. If the coverage matching degree indicates that the actual execution vector completely covers the necessary key nodes in the standard path topology matrix and there are no jump anomalies, it is determined that the preset closed loop condition is met, and the path closed loop status identifier indicating that the verification has passed is output.

5. The unified event chain control device according to claim 1, characterized in that, The formal path effectiveness control module also includes a double-chain conflict identification unit, which is used to determine that a double-chain conflict phenomenon of inconsistent execution state has occurred between the application layer logic approval link and the underlying hardware state change link of the automation system when the node type identifier extracted by the control activity normalization module indicates that the current event node is the result event from the industrial control hardware layer, and the preceding dependency verification module outputs the preceding verification failure status, or the path closure determination of the result event is not closed. When the dual-chain conflict is triggered, the current control activity is marked as a physical bypass intrusion event that bypasses software logic approval and is initiated directly at the hardware end, and an output blocking control command is triggered.

6. The unified event chain control device according to claim 5, characterized in that, The operation of the formal path effectiveness control module triggering the blocking control command or the controlled degradation control command specifically includes: A physical enable blocking unit is used to generate the blocking control command when it is determined that the physical bypass intrusion event exists. The blocking control command is used to cut off the power enable channel of the underlying controlled hardware corresponding to the current control activity. The gray-scale degradation operation unit is used to determine a non-intrusive event absence when the preceding verification fails and no corresponding event node input is received within a preset time, and the underlying controlled hardware does not report contradictory action execution feedback. The unit then generates the controlled degradation control instruction, which is used to strip the formal write library permissions of the candidate event chain containing the current event node and redirect the instruction data packet and communication session corresponding to the candidate event chain to the network isolation sandbox environment for observation and interception.

7. The unified event chain control device according to claim 1, characterized in that, The event chain construction and closed-loop determination module also includes an anti-tampering anchoring unit, which is used to extract the digital signature features, current control parameters and timestamp of the preceding event when the preceding reference identifier is written into the current event node, and calculate and generate a chain feature verification code through an irreversible encryption algorithm, and solidify the chain feature verification code into the chain head verification field of the candidate event chain after the current event node is appended.

8. The unified event chain control device according to claim 1, characterized in that, It also includes a suspended event timeout cleanup module connected to the event chain construction and closed-loop determination module. After the event chain construction and closed-loop determination module adds the current event node that belongs to the necessary intermediate event to the candidate event chain, it reads the pre-configured hardware rated action delay parameter, calculates the maximum reasonable time threshold for the occurrence of the result event downstream of the candidate event chain, and if the corresponding verification receipt input is not detected after the maximum reasonable time threshold is exceeded, it determines that an execution fault anomaly has occurred and extracts the chain identifier of the candidate event chain for active destruction.

9. The unified event chain control device according to claim 1, characterized in that, It also includes a cross-domain collaborative verification module, which is used to send an asynchronous verification probe to the peer physical domain according to the pre-reference identifier when the node type identifier indicates that the current control activity involves transmission across physical isolation domains, and temporarily place the candidate event chain containing the current event node in a cross-domain pending state if no matching result is obtained when the existence retrieval is performed locally. If no verification synchronization receipt is received from the probe within the preset tolerance transmission time limit, the candidate event chain in the pending state is marked as a cross-domain chain breakage exception, and the cross-domain chain breakage exception is fed back to the formal path effectiveness control module.

10. The unified event chain control device according to claim 1, characterized in that, It also includes an event chain state rollback module, specifically including: The closed-loop anomaly response unit is used to trigger when the formal path effectiveness control module determines that the path closed-loop state of the result event or receipt event is not closed-loop and strips the effectiveness of the candidate event chain, and extracts the most recent lossless event node group with a complete closed-loop state from the formal path event library in descending order of time. The reverse tracing and compensation unit is used to compare the changed action variables in the currently failed candidate event chain with the state parameters of the lossless event node group, generate the corresponding reverse undo event instruction set, issue the reverse undo event instruction set to perform action compensation, and make the system logic state fall back to the most recent compliance and security baseline.

Images