An operating state execution control device for a high-consequence automation system

Abstract

The application discloses a kind of operation mode execution control device for high consequence automation system, it is related to automation system technical field, for reducing the risk of separation of check and use of automation system.In the device, by heterogeneous state convergence generates single atomic characteristic fingerprint, and establishes execution front locking window when consistency check passes.In window, execution request is forced short-time binding with the running context at that time to form snapshot, and then global unique concurrent mutual exclusion is implemented by means of snapshot, and high-frequency anti-drift detection and two-stage handshake are carried out before final physical commitment, and if there is any deviation, it is blocked and cascaded to cancel, so as to reduce the risk of separation of check and use of automation system.

Description

Technical Field

[0001] This application relates to the field of automation system technology, and in particular to an operational execution control device for high-consequence automation systems. Background Technology

[0002] With the rapid development of automation technology, high-consequence automation systems (such as energy storage system control and autonomous driving) are increasingly widely used in industrial production and core infrastructure. In these systems, the actions performed by automated equipment often have extremely high physical or logical impacts. Misoperation, erroneous operation, or unexpected execution can lead to serious safety accidents, equipment damage, or economic losses. Therefore, to improve the safety of high-consequence actions, strict safety management and state control are typically required for each stage of the automated action's triggering, flow, and final execution.

[0003] In high-consequence automation systems, the control of execution requests typically employs a multi-module distributed pipelined verification architecture. Specifically, the automation system independently sets up multiple functional modules, including a decision root node, rule verification layer, rule change control layer, bypass detection layer, and execution boundary. When an execution proposal is generated, it flows through these modules sequentially for processing. The decision root node determines whether the proposal enters the governance chain; the rule verification layer provides a permission or blocking conclusion based on preset security rules; the rule change control layer outputs the current freeze or change status; the bypass detection layer provides the corresponding bypass conclusion; and finally, the execution boundary module receives instructions from these preceding modules and initiates a formal physical commit to the target device. Each module operates independently based on its own business logic, generating its own format and granularity of judgment results or status identifiers, which are then passed downstream level by level, ultimately driving the underlying devices to complete the action execution.

[0004] However, in the aforementioned distributed pipeline architecture, the unavoidable time window between the inspection process of each preceding control module and the final physical execution leads to the risk of separation of inspection and use (TOCTOU) in the automated system. Summary of the Invention

[0005] This application provides a runtime execution control device for high-consequence automated systems, which reduces the risk of separation of inspection and use (TOCTOU) in automated systems.

[0006] Firstly, a runtime execution control device for high-consequence automated systems is provided, characterized by comprising: a heterogeneous state convergence module, used to acquire candidate execution requests for a target device, extract a unified input object corresponding to the target execution behavior of the candidate execution requests, and acquire heterogeneous key states output by multiple preceding control modules, and fuse the logically normalized heterogeneous key states with the unified input object to generate a current execution feature fingerprint; a consistency verification module, used to perform a consistency comparison between the current execution feature fingerprint and the current running state of the target device and a preset safe execution template, and output a verification pass certificate when the comparison passes; and a locking window control module, triggered when the verification pass certificate is acquired, used to establish a pre-execution locking window, and within the pre-execution locking window, store the unified input... The system performs time-sensitive binding of objects and current execution feature fingerprints to generate a lock context snapshot. A unique conclusion generation module, within the pre-execution lock window, performs mutual exclusion suppression on concurrent candidate execution requests based on the lock context snapshot, generating a unique control conclusion that only allows a single candidate execution request matching the lock context snapshot to enter the formal submission stage. A submission coordination and cascading reversal module, based on the unique control conclusion, performs a handshake with the formal execution boundary to establish a lock control path. Before releasing the formal submission signal to the formal execution boundary, it performs anti-drift detection. If the physical state of the target device or the heterogeneous critical state output by the preceding control module deviates from the lock context snapshot, cascading reversal is performed and submission is blocked. If there is no deviation and the lock control path remains connected, the formal submission signal is released.

[0007] By adopting the above technical solution, a single-atom feature fingerprint is generated through heterogeneous state convergence, and a pre-execution locking window is established when the consistency check passes. Within the window, the execution request is forcibly and briefly bound to the current running context to form a snapshot. Then, based on the snapshot, globally unique concurrent mutual exclusion suppression is implemented, and high-frequency anti-drift detection and two-phase handshake are performed before the final physical commit. If any deviation occurs, it is blocked and cascaded undoed, thereby reducing the risk of separation of inspection and use (TOCTOU) in the automated system.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the heterogeneous state convergence module specifically includes: an input object aggregation unit, used to parse candidate execution requests, extract target action identifiers, target device identifiers, target execution parameters, and session identifiers, and encapsulate them into a unified input object; a multi-module state aggregation unit, used to collect heterogeneous key states output by the preceding control module, the heterogeneous key states including at least rule-allowed states, rule-frozen states, bypass detection states, and boundary-available states; and a unified state representation unit, used to perform logical normalization processing on the heterogeneous key states, generate a unified state vector, and perform hash fusion of the unified state vector and the unified input object to generate the current execution feature fingerprint.

[0009] By adopting the above technical solution and using hash fusion technology to generate the current execution feature fingerprint, the original core execution intent is cryptographically bound to its various distributed permission preconditions, making the current execution feature fingerprint indivisible and tamper-proof during downstream transfer and verification.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the consistency verification module specifically includes: a state parsing and matching unit, used to parse a unified state vector from the current execution feature fingerprint, and determine whether the rule-allowed state, rule-frozen state, bypass detection state, and boundary-available state all meet the preset conditions for continued submission; a device state verification unit, used to obtain the current operating state of the target device, and determine whether the current operating state supports the execution of the action corresponding to the target execution parameters; and a comprehensive judgment unit, used to determine that the consistency comparison is passed and output a verification pass certificate when the judgment results of the state parsing and matching unit and the device state verification unit are both yes, and the current execution feature fingerprint matches the preset secure execution template.

[0011] By adopting the above technical solution, not only are the logical judgments of each front-end governance node fully compliant, but the compatibility of the physical operating status of the underlying target device with the current request action is also verified. Furthermore, the compliance of the overall operation mode is improved by pre-setting a secure execution template. Certificates are issued only when all three dimensions pass verification, enhancing the decision-making accuracy of the high-consequence automated system in complex edge environments and its ability to intercept unauthorized and illegal commands.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the locking window control module specifically includes: a time and resource locking unit, used to bind a local security clock to generate a pre-execution locking window when a verification pass credential is obtained, and to exclusively lock the protected access window of the target device; and a snapshot generation unit, used to extract a unified input object, the current execution feature fingerprint, and the current running state of the target device within the pre-execution locking window, combine them to generate a locking context snapshot, and write the locking context snapshot to the protected memory area.

[0013] By employing the above technical solution, a time-sensitive pre-execution locking window is established by binding a hardware clock, and the protected access window of the target device is exclusively locked, limiting resource contention in a concurrent environment. Simultaneously, a snapshot of the locking context, including the input object, feature fingerprint, and the device's current operating state, is written to the protected memory area. This mechanism fixes the context baseline for the upcoming execution in both time and resource dimensions, providing a stable and overwrite-proof reference for subsequent handling of concurrent contention and verification of state consistency.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the unique conclusion generation module specifically includes: a concurrent request interception unit, used to intercept all concurrent candidate execution requests for the target device within a pre-execution locking window; a feature fingerprint comparison unit, used to extract the execution feature fingerprint corresponding to each candidate execution request and compare it with the locking context snapshot in the protected memory area; and a contention suppression and release unit, used to mark the candidate execution request that completely matches the locking context snapshot as the unique candidate execution request and generate a unique control conclusion that allows it to enter the formal submission stage, and to perform mutual exclusion suppression on the remaining unmatched candidate execution requests, wherein the mutual exclusion suppression includes logical isolation, control revocation, or path disconnection.

[0015] By adopting the above technical solution, concurrent execution requests are intercepted within the pre-execution locking window. By comparing the execution feature fingerprint of each request with the locking context snapshot, only the unique candidate execution request that completely matches is allowed. For the remaining unmatched concurrent requests, mutual exclusion suppression measures such as logical isolation, control revocation, or path cutoff are implemented. This design solves the problem of redundant or overridden execution of instructions caused by network latency, automatic system retries, or concurrent contention requests, and ensures that instructions under a specific authorization context can flow backward in a single and unique manner.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the submission coordination and cascading revocation module specifically includes: a two-stage handshake unit, used to send a lock request containing a unique control conclusion to the formal execution boundary in the first stage, and receive a ready feedback status returned by the formal execution boundary in the second stage to establish a lock control path; a high-frequency anti-drift monitoring unit, used to cyclically collect the physical state of the target device and the heterogeneous key states output by the preceding control module during the critical time period before releasing the formal submission signal, and compare them with the lock context snapshot in real time; and a cascading revocation execution unit, used to revoke the submission qualification of the unique candidate execution request and broadcast an abnormal blocking signal to the preceding control module when the high-frequency anti-drift monitoring unit detects a state deviation or the two-stage handshake unit fails to receive a ready feedback status, causing the lock control path to be disconnected.

[0017] By adopting the above technical solution, during the critical period before releasing the formal submission signal, the physical state of the acquisition device and the state of the preceding modules are cyclically collected for anti-drift monitoring, and the communication path for confirming the execution boundary is ready in conjunction with a two-phase handshake. If it is found that the current acquisition state deviates from the locked context snapshot, or the locked control path is broken, the module immediately blocks the submission and broadcasts an abnormal blocking signal to the preceding module. This mechanism supplements the secondary confirmation of the state after verification and before physical execution, avoiding unexpected execution caused by sudden state deviations, and ensuring that the states of upstream modules can be synchronously rolled back in a timely manner through cascading reversal.

[0018] In conjunction with some embodiments of the first aspect, some embodiments further include a control receipt generation module, specifically comprising: a data extraction unit for extracting a unified input object, a locked context snapshot, a unique control conclusion, and the final submission or blocking status after the submission coordination and cascading cancellation module releases the formal submission signal or executes cascading cancellation; and a receipt encapsulation unit for binding the extracted data with the current timestamp to generate a unified control receipt object, which is used to provide an immutable runtime snapshot certificate for subsequent accountability tracing and boundary verification.

[0019] By adopting the above technical solution, after the control flow ends (whether it's a release commit or a cascading reversal), the unified input object, snapshot, conclusion, and final state are extracted and bound to the timestamp at that time to generate a unified control receipt object. This mechanism structurally solidifies the key data and runtime results at the moment of execution decision, providing runtime data credentials for post-event responsibility location, fault tracing, and boundary operation review.

[0020] In conjunction with some embodiments of the first aspect, some embodiments further include an anomaly blocking and degradation module, specifically including: an anomaly event capture unit, used to capture the anomaly event type that causes the blocking when the submission coordination and cascading cancellation module performs cascading cancellation and blocks the submission; and a security degradation execution unit, used to match a preset security degradation strategy according to the anomaly event type, take over the control of the target device, and transfer the target execution behavior to a controlled exception path, downgrade it to a safe mode action, or suspend the current automated submission and generate a manual upgrade review request.

[0021] By adopting the above technical solution, in the event of cascading reversal and blocking of submission, the system matches and executes a preset security degradation strategy based on the specific abnormal event type that caused the blocking. Compared with a single direct blocking command, this degradation mechanism allows the program to take over control of the device and selectively switch to a controlled path, security mode, or manual review, thereby improving the automation system's ability to handle abnormal blocking and its environmental adaptability, and preventing the target device from falling into an uncontrollable state.

[0022] In conjunction with some embodiments of the first aspect, some embodiments further include a runtime audit record module, specifically including: a full-process time-series tracking unit, used to collect control node interaction data in real time according to time sequence for the entire process of heterogeneous state convergence, consistency verification, locking window establishment, unique conclusion generation and submission coordination; and an audit snapshot solidification unit, used to structurally encapsulate the control node interaction data, candidate execution request records intercepted and suppressed by the unique conclusion generation module, and abnormal reversal records to generate runtime audit records independent of regular business logs.

[0023] By adopting the above technical solution, the interaction data between control nodes is collected in real time in chronological order, and these interaction processes, suppressed and intercepted concurrent candidate execution requests, and abnormal cancellation records are encapsulated to generate runtime audit records independent of regular business logs. This helps to fully reflect the flow sequence of execution requests between modules and the interception situation, and provides structured data support for operation and maintenance and audit personnel to investigate the causes of concurrent conflicts, discover system retry logic defects, or locate abnormal cancellation trigger points.

[0024] In conjunction with some embodiments of the first aspect, in some embodiments, the consistency verification module further includes an expired conclusion detection unit, which is used to extract the generation timestamps of each heterogeneous key state output by the preceding control module during consistency comparison, calculate the time difference between each generation timestamp and the current verification time, and determine whether the time difference exceeds the preset effective time window matched with the corresponding preceding control module. If any time difference exceeds the corresponding preset effective time window, the heterogeneous key state is determined to be an expired conclusion and regarded as a state mismatch, and a verification failure signal is directly output.

[0025] By adopting the above technical solution, by calculating the time difference between the generation timestamp of the preceding critical state and the current verification time, and comparing the effective time windows corresponding to each preceding module, expired state conclusions caused by network flow delays or processor scheduling queuing can be identified and intercepted in a timely manner. This avoids the system making current release decisions based on outdated and invalid historical logical states, and further narrows the time difference between the state check conclusion and the actual use 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. By generating a single-atom feature fingerprint through heterogeneous state convergence, a pre-execution locking window is established when the consistency check passes. Within the window, the execution request is forcibly and briefly bound to the current running context to form a snapshot. Then, based on the snapshot, globally unique concurrent mutual exclusion suppression is implemented. Before the final physical commit, high-frequency anti-drift detection and two-phase handshake are performed. If any deviation occurs, it is blocked and cascaded undoing, thereby reducing the risk of separation of inspection and use (TOCTOU) in the automated system.

[0028] 2. Before execution, concurrent execution requests are intercepted within the locked window. By comparing the execution feature fingerprint of each request with the lock context snapshot, only the unique candidate execution request that completely matches is allowed to proceed. For the remaining unmatched concurrent requests, mutual exclusion suppression measures such as logical isolation, control revocation, or path disconnection are implemented. This design solves the problem of redundant or overridden execution of instructions caused by network latency, automatic system retries, or concurrent contention requests, ensuring that instructions under a specific authorization context can flow backward in a single and unique manner.

[0029] 3. By calculating the time difference between the generation timestamp of the preceding critical state and the current verification time, and comparing the effective time windows corresponding to each preceding module, expired state conclusions caused by network flow delays or processor scheduling queuing are promptly identified and intercepted. This avoids the system making current release decisions based on outdated and invalid historical logical states, and further narrows the time difference between the state check conclusion and the actual usage time. Attached Figure Description

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

[0031] Figure 2 This is a schematic diagram of the heterogeneous state convergence module of the running state execution control device in the embodiments of this application.

[0032] Figure 3 This is a schematic diagram of the consistency verification module of the running execution control device in the embodiments of this application.

[0033] Figure 4 This is a schematic diagram of the locking window control module of the running execution control device in the embodiments of this application.

[0034] Figure 5 This is a schematic diagram of the unique conclusion generation module of the running execution control device in this application embodiment.

[0035] Figure 6 This is a schematic diagram of the submission coordination and cascading cancellation module of the running execution control device in this embodiment of the application. Detailed Implementation

[0036] 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.

[0037] 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.

[0038] This application provides a runtime execution control device for high-consequence automated systems, which reduces the risk of separation of inspection and use (TOCTOU) in automated systems.

[0039] Please see Figure 1 This is a module architecture diagram of the running execution control device in the embodiments of this application.

[0040] This runtime execution control device, which can be referred to as the Execution Control Core (ECC) in this embodiment, is deployed as an atomic control unit between multiple distributed preceding control modules and the final formal execution boundary.

[0041] The runtime execution control device includes:

[0042] The heterogeneous state convergence module 101 is used to obtain candidate execution requests for the target device, extract the unified input object of the target execution behavior corresponding to the candidate execution request, and obtain the heterogeneous key states output by multiple preceding control modules. The heterogeneous key states after logical normalization are fused with the unified input object to generate the current execution feature fingerprint.

[0043] In this context, a candidate execution request refers to an initial instruction generated by the upstream part of the automation system, intended to perform a specific operation on a target device. The target device refers to a physical or logical entity (such as an energy storage inverter or a high-voltage circuit breaker) controlled by the automation system whose actions will produce high consequences. A unified input object is a standardized data structure used to uniformly encapsulate the core information in the candidate execution request. This core information includes at least the target action identifier, target device identifier, target execution parameters, and session identifier. A pre-processing control module refers to multiple independent functional modules that have completed specific-dimensional verification of the execution request before the execution control core (ECC) of this invention. Pre-processing control modules include, but are not limited to, a root node admission control module, a large language model-driven autonomous system output governance module, a distributed rule verification engine, a rule change control module, a bypass monitoring node based on hardware power consumption / current / voltage or interface status verification, a formal execution boundary status feedback module, a device status monitoring module, a manual review receipt module, or a combination thereof. Different pre-processing control modules can output heterogeneous key states with different formats, granularities, or timestamps. The heterogeneous state convergence module is used to perform logical normalization processing on these states. Heterogeneous key states refer to the judgment results output by each preceding control module, which have different data formats and semantics. Examples include the Boolean rule-allowed state output by the rule verification layer module and the enumerated rule-frozen state output by the rule change control layer module. Logical normalization refers to uniformly processing these heterogeneous key states into a standardized unified state vector (such as a fixed-length binary bitmap) through preset mapping rules. The current execution feature fingerprint is a unique identifier generated by a cryptographic hash algorithm. The input to this algorithm is the unified state vector and a unified input object, thereby atomically binding the execution intent to all its preconditions and preventing tampering or contextual errors during the process.

[0044] Specifically, the heterogeneous state convergence module 101 receives candidate execution requests and aggregates heterogeneous key states related to the request from multiple preceding control modules. This module is configured for execution logic normalization processing, eliminating differences in data structures and communication protocols between different preceding modules and converting heterogeneous key states into a unified state vector. Subsequently, this module generates an immutable current execution feature fingerprint by hashing and fusing the unified input object and the unified state vector.

[0045] In one implementation, the heterogeneous state convergence module 101 can be implemented as a bypass plugin for an API gateway or an independent microservice. This plugin intercepts requests flowing to the execution boundary, parses the request content in JSON or Protobuf format to generate a unified input object. Simultaneously, the plugin concurrently requests the latest state of multiple preceding control modules for the current session ID via internal gRPC service calls. After obtaining the heterogeneous states, the plugin maps them to a unified state vector (e.g., a 64-bit long integer, where different bit segments represent the states of different modules) using a built-in transformation function matrix. Finally, the plugin concatenates the serialized byte stream of the unified input object with the unified state vector and calculates its hash value using the SHA-256 algorithm, thereby generating the current execution feature fingerprint.

[0046] The consistency verification module 102 is used to compare the current execution feature fingerprint with the current operating status of the target device and the preset security execution template, and output the verification pass certificate when the comparison is successful.

[0047] The current execution fingerprint is a unique identifier generated by the heterogeneous state convergence module 101. The current operating state of the target device refers to data obtained through a real-time monitoring system (such as a SCADA system) that reflects the immediate physical condition of the target device (e.g., temperature, voltage, current on / off status). The preset security execution template is a predefined set of policies containing one or more sets of known secure execution fingerprints or their matching rules. The verification pass credential is an authorization credential with time validity and a cryptographic signature generated by this module when all consistency verification conditions are met, used to activate the subsequent locking window control module.

[0048] Specifically, the consistency verification module 102 performs a final consistency verification on the execution context represented by the current execution feature fingerprint before establishing the pre-execution locking window. This module is configured to perform multi-dimensional parallel verification operations: on one hand, it parses the unified state vector contained in the fingerprint to confirm that the states of all preceding modules meet the execution requirements; on the other hand, it interacts with the device runtime monitoring module to verify whether the current physical state of the target device is compatible with the requested action; furthermore, it ensures that the overall mode of this operation is within the scope of the preset security policy. The module determines that the consistency comparison is successful and issues a verification pass certificate only if all dimensions of verification pass. If any verification fails, the module will output a blocking control conclusion and record any unauthorized or illegal attempts.

[0049] In one implementation, the consistency verification module 102 can be implemented using a high-performance in-memory rule engine (such as Drools). Upon receiving the current execution feature fingerprint and related context information, it submits the unified state vector, the device's real-time state variables, and the fingerprint itself as facts to the working memory of the rule engine. The engine performs pattern matching and inference based on a set of rules predefined in the decision table. When all key rules are satisfied, an action is triggered to generate a verification pass credential, which includes the current timestamp and is asymmetrically encrypted and signed using the control center's private key.

[0050] The locking window control module 103 is triggered when the verification certificate is obtained. It is used to establish a pre-execution locking window and bind the unified input object and the current execution feature fingerprint within the pre-execution locking window to generate a locking context snapshot.

[0051] The pre-execution lock window is a short-lived control interval created by this module with strict time limits (e.g., milliseconds). Its purpose is to provide a stable and protected environment for the control phase from completion of verification to formal submission. Time-bound binding refers to strongly associating key information such as the unified input object and the current execution feature fingerprint with the lifecycle of the lock window, making it valid only within that window and automatically invalidating upon timeout. The lock context snapshot is an authoritative data set solidified at the moment the lock window opens. This set serves as the sole legitimate benchmark for subsequent uniqueness determination and anti-drift monitoring.

[0052] Specifically, the locking window control module 103 is activated after verifying the signature and validity of the verified credentials. This module binds to a local high-precision hardware clock to establish a pre-execution locking window and performs locking operations within this window. The locking operation includes not only applying an exclusive lock to the logical control of the target device, but also combining all verified key information to generate a locking context snapshot, and storing this snapshot in a tamper-proof protected memory area (such as SGXEnclave or a specific security register).

[0053] In one implementation, the locking window control module 103 can utilize a distributed coordination service (such as etcd or ZooKeeper) combined with a local spinlock. Upon receiving credentials, the module attempts to create a temporary sequential node carrying a snapshot of the locking context under a predefined device path. Successful creation of this node represents a logical lock on the target device, and the lease time (TTL, typically set to a very short tens of milliseconds) of this node constitutes the pre-execution locking window.

[0054] The unique conclusion generation module 104 is used to perform mutual exclusion suppression on concurrent candidate execution requests based on the lock context snapshot within the pre-execution lock window, and generate a unique control conclusion that only allows the unique candidate execution request that matches the lock context snapshot to enter the formal submission stage.

[0055] Concurrent candidate execution requests refer to competing instructions targeting the same device that arise during the locking window due to network latency, retry mechanisms, or malicious attacks. Mutual exclusion suppression is a proactive measure taken for concurrent requests that do not match the locking context snapshot, such as logical isolation, control revocation, or path disconnection, to ensure that high-consequence actions are executed only once and uniquely. The unique control conclusion is the final decision generated by this module after adjudication, which explicitly authorizes the only candidate execution request matching the snapshot to enter the formal submission stage. The unique control conclusion does not directly trigger physical execution, but serves as the sole qualification for entering the subsequent formal execution boundary handshake and anti-drift detection. Only when the locking control path remains connected and no state deviation is detected will the submission coordination and cascading revocation module 105 finally release the formal submission signal.

[0056] Specifically, the unique conclusion generation module 104 operates within the pre-execution locking window, acting as the final concurrent firewall before execution. This module makes the final decision on all concurrent candidate execution requests pointing to the same target device. For each concurrent request, its current execution feature fingerprint is calculated in real time, and these newly generated fingerprints are rigorously compared at the memory level with a snapshot of the locking context in protected memory. For requests with completely matching feature fingerprints, a unique control conclusion allowing formal submission is generated; for concurrent requests with mismatched fingerprints, mutual exclusion is immediately implemented, the request is discarded, and related resources are released.

[0057] In one implementation, the unique conclusion generation module 104 may employ a lock-free contention mechanism based on atomic compare-and-swap (CAS). The system maintains an atomic pointer to the currently valid snapshot. For each arriving concurrent request, the module calculates its fingerprint and attempts to bind the request's identifier to the snapshot via a CAS operation. Due to the atomicity of the CAS operation at the CPU instruction level, only one operation will succeed among all concurrent attempts. The request that successfully executes the CAS is determined to be the unique candidate execution request.

[0058] The submission coordination and cascading revocation module 105 is used to establish a locking control path by handshaking with the formal execution boundary based on the unique control conclusion. Before releasing the formal submission signal to the formal execution boundary, it performs anti-drift detection. If the physical state of the target device or the heterogeneous key state output by the preceding control module is detected to deviate from the locking context snapshot, cascading revocation is performed and submission is blocked. If there is no deviation and the locking control path remains connected, the formal submission signal is released.

[0059] The formal execution boundary (ECS) is the final module in the current automation system responsible for translating logical instructions into physical actions on the target device (such as PLC sending messages). The formal execution boundary can be an exclusive execution submission boundary, a physical execution submission gateway, a controlled submission module of the underlying execution interface, a device driver layer submission controller, a power converter control entry point, a robot motion control entry point, or other boundary control units used to receive formal submission signals and trigger execution on the target device. Handshake refers to a two-stage atomic synchronization protocol performed between this module and the formal execution boundary. Locking the control path is a temporary exclusive communication connection established through this handshake process. Anti-drift detection is a high-frequency, continuous state re-verification performed during a critical period before issuing the final instruction, used to prevent physical state abrupt changes that occur very shortly after the locking window is established. Cascaded undo is a systematic fault handling mechanism that not only aborts the current submission but also broadcasts an abnormal blocking signal to all upstream preceding control modules to safely roll back the entire execution chain.

[0060] Specifically, the commit coordination and cascading revocation module 105 is activated upon receiving the sole control conclusion allowing commit. This module first performs a two-phase atomic handshake with the formal execution boundary (ECS) to establish a lock control path. During the critical period before issuing the formal commit signal, the module initiates high-frequency anti-drift monitoring, continuously fetching the underlying sensor status of the target device and the latest status of each preceding control module, and comparing it in real-time with the lock context snapshot. If any state deviation is detected during this process (such as a sudden temperature exceedance), or a heartbeat interruption occurs in the lock control path with the ECS, the module will immediately trigger cascading revocation, blocking physical execution. Conversely, if all states remain consistent until the very last moment, the module will release the formal commit signal.

[0061] In one implementation, the two-phase handshake can be implemented using a request / response model. This module sends a `prepare_commit` request to the ECS, and the ECS replies with a `ready` confirmation after completing its internal resource reservation. High-frequency anti-drift monitoring runs in a high-priority thread bound to a dedicated CPU core, obtaining real-time status by directly reading the shared memory mapping area, avoiding network I / O latency. If a deviation is detected, this thread sets an atomic abort flag. The main thread issuing the formal commit signal must check this flag before calling the underlying driver. Cascading undo is triggered by publishing a message to a global undo topic based on a message broker such as Kafka.

[0062] The above describes the module architecture diagram of the running execution 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 heterogeneous state convergence module of the running state execution control device in the embodiments of this application.

[0064] Heterogeneous state convergence module 101 includes:

[0065] The input object aggregation unit 1011 is used to parse candidate execution requests, extract target action identifier, target device identifier, target execution parameters and session identifier, and encapsulate them into a unified input object.

[0066] Among them, the candidate execution request is the original operation instruction generated upstream of the system. The target action identifier, target device identifier, target execution parameters, and session identifier are the basic information elements constituting an execution intent. In addition to these basic information, the unified input object can also encapsulate other contextual information, such as time window identifier, action proposal identifier to be judged, and judgment result object identifier. This contextual information may come from different preceding control modules.

[0067] Specifically, the input object aggregation unit 1011 is one of the functional components of the heterogeneous state convergence module 101, which standardizes and aggregates the incoming information related to the execution intent. In a distributed system, complete execution context information may be scattered across multiple data carriers. The role of this unit is to parse the core candidate execution requests to extract basic information, and simultaneously obtain other context information from metadata accompanying the request flow or by querying relevant modules. Finally, this unit encapsulates all the collected information into a unified input object with a predefined data structure, providing a complete and uniformly formatted data foundation for subsequent state fusion and fingerprint generation.

[0068] In one implementation, the input object aggregation unit 1011 can be implemented as a data aggregation service. When a core request is received, it uses the session identifier in the request as an association key to look up additional information asynchronously written by other preceding control modules in a distributed cache. The unit merges all the retrieved information with the core request information and populates it into a standard data class instance to form a unified input object.

[0069] The multi-module state aggregation unit 1012 is used to collect heterogeneous key states output by the preceding control module. The heterogeneous key states include at least the rule-allowed state, the rule-frozen state, the bypass detection state, and the boundary available state.

[0070] Among them, the preceding control modules refer to the various decision-making and state management components upstream of the Execution Control Core (ECC). Heterogeneous critical states are the judgment conclusions output by these modules, and their scope includes, but is not limited to, rule-allowed state, rule-frozen state, bypass detection state, boundary available state, judgment result valid state, root node admission token valid state, and device executable state.

[0071] Specifically, the multi-module state convergence unit 1012 is one of the functional components of the heterogeneous state convergence module 101. At a specific moment when processing a candidate execution request, it comprehensively collects the current states of all relevant preceding control modules. This unit collects all key states predefined in the state set concurrently and efficiently.

[0072] In one implementation, the multi-module state aggregation unit 1012 can be implemented as a state aggregator. It maintains a service discovery registry, which registers the state query interface addresses of all preceding control modules. When state aggregation is needed, it retrieves the addresses of all currently healthy services from the registry and concurrently sends query requests to all these interfaces using asynchronous I / O. After collecting all responses, the unit extracts and aggregates the state data from the responses.

[0073] The unified state representation unit 1013 is used to perform logical normalization processing on heterogeneous key states, generate a unified state vector, and perform hash fusion with a unified input object to generate the current execution feature fingerprint.

[0074] The heterogeneous key states are collections of raw state information in various formats collected by the multi-module state aggregation unit 1012. Logical normalization processing refers to converting this diverse information into a standardized unified state vector through predefined encoding or mapping rules. Hash fusion is a process of cryptographically binding the unified state vector to a unified input object, the product of which is the current execution feature fingerprint. The data structure of this fingerprint is designed to simultaneously represent allowed states, blocked states, frozen states, bypass states, and boundary states, and to reflect the consistency relationship between the request and the judgment result.

[0075] Specifically, the unified state representation unit 1013 is one of the functional components of the heterogeneous state convergence module 101. This unit first performs logical normalization on the collected heterogeneous key states, converting them into a unified state vector. Next, to ensure that the request content and system permission state are inseparable and tamper-proof in subsequent processes, this unit performs hash fusion. It deterministically serializes the unified input object, then concatenates the serialization result with the unified state vector, and inputs the concatenated overall data into a strong hash function. The output of this hash function is the current execution feature fingerprint, which constitutes a unique, compact, and secure digital digest of the content and all preconditions of this execution request at the current moment.

[0076] In one implementation, the unified state representation unit 1013 may employ a bit-field representation. This unit pre-allocates one or more bits for each key state. During normalization, each state value is converted into a corresponding bit pattern, and they are combined into a single integer using bitwise operations; this integer is the unified state vector. This integer is then hashed together with the serialized unified input object byte stream.

[0077] Please refer to the following: Figure 3 This is a schematic diagram of the consistency verification module of the running execution control device in this embodiment of the application.

[0078] The consistency verification module 102 includes:

[0079] The state parsing and matching unit 1021 is used to parse a unified state vector from the current execution feature fingerprint and determine whether the rule-allowed state, rule-frozen state, bypass detection state, and boundary-available state all meet the preset conditions for continuing to submit.

[0080] The current execution feature fingerprint is a unique identifier generated by the upstream module. The unified state vector is a standardized set of preceding states extracted from the fingerprint or its accompanying metadata. Rule-allowed states, rule-frozen states, bypass detection states, and boundary-available states are key components of the unified state vector. Preset continue-submission conditions are a set of logical rules that define specific combinations of conditions that the unified state vector must satisfy.

[0081] Specifically, the state parsing and matching unit 1021 is an internal functional component of the consistency verification module 102, which verifies the system permission state encapsulated in the current execution feature fingerprint. This unit first obtains a unified state vector from the input. Then, based on preset conditions for continued submission, the unit checks the unified state vector item by item or in combination. For example, it verifies whether the dimension representing the rule verification layer conclusion is allowed, and whether the dimension representing the rule change control layer conclusion is not frozen. Only when all checked dimensions in the vector fully meet the security requirements does the unit determine a successful match. If the state of any dimension does not meet the conditions, the unit will determine it as a mismatch.

[0082] The device status verification unit 1022 is used to obtain the current operating status of the target device and determine whether the current operating status supports the execution of the action corresponding to the target execution parameters.

[0083] In this context, the target device is the object to which the requested operation is performed. The current operating status is the real-time physical or logical condition of the device obtained through real-time monitoring. The target execution parameters are the specific operation values ​​defined in the request. The action is the specific operation defined by the target action identifier.

[0084] Specifically, the device status verification unit 1022 is an internal functional component of the consistency verification module 102, used to verify whether the physical or logical state of the target device is suitable for executing the requested action. This unit queries the latest operating status of the target device through the monitoring system, and then, based on a set of preset device status-action compatibility rules, determines whether the current state of the device supports executing the action defined in the request. For example, the rules may stipulate that a specific action can only be executed when a certain parameter value of the device is lower than a preset threshold. If the verification fails, the unit will determine it as a mismatch to ensure that the system does not issue physically infeasible or dangerous instructions.

[0085] The comprehensive judgment unit 1023 is used to determine the consistency comparison is passed and output the verification certificate when the judgment results of the status parsing and matching unit and the device status verification unit are both yes, and the current execution feature fingerprint matches the preset security execution template.

[0086] The status parsing and matching unit and the device status verification unit are the pre-verification components of the consistency verification module. The current execution feature fingerprint is a unique digital digest of this execution. The preset secure execution template is a collection of known secure and audited operating modes. The verification pass certificate is the final authorization issued by the consistency verification module after all checks have passed.

[0087] Specifically, the comprehensive judgment unit 1023 is the final decision component of the consistency verification module 102. This unit aggregates the judgment results from the state parsing and matching unit and the device state verification unit, and performs a global final check. This unit first confirms whether the judgment results of the first two internal components are both passed. If either result is negative, the verification immediately fails. If both are positive, the unit continues to match the complete current execution feature fingerprint with the preset secure execution template library. This step aims to verify the legality of each legitimate state combined with specific operations, devices, and parameters. Only when all three conditions—the preceding state is correct, the device state is appropriate, and the overall operating mode is within the secure template—are met simultaneously will the unit ultimately determine that the consistency comparison has passed and generate a verification pass certificate.

[0088] In one implementation, the comprehensive determination unit 1023 may employ multi-level filtering logic. The first-level filter checks the Boolean results of the two internal components. If successful, the second-level filter uses a Bloom filter to quickly screen the current execution feature fingerprint. If the initial screening passes, the third-level filter performs a more precise fingerprint match from a persistent database or hash table for final confirmation.

[0089] In some embodiments, the consistency verification module further includes an expired conclusion detection unit, which is used to extract the generation timestamps of each heterogeneous key state output by the preceding control module when performing consistency comparison, calculate the time difference between each generation timestamp and the current verification time, and determine whether the time difference exceeds the preset effective time window matched with the corresponding preceding control module. If any time difference exceeds the corresponding preset effective time window, the heterogeneous key state is determined to be an expired conclusion and regarded as a state mismatch, and a verification failure signal is directly output.

[0090] The generation timestamp is a time stamp attached by the preceding control module when generating the judgment conclusion. The preset valid time window is the conclusion freshness period set for different modules (for example, the valid window for bypass detection status may be only 50 milliseconds, while that for rule-allowed status may be 200 milliseconds). Expired conclusions refer to historical states that have lost their timeliness due to system flow delays.

[0091] Specifically, the expired conclusion detection unit 1024 is the time-dimensional security component of the consistency verification module 102. To prevent the system from using outdated permitted states to execute actions that may already be dangerous, this unit ensures the freshness of all states by comparing timestamps. It calculates the dwell time of each state using a high-precision clock synchronization mechanism (such as the PTP protocol). Once the dwell time of a state exceeds its dedicated valid time window, the state is deemed invalid, thereby forcibly blocking subsequent processes and requiring the system to re-initiate the verification.

[0092] Please refer to the following: Figure 4 This is a schematic diagram of the locking window control module of the running execution control device in this embodiment of the application.

[0093] The window locking control module 103 includes:

[0094] The time and resource locking unit 1031 is used to bind a local security clock to generate a pre-execution locking window when a verification pass certificate is obtained, and to exclusively lock the protected access window of the target device.

[0095] The verification pass certificate is an authorization signal issued upstream. The local secure clock is a reliable and tamper-proof time source. The pre-execution lock window is a short time interval created based on this secure clock. The protected access window of the target device refers to the logical or physical resources protected by security mechanisms that are required to operate the device. Exclusive locking ensures that only the currently executing process can access the resource during the lock period.

[0096] Specifically, the time and resource locking unit 1031 is a functional component of the locking window control module 103, which is activated upon receiving the verified credential. This unit creates a stable environment for the subsequent submission process from both time and resource dimensions. In the time dimension, a secure clock is bound to record the current moment as the starting point of the locking window, and a short validity period is set. In the resource dimension, the access resources of the target device are exclusively locked, ensuring that any other instructions attempting to operate on that resource during the window period are blocked or rejected.

[0097] In one implementation, the time and resource locking unit 1031 can be implemented using a distributed key-value store that supports a lease mechanism. Upon receiving a credential, the unit requests a lease from the storage system; the lease's lifespan is the length of the locking window. Then, it attempts to associate a key-value pair with the device ID as the key and the current session ID as the value with the lease. A successful write indicates that an exclusive lock has been acquired.

[0098] The snapshot generation unit 1032 is used to extract the unified input object, the current execution feature fingerprint and the current running state of the target device within the pre-execution locking window, combine them to generate a locking context snapshot, and write the locking context snapshot to the protected memory area.

[0099] The pre-execution lock window is an established protected time interval. The unified input object, the current execution feature fingerprint, and the current operating state of the target device are the core data elements constituting the snapshot.

[0100] Specifically, the snapshot generation unit 1032 executes immediately after the lock window is established. It packages and solidifies all verified key information to form a lock context snapshot. It extracts and combines three pieces of information: a unified input object defining the operation content, a current execution feature fingerprint serving as a credential of legitimacy, and the current operating state of the target device for reconfirmation. Then, it writes this combined data object into a protected memory area.

[0101] In one implementation, the snapshot generation unit 1032 can serialize the snapshot data structure and calculate its HMAC (Hash-based Message Authentication Code) using a secure key. Then, the serialized data plus the HMAC is stored in memory. When subsequent modules need to use the snapshot, they need to recalculate the HMAC of the received serialized data and compare it with the accompanying HMAC to confirm that the snapshot has not been tampered with.

[0102] Please refer to the following: Figure 5 This is a schematic diagram of the unique conclusion generation module of the running state execution control device in this application embodiment.

[0103] The unique conclusion generation module 104 includes:

[0104] The concurrent request interception unit 1041 is used to intercept all concurrent candidate execution requests for the target device within a pre-execution locking window.

[0105] The pre-execution lock window is a protected time and resource interval. The target device is the sole object of this operation. Concurrent candidate execution requests refer to any other competing instructions attempting to initiate an operation on the same target device during the lock window.

[0106] Specifically, the concurrent request interception unit 1041 is a functional component of the unique conclusion generation module 104, and its role extends throughout the entire pre-execution locking window. Once the locking window is open, this unit establishes an admission control point for the target device. This unit is configured to intercept all newly arriving candidate execution requests directed to the target device and redirect them to a temporary buffer area. This interception operation provides the prerequisite for subsequent uniqueness determination, ensuring that the decision-making process faces a closed and deterministic set of requests.

[0107] In one implementation, the concurrent request interception unit 1041 may utilize a message queue that supports single-consumer mode. When the locking window is open, a temporary queue is created for the target device, and the device listens for this queue as the sole consumer. Simultaneously, an upstream request router is configured to push all requests destined for the device into this temporary queue.

[0108] The feature fingerprint comparison unit 1042 is used to extract the execution feature fingerprint corresponding to each candidate execution request and compare it with the lock context snapshot in the protected memory area.

[0109] Among them, candidate execution requests are intercepted competing requests. Execution feature fingerprints are digital summaries generated in real time for each request.

[0110] Specifically, the feature fingerprint comparison unit 1042 is a functional component of the unique conclusion generation module 104. This unit is configured to authenticate all intercepted candidate execution requests. For each intercepted request, this unit invokes the same logic as the heterogeneous state convergence module 101 to generate an immediate execution feature fingerprint. This newly generated fingerprint is then rigorously compared with a baseline fingerprint stored in a locking context snapshot, thereby enabling the identification of the unique request that matches the initial authorization from multiple concurrent requests.

[0111] In one implementation, the fingerprint comparison unit 1042 may utilize a hash table. When the locked window is open, the baseline fingerprint in the lock context snapshot is stored as a key in a temporary hash table. Then, for each intercepted request, its fingerprint is calculated and directly searched in this hash table to determine if a match exists.

[0112] The contention suppression and release unit 1043 is used to mark the candidate execution request that completely matches the locked context snapshot as the unique candidate execution request and generate a unique control conclusion that allows it to enter the formal submission stage, and to perform mutual exclusion suppression on the remaining unmatched candidate execution requests. Mutual exclusion suppression includes logical isolation, control revocation or path disconnection.

[0113] In this context, the unique candidate execution request is the request that succeeds in the comparison. The unique control conclusion is the instruction that authorizes the request to continue execution. Mutual exclusion is the handling measure taken for all requests that fail to match, such as logical isolation, control revocation, or path termination.

[0114] Specifically, the contention suppression and release unit 1043 processes all requests based on the comparison results from the feature fingerprint comparison unit. For a unique candidate execution request identified as a complete match, the unit generates a unique control conclusion allowing formal submission and passes it to the next processing stage. For all other requests that fail the comparison, the unit performs mutual exclusion suppression according to a preset strategy. This mechanism ensures that within any given execution window, only one rigorously verified execution intent can flow to the final physical execution boundary.

[0115] In one implementation, the contention suppression and release unit 1043 may employ a dispatcher pattern. This unit receives requests with matching results from the comparison unit. If a match is found, the request is pushed into a designated submission channel. If no match is found, the request is pushed into different rejection channels based on its attributes, with each rejection channel having a corresponding processor to perform specific suppression actions.

[0116] Please refer to the following: Figure 6 This is a schematic diagram of the submission coordination and cascading cancellation module of the running execution control device in this embodiment of the application.

[0117] The submission coordination and cascading cancellation module 105 includes:

[0118] The two-phase handshake unit 1051 is used to send a lock request containing a unique control conclusion to the formal execution boundary in the first phase, and to receive a ready feedback status returned by the formal execution boundary in the second phase, so as to establish a lock control path.

[0119] The formal execution boundary (ECS) is the final actuator interface. The sole control conclusion is the upstream authorization command. A lock request is a signal issued by this unit requiring the ECS to enter a ready and exclusive service state. The ready feedback state is an acknowledgment returned by the ECS after it has completed preparation. The lock control path is a temporary dedicated communication link established through this process between this unit and the ECS.

[0120] Specifically, the two-phase handshake unit 1051 strictly adheres to the two-phase atomic handshake protocol. In the first phase, this unit sends a lock request carrying a unique control conclusion summary to the ECS. In the second phase, after receiving the request and completing its internal preparations, the ECS returns a ready feedback status to this unit. Only when this unit successfully receives this feedback is a lock control path formally established.

[0121] In one implementation, the two-phase handshake unit 1051 may utilize a protocol that supports bidirectional communication, such as bidirectional streaming in gRPC. In the first phase, the client initiates a streaming call to the server and sends a lock request message. Once ready, the server sends a ready feedback message back to the client via the same stream, completing the second phase.

[0122] The high-frequency anti-drift monitoring unit 1052 is used to cyclically collect the physical state of the target device and the heterogeneous key state output by the preceding control module during the critical time period before the release of the formal submission signal, and compare it with the lock context snapshot in real time.

[0123] The formal submission signal is the final execution instruction. The critical time period is the last high-risk period from the successful handshake to the imminent issuance of the submission signal. The physical state of the target device and the heterogeneous critical states output by the preceding control modules are the core monitoring objects. Locking the context snapshot serves as the benchmark for comparison. Real-time comparison is a continuous, instantaneous comparison.

[0124] Specifically, the high-frequency anti-drift monitoring unit 1052 is a functional component of the coordination and cascading reversal module 105, which is activated during the critical time period. It captures potential state drift that may occur after the locking window is established but before actual execution. A high-frequency cyclic monitoring task is initiated, continuously re-collecting critical states, including the physical state of the target device and the heterogeneous critical states output by each preceding control module. These latest real-time states are then compared in real-time with the baseline values ​​in the locking context snapshot. Once any mismatch is detected, the unit immediately triggers cascading reversal.

[0125] In one implementation, the high-frequency anti-drift monitoring unit 1052 can be implemented using a thread with a high scheduling priority. This thread reads sensor data in a compact loop by accessing memory-mapped I / O and obtains the status of other modules via lock-free shared memory. The comparison logic is performed directly in the CPU registers. Once a mismatch is detected, cancellation is triggered via an atomic flag.

[0126] In one implementation scenario, the high-frequency anti-drift monitoring unit can cyclically collect at least one of the following physical quantities of the target device during the critical time period before releasing the formal submission signal: voltage, current, temperature, pressure, displacement, speed, power slope, internal resistance, SOC, temperature rise rate, relay status, contactor status, control bus status, or thermal management status, at a sampling period of microseconds, milliseconds, or dynamically determined based on the risk level of the target device. This data is then compared in real-time with a locked context snapshot. If any of the aforementioned physical quantities exhibits a deviation exceeding a preset drift threshold, a change direction inconsistent with the target's execution behavior, or a change rate exceeding a preset safety slope, a physical state deviation is determined, and cascading reversal is immediately triggered.

[0127] The cascaded cancellation execution unit 1053 is used to cancel the submission qualification of the only candidate execution request and broadcast an abnormal blocking signal to the preceding control module when the high-frequency anti-drift monitoring unit detects a state deviation or the two-stage handshake unit fails to receive a ready feedback state, causing the lock control path to be disconnected.

[0128] Here, "state deviation" refers to a discrepancy between the real-time state and the snapshot. "Lockout control path disconnection" indicates a failure in the connection to the ECS. The preceding control modules are upstream modules such as WRS and RCC. The anomaly blocking signal is a broadcast notification requiring a global rollback.

[0129] Specifically, the cascading rollback execution unit 1053 is a fail-safe component of the submission coordination and cascading rollback module 105. It is triggered when the high-frequency anti-drift monitoring unit detects a state deviation, or when the two-stage handshake unit detects a disconnection with the ECS. Upon triggering, this unit immediately executes a series of actions to safely roll back the system. First, it revokes the submission eligibility of the sole candidate execution request. Second, it performs a cascading rollback, broadcasting an abnormal blocking signal to all relevant upstream preceding control modules, notifying them to roll back their respective states.

[0130] In one implementation, the cascading rollback execution unit 1053 can be implemented using a compensation transaction framework. The entire process from verification to commit is constructed as a distributed transaction, with each module registering a corresponding compensation operation while performing its forward operation. When this unit triggers rollback, the compensation process of the transaction is initiated, and the framework automatically calls the compensation operations of all executed steps in reverse to achieve reliable rollback.

[0131] In some embodiments, the runtime execution control device further includes a control receipt generation module 106, specifically comprising: a data extraction unit, used to extract the unified input object, locked context snapshot, unique control conclusion, and final submission or blocking status after the submission coordination and cascading cancellation module releases the formal submission signal or executes cascading cancellation; and a receipt encapsulation unit, used to bind the extracted data to the current timestamp to generate a unified control receipt object, which provides an immutable runtime snapshot certificate for subsequent accountability tracing and boundary verification.

[0132] In this context, evidence-based data refers to all context slices of the system at the moment of executing critical decisions. A unified control receipt object is a structured digital credential. Specifically, to meet the stringent auditing requirements of high-consequence automated systems, the control receipt generation module automatically collects process data after each execution attempt (regardless of success or failure). The receipt encapsulation unit uses national cryptographic algorithms or asymmetric encryption technologies such as RSA to digitally sign this data, generating a unified control receipt object to ensure the data has legal validity and non-repudiation in subsequent traceability.

[0133] In some embodiments, the runtime execution control device further includes an anomaly blocking and degradation module, specifically including: an anomaly event capture unit, used to capture the anomaly event type that causes the blocking when the submission coordination and cascading undo module performs cascading undo and blocks the submission; and a security degradation execution unit, used to match a preset security degradation strategy according to the anomaly event type, take over control of the target device, and transfer the target execution behavior to a controlled exception path, downgrade it to a secure mode action, or suspend the current automated submission and generate a manual upgrade review request.

[0134] The types of abnormal events include, but are not limited to, state drift, clock synchronization failure, and handshake timeout. The preset security degradation strategy is a pre-configured emergency response plan. Specifically, when a cascading reversal occurs in the system, a simple block may leave the device in an unknown state. The security degradation execution unit will query the policy matrix based on the specific type of anomaly captured. For example, if the blockage is caused by sensor data drift, the policy may instruct the device to switch to a safety hold mode. If it is a handshake timeout, the policy may instruct the generation of an alarm and require manual intervention for verification.

[0135] In some embodiments, the runtime execution control device further includes a runtime audit record module, specifically comprising: a full-process time-series tracking unit, used to collect control node interaction data in real time according to time sequence, covering the entire process of heterogeneous state convergence, consistency verification, locking window establishment, unique conclusion generation, and submission coordination; and an audit snapshot solidification unit, used to structurally encapsulate control node interaction data, candidate execution request records intercepted and suppressed by the unique conclusion generation module, and abnormal reversal records to generate runtime audit records independent of regular business logs.

[0136] The control node interaction data contains microsecond-level timing information of instructions flowing between various modules. The runtime audit logs are high-density logs specifically designed for security analysis. Specifically, to prevent covert concurrent attacks or potential system logic vulnerabilities, the full-process timing tracing unit collects timing data from the entire control chain with minimal performance overhead. The audit snapshot persistence unit structures and packages this data, especially those concurrent requests that are mutually exclusive (often evidence of attack attempts or system retry storms), and asynchronously writes them to WORM (Write Once, Read Many) storage media, forming a security audit tracing chain independent of ordinary business logs.

[0137] 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.

[0138] 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)".

[0139] 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.

[0140] 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 runtime execution control device for high-consequence automated systems, characterized in that, include: The heterogeneous state convergence module is used to obtain candidate execution requests for the target device, extract the unified input object of the target execution behavior corresponding to the candidate execution request, and obtain the heterogeneous key states output by multiple preceding control modules. The logically normalized heterogeneous key states are fused with the unified input object to generate the current execution feature fingerprint. The consistency verification module is used to compare the current execution feature fingerprint with the current operating state of the target device and the preset security execution template, and output a verification pass certificate when the comparison is successful. The locking window control module is triggered when the verification pass certificate is obtained. It is used to establish a pre-execution locking window and bind the unified input object and the current execution feature fingerprint in the pre-execution locking window to generate a locking context snapshot. The unique conclusion generation module is used to perform mutual exclusion suppression on concurrent candidate execution requests based on the lock context snapshot within the pre-execution locking window, and generate a unique control conclusion that only allows the unique candidate execution request that matches the lock context snapshot to enter the formal submission stage; The submission coordination and cascading revocation module is used to establish a locking control path by handshaking with the formal execution boundary based on the unique control conclusion, and to perform anti-drift detection before releasing the formal submission signal to the formal execution boundary. If the physical state of the target device or the heterogeneous key state output by the preceding control module is detected to deviate from the locking context snapshot, then cascading revocation is performed and submission is blocked. If there is no deviation and the locking control path remains connected, then the formal submission signal is released.

2. The operating state execution control device according to claim 1, characterized in that, The heterogeneous state convergence module specifically includes: The input object aggregation unit is used to parse the candidate execution request, extract the target action identifier, target device identifier, target execution parameters and session identifier, and encapsulate them into the unified input object; A multi-module state aggregation unit is used to collect the heterogeneous key states output by the preceding control module. The heterogeneous key states include at least the rule-allowed state, the rule-frozen state, the bypass detection state, and the boundary-available state. A unified state representation unit is used to perform logical normalization processing on the heterogeneous key states, generate a unified state vector, and perform hash fusion of the unified state vector with the unified input object to generate the current execution feature fingerprint.

3. The operating state execution control device according to claim 2, characterized in that, The consistency verification module specifically includes: The state parsing and matching unit is used to parse the unified state vector from the current execution feature fingerprint and determine whether the rule allowed state, the rule frozen state, the bypass detection state and the boundary available state all meet the preset conditions for continuing to submit. The device status verification unit is used to obtain the current operating status of the target device and determine whether the current operating status supports the execution of the action corresponding to the target execution parameters. The comprehensive judgment unit is used to determine the consistency comparison is passed and output the verification certificate when the judgment results of the status parsing and matching unit and the device status verification unit are both yes, and the current execution feature fingerprint matches the preset security execution template.

4. The operating state execution control device according to claim 1, characterized in that, The locked window control module specifically includes: The time and resource locking unit is used to bind a local security clock to generate the pre-execution locking window when the verification pass certificate is obtained, and to exclusively lock the protected access window of the target device. The snapshot generation unit is used to extract the unified input object, the current execution feature fingerprint, and the current running state of the target device within the pre-execution locking window, combine them to generate the locking context snapshot, and write the locking context snapshot into the protected memory area.

5. The operating state execution control device according to claim 4, characterized in that, The unique conclusion generation module specifically includes: The concurrent request interception unit is used to intercept all concurrent candidate execution requests for the target device within the pre-execution locking window; The feature fingerprint comparison unit is used to extract the execution feature fingerprint corresponding to each of the candidate execution requests and compare it with the lock context snapshot in the protected memory area; The contention suppression and release unit is used to mark the candidate execution request that completely matches the locked context snapshot as the unique candidate execution request, and generate the unique control conclusion that allows it to enter the formal submission stage, and to perform mutual exclusion suppression on the remaining unmatched candidate execution requests, wherein the mutual exclusion suppression includes logical isolation, control revocation or path disconnection.

6. The operating state execution control device according to claim 1, characterized in that, The submission coordination and cascading cancellation module specifically includes: A two-phase handshake unit is used to send a lock request containing the unique control conclusion to the formal execution boundary in the first phase, and to receive a ready feedback status returned by the formal execution boundary in the second phase, so as to establish the lock control path. The high-frequency anti-drift monitoring unit is used to cyclically collect the physical state of the target device and the heterogeneous key state output by the preceding control module during the critical time period before the release of the formal submission signal, and compare them with the locking context snapshot in real time. The cascaded revocation execution unit is used to revoke the submission qualification of the unique candidate execution request and broadcast an abnormal blocking signal to the preceding control module when the high-frequency anti-drift monitoring unit detects a state deviation or the two-stage handshake unit fails to receive the ready feedback state, causing the locking control path to be disconnected.

7. The operating state execution control device according to claim 1, characterized in that, It also includes a control receipt generation module, which specifically includes: The evidence data extraction unit is used to extract the unified input object, the locking context snapshot, the unique control conclusion, and the final submission or blocking status after the submission coordination and cascading cancellation module releases the formal submission signal or performs cascading cancellation. The receipt encapsulation unit is used to bind the extracted evidence data with the current timestamp to generate a unified control receipt object. The unified control receipt object is used to provide an immutable runtime snapshot certificate for subsequent accountability and boundary verification.

8. The operating state execution control device according to claim 1, characterized in that, It also includes anomaly blocking and degradation modules, specifically including: An exception event capture unit is used to capture the type of exception event that causes the blocking when the submit coordination and cascading undo module performs cascading undo and blocks the submit; The security degradation execution unit is used to match a preset security degradation strategy according to the type of abnormal event, take over the control of the target device, and transfer the target execution behavior to a controlled exception path, downgrade it to a safe mode action, or suspend the current automated submission and generate a manual upgrade review request.

9. The operating state execution control device according to claim 1, characterized in that, It also includes a runtime audit log module, which specifically includes: The full-process time-series tracking unit is used to collect control node interaction data in real time according to the time sequence of the heterogeneous state convergence, consistency verification, locking window establishment, unique conclusion generation and submission coordination process. The audit snapshot solidification unit is used to structurally encapsulate the control node interaction data, the candidate execution request records intercepted and suppressed by the unique conclusion generation module, and the abnormal reversal records to generate runtime audit records that are independent of regular business logs.

10. The operating state execution control device according to claim 1, characterized in that, The consistency verification module further includes an expired conclusion detection unit, which is used to extract the generation timestamps of each heterogeneous key state output by the preceding control module when performing the consistency comparison, calculate the time difference between each generation timestamp and the current verification time, and determine whether the time difference exceeds the preset effective time window matched with the corresponding preceding control module. If any time difference exceeds the corresponding preset effective time window, the heterogeneous key state is determined to be an expired conclusion and regarded as a state mismatch, and a verification failure signal is directly output.

Images