Rule object-based physical enforcement admission control apparatus

Abstract

A rule-object-based physical execution access control device is used to improve the security of physical execution of high-consequence automation systems. In the device, the physical execution access control device objectifies the scattered rule logic and centrally manages it. After obtaining a decision result, the device does not directly issue a binary value, but generates an objectified authorization credential containing the decision result, rule trace information, and rule reference feature sequence. The downstream execution boundary can verify the rule reference feature sequence in the credential before execution, ensuring that the decision basis is consistent with the current system global version. Thus, a strong context association is established between the upper-layer decision and the bottom-layer physical execution, making the physical execution verifiable before execution, thereby reducing the risk of version inconsistency or instruction replay, and improving the security and traceability of the physical execution of high-consequence automation systems.

Description

Technical Field

[0001] This application relates to the field of automation system technology, and in particular to a physical execution access control device based on rule objectification. Background Technology

[0002] In high-consequence automated systems such as energy storage regulation, industrial production line control, and autonomous driving, whether the physical actions of the target task (such as high-power discharge, equipment start-up and shutdown, emergency braking, etc.) can be allowed to occur usually depends on the system's preset rules, operating thresholds, spatiotemporal constraints, and safety boundaries for access judgment.

[0003] Related automated systems typically distribute various security restrictions and business rules across the main program's low-level code, external configuration files, and environment variables. During actual operation, when an execution request is received, the automated system directly reads and invokes these distributed configuration items and hard-coded logic, feeding them into a conditional judgment stream for continuous calculation and comprehensive judgment, arriving at a decision to allow or block. Subsequently, a simple Boolean control value (such as an allow or deny logical bit state) is sent directly to the underlying physical execution boundary (such as downstream hardware drivers or management modules), and a local operation log is generated. The downstream execution boundary then triggers the corresponding physical action based on the received Boolean value.

[0004] However, the related technologies use Boolean values ​​to issue instructions, severing the contextual relationship between physical actions and the complex upper-level decision-making system. In high-risk scenarios where multiple control rules are intertwined, the downstream only receives a single logical state and cannot perceive the specific blocking reason or authorization rule version. It is difficult to verify and review conflicts before execution, which reduces the security of physical execution of high-consequence automated systems. Summary of the Invention

[0005] This application provides a rule-based physical execution admission control device to improve the security of physical execution in high-consequence automated systems.

[0006] Firstly, a physical execution access control device based on rule objectification is provided, characterized by comprising: a rule loading module, used to receive a physical execution request for a target device, match target rule objects associated with the physical execution request in a preset rule base, and convert the environment and operating parameters in the physical execution request into standardized inputs; a rule matching module, used to input the standardized inputs to each target rule object for judgment, and output sub-matching results containing either a permission state or a blocking state to obtain a preliminary result set; and a rule conflict handling module, used to parse the preliminary result set, and when at least one blocking state exists, to mask the permission state in the preliminary result set and output a single... The system makes a decision and extracts the identifier data of the target rule object in the blocked state as a record of rule tracing information. The authorization credential generation module combines the version number and identifier data of each target rule object to generate a rule baseline feature sequence, and encapsulates the single decision result, rule tracing information and rule baseline feature sequence into an objectified authorization credential. The execution boundary verification module issues the objectified authorization credential to the target execution boundary, enabling the target execution boundary to extract the rule baseline feature sequence and verify it with the currently effective global rule feature sequence of the automation system. If they match, a physical response is triggered according to the single decision result; if they do not match, the physical response is blocked.

[0007] By adopting the above technical solution, the physical execution access control device objectifies and centrally manages the dispersed rule logic. After obtaining the decision result, instead of directly issuing a pass / follow value, it generates an objectified authorization certificate containing the decision result, rule traceability information, and rule baseline feature sequence. Before execution, the downstream execution boundary can verify the rule baseline feature sequence in the certificate to ensure that the decision basis is consistent with the current global version of the system. This establishes a strong contextual association between the upper-level decision and the lower-level physical execution, making physical execution verifiable before execution, thereby reducing the risks of version inconsistency or instruction replay, and improving the security and traceability of physical execution in high-consequence automated systems.

[0008] In conjunction with some embodiments of the first aspect, some embodiments further include a rule sandbox pre-verification module, specifically comprising: a test data extraction unit, used to use historical physical execution request data received by the automation system within a preset historical time period that has been intercepted or released as a test input set, and extract the historical judgment result corresponding to each data in the test input set under the original rules of the automation system; a shadow environment playback unit, used to load the target rule object to be launched into a preset shadow test sandbox that is not connected to the physical execution peripheral, and input the data in the test input set one by one into the target rule object for judgment, and obtain the simulated trial run result of the target rule object for each data; a state inversion restriction unit, used to count the number of data items that have undergone state inversion based on the simulated trial run result and the historical judgment result, and when the number of data items that were originally released but turned into intercepted exceeds a preset excessive blocking threshold, or when the number of data items that were originally intercepted but turned into released exceeds a preset dangerous release threshold, output a prohibition loading instruction and refuse to write the target rule object to be launched into the preset rule library; when neither exceeds the corresponding threshold, the target rule object to be launched is written into the preset rule library.

[0009] By adopting the above technical solution, and by using historical real data to replay tests of new rules in a shadow environment and comparing them with historical results, the potential business impact (excessive blocking) and security risks (dangerous access) of new rule implementation can be quantitatively assessed. Using the threshold set by the state inversion restriction unit, rule changes that do not meet expectations can be automatically blocked, thereby avoiding the introduction of defective rules due to human oversight and improving the overall quality and stability of the rule base.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the rule sandbox pre-verification module further includes: an asset rating and parsing unit, used to pre-obtain the asset importance rating attributes for the target device, and convert the asset importance rating attributes into strictness weighting coefficients according to a preset importance mapping table; and a dynamic threshold configuration unit, used to collect the basic processing throughput of the automated system within a preset historical time period, and, in conjunction with the strictness weighting coefficients, perform weighted calculations on the preset benchmark interception deviation value and the preset benchmark release deviation value respectively, to obtain the preset excessive blocking threshold and the preset dangerous release threshold under the current operating cycle.

[0011] By adopting the above technical solutions and introducing asset importance rating and dynamic threshold configuration, the tolerance for state reversals is no longer static, but can be adaptively adjusted based on the importance of the affected equipment and the current system load. For example, rule changes for core assets will employ stricter risk clearance thresholds, making the security policy more aligned with actual business scenarios.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the rule loading module specifically includes: a communication message parsing unit, used to unpack the physical execution request according to a preset communication protocol to obtain the original data payload containing business attributes; a parameter separation and mapping unit, used to extract the specific environment and operating parameters of each target device from the original data payload, and convert the device identifier and data format of the environment and operating parameters into the preset unified format of the automation system according to a preset standard parameter mapping relationship table to obtain an intermediate parameter set; and a unit alignment unit, used to perform numerical conversion and alignment on the numerical data with physical unit differences in the intermediate parameter set according to a preset benchmark unit conversion rule, and use the aligned parameter set as standardized input.

[0013] By adopting the above technical solution, through communication message parsing, parameter separation and mapping, and dimensional alignment, heterogeneous raw request data is converted into a unified standardized input within the system, enabling rule objects to be developed based on a standardized data model, thereby improving the system's scalability and maintainability.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the rule matching module specifically includes: a timeliness feature extraction unit, used to extract the initial network timestamp when the physical execution request is generated from the standardized input; a time difference calculation unit, used to obtain the current system timestamp and calculate the time difference between the current system timestamp and the initial network timestamp; and a forced interception control unit, used to determine whether the time difference is greater than the effective survival time threshold when the target rule object has an embedded effective survival time threshold. If so, it is determined that the physical execution request has experienced network lag, and other environmental and operational parameter judgments in the target rule object are skipped, and the sub-matching result of the blocking state is directly output; otherwise, the judgment and output are performed according to the original logical conditions of the target rule object.

[0015] By employing the above technical solution, and calculating the time difference between a request's generation and processing, and comparing it with the valid lifetime threshold embedded in the rule, expired requests caused by network congestion or system delays can be quickly identified and blocked. This avoids performing complex subsequent business logic checks on expired requests, thereby saving system computing resources and preventing security incidents that may be caused by executing expired instructions.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the rule conflict handling module specifically includes: a tag parsing unit, used to extract the tag type carried by the target rule object of the output blocking state when there is at least one blocking state in the preliminary result set, wherein each target rule object in the preset rule base carries a core rule tag, a domain rule tag, or an exception rule tag; a core priority blocking unit, used to directly block all the release states in the preliminary result set and output a single decision result representing refusal to execute if the extracted tag type contains a core rule tag; and an exception exemption unit, used to block the original blocking state and output a single decision result representing conditional release if the extracted tag type is only a domain rule tag and there is a release state output by a target rule object carrying an exception rule tag in the preliminary result set, and record the identification data of the target rule object of the output release state as new rule tracing information.

[0017] By adopting the above technical solution and pre-setting tags such as core, domain, and exception for the rules, when faced with multiple contradictory sub-matching results, the system can make a decision based on the preset strategy (such as core rules vetoing and exception rules exempting domain rules), thereby improving the accuracy of decision-making under complex business logic.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the authorization credential generation module specifically includes: a hash feature calculation unit, used to call a preset hash algorithm, to normalize and combine the identification data and version number of each target rule object participating in the matching according to a preset sorting rule, and then perform a hash operation on the combined data to generate a string of fixed-length hash characters as a rule baseline feature sequence; and an encrypted signature encapsulation unit, used to tightly concatenate the single decision result, rule traceability information and rule baseline feature sequence into a plaintext data payload, and use the private key of the automated system to perform a digital signature operation on the plaintext data payload to generate an objectified authorization credential.

[0019] By adopting the above technical solution, the hash feature calculation unit generates a lightweight fingerprint based on the rule's identifier data and version number. This fingerprint reflects the state of the rule set used for decision-making while reducing the size of the credential and the burden on downstream verification. The encrypted signature encapsulation unit utilizes asymmetric encryption technology to ensure that the credential is not tampered with during transmission and that its source is trustworthy.

[0020] In conjunction with some embodiments of the first aspect, in some embodiments, the execution boundary verification module specifically includes: a credential decomposition unit, used to extract the embedded rule baseline feature sequence after the target execution boundary receives the objectified authorization credential; a string comparison unit, used to read the current global rule feature sequence cached locally at the target execution boundary, and compare the extracted rule baseline feature sequence with the global rule feature sequence character by character; and a physical response control unit, used to determine that the rule version on which the two strings are completely consistent is valid and to trigger a physical response based on a single decision result when there is a character inconsistency, and to determine that there is a risk of replaying an old version or rule disconnection on the execution basis, and to block the physical response.

[0021] By employing the above technical solution, and comparing the rule baseline feature sequence in the credential with the locally cached global sequence bit by bit, it is possible to more accurately verify whether the rule version upon which the authorization instruction is based is the latest and valid version in the current system. This mechanism can resist attacks using old credentials caused by network latency, message queue backlog, or malicious replay, ensuring that physical execution actions are always strictly synchronized with the latest security policies.

[0022] In conjunction with some embodiments of the first aspect, in some embodiments, the execution boundary verification module further includes: a difference tracing and extraction unit, used to extract outdated rule feature sequences still residing in the local memory of the target execution boundary after the physical response control unit determines that there is a character inconsistency and blocks the physical response; a version alignment request unit, used to combine the outdated rule feature sequence with the rule baseline feature sequence extracted by the credential disassembly unit into a version difference request packet, and send it in reverse to the version management node built into the automation system; and a controlled hot synchronization unit, used to write the incremental difference rule logic into the local memory while maintaining the current physical circuit breaker state, based on the incremental difference rule logic issued by the version management node in response to the version difference request packet, and re-initiate the retrieval and character-by-character comparison operation for the global rule feature sequence.

[0023] By adopting the above technical solution, when version inconsistency is detected, the system proactively reports the version differences and requests incremental updates. The controlled hot synchronization unit ensures that the update process is performed under safe conditions of physical disconnection. This improves the robustness and operational efficiency of the distributed system and reduces service interruption time caused by version asynchrony.

[0024] In conjunction with some embodiments of the first aspect, some embodiments further include a rule base hot deployment module, specifically including: a backup storage area construction unit, used to configure a backup storage area isolated from the current working storage area of ​​the preset rule base in the system storage space; a background loading unit, used to preload and write the target rule object carrying the new version number into the backup storage area when a target rule update instruction is received; and an atomic switching trigger unit, used to monitor the concurrent processing status of the rule matching module in real time, and when the system processing idle period is detected, switch the backup storage area to the effective working storage area, and synchronously trigger the automated system to update the currently effective global rule feature sequence.

[0025] By adopting the above technical solution, and through the construction of a backup storage area and the use of system idle periods for atomic switching, potential system logic chaos or request processing interruptions during rule updates are avoided. Simultaneously updating and distributing the global rule feature sequence during the switching process ensures that the central endpoint and all execution boundaries achieve version alignment at the same time, improving system availability and data consistency during rule iteration and upgrades.

[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 physical execution access control device objectifies and centrally manages the dispersed rule logic. After reaching a decision, it does not directly issue a pass / fail value, but instead generates an objectified authorization credential containing the decision result, rule traceability information, and rule baseline feature sequence. Before execution, the downstream execution boundary can verify the rule baseline feature sequence in the credential to ensure that the decision basis is consistent with the current global system version. This establishes a strong contextual relationship between upper-level decision-making and lower-level physical execution, making physical execution verifiable before execution. This reduces the risks of version inconsistency or instruction replay, improving the security and traceability of physical execution in high-consequence automated systems.

[0028] 2. By using historical real data to replay tests of new rules in a shadow environment and comparing the results with historical data, the potential business impact (excessive blocking) and security risks (dangerous access) of new rule implementation can be quantitatively assessed. Using the threshold set by the state inversion restriction unit, rule changes that do not meet expectations can be automatically blocked, thus avoiding the introduction of flawed rules due to human oversight and improving the overall quality and stability of the rule base.

[0029] 3. When a version inconsistency is detected, the system proactively reports the version differences and requests an incremental update. The controlled hot synchronization unit ensures that the update process occurs under safe conditions of physical disconnection. This improves the robustness and operational efficiency of the distributed system and reduces service interruption time caused by version discrepancies. Attached Figure Description

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

[0031] Figure 2 This is a schematic diagram of the rule loading module of the physical execution admission control device in the embodiments of this application.

[0032] Figure 3 This is a schematic diagram of the rule matching module of the physical execution access control device in the embodiments of this application.

[0033] Figure 4 This is a schematic diagram of the rule conflict handling module of the physical execution admission control device in the embodiments of this application.

[0034] Figure 5 This is a schematic diagram of the authorization credential generation module of the physical execution access control device in this application embodiment.

[0035] Figure 6 This is a schematic diagram of the execution boundary verification module of the physical execution access control device in the embodiments of this 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 rule-based physical execution admission control device to improve the security of physical execution in high-consequence automated systems.

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

[0040] The physical enforcement access control device includes:

[0041] The rule loading module 101 is used to receive physical execution requests for the target device, match the target rule objects associated with the physical execution request in the preset rule base, and convert the environment and operating parameters in the physical execution request into standardized input.

[0042] In this context, "target device" refers to a hardware entity or subsystem controlled by the automated system that can perform physical actions, such as battery stacks in an energy storage station, industrial robots, or vehicle braking systems. A physical execution request represents a data instruction carrying a clear execution intent and relevant parameters, designed to trigger an actual physical change in the target device. The preset rule base is a structured, centralized repository containing various rule logics used to determine the compliance of physical execution requests, stored in object form. A target rule object represents a single rule encapsulation associated with a specific physical execution request, stored in the rule base; each object contains an independent set of judgment logic, conditions, and metadata. Environmental and operational parameters refer to dynamic data accompanying the physical execution request, describing the current device state or external environment, such as temperature, pressure, voltage, geographical location, and timestamps. Standardized input refers to a set of environmental and operational parameters that have undergone uniform formatting, unit alignment, and structuring processing; it serves as the direct data source for subsequent rule matching.

[0043] Specifically, when the automated system deployed by the physical execution access control device receives a physical execution request for a specific target device from an external control unit, sensor network, or upper-layer business platform, the rule loading module is triggered. The rule loading module first performs preliminary parsing of the received request to identify the intended target device and the request type. Based on this identification information, it searches a preset rule base to find and load all target rule objects related to the target device and request type. For example, a request to perform a 100kW charging operation on energy storage cabinet A will match all rules applicable to the energy storage cabinet charging scenario, such as rules that the battery temperature must not exceed 50°C and the charging power must not exceed the rated power. After locating the relevant rule objects, the module extracts all environmental and operational parameters from the original physical execution request and initiates a conversion process to address the heterogeneity of request data from different sources in terms of format, naming conventions, and physical quantity units. Ultimately, all parameters are converted into a unified data structure and reference unit agreed upon within the system, forming a standardized input data packet, which is then passed to the subsequent rule matching module 102 for processing.

[0044] In some embodiments, to improve the quality and security of target rule objects written into a preset rule base and to prevent unexpected system behavior from being introduced due to rule changes, the device may also include a rule sandbox pre-verification module. This module provides an automated regression testing and impact assessment process before new or updated rule objects are officially deployed online.

[0045] Specifically, the rule sandbox pre-verification module includes a test data extraction unit, a shadow environment playback unit, and a state flipping restriction unit.

[0046] The test data extraction unit extracts all received physical execution request data that has been judged (whether blocked or allowed) by the online system within a preset historical time period (e.g., the past 24 hours) from the historical logs or database of the automated system, forming a batch of test input sets. Simultaneously, the test data extraction unit also extracts and records the historical judgment result (i.e., whether it was allowed or blocked) for each historical request data under the old rules used by the automated system at that time. The shadow environment replay unit constructs a preset shadow test sandbox isolated from the online environment. This sandbox logically replicates the core judgment process of the access control device but is not connected to any real physical execution peripherals, ensuring that the test process does not generate actual physical actions. The shadow environment replay unit loads the target rule object of the new version to be deployed into this sandbox, and then replays the historical data from the test input set one by one into this new rule object for simulated judgment, thereby obtaining the simulated trial run result of the new rule output for each historical data. The state inversion constraint unit compares the simulated trial run result of each test data under the new rule with its historical judgment result under the old rule. The state inversion restriction unit counts the number of data entries that have undergone state inversion, i.e., how many data entries were originally allowed but are now blocked by the new rule (potentially causing excessive blocking and impacting system availability), and how many data entries were originally blocked but are now allowed by the new rule (potentially introducing new security risks). When the number of data entries that were allowed but turned into blocked exceeds a preset excessive blocking threshold, or when the number of data entries that were blocked but turned into allowed exceeds a preset dangerous allowance threshold, a prohibition loading command is output, automatically rejecting the rule's deployment and issuing an alert to development or operations personnel. Only when neither of these thresholds is triggered is the impact of the new rule change considered within an acceptable range, allowing it to be formally written into the preset rule base for use in the online system.

[0047] To make the preset over-blocking threshold and preset dangerous release threshold more adaptive, in some embodiments, the rule sandbox pre-verification module may also include an asset grading and parsing unit and a dynamic threshold configuration unit.

[0048] The asset grading and analysis unit manages the asset importance information of each target device in the system. Maintenance personnel can pre-assess the importance level (e.g., core, important, general) of each device (such as a critical energy storage unit or a common auxiliary fan). Based on a pre-defined importance mapping table, the asset grading and analysis unit converts these qualitative rating attributes into a quantitative weighted coefficient. For example, the coefficient for a core asset might be 1.5, while the coefficient for a general asset might be 0.8. The dynamic threshold configuration unit is responsible for dynamically calculating the aforementioned excessive blocking threshold and dangerous release threshold. It collects the basic processing throughput of the automated system over a historical period (e.g., total number of requests) and combines it with the strictness weighted coefficients obtained from the asset grading and analysis unit for the target devices affected by the current rule change. Then, the dynamic threshold configuration unit uses these strictness weighted coefficients to perform a weighted calculation on two pre-defined baseline deviation values ​​(e.g., baseline blocking deviation allowed at 5%, baseline release deviation allowed at 1%). For example, for core assets, the final risk release threshold may be tightened, while the tolerance for excessive blocking may be relaxed, thereby achieving differentiated and refined management of the risk of changes in assets of different importance.

[0049] The rule matching module 102 is used to input the standardized input to each target rule object for judgment, and output sub-matching results containing the release state or the blocking state to obtain a preliminary result set.

[0050] In this context, standardized input refers to a set of parameters with a uniform format and units obtained after processing by the rule loading module 101. A target rule object refers to each independent rule entity matched from the rule base, encapsulating specific judgment logic. A sub-matching result refers to the judgment output obtained after applying the standardized input to a single target rule object; this output explicitly indicates whether the rule is satisfied or violated. A "allow" state represents one state of the sub-matching result, meaning that the physical execution request satisfies the condition constraints of the current target rule object. A "block" state represents another state of the sub-matching result, meaning that the physical execution request violates the condition constraints of the current target rule object. The preliminary result set refers to the set formed by summarizing the sub-matching results generated by all relevant target rule objects; this set may contain multiple "allow" and / or "block" states.

[0051] Specifically, after the rule loading module 101 completes the standardization processing of the physical execution request, the rule matching module 102 receives the standardized input. The rule matching module inputs the standardized input data in parallel or serially to all previously loaded target rule objects. Each target rule object contains a set of preset logical condition expressions, such as temperature parameter <50 AND voltage parameter >400. The rule matching module drives each rule object to execute its internal logic, substituting the corresponding parameter values ​​from the standardized input into the expressions for calculation and comparison. If the logical condition is true, the target rule object outputs a sub-matching result marked as a release state. If the logical condition is false, it outputs a sub-matching result marked as a blocking state. This process is executed one by one for all associated target rule objects. For example, a charging request may simultaneously trigger three rule objects: over-temperature protection, over-voltage protection, and SOC range limitation, obtaining sub-matching results for each of these three rules. Finally, the rule matching module collects all these independent sub-matching results (e.g., {overtemperature protection: release state, overvoltage protection: blocking state, SOC range limit: release state}) to form a preliminary result set, and passes it to the rule conflict processing module 103 for final adjudication.

[0052] In some embodiments, the rule matching module can be implemented in several ways: Optionally, it can be implemented using rule engine technology. First, all target rule objects are pre-compiled or converted into a format recognizable by the rule engine, such as Drools' drl file. Second, after receiving standardized input, the rule matching module inserts it as a fact into the working memory of the rule engine. Finally, the rule engine is triggered to execute all active rules. The rule engine automatically matches the facts with the rule conditions and executes the consequence part of the rule, which is designed to generate corresponding allow or block sub-matching results and add them to a shared result list. Optionally, it can also be implemented using multi-threaded parallel processing. First, an independent execution thread is created for each target rule object to be matched, or a thread is allocated from a thread pool. Second, standardized input data is shared with all threads in read-only mode, and these threads are started to concurrently execute the judgment logic of their respective rule objects. Finally, the main thread waits for all child threads to finish executing and collects the sub-matching results returned by each child thread through a thread synchronization mechanism, ultimately assembling a preliminary result set.

[0053] The rule conflict handling module 103 is used to parse the preliminary result set. When there is at least one blocking state, it blocks the release state in the preliminary result set, outputs a single decision result, and extracts the identification data of the target rule object of the output blocking state as a rule tracing information record.

[0054] The preliminary result set refers to the collection of sub-matching results generated by the rule matching module 102, containing all relevant rules. Masking refers to ignoring or discarding certain sub-matching results during this processing stage so that they do not affect the final decision. A single decision result refers to the unique and explicit decision obtained after conflict resolution, typically allowing or denying execution. The identification data of the target rule object refers to the characteristic information that can uniquely identify a rule object, such as the rule's unique ID, name, or code. Rule tracing information refers to the information used to record and trace the basis of decisions, specifically referring to the specific rule that leads to the final decision result (especially blocking decisions).

[0055] Specifically, the rule conflict handling module 103 forms a globally unique final decision based on a preset arbitration strategy. Its processing logic follows the principle of security priority or veto power. First, it parses the preliminary result set, checking if there are at least one sub-matching result in a blocked state. If one or more blocked states are detected, regardless of the number of allowed states, a masking operation is performed, ignoring all allowed state results. At this point, a single decision representing rejection is output. Simultaneously, for the traceability and interpretability of the decision, the rule conflict handling module extracts the identification data (e.g., rule ID SEC-001-TEMP-HIGH) of the target rule object(s) that caused this blocking result and combines this identification data into rule tracing information and records it. If all sub-matching results in the preliminary result set are in an allowed state, a single decision representing permission is output.

[0056] The authorization certificate generation module 104 is used to combine the version number and identification data of each target rule object to generate a rule baseline feature sequence, and encapsulate the single decision result, rule traceability information and rule baseline feature sequence into an objectified authorization certificate.

[0057] In this context, the version number and identification data of the target rule object refer to the combination of version information (e.g., v1.0, v2.1) and unique identity ID of each rule participating in the matching. The rule baseline feature sequence refers to a fingerprint or snapshot of the entire set of rules participating in this decision, generated by a pre-defined algorithm. Rule source information refers to a set of specific rule IDs that record the decision outcome (especially blocking). The objectified authorization credential is a structured data packet that aggregates the decision outcome, source information, and rule baseline feature sequence, forming an authorization entity.

[0058] Specifically, the authorization credential generation module 104 collects metadata from all target rule objects participating in the matching process, particularly their version numbers and identifiers. This information is then combined in a predetermined order and a fixed-length string is calculated using a pre-defined algorithm (such as a hash algorithm). This string is the rule baseline feature sequence. This sequence uniquely represents which set and version of rules were used to make the decision. Subsequently, the single decision result (allow / block), rule tracing information, and the newly generated rule baseline feature sequence are encapsulated into a structured data object, such as a JSON or XML object. This final data package is the objectified authorization credential, which not only informs the downstream what to do (decision result) but also explains why it is done (tracing information) and what it is based on (rule baseline).

[0059] The execution boundary verification module 105 is used to issue objectified authorization credentials to the target execution boundary, enabling the target execution boundary to extract the rule baseline feature sequence and verify it with the currently effective global rule feature sequence of the automated system. If they match, a physical response is triggered based on a single decision result; if they do not match, the physical response is blocked.

[0060] In this context, the target execution boundary refers to the lowest-level software or hardware module in an automation system that directly controls the actions of physical hardware, such as a driver, PLC (Programmable Logic Controller), or MCU (Microcontroller). The global rule feature sequence refers to the fingerprint of the global rule set that is confirmed to be valid and running within the system where the current target execution boundary resides; it is generated and distributed by the system rule management module during rule updates. The physical response refers to the actual physical action performed by the target device, such as motor rotation, valve opening, or circuit breaker closing.

[0061] Specifically, the execution boundary verification module 105 ensures that the rule version upon which the action to be executed is strictly consistent with the currently effective rule version globally in the system. This prevents security risks associated with using outdated credentials to perform operations due to communication delays, message replays, or asynchronous system rule updates. When the objectified authorization credential arrives, the execution boundary verification module first extracts the embedded rule baseline feature sequence. Simultaneously, it reads the currently effective global rule feature sequence maintained by the system from a local secure storage area (such as memory or a specific register). Then, it performs a comparison operation to verify that the two sequences are completely identical. If the two feature sequences are completely identical, it indicates that the authorization credential was generated based on the latest and correct rule set and is valid. At this point, the execution boundary verification module will parse the single decision result in the credential and trigger or block the physical response accordingly. Conversely, if there is any inconsistency between the two sequences, the module will determine that the credential may be invalid or generated based on old rules, posing a security risk. In this case, regardless of whether the single decision result is to allow or block, the module will enforce the strategy of blocking the physical response and may trigger an exception reporting process.

[0062] The above describes the module architecture diagram of the physical execution admission control device in the embodiments of this application. The modules are described below.

[0063] Please refer to the following: Figure 2 This is a schematic diagram of the rule loading module of the physical execution access control device in the embodiments of this application.

[0064] Rule loading module 101 includes:

[0065] The communication message parsing unit 1011 is used to unpack the physical execution request according to a preset communication protocol to obtain the original data payload containing service attributes.

[0066] The preset communication protocol refers to the data transmission format and specifications agreed upon between the automation system and the external request source, such as Modbus, CAN, a custom application layer protocol over TCP / IP, or HTTP. A physical execution request refers to the raw, unprocessed communication data packet carrying execution instructions, such as a CAN message frame or a TCP data stream. The unpacking operation represents the process of parsing and structurally deconstructing the physical execution request according to the communication protocol definition to access its internal data fields. Business attributes refer to the semantic information related to specific operations carried in the data packet, such as device address, function code, and operation type. The raw data payload refers to the core data portion of the data packet carrying environmental and operational parameters after removing communication overhead such as protocol headers and checksums.

[0067] Specifically, the communication message parsing unit incorporates decoding logic for one or more preset communication protocols. For example, if the system uses the Modbus TCP protocol, the communication message parsing unit identifies and separates the transaction identifier, protocol identifier, length, unit identifier, function code, and data area from the message. The core of the unpacking operation is to segment and identify each meaningful field from a continuous binary data block according to the protocol specification. Through this operation, the communication message parsing unit can extract the target device address of the instruction, the type of operation to be performed (service attribute), and the raw data payload containing specific parameters such as temperature, voltage, and power setpoints. This raw data payload is usually an uninterpreted byte array, which will be passed to the parameter separation and mapping unit 1012 for further semantic parsing.

[0068] The parameter separation and mapping unit 1012 is used to extract the specific environmental and operating parameters of each target device from the original data payload, and convert the device identifier and data format of the environmental and operating parameters into the preset unified format of the automation system according to the preset standard parameter mapping relationship table to obtain the intermediate parameter set.

[0069] The original data payload refers to the raw byte block containing multiple parameters obtained after unpacking by the communication message parsing unit 1011. The target device-specific environment and operating parameters refer to the parameters in the original data payload, represented in their unique ways (such as register addresses, offsets, and data types) according to different device manufacturers or protocol definitions. The preset standard parameter mapping table is a configuration library that defines the correspondence from device-specific parameter identifiers (such as register 40001) to system-wide unified parameter names (such as BatteryTemperature), as well as data type conversion rules. Device identification and data format conversion refers to unifying the parameter names and their binary representations to the internal standard of the automation system. The intermediate parameter set refers to the set of parameters that have undergone parameter identification and format unification, but whose physical units may not yet be aligned.

[0070] Specifically, the parameter separation and mapping unit 1012 loads a corresponding preset standard parameter mapping table based on the type of the target device. This table specifies which system parameter (e.g., ambient temperature) is represented at which position in the original data payload (e.g., starting from the second byte, with a length of 4 bytes) and in what data type (e.g., a 32-bit floating-point number). The binary values ​​of each parameter are extracted from the original data payload according to the mapping table, and tagged with a unified system name defined in the table. Simultaneously, data format conversion is handled, such as converting a 16-bit unsigned integer in the Modbus protocol to a 64-bit floating-point number used internally by the system. After processing by this unit, the originally mixed parameters, strongly correlated with specific devices, are separated, identified, and formatted into a structured set of intermediate parameters, where each parameter has a unified name and data type.

[0071] In some embodiments, the parameter separation and mapping unit can be implemented in several ways: Optionally, it can be implemented through database-based mapping configuration. First, the parameter mapping relationships of all devices are stored in a table in a relational database. The table fields include device model, original parameter address / offset, data type, byte order, system standard parameter name, etc. Second, when the unit is working, it first queries the database based on the target device model to obtain a complete set of mapping rules and builds a mapping table in memory. Finally, it iterates through each rule in the mapping table and performs the corresponding extraction and type conversion operations on the original data payload. Optionally, it can also be implemented based on an object-oriented plug-in adapter. First, an independent adapter plug-in (e.g., a class file) is developed for each type of device. The parameter separation and mapping logic for that device is hard-coded or implemented through a configuration file in the plug-in class. Second, the unit dynamically loads and instantiates the corresponding adapter object according to the type of the target device through a factory pattern or dependency injection. Finally, it calls the unified interface method of the adapter object, which internally completes all specific parsing and mapping work and returns an intermediate parameter set.

[0072] The dimensional alignment unit 1013 is used to perform numerical conversion and alignment on the numerical data with physical unit differences in the intermediate parameter set according to the preset benchmark unit conversion rules, and use the aligned parameter set as the standardized input.

[0073] The preset benchmark unit conversion rules refer to a configuration library that defines standard units for various physical quantities (e.g., temperature in degrees Celsius, pressure in Pascals) and conversion formulas between different units (e.g., Fahrenheit to Celsius, bar to Pascals). The intermediate parameter set refers to a set generated by the parameter separation and mapping unit 1012, where parameter names and formats are standardized, but physical units are not yet standardized. Physical unit differences refer to the fact that the same physical quantity may be measured in different units on different devices or request sources, such as kilometers per hour versus meters per second. Numerical conversion and alignment refers to the process of unifying the values ​​of all parameters to the benchmark unit according to the conversion rules. The aligned parameter set is the final standardized input, which can be directly used for subsequent logical judgments.

[0074] Specifically, after the parameter separation and mapping unit 1012 generates the intermediate parameter set, the dimensional alignment unit 1013 immediately begins its work. At this point, although all parameters have a unified name and data type, the physical units represented by their values ​​may still be inconsistent. For example, one device reports a temperature in Fahrenheit, while another device reports in Celsius, but both are labeled as temperatures in the system. Without unit unification, subsequent rule judgments (such as temperature < 50°C) will produce ambiguity and errors. Therefore, the dimensional alignment unit eliminates these dimensional differences. The dimensional alignment unit traverses each numerical data with a physical unit in the intermediate parameter set and queries a preset base unit conversion rule. This rule base specifies the base unit for each parameter and the mathematical formula for converting from other units to the base unit. The dimensional alignment unit applies these formulas to calculate the values. After processing all parameters that need to be converted, all values ​​in the final parameter set have a unified physical meaning. This set is the standardized input that the rule matching module 102 can directly use.

[0075] Please refer to the following: Figure 3 This is a schematic diagram of the rule matching module of the physical execution access control device in the embodiments of this application.

[0076] Rule matching module 102 includes:

[0077] The time-sensitivity feature extraction unit 1021 is used to extract the initial network timestamp when the physical execution request was generated from the standardized input.

[0078] The standardized input refers to the unified data packet generated by the rule loading module 101, which contains all the parameters required for processing. The initial network timestamp when the physical execution request is generated is used to indicate the precise moment when the request was created and prepared to be sent at its source (such as a sensor or host computer). This timestamp is usually added by the request initiator when generating the request and is included in the request as one of the parameters.

[0079] Specifically, after the rule matching module 102 receives the standardized input, the timeliness feature extraction unit 1021 searches for and reads the specific field that is conventionally designated as the initial network timestamp from the standardized parameter set. The value of this field may be a Unix timestamp, a date and time string in ISO 8601 format, or other conventional time representation format. This unit is responsible for parsing this value and converting it into a system-wide unified time object or numerical value for subsequent time calculations.

[0080] The time difference calculation unit 1022 is used to obtain the current system timestamp and calculate the time difference between the current system timestamp and the initial network timestamp.

[0081] The system current timestamp refers to the instantaneous time reading obtained by this device from its operating system or hardware clock when performing the specific operation of time difference calculation. The initial network timestamp refers to the original generation time of the physical execution request extracted by the timeliness feature extraction unit 1021. The time difference refers to the interval between the system current timestamp and the initial network timestamp. This difference directly reflects the total time elapsed from the generation of the request to its processing, including network transmission delay, system queuing delay, etc.

[0082] Specifically, after the timeliness feature extraction unit 1021 successfully obtains the initial network timestamp of the physical execution request, the time difference calculation unit 1022 first calls the system-level time service to obtain a current time, i.e., the system's current timestamp. Then, it subtracts this current timestamp from the initial network timestamp obtained in the previous step. To improve the accuracy of the calculation, the two timestamps are standardized to the same format and unit (e.g., all converted to milliseconds in UTC time) before the calculation. The difference obtained from the calculation is a quantized time span, such as 350 milliseconds.

[0083] The forced interception control unit 1023 is used to determine whether the time difference is greater than the effective survival time threshold when the target rule object has an embedded effective survival time threshold. If it is, it determines that the physical execution request has a network delay, skips the judgment of other environment and operation parameters in the target rule object, and directly outputs the sub-matching result of the blocking state; if not, it judges and outputs according to the original logical conditions of the target rule object.

[0084] The "Embedded Effective Lifetime Threshold" in the target rule object refers to certain time-sensitive rules that include a parameter in their definition to set the maximum allowed delay time from request generation to processing, such as 100 milliseconds. "Time Difference" refers to the actual delay of the request calculated by the time difference calculation unit 1022. "Network Lag" means that the actual delay of the request exceeds its acceptable maximum delay. "Skipping Other Environmental and Operational Parameter Judgments" means that after confirming that the request has timed out, the judgments regarding other business conditions such as temperature and pressure defined in the rule object will not be executed to improve efficiency. "Blocking Sub-Matching Result" means that the current rule is directly determined to be invalid, and a result indicating blocking is generated.

[0085] Specifically, after the time difference calculation unit 1022 outputs the time difference value, the forced interception control unit 1023 first checks the target rule object currently being matched to see if it defines a valid time-to-live (TTL) threshold. If the rule object does not have this setting, this unit does not perform any operation, and the process proceeds normally to the original parameter judgment logic of the rule object. If the rule object sets a TTL threshold (e.g., TTL=200ms), this unit compares the actual time difference value calculated in the previous step (e.g., 350ms) with this threshold. If the time difference value is greater than the threshold, it is determined that the physical execution request has lost its timeliness due to network transmission or system processing delays, and executing it may bring risks. At this time, the target rule object is forced to output a blocking sub-matching result, and the remaining judgment logic in the rule object is not executed. If the time difference value does not exceed the threshold, the judgment and output are performed according to the original logic conditions of the target rule object.

[0086] Please refer to the following: Figure 4 This is a schematic diagram of the rule conflict handling module of the physical execution admission control device in this application embodiment.

[0087] Rule conflict handling module 103 includes:

[0088] The tag parsing unit 1031 is used to extract the tag type carried by the target rule object of the output blocking state when there is at least one blocking state in the preliminary result set. Each target rule object in the preset rule base carries a core rule tag, a domain rule tag, or an exception rule tag.

[0089] Here, label type refers to the classification mark pre-assigned to each target rule object to indicate its nature and priority. Core rule labels represent the highest priority rules that concern fundamental system safety and cannot be exempted under any circumstances, such as physical device limits and prohibitions on simultaneous charging and discharging. Domain rule labels represent general constraints under specific business scenarios, with lower priority than core rules; for example, in economy mode, charging power cannot exceed 50kW. Exception rule labels represent special release rules that can exempt certain domain rules under specific conditions, such as allowing over-power discharge in emergency fire mode.

[0090] Specifically, the tag parsing unit 1031 traverses the preliminary result set to locate sub-matching results in the blocking state. For each such result, it determines the target rule object that generated the result and reads the tag type carried by that object. Simultaneously, to handle potential exceptions, it can also check whether there are any allowing results generated by rule objects carrying exception rule tags. For example, a result set might be: {Core Rule A: Allow, Domain Rule B: Block, Exception Rule C: Allow}. The tag parsing unit's job is to parse out the blocking caused by a domain rule and the allowing caused by an exception rule in this set. The parsed tag type information, such as core, domain, and exception, will be passed to the subsequent core priority blocking unit 1032 and exception exemption unit 1033 for decision-making.

[0091] The core priority blocking unit 1032 is used to directly block all allowed states in the preliminary result set if the extracted label type contains a core rule label, and output a single decision result representing refusal to execute.

[0092] Among them, the tag type containing the core rule tag means that after analyzing all the rules that caused the blocking, the tag parsing unit 1031 found that at least one rule was marked as a core rule. Masking all allowed states in the preliminary result set means ignoring any possible allowed results generated by other rules (whether domain rules or exception rules).

[0093] Specifically, after the label parsing unit 1031 completes the parsing of each rule label in the preliminary result set, the core priority blocking unit 1032 checks the label type set extracted by the label parsing unit. As long as a core rule label appears in this set, regardless of the type of other blocking rules or whether any exception rules have generated a pass state, its highest priority blocking logic will be immediately triggered, directly blocking all pass state sub-matching results in the preliminary result set without granting any exemption. Subsequently, a single decision result representing rejection is output. Simultaneously, rule source information records which core rule(s) caused this blocking.

[0094] The exception exemption unit 1033 is used to shield the original blocking state and output a single decision result representing conditional release when the extracted tag type is only a domain rule tag and the preliminary result set also contains a release state output by the target rule object carrying the exception rule tag. The identification data of the target rule object that outputs the release state is recorded as new rule tracing information.

[0095] Specifically, when the conditions of the core priority blocking unit 1032 are not met (i.e., no core rule is triggered for blocking), the processing flow enters the exception exemption unit 1033. The exception exemption unit first confirms that all triggered blocking rules are simply domain rules. Then, it checks the preliminary result set to see if there is a release state result generated by an exception rule. If both conditions are met simultaneously, an exemption scenario is formed. For example, a domain rule states that discharge is prohibited when the battery SOC is below 20% (blocking), but an exception rule states that discharge to 10% is allowed when a grid-level dispatch instruction is received (release). In this case, the exception exemption unit performs a masking operation, ignoring the blocking state generated by the domain rule and adopting the release state of the exception rule. The exception exemption unit outputs a single decision result representing the condition for release. It also updates the rule tracing information, recording the identifier data of the exception rule that caused the release, rather than recording the exempted domain rule, so that the audit log can reflect that the decision is based on a special exemption condition, rather than a regular condition. If there is no exception rule to allow passage, or if the blocking rule contains a non-domain rule, the exception exemption unit will not work.

[0096] In some embodiments, the rule tracing information record not only retains the target rule object identifier in the output blocking or allowing state, but also establishes a corresponding binding relationship with the target rule object identifier data involved in this judgment, the standardized input parameter summary that triggered the judgment, and the final single decision result. Therefore, when the target execution boundary or subsequent audit module receives the objectified authorization certificate, it can not only confirm whether the current physical execution request is allowed or blocked, but also trace, based on the rule tracing information, rule baseline feature sequence, and input parameter summary, which version, which set of rule objects, and under what standardized input conditions the conclusion was formed. This corresponding binding relationship ensures that subsequent execution boundary verification, version difference tracing, and hot synchronization operations are based on verifiable rule bases, rather than simple Boolean control values ​​or local logs, thereby improving the causal tracing capability of this physical execution access control device.

[0097] Please refer to the following: Figure 5 This is a schematic diagram of the authorization credential generation module of the physical execution access control device in this application embodiment.

[0098] The authorization credential generation module 104 includes:

[0099] The hash feature calculation unit 1041 is used to call a preset hash algorithm, and after normalizing and combining the identification data and version number of each target rule object participating in the matching according to the preset sorting rules, perform hash operation on the combined data to generate a string of hash characters of fixed length as the rule base feature sequence.

[0100] The preset hash algorithm refers to an algorithm that can convert input data of arbitrary length into a fixed-length output string through a deterministic mathematical operation, such as SHA-256 and MD5. Its characteristic is that small changes in the input data can lead to significant differences in the output results. The identifier data and version number of each target rule object participating in the matching refer to the unique identity (such as rule ID, rule name, or rule code) of each rule called by the rule matching module 102 during this decision-making process, as well as their current version identifier. The preset sorting rule refers to a pre-determined combination order (such as ascending lexicographical order of rule IDs), which ensures that for the same set of rules, the generated feature sequence is unique and deterministic, preventing attackers from circumventing verification by changing the combination order. Hash operation refers to the process of executing the hash algorithm.

[0101] Specifically, when the authorization credential generation module 104 prepares to encapsulate the credential, the hash feature calculation unit first collects the identification data and version numbers of all target rule objects participating in the matching process. Then, this concise metadata information is combined and concatenated in a predetermined order. For example, it can be sorted alphabetically by rule ID, and then the identification data and version number (e.g., Rule_ID_001_v2.0) of each rule are concatenated into a lightweight structured string. Next, this concatenated input is fed into a preset hash algorithm for calculation. After the algorithm executes, it outputs a fixed-length hash string. This output feature sequence retains the core traceability and verification capabilities of which rules participated in the decision (using identification data to prevent rule discrepancies) and what version was used (using the version number to prevent replay of older versions), while avoiding a large rule base storage and heavy hash comparison computational burden on the downstream execution boundary. After this sequence is generated, it is passed to the cryptographic signature encapsulation unit 1042 for subsequent credential encapsulation.

[0102] The encryption signature encapsulation unit 1042 is used to tightly concatenate a single decision result, rule traceability information and rule benchmark feature sequence into a plaintext data payload, and use the private key of the automated system to perform a digital signature operation on the plaintext data payload to generate an objectified authorization certificate.

[0103] In this context, the plaintext data payload refers to the raw data body where these three parts of information are concatenated according to a specific format (such as JSON), but before encryption or signing. The private key of the automated system is a non-public key held and kept only by this automated system, used for digital signature operations. It corresponds to a publicly available key used for signature verification. The digital signature operation is the process of encrypting the hash value of the plaintext data payload using the private key. The result (i.e., the digital signature) proves that the data payload was indeed issued by the holder of the private key and has not been tampered with during transmission. The objectified authorization credential refers to the final generated complete data packet containing the plaintext data payload and the digital signature.

[0104] Specifically, the encryption signature encapsulation unit 1042 concatenates a single decision result (e.g., granting permission), rule source information (e.g., {rule ID: EXC-001}), and a rule baseline feature sequence (e.g., a long string of hash values) into a structured plaintext data payload, such as a JSON object. Then, a hash operation is performed on this plaintext data payload to obtain a digest. Next, the unit calls a cryptography library and uses a pre-configured private key belonging to this automated system to encrypt this digest; the encrypted result is the digital signature. Finally, the original plaintext data payload and the generated digital signature are combined to form the final objectified authorization credential. The typical format is to Base64 encode the plaintext data payload and then concatenate it with the similarly encoded signature using a delimiter. This credential is both readable (after decoding the payload) and secure (with a signature available for verification).

[0105] In some embodiments, to further enhance tamper resistance, the cryptographic signature encapsulation unit 1042 can extract preset key numerical attributes from the standardized input to generate a core parameter digest, and encapsulate this digest along with a single decision result, rule tracing information, and rule baseline feature sequence into a structured data payload (e.g., JSON or XML format). Subsequently, a digital signature is generated using the asymmetric encryption private key of the automated system. Finally, the plaintext data and signature are combined in a preset encoding format (e.g., Base64) to form the final objectified authorization credential. This credential not only informs downstream actions but also binds the complete logical chain of input parameters, adjudication rules, and output conclusion.

[0106] Please refer to the following: Figure 6 This is a schematic diagram of the execution boundary verification module of the physical execution access control device in the embodiments of this application.

[0107] The boundary verification module 105 includes:

[0108] The credential decomposition unit 1051 is used to extract the embedded rule baseline feature sequence after receiving the objectified authorization credential at the target execution boundary.

[0109] Specifically, when an object-based authorization credential arrives at the target execution boundary via network or inter-process communication, the credential decomposition unit 1051 parses its embedded rule baseline signature sequence according to the format specification of the object-based authorization credential. For example, if the credential is a JSON object, the unit parses the JSON string and looks for a field named `rule_baseline_signature` or a similarly agreed-upon key name, reading its value. If the credential is a custom binary format, it reads a fixed-length byte sequence starting from a pre-agreed byte offset. This read value is the rule baseline signature sequence calculated when the authorization credential was generated.

[0110] The string comparison unit 1052 is used to read the current global rule feature sequence of the target execution boundary local cache and compare the extracted rule baseline feature sequence with the global rule feature sequence character by character.

[0111] Specifically, after the credential decomposition unit 1051 extracts the rule baseline feature sequence from the objectified authorization credential, the string comparison unit 1052 reads the currently effective global rule feature sequence from a reliable local storage location at the execution boundary (e.g., a read-only memory region, a specific sector of flash memory, or a protected configuration file). This sequence is calculated and distributed to all execution boundaries by the system after the most recent rule deployment or update. The unit then performs a character-by-character comparison between this local standard sequence and the credential claim sequence extracted from the credential.

[0112] The physical response control unit 1053 is used to determine the validity of the rule version when the strings of the two are completely identical, and to trigger a physical response based on a single decision result; when there is a character inconsistency, the decision execution basis has the risk of replaying an old version or rule disconnection, and the physical response is blocked.

[0113] Specifically, after the string comparison unit 1052 outputs the comparison result, the physical response control unit 1053 takes the final action based on this result. This is a binary decision-making process. If the comparison result is consistent, the physical response control unit determines that the received objectified authorization credential is valid and timely, and continues to parse the single decision result field in the credential. If the decision result is to allow or permit, the physical response control unit calls the underlying hardware driver interface to send the corresponding control signal to the physical device (such as a relay or motor controller) to trigger the expected physical action. If the decision result is to block or deny, no operation is performed, which is equivalent to maintaining the status quo. If the comparison result is inconsistent, the physical response control unit determines that the credential is invalid and considers that executing the instruction poses a significant security risk. In this case, the single decision result in the credential is ignored—even if the result is to allow, it will be disregarded. The physical response control unit will directly execute the blocking strategy to ensure that the physical device does not respond to the execution request and issue a high-priority security alarm to the monitoring system, reporting this version mismatch event.

[0114] Furthermore, in order to improve the robustness of the automation system, in some embodiments, the execution boundary verification module 105 may also include a functional unit for automatic version alignment after executing the blocking.

[0115] When the physical response control unit 1053 determines to block a physical response due to inconsistency in the feature sequence, a difference tracing and extraction unit is activated. This unit extracts the outdated global rule feature sequence that is still resident in the local memory or cache of the target execution boundary and caused the comparison failure. Subsequently, a version alignment request unit combines this local outdated sequence with the new sequence carried by the credential extracted from the credential into a structured version difference request packet. This request packet is sent back to a centralized version management node in the automation system. This request packet informs the management node: my version is the old A, and I expect the new version B. After receiving this request, the version management node identifies the version difference and responds to the request by issuing an incremental difference rule logic containing only the changes required from version A to version B. After receiving this incremental rule logic at the target execution boundary, the controlled hot synchronization unit writes this incremental logic into the local rule storage area while maintaining the current physical circuit breaker state (i.e., continuously blocking any physical response), thus completing the hot update of the local rule base. After the update is complete, the operation of retrieving the global rule feature sequence is triggered again (this time the retrieved sequence should be consistent with the new version of the voucher), and then compared character by character with the sequence in the voucher again. If the comparison matches, the subsequent process can be executed normally based on a single decision result, thus completing a more secure automatic version synchronization and recovery without manual intervention.

[0116] In some embodiments, in order to make the update process of the preset rule base smoother and without interrupting the service, the device may also include a rule base hot deployment module.

[0117] Specifically, the rule base hot deployment module may include a backup storage area construction unit, a background loading unit, and an atomic switch trigger unit.

[0118] The backup storage area construction unit is responsible for allocating two logically isolated storage areas in memory or high-speed storage when the system starts up: one as the working storage area for currently providing services, and the other as the backup storage area. The online rule loading and rule matching modules always read rule objects from the working storage area. When the system receives a rule update instruction (e.g., an administrator publishes a new version of a rule through the backend), the backend loading unit pre-loads and fully writes the new rule object, carrying the new version number, into the idle backup storage area. This loading process occurs silently in the background and does not affect normal read / write operations in the working storage area. The atomic switch triggering unit continuously and with low power monitors the concurrent processing status of the rule matching module. For example, it can monitor system metrics such as the global request processing counter, CPU load threshold, active number of rule matching thread pools, or message queue pending length. When the above metrics are detected to be below preset thresholds, indicating that the system has entered a processing idle period (e.g., no new requests for a continuous period or the queue is cleared), an atomic pointer or reference switch operation is immediately executed, switching the system's access to the rule base from the working storage area to the backup storage area. At this point, the standby storage area immediately becomes the new working storage area, while the original old working area becomes an idle standby area, awaiting the next update. Simultaneously with this atomic switch, the atomic switch triggering unit synchronously triggers the automated system to recalculate and update the currently valid global rule feature sequence, and distributes this new global sequence to all execution boundaries, ensuring that the entire system's rule version awareness is refreshed at the same time.

[0119] Furthermore, in some embodiments, to meet the high security requirements of industrial or automotive-grade high-consequence systems, heterogeneous computing and hardware-level security involved in this device can also be supported. For example, the authorization credential generation module 104 and the execution boundary verification module 105 can be deployed in a trusted execution environment within a microprocessor or in a separate security chip. The high-frequency hash operations involved in the hash feature calculation unit and the cryptographic operations in the encrypted signature encapsulation unit can be accelerated using field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), further improving the system's processing throughput and its ability to resist side-channel attacks.

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

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

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

[0123] 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 physical execution admission control device based on rule objectification, characterized in that, include: The rule loading module is used to receive physical execution requests for target devices, match target rule objects associated with the physical execution requests in a preset rule base, and convert the environment and operating parameters in the physical execution requests into standardized inputs; The rule matching module is used to input the standardized input to each of the target rule objects for judgment, and output sub-matching results containing the allow state or the block state to obtain a preliminary result set; The rule conflict handling module is used to parse the preliminary result set. When there is at least one blocking state, the allowing state in the preliminary result set is masked, a single decision result is output, and the identification data of the target rule object that outputs the blocking state is extracted as the rule tracing information record. The authorization credential generation module is used to combine the version number and identification data of each target rule object to generate a rule baseline feature sequence, and encapsulate the single decision result, the rule tracing information and the rule baseline feature sequence into an object-oriented authorization credential; The execution boundary verification module is used to issue the objectified authorization credential to the target execution boundary, so that the target execution boundary extracts the rule baseline feature sequence and verifies it with the global rule feature sequence currently running in the automation system. If they match, a physical response is triggered according to the single decision result; if they do not match, the physical response is blocked.

2. The physical execution access control device according to claim 1, characterized in that, It also includes a rule sandbox pre-validation module, specifically including: The test data extraction unit is used to take the historical physical execution request data that was intercepted or released by the automation system within a preset historical time period as the test input set, and extract the historical judgment result corresponding to each piece of data in the test input set under the original rules of the automation system. The shadow environment playback unit is used to load the target rule object to be launched into a preset shadow test sandbox that is not connected to a physical execution peripheral, and input the data in the test input set one by one into the target rule object for judgment, so as to obtain the simulated test run results output by the target rule object for each data. The state reversal restriction unit is used to count the number of data entries that have undergone state reversal based on the simulated trial operation results and the historical judgment results. When the number of data entries that were originally allowed but became blocked exceeds a preset excessive blocking threshold, or when the number of data entries that were originally blocked but became allowed exceeds a preset dangerous release threshold, it outputs a prohibition loading command and refuses to write the target rule object to be launched into the preset rule library; when neither exceeds the corresponding threshold, the target rule object to be launched is written into the preset rule library.

3. The physical execution access control device according to claim 2, characterized in that, The rule sandbox pre-validation module also includes: The asset grading and analysis unit is used to pre-obtain the asset importance rating attributes for the target equipment, and convert the asset importance rating attributes into strictness weighted coefficients according to a preset importance mapping table. The dynamic threshold configuration unit is used to collect the basic processing throughput of the automated system within the preset historical time period, and, in combination with the strictness weighting coefficient, to perform weighted calculations on the preset baseline interception deviation value and the preset baseline release deviation value to obtain the preset excessive blocking threshold and the preset dangerous release threshold under the current operating cycle.

4. The physical execution access control device according to claim 1, characterized in that, The rule loading module specifically includes: The communication message parsing unit is used to unpack the physical execution request according to a preset communication protocol to obtain the original data payload containing service attributes. The parameter separation and mapping unit is used to extract the specific environment and operating parameters of each target device from the original data payload, and convert the device identifier and data format of the environment and operating parameters into the preset unified format of the automation system according to the preset standard parameter mapping relationship table to obtain the intermediate parameter set. The dimensional alignment unit is used to perform numerical conversion and alignment on the numerical data with physical unit differences in the intermediate parameter set according to the preset benchmark unit conversion rules, and use the aligned parameter set as the standardized input.

5. The physical execution access control device according to claim 1, characterized in that, The rule matching module specifically includes: The timeliness feature extraction unit is used to extract the initial network timestamp when the physical execution request was generated from the standardized input; The time difference calculation unit is used to obtain the current system timestamp and calculate the time difference between the current system timestamp and the initial network timestamp; The forced interception control unit is used to determine whether the time difference is greater than the effective survival time threshold when the target rule object has an embedded effective survival time threshold. If it is, the physical execution request is determined to have a network delay, and other environmental and operating parameter judgments in the target rule object are skipped, and the sub-matching result of the blocking state is directly output. If not, the judgment and output are performed according to the original logical conditions of the target rule object.

6. The physical execution access control device according to claim 1, characterized in that, The rule conflict handling module specifically includes: The tag parsing unit is used to extract the tag type carried by the target rule object of the blocking state when at least one blocking state exists in the preliminary result set. Each target rule object in the preset rule base carries a core rule tag, a domain rule tag, or an exception rule tag. The core priority blocking unit is used to directly block all allowed states in the preliminary result set and output the single decision result representing refusal to execute if the extracted label type contains the core rule label. The exception exemption unit is used to shield the original blocking state and output the single decision result representing conditional release when the extracted tag type is only the domain rule tag and the preliminary result set simultaneously contains a release state output by the target rule object carrying the exception rule tag, and to record the identification data of the target rule object that outputs the release state as new rule tracing information.

7. The physical execution access control device according to claim 1, characterized in that, The authorization credential generation module specifically includes: The hash feature calculation unit is used to call a preset hash algorithm, and after normalizing and combining the identification data and version number of each target rule object participating in the matching according to a preset sorting rule, perform a hash operation on the combined data to generate a string of hash characters of fixed length as the rule base feature sequence. The encryption signature encapsulation unit is used to tightly concatenate the single decision result, the rule tracing information, and the rule benchmark feature sequence into a plaintext data payload, and use the private key of the automated system to perform a digital signature operation on the plaintext data payload to generate the objectified authorization certificate.

8. The physical execution access control device according to claim 1, characterized in that, The execution boundary verification module specifically includes: The credential decomposition unit is used to extract the embedded rule baseline feature sequence after the objectified authorization credential is received at the target execution boundary; The string comparison unit is used to read the current global rule feature sequence of the target execution boundary local cache, and compare the extracted rule baseline feature sequence with the global rule feature sequence character by character; The physical response control unit is used to determine the validity of the rule version when the strings of the two are completely identical, and to trigger a physical response based on the single decision result; when there is a character inconsistency, it determines that there is a risk of replaying an old version or rule disconnection, and blocks the physical response.

9. The physical execution access control device according to claim 8, characterized in that, The execution boundary verification module also includes: The difference tracing and extraction unit is used to extract the outdated rule feature sequence that still resides in the local memory of the target execution boundary after the physical response control unit determines that there is a character inconsistency and blocks the physical response; The version alignment request unit is used to combine the outdated rule feature sequence with the rule baseline feature sequence extracted by the credential disassembly unit into a version difference request packet, and send it in reverse to the version management node built into the automation system. The controlled hot synchronization unit is used to write the incremental difference rule logic into the local machine while maintaining the current physical disconnection state, based on the incremental difference rule logic issued by the version management node in response to the version difference request packet, and to re-initiate the pull and character-by-character comparison operation for the global rule feature sequence.

10. The physical execution access control device according to claim 1, characterized in that, It also includes a rule base hot deployment module, specifically including: The standby storage area construction unit is used to configure a standby storage area within the system storage space that is isolated from the current working storage area of ​​the preset rule base; The background loading unit is used to preload and write the target rule object carrying the new version number into the backup storage area when a target rule update instruction is received; The atomic switching trigger unit is used to monitor the concurrent processing status of the rule matching module in real time. When the system detects an idle period, it switches the backup storage area to the effective working storage area and simultaneously triggers the automation system to update the currently effective global rule feature sequence.

Images