A smart park risk identification method and system based on operation association rules

Abstract

This invention discloses a method and system for identifying risks in smart parks based on operational association rules, specifically relating to the field of smart park risk identification technology. The method includes collecting and aligning the operational rules, permission configurations, and action logs of each subdomain of the smart park with data; constructing a digital twin operational state that corresponds one-to-one with the current real operational state of the park; and outputting a rule table and baseline weights based on the digital twin operational state. The rule table includes at least a rule identifier, a trigger field, an action field, and an object identifier. The baseline weights characterize the initial set of reachable permissions corresponding to the object identifier. By modeling the continuous execution relationship between operational rules in multiple subdomains without changing existing permission configurations or triggering the execution of real system rules, and by deduce and compare the permission evolution process under the continuous action of rules in the digital twin operational state, the method identifies the implicit authorization penetration risk accumulated from multiple legitimate operational rules.

Description

Technical Field

[0001] This invention relates to the field of smart park risk identification technology, and more specifically, to a smart park risk identification method and system based on operational association rules. Background Technology

[0002] In existing smart park operation and management technologies, in order to automate the processing of business such as personnel access, equipment maintenance, energy consumption scheduling and safety linkage, the method of configuring operation rules and access control in subsystems is usually adopted. Each subsystem executes corresponding actions according to preset conditions and completes cross-system collaboration through linkage mechanisms. In engineering practice, this approach mainly solves the problem of a single system being able to respond correctly to the operating status according to the rules within the given permission scope. In practical applications, such as during the nighttime operation of large parks, it is often necessary to simultaneously enable multiple operating rules, such as temporary visitor access, remote access for inspection personnel, switching of equipment maintenance strategies, and relaxation of security strategies. It is also required to maintain continuous operation of the park throughout the process, without introducing manual intervention or frequently adjusting existing permission configurations. Under the above constraints, a stable phenomenon can be observed: each subsystem performs normally in terms of rule execution and permission verification, and the triggering result of a single rule also meets the design expectations. However, after multiple rules take effect continuously according to the established process, some personnel or equipment actually have the ability to operate on originally restricted resources or key objects within a specific time period. This capability does not originate from the violation of a single rule, but rather from the cumulative effect of multiple rules being triggered consecutively in different systems. Existing technologies typically only verify a single rule trigger or a single system's permission status, lacking the ability to identify and judge the overall authorization changes resulting from the continuous action of cross-system rules. Consequently, such risks can only be indirectly discovered after the fact through incidents or abnormal results. Therefore, the technical problem to be solved by this application is how to identify the implicit authorization penetration risk formed by the continuous action of multiple legitimate operating rules while the smart park is operating normally and the existing permission rules remain unchanged. Summary of the Invention

[0003] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a smart park risk identification method and system based on operational association rules. By modeling the continuous execution relationship between multi-subdomain operational rules without changing the existing permission configuration and without triggering the execution of real system rules, and by deduce and compare the permission evolution process under the continuous action of rules in the digital twin operational state, the implicit authorization penetration risk formed by the accumulation of multiple legal operational rules can be identified.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a smart park risk identification method based on operational association rules, comprising: S1. Collect and align the operation rules, permission configurations and action logs of each subdomain of the smart park with fields, construct a digital twin operation state that corresponds one-to-one with the current real operation state of the park, and output a rule table and a baseline weight based on the digital twin operation state. The rule table includes at least a rule, trigger field, action field and object identifier. The baseline weight is used to characterize the initial set of achievable permissions corresponding to the object identifier in the current real operation state. S2. Without triggering the execution of real system rules, perform the calculation of the connection between the trigger field and the action field of the rule table. With the rule as the point and the connection relationship as the edge, and each edge associated with the action field of the preceding rule and the trigger field of the subsequent rule, output a chain graph to represent the continuous execution relationship of the rules. S3. In the digital twin's operational state, perform edge-by-edge propagation calculations on the baseline weights based on the chain graph, simulate the continuous triggering process that may occur in the real operating environment, record the object identifier, rule, incoming weight, outgoing weight and trigger time for each rule, and output the ledger. S4. Perform reachability set calculation on the outgoing directions recorded in the ledger. Compare the final outgoing direction corresponding to each object identifier with the initial reachable permission set corresponding to the base permission direction item by item. Identify permission items that exist in the final outgoing direction but not in the initial reachable permission set, and output the outbound permission items. S5. When there is an out-of-boundary weight, perform backtracking calculation on the records in the ledger corresponding to the out-of-boundary weight in reverse order of the trigger time to determine the standard sequence that forms the out-of-boundary weight and the corresponding edge relationship, output the penetration path, and output the smart park operation risk identification result based on the penetration path to indicate the potential authorized penetration risk in the real operating environment.

[0005] In a preferred embodiment, S1 includes: S1-1. Extract the object identifier field from the operation rules, permission configurations and action logs collected from each subdomain of the smart park, and construct a candidate set of object identifiers; Perform key-value normalization on the candidate set of object identifiers and generate an object identifier alignment key, wherein the object identifier alignment key is formed by concatenating the subdomain identifier, the object type field and the object original identifier field; When the same object identifier alignment key corresponds to multiple object original identifiers in different subdomains, an object identifier conflict record is written and the corresponding object identifier alignment key is marked as inconsistent; otherwise, the object identifier alignment key and the corresponding object original identifier are written into the object identifier alignment table and marked as consistent, and the object identifier alignment table is output. S1-2. Based on the object identifier alignment table, extract the field name, field type and field value range from the trigger field and action field in the running rule to form the trigger field set and the action field set; Perform field matching calculations on the trigger field set and the action field set to generate a field mapping table, wherein the field matching calculations include: When the trigger field name and the action field name are the same and the field types are the same, it is determined that the name matches and the types match; otherwise, when the trigger field name and the action field name are different, the name equivalence relationship is determined based on the preset field synonym comparison set, and the field type consistency relationship is determined when the name equivalence is established; when the name matches or the name is equivalent and the field types are the same, the comparability determination is further performed on the value range of the trigger field and the value range of the action field. When there is a non-empty intersection between the two, they are marked as semantically comparable and written to the field mapping table; otherwise, they are marked as semantically incomparable and written to the field exclusion record. Output the field mapping table, which is used to record the correspondence between the trigger field and the action field.

[0006] In a preferred embodiment, S1 further includes: S1-3. Based on the field mapping table, extract the rule identifier from the running rules to generate the rule identifier. The rule identifier is formed by concatenating the subdomain identifier, the rule name field and the rule version field and is written into the rule table. Perform association matching between the action log and the rule identifier according to the object identifier alignment key, map the actual action result field recorded in the action log to the corresponding action field in the rule table, and output the rule action mapping record; The trigger satisfaction determination is performed on the rule action mapping record. The trigger satisfaction determination includes: locating the trigger field corresponding to the action result field based on the field mapping table, reading the value conditions of the trigger field and performing condition validation on the action result field. When the condition validation passes, the rule identifier and object identifier are aligned and written into the established record and marked as established; otherwise, an invalid record is written and marked as invalid. The set of established rule records is output. S1-4. Based on the rule-established record set, extract the corresponding establishment marker for each rule identifier as a trigger state, and summarize the associated rule identifiers and corresponding trigger states for each object identifier by alignment key. Perform state aggregation calculation to output the digital twin running state, wherein the state aggregation calculation includes: For multiple rule records that are true within the same time window with the same object identifier alignment key, deduplication and merging are performed, and the latest trigger time is retained. Different rule identifiers corresponding to the same object identifier alignment key are sorted by trigger time to form a rule status sequence. The rule status sequence is written into the digital twin runtime state, which includes at least the rule identifier, the object identifier alignment key, and the rule status. S1-5. Based on the digital twin's operational state, extract the set of rule identifiers in the corresponding rule state sequence for each object identifier alignment key, where the rule is established, and read the set of permission change items corresponding to the rule identifier set based on the rule table. Perform a union calculation on the set of permission change items and the permission grant range corresponding to the alignment key of the object identifier in the permission configuration to output the reachable permission set. The union calculation includes: writing the permission grant range into the initial permission set, writing the newly added permission items in the set of permission change items into the initial permission set and removing duplicate items; the output is a baseline weight that represents the initial reachable permission set of the object identifier in the current real running state.

[0007] In a preferred embodiment, S2 includes: S2-1. Taking the rule table as input, read the corresponding action field list for each rule in the rule table and form a rule action field pair. At the same time, read the corresponding trigger field list and form a rule trigger field pair. Output the rule action field pair set and the rule trigger field pair set. S2-2. Based on the set of action field pairs and the set of trigger field pairs of the standard, perform pairwise combination calculations for any two different standards, and select the action field of the first standard and the trigger field of the second standard as the field pair to be judged; for the field pair to be judged, check whether there is a field correspondence according to the field mapping table, and if there is a field correspondence, further read the value range of the corresponding action field and trigger field, perform the intersection calculation of the value range, and when the intersection is not empty, determine that the first standard and the second standard can be connected; S2-3. When it is determined that the first standard mark and the second standard mark can be connected, a connection record from the first standard mark to the second standard mark is generated, and the corresponding connection record is written into the connection record set. The connection record includes at least the preceding standard mark, the following standard mark, and the field mapping identifier used to support the connection determination. S2-4. Execute graph construction calculation based on the connection record set, wherein the graph construction calculation includes: taking all the rules appearing in the connection record set as the node set, and writing each connection record as a directed edge from the previous rule to the subsequent rule between the node sets, and outputting a chain graph to represent the continuous execution relationship of the rules. S2-5. Perform structural purification calculations on the chain graph. The structural purification calculations include: traversing the set of directed edges in the chain graph; marking an edge as a self-loop edge when the preorder label and subsequent label are the same; marking multiple edges as duplicate edges when multiple edges have the same preorder label, subsequent label, and field mapping identifier; removing the marked self-loop edges and duplicate edges; and outputting the deredundant chain graph.

[0008] In a preferred embodiment, S3 includes: S3-1. Taking the digital twin running state, chain graph and base weight as input, read the base weight corresponding to the current object identifier for each object identifier in the chain graph as the initial value of the input weight of the current object identifier, and write the initial value of the input weight into the current input weight variable. S3-2. Based on the directed edges in the chain graph from the previous label to the subsequent label, perform edge-by-edge propagation calculation on the current input weight according to the pointing order of the edges; The edge-by-edge propagation calculation includes: reading the permission change rules corresponding to the previous rules in the rule table, the permission change rules include at least a set of new permission items and a set of removed permission items; for the current incoming direction, first perform the permission item removal operation to delete the permission item in the removed permission item set, then perform the permission item addition operation to add the permission item in the new permission item set, and output the outgoing direction as the propagation result; S3-3. When there is a difference in the set of permission items between the current permission outgoing direction and the current permission incoming direction, write the object identifier, the preceding rule, the current permission incoming direction, the permission outgoing direction and the current trigger time into the ledger and mark it as a change propagation record; otherwise, write the object identifier, the preceding rule and the current trigger time into the ledger and mark it as no change propagation record. S3-4. Write the outgoing weight direction into the current incoming weight direction variable as the current incoming weight direction corresponding to the subsequent standard, and continue to perform edge-by-edge propagation calculation along the directed edges in the chain graph until there are no more directed edges in the chain graph with the current standard as the preceding standard, and output the complete ledger. S3-5. During the edge-by-edge propagation computation, when a propagation record with the same object identifier, the same specification, and the same current input weight is detected in the ledger, the propagation computation on the corresponding directed edge is terminated, and the corresponding termination status is written to the ledger to mark that the corresponding propagation path has been processed, thereby avoiding duplicate propagation.

[0009] In a preferred embodiment, S4 includes: S4-1. Using the ledger and the base weight as input, sort the propagation records corresponding to each object identifier in the ledger according to the trigger time, extract the outgoing weight from the last propagation record of the current object identifier, and use it as the final outgoing weight of the current object identifier. S4-2. Based on the final outgoing permission direction, perform reachability set generation calculation for each object identifier, wherein the reachability set generation calculation includes: reading all permission items contained in the final outgoing permission direction and forming a final reachable permission set; S4-3. Based on the baseline permissions, read the corresponding initial reachable permission set for each object identifier to form the baseline reachable permission set; S4-4. Perform item-by-item difference calculation on the final reachable permission set and the baseline reachable permission set. The item-by-item difference calculation includes: traversing each permission item in the final reachable permission set, performing an existence matching judgment on each permission item in the baseline reachable permission set, writing the corresponding permission item into the superboundary weight set when the matching fails, skipping the corresponding permission item when the matching succeeds, and outputting the superboundary weight set. S4-5. When the set of super-boundary weights is empty, write the corresponding object identifier and the state of no super-boundary status into the result record; when the set of super-boundary weights is not empty, write the object identifier and the corresponding set of super-boundary weights into the super-boundary record, and use the corresponding super-boundary record as the input for subsequent traversal path backtracking and smart park operation risk identification.

[0010] In a preferred embodiment, S5 includes: S5-1. Using the set of superboundary weights and the ledger as input, locate the corresponding object identifier and final outgoing direction for each superboundary weight, and filter out the propagation records in the ledger that simultaneously contain the current object identifier and the current superboundary weight to form a candidate backtracking record set. S5-2. Based on the candidate backtracking record set, select the most recent propagation record containing the outbound weight in reverse order of trigger time, read the marker in the corresponding propagation record as the current backtracking marker, and output the current backtracking node. S5-3. Starting from the current backtracking standard, continue to filter the corresponding preceding propagation records in the ledger in reverse order of trigger time, and add the filtered preceding standards to the standard sequence in turn until the corresponding input weight direction is consistent with the base weight direction, and output the complete standard sequence. S5-4. Based on the standard sequence, read the directed edge relationship between adjacent standard in the chain graph one by one, and combine the directed edge relationship according to the standard sequence order to output the penetration path corresponding to the standard sequence. S5-5. Write the penetration path and the corresponding boundary weight into the risk result record, and output the smart park operation risk identification result based on the penetration path to indicate the potential authorized penetration risk in the real operating environment.

[0011] A smart park risk identification system based on operational association rules includes a twin modeling module, a rule connection module, a permission propagation module, an out-of-bounds determination module, and a path backtracking module. The twin modeling module is used to collect and align the operation rules, permission configurations, and action logs of each subdomain of the smart park with fields, and to construct a digital twin operation state that corresponds one-to-one with the current real operation state of the park. Based on the digital twin operation state, it outputs a rule table and a baseline weight. The rule table includes at least a rule, trigger field, action field, and object identifier. The baseline weight is used to characterize the initial set of achievable permissions corresponding to the object identifier in the current real operation state. The rule connection module is used to perform connection calculations on the trigger fields and action fields of the rule table without triggering the execution of real system rules. It uses the rule as the point and the connection relationship as the edge, and each edge is associated with the action field of the preceding rule and the trigger field of the subsequent rule. The output is a chain graph that represents the continuous execution relationship of rules. The permission propagation module is used to perform edge-by-edge propagation calculations on the baseline weight direction based on the chain graph in the digital twin runtime state, simulate the continuous triggering process that may occur in the real runtime environment, record the object identifier, rule, input weight direction, output weight direction and trigger time for each rule, and output the ledger. The outbound determination module is used to perform reachability set calculation on the outbound directions recorded in the ledger. It compares the final outbound direction corresponding to each object identifier with the initial reachable permission set corresponding to the base direction item by item, identifies permission items that exist in the final outbound direction but not in the initial reachable permission set, and outputs outbound permission items. The path backtracking module is used to perform backtracking calculations on the records in the ledger corresponding to the out-of-bounds weights in reverse order of the trigger time when out-of-bounds weights exist. It determines the standard sequence that forms the out-of-bounds weights and the corresponding edge relationship, outputs the penetration path, and outputs the smart park operation risk identification results based on the penetration path to indicate the potential authorized penetration risk in the real operating environment.

[0012] The technical effects and advantages of this invention are as follows: This solution constructs a structured model of the interoperability of multi-subdomain operating rules in the digital twin operating state, and performs edge-by-edge propagation and comparison judgment of the permission status under the continuous action of rules. This enables the identification of implicit authorization penetration risks caused by the continuous triggering of multiple legal rules without changing the existing permission configuration or interrupting the normal operation of the park, thereby making up for the shortcomings of existing technologies that can only verify the permission status of a single rule or a single system. The trigger and action fields of the running rules are subjected to semantic and value range constraints for interconnected calculations, and a chain graph of continuous rule execution relationship is constructed based on this. This allows potential linkage paths between rules to be identified in advance without triggering the execution of real system rules, thereby relatively reducing the risk of unpredictable linkage caused by the complexity of rule configuration. In the digital twin runtime, the permission state is propagated edge by edge based on the chain graph, and each permission change is recorded in the form of a ledger. This makes the evolution process of object permissions under the continuous action of multiple rules have a complete time series and causal traceability, thereby relatively improving the problem of the unexplainable permission change process in the existing technology. By comparing the final set of permissions after continuous propagation of the rules with the initial set of achievable permissions item by item, permission items that exceed the initial authorization range can be directly identified from the permission achievable results. This makes the determination of authorization anomalies not dependent on empirical thresholds or post-event accident results, but rather on deterministic identification based on the rule operation logic itself. After identifying out-of-bounds permissions, backtracking calculations are performed based on the propagation ledger in reverse order of trigger time to restore the rule sequence and its connection relationship that formed the out-of-bounds permissions. This allows authorization penetration risks to not only be discovered, but also to be located to specific rule combination paths, thus providing a clear basis for rule optimization or risk management. Attached Figure Description

[0013] Figure 1 This is a flowchart outlining the method steps of the present invention; Figure 2 This is a schematic diagram of the system module structure of the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] Refer to the instruction manual appendix Figure 1-2 An embodiment of the present invention provides a smart park risk identification method based on operational association rules, comprising: S1. Collect and align the operation rules, permission configurations and action logs of each subdomain of the smart park with fields, construct a digital twin operation state that corresponds one-to-one with the current real operation state of the park, and output a rule table and baseline weights based on the digital twin operation state. The rule table includes at least a rule, trigger field, action field and object identifier, and the baseline weights are used to characterize the initial set of reachable permissions corresponding to the object identifier. S1 includes: In this embodiment, addressing the issues of diverse rule sources, inconsistent object identification standards, and difficulty in comprehensively depicting rule operation status within smart parks, a digital twin operation state generation process is constructed, based on object identification alignment and centered on rule operation status. This implementation process, through unified collection and structured processing of operation rules, permission configurations, and action logs, maps the current park operation status to a computable and traceable twin state without interfering with the operation of the real system, providing a foundational data structure for subsequent rule correlation analysis and risk identification. This implementation process includes the following steps: First, object identifier alignment is performed to resolve the issue of inconsistent entity identifiers across different subdomains, which prevents rules from being associated. Specifically, object identifier fields for identifying personnel, equipment, or system entities are extracted from operational rules, permission configurations, and action logs collected from each subdomain of the smart park, constructing a candidate set of object identifiers. Object identifier fields typically originate from primary key fields used for permission control, action records, or rule triggering in the business system. Next, key-value normalization is performed on the candidate set of object identifiers, generating object identifier alignment keys according to preset unified encoding rules. These alignment keys are formed by concatenating the subdomain identifier, object type field, and original object identifier field, uniquely representing an entity object across the entire park. During generation, if the same object identifier alignment key corresponds to multiple different original object identifiers in different subdomains, this is recorded in the object identifier conflict record, and the corresponding object identifier alignment key is marked as inconsistent for isolation or manual review in subsequent processing. When no conflict exists, the object identifier alignment key and the corresponding original object identifier are written into the object identifier alignment table and marked as consistent. Finally, the object identifier alignment table is output as the unified index basis for subsequent rule association. Secondly, the rule field mapping process is executed to determine whether there are compatible field bases between different rules. Based on the object identifier alignment table, the field name, field type, and field value range information are extracted from the trigger fields and action fields defined in the running rules, forming a trigger field set and an action field set. The field value range comes from the constraints on the fields in the rule configuration or the limitations on the field values ​​in the permission configuration. Subsequently, field matching calculations are performed on the trigger field set and the action field set to generate a field mapping table. The field matching calculation first determines whether the trigger field name and action field name are consistent and whether the field types are consistent. If they are, it is directly considered that the name and type are matched; if the field names are inconsistent, then the base... The system determines whether names are equivalent based on a pre-defined set of field synonyms. This set is compiled from system configurations or historical rules and describes the semantic equivalence of fields in different systems. If name equivalence is established, the system further determines field type consistency. If names match or are equivalent and field types are consistent, the system performs a comparability check on the range of values ​​for the trigger field and the action field. Specifically, it calculates the intersection of their value sets. If the intersection is not empty, the field pair is considered semantically comparable, and the corresponding mapping is written to the field mapping table. If the intersection is empty, the pair is considered semantically incomparable and is written to the field exclusion record, thus avoiding the introduction of invalid field mappings in subsequent rule association processes. Finally, the system outputs the field mapping table. Next, the execution of rule validity status determination aims to determine which rules are actually effective under the current real-world operating conditions. Based on the field mapping table, rule identifiers are extracted from the running rules and a rule identifier is generated. The rule identifier is formed by concatenating the subdomain identifier, rule name field, and rule version field, and is written into the rule table to uniquely identify a rule during rule association and propagation. Subsequently, the action log is associated and matched with the rule identifier according to the object identifier alignment key, mapping the actual action result field recorded in the action log to the corresponding action field in the rule table, forming a rule action mapping record. On this basis, a trigger satisfaction determination is performed on the rule action mapping record, specifically including: locating the trigger field corresponding to the action result field based on the field mapping table, reading the value conditions defined in the trigger field, and verifying the actual value of the action result field against the value conditions. When the verification result meets the conditions, the corresponding rule identifier and object identifier alignment key are written into the validity record and marked as valid; when the verification does not meet the conditions, the corresponding information is written into the invalid record and marked as invalid, finally outputting the rule validity record set. Subsequently, rule state aggregation processing is performed to construct an overall mapping of the current park operation status at the object dimension. Based on the rule establishment record set, the establishment marker of each rule identifier is extracted as the trigger state, and the associated rule identifiers and corresponding trigger states of each object identifier alignment key are summarized, and state aggregation calculation is performed. The state aggregation calculation includes: deduplicating and merging multiple rule establishment records generated within the same time window for the same object identifier alignment key, retaining only the record corresponding to the latest trigger time to avoid state inflation caused by repeated triggers; at the same time, different rule identifiers associated with the same object identifier alignment key are sorted according to the trigger time to form a rule state sequence; based on the rule state sequence, the rule identifier, object identifier alignment key, and rule establishment state are written into the digital twin operation state, thereby obtaining a twin state description that corresponds one-to-one with the current real operation state. Finally, the initial reachable permissions are calculated to determine the basic permission boundaries of each object in the current running state. Based on the digital twin running state, for each object identifier alignment key, the set of rule identifiers whose rule establishment state is established is extracted from its rule state sequence, and the set of permission change items corresponding to the set of rule identifiers is read based on the rule table. The set of permission change items comes from the permission addition or permission adjustment configuration defined in the rule. Then, the set of permission change items is combined with the permission granting range predefined for the object identifier alignment key in the permission configuration. The combination calculation includes: first, writing the permission granting range into the initial permission set, then writing the newly added permission items in the set of permission change items into the initial permission set one by one and removing duplicate items, and finally outputting the baseline weight of the initial reachable permission set of the object identifier in the current real running state. Through the above implementation process, the rules, permissions, and action information scattered in various subdomains are uniformly mapped into a computable digital twin operational state without interfering with the operation of the real park system. In practical applications, this baseline authority can serve as the initial input for subsequent rule association propagation, permission evolution analysis, and authorization penetration risk identification, enabling managers to predict and locate potential risks based on the rule operation logic itself before risks occur, thereby improving the overall security and controllability of the smart park operation. S2. Without triggering the execution of real system rules, perform the calculation of the connection between the trigger field and the action field of the rule table. With the rule as the point and the connection relationship as the edge, and each edge associated with the action field of the preceding rule and the trigger field of the subsequent rule, output the chain graph. S2 includes: In this embodiment, to address the issue that numerous operational rules in a smart park are configured independently but may trigger continuously due to field transmission relationships during actual operation, a rule association structure generation process based on field semantic connection is constructed. The core objective of this process is to pre-identify whether there are continuously executable structural relationships between rules without triggering the execution of real system rules, and to solidify these relationships in a computable graph structure, providing a structural foundation for subsequent permission propagation and risk simulation. This implementation process includes the following steps: First, the rule field extraction process is performed to decompose the triggering conditions and execution results within the rules into comparable field-level objects. Specifically, taking the rule table as input, the action field list configured for each rule is read. The action field list comes from the execution result field defined in the rule and describes the changes to the system state after the rule is established. At the same time, the trigger field list corresponding to the rule is read. The trigger field list comes from the triggering condition field defined in the rule and describes the state constraints on which the rule depends. Through the above reading operations, rule action field pairs and rule trigger field pairs are formed respectively. The action field pairs corresponding to all rules are summarized to form a rule action field pair set, and the trigger field pairs corresponding to all rules are summarized to form a rule trigger field pair set. These two sets are used as input for subsequent rule field connection determination. When a rule does not have a configured action field or trigger field, the rule is marked as not eligible to participate in the connection calculation and is excluded from the corresponding set. Secondly, the execution rule field connection determination aims to determine whether there is a possibility of continuous triggering between different rules through semantic transmission of fields. Based on the set of rule action field pairs and the set of rule trigger field pairs, pairwise combination calculations are performed on any two different rules. In each combination, the action field of the first rule and the trigger field of the second rule are selected as the field pair to be determined. For the field pair to be determined, the field mapping table is first used to query whether there is an established field correspondence between the action field and the trigger field. The field mapping table comes from the aforementioned field matching process and is used to limit the connection determination to only between semantically comparable fields. When there is no field correspondence, the rule combination is directly determined to be unconnectable and the current combination calculation ends. When there is a field correspondence, the value ranges corresponding to the action field and the trigger field are further read. The value ranges come from the constraints on field values ​​in the rule configuration or the limited intervals in the permission configuration, and the intersection of the value ranges of the two is calculated. When the intersection is not empty, it is determined that the first rule and the second rule have a connectable relationship on this field, thus having the possibility of continuous execution; otherwise, it is determined to be unconnectable. Subsequently, based on the determination of connectability according to the rules, a connection record is generated. The purpose is to solidify the abstract connection relationship into a traceable data record. When the first standard and the second standard are determined to be connectable, a connection record pointing from the first standard to the second standard is generated and written into the connection record set. The connection record includes at least the preceding standard, the following standard, and the field mapping identifier used to support the connectability determination. The field mapping identifier is used to indicate which set of field correspondences supports the connection. For cases where the same standard combination is mapped to different fields, multiple connection records can be generated or records can be merged. The specific strategy is determined by the system's preset configuration. When the connection record writing fails or the field mapping information is missing, the corresponding combination is marked as abnormal and skipped to avoid affecting the overall structure generation. Next, the rule association graph construction process is performed, the purpose of which is to organize the discrete connection records into a coherent and computable rule-based continuous execution structure. The graph construction computation is based on the connection record set, specifically including: using all the rules appearing in the connection record set as a node set, and writing each connection record as a directed edge from the preceding rule to the following rule between the node sets, thereby constructing the rule association graph structure. This directed graph is used to describe the possible continuous execution paths between rules under the current rule configuration and field semantics. During the graph construction process, if it is found that a rule referenced by a connection record does not exist in the rule table, the connection record is considered invalid and ignored to ensure the integrity and consistency of the graph structure. Finally, a chain graph representing the continuous execution relationship of rules is output. Finally, a chain graph structure purification process is performed to eliminate structures that are meaningless to subsequent propagation calculations or may cause computational redundancy. This purification process involves: traversing the set of directed edges in the chain graph; marking an edge as a self-loop edge when its preorder label and subsequent label are the same (i.e., the rule points to itself); marking multiple directed edges as duplicate edges when they have the same preorder label, subsequent label, and field mapping identifier; removing marked self-loop and duplicate edges, retaining only the minimum necessary rule relationships, and outputting the purified chain graph; if the chain graph has no directed edges after purification, this is recorded, and the chain graph is passed as an empty structure to subsequent steps. Through the above implementation process, the continuous execution relationship between rules can be pre-modeled based on field semantics and value constraints before the rules are actually triggered for execution. In practical applications, this chain graph can be used as the structural input for subsequent edge-by-edge permission propagation calculations to analyze the cumulative effects that multiple rules may produce under different sequential combinations. This enables managers to identify potential hidden risk paths during the rule configuration stage or before operation, thereby improving the overall security and controllability of the smart park rule system. S3. In the digital twin's operational state, perform edge-by-edge propagation calculations on the baseline weights based on the chain graph, record the object identifier, standard, incoming weight, outgoing weight, and trigger time for each item, and output the ledger. S3 includes: In this embodiment, to address the issue that multiple operational rules in a smart park may trigger a gradual evolution of permission states when triggered consecutively on the same object, but existing systems struggle to fully characterize this evolution path beforehand, a permission propagation calculation process based on rule association structures is constructed. This process uses a digital twin operational state as the computing environment and a chain graph as the structural constraint for the continuous execution of rules. By simulating the propagation of permission states without triggering real system rules, a complete and traceable permission evolution ledger is formed, providing a foundation for subsequent out-of-bounds determination and risk backtracking. This implementation process includes the following steps: First, the permission propagation initialization process is executed. Its purpose is to determine a unique and deterministic initial permission state for each object before rule propagation begins. Specifically, using the digital twin runtime state, the chain graph, and the baseline weights as input, the starting target node is located for each object identifier appearing in the chain graph. The starting target node is the node in the chain graph where no preceding target points to the object, representing the starting point of rule propagation. Then, the initial reachable permission set corresponding to the object identifier in the baseline weights is read, this permission set is written into the initial value of the input weight, and the initial value of the input weight is assigned to the current input weight variable for subsequent edge-by-edge propagation calculations. When an object identifier does not find a corresponding permission set in the baseline weight, its current input weight variable is initialized to an empty set and an abnormal state is recorded to avoid affecting the propagation process of other objects. Secondly, the edge-by-edge propagation calculation of permissions is performed to simulate the cumulative impact of rules on permission states under continuous execution conditions. Based on the directed edges in the chain graph pointing from previous rules to subsequent rules, edge-by-edge propagation calculation is performed on the current incoming direction according to the pointing order of the directed edges. Specifically, for the currently traversed previous rule, the permission change rules configured in its rule table are read. The permission change rules include at least a set of newly added permission items and a set of removed permission items. The set of newly added permission items represents the permissions granted after the rule is established, and the set of removed permission items represents the permissions that need to be revoked after the rule is established. The relevant configuration comes from the rule definition or permission policy constraints. Then, using the current incoming direction as input, the permission item removal operation is first performed to delete the permission items contained in the removed permission item set from the current incoming direction. Then, the permission item addition operation is performed to add the permission items in the newly added permission item set to the current incoming direction. The result is deduplicated, and finally the outgoing direction corresponding to the directed edge is obtained as the output of this propagation calculation. When the permission change rule is empty or missing, the current incoming direction is directly output as the outgoing direction and an exception flag is recorded. Subsequently, the propagation result recording process is performed to fully record every change in permission status. The differences in the permission item set between the outgoing permission direction and the current incoming permission direction are compared. When at least one permission item is detected to be different, indicating a change in the permission set, the object identifier, preceding rule label, current incoming permission direction, outgoing permission direction, and current trigger time are written into the ledger, and this record is marked as a change propagation record. The trigger time is derived from the timestamp of the corresponding rule's establishment record in the digital twin's runtime state. When the outgoing permission direction and the current incoming permission direction are completely identical, the object identifier, preceding rule label, and current trigger time are still written into the ledger, but it is marked as no change propagation record, indicating that although the rule was traversed, it did not have an actual impact on the permission status. Next, the propagation state update and continued propagation process is performed to ensure that the permission state can be continuously passed along the rule structure. The previously obtained outgoing permission direction is written into the current incoming permission direction variable, making it the current incoming permission direction corresponding to the subsequent rule. With this rule as the new preceding node, the edge-by-edge propagation calculation is continued along the directed edges in the chain graph. When there is no directed edge in the chain graph with the current rule as the preceding rule, the propagation path is determined to end, and all propagation records of the object identifier are summarized and written into the ledger as the complete permission evolution result of the object under the current rule structure. Finally, a propagation termination determination is performed to prevent infinite propagation when rules have loops or repetitive structures. During edge-by-edge propagation calculation, the ledger is checked in real time to see if there are propagation records with the same object identifier, the same rule identifier, and the same current input direction. When the detection result is true, it is determined that the propagation path has been processed, and the propagation calculation on the corresponding directed edge is terminated. The corresponding termination status is written to the ledger as a marker, thereby preventing the permission status from being repeatedly propagated in rule loops. When no duplicate records are detected, the propagation process is allowed to continue. Through the above implementation process, deterministic propagation modeling of permission status along the rule association structure is realized in the digital twin operation state, and a ledger record containing each step of the permission change process is formed. In practical applications, this ledger can be directly used to analyze how the permissions of an object gradually evolve under the continuous action of multiple rules, and provide an accurate data foundation for subsequent over-boundary permission judgment and risk path backtracking, so that managers can clearly grasp the formation process and scope of impact of potential authorization penetration before the real system triggers risks. S4. Perform reachability set calculation on the outgoing directions recorded in the ledger. Compare the final outgoing direction corresponding to each object identifier with the initial reachable permission set corresponding to the base permission direction item by item. Identify permission items that exist in the final outgoing direction but not in the initial reachable permission set, and output the outbound permission items. S4 includes: In this embodiment, to address the issue that object permissions in a smart park may gradually deviate from their initial authorization boundaries after being continuously applied by multiple rules, but existing technologies struggle to accurately identify which permissions constitute abnormal expansions from a large volume of propagation records, a process for identifying out-of-boundary permissions based on propagation result comparison is constructed. This process, through temporal merging and set comparison of the permission propagation ledger, directly identifies permission items exceeding the initial authorization scope from the permission reachability results without relying on additional rule inference, providing a clear basis for subsequent risk retrospective analysis and handling. This implementation process includes the following steps: First, the final permission status extraction process is performed to determine the final permission result for each object after the current rule propagation is completed. Specifically, taking the ledger and the baseline permission direction as input, the propagation records corresponding to each object identifier in the ledger are sorted by trigger time, which comes from the rule trigger timestamp recorded during the permission propagation process. Then, the outgoing permission direction in the last propagation record of the current object identifier is extracted from the sorted propagation records, which is taken as the final outgoing permission direction for the object after this round of rule propagation. When an object identifier only has an initial propagation record or no propagation record in the ledger, its baseline permission direction is directly taken as the final outgoing permission direction, and this situation is recorded for subsequent auditing. Secondly, the final reachable permission set generation process is performed to unify the final permission status into a directly comparable set structure. Based on the final outgoing permission direction, the reachable set generation calculation is performed for each object identifier. Specifically, this includes: reading all permission items contained in the final outgoing permission direction and deduplicating them according to the unique identifier of the permission item to form the final reachable permission set; when the final outgoing permission direction is empty or missing, the final reachable permission set is initialized to an empty set and the abnormal state is recorded to avoid affecting subsequent set comparison calculations. Subsequently, the baseline reachable permission set is read, the purpose of which is to clarify the permission boundaries that the object is originally allowed to reach in the actual running state; based on the baseline weights, the initial reachable permission set corresponding to each object identifier is read. The initial reachable permission set comes from the baseline weights calculated in the aforementioned digital twin running state, and is used to characterize the permission authorization range of the object before the continuous propagation of rules; when the baseline weights do not contain the corresponding object identifier, its baseline reachable permission set is initialized to an empty set and recorded as a configuration missing state; Next, out-of-bounds permission determination processing is performed. Its purpose is to identify permission items that do not belong to the initial authorization scope from the final permission results. A step-by-step difference calculation is performed between the final reachable permission set and the baseline reachable permission set. Specifically, this includes: traversing each permission item in the final reachable permission set and performing an existence matching determination for the current permission item in the baseline reachable permission set; when the match fails, i.e., the permission item is not in the baseline reachable permission set, the permission item is added to the out-of-bounds permission set; when the match succeeds, the permission item is skipped and the next item is traversed, finally outputting the complete out-of-bounds permission set. This step-by-step difference calculation does not rely on thresholds or statistical parameters, but only on a deterministic comparison between the rule propagation results and the initial authorization scope, ensuring the verifiability of the determination results. Finally, the process of recording the results of exceeding the boundary is performed. The purpose of this process is to write the judgment results into the system in a structured form for subsequent risk analysis. When the set of exceeding the boundary rights is empty, it is determined that the current object identifier does not have any exceeding boundary permissions. The object identifier and the state of no exceeding the boundary are written into the result record to indicate that its permission evolution process has not broken through the initial authorization boundary. When the set of exceeding the boundary rights is not empty, the object identifier and the corresponding set of exceeding the boundary rights are written into the exceeding boundary record. The exceeding boundary record serves as important input data for subsequent tracing of the penetration path and identification of risks in the operation of the smart park. Through the above implementation process, the final permission status of objects in the permission propagation ledger is accurately merged and compared with the boundaries. It can directly identify out-of-boundary permissions caused by the continuous action of multiple rules without the need for manual rule interpretation. In practical applications, this out-of-boundary record can be used to locate objects with potential authorization penetration risks. For example, in park operation and maintenance or security audit scenarios, managers can quickly identify which personnel or equipment have obtained permissions beyond the original authorization scope under the superposition of rules based on the out-of-boundary permission item set, so as to take adjustment or restriction measures in advance to ensure the security and compliance of smart park operation. S5. When there is an out-of-boundary weight item, perform backtracking calculation on the records in the ledger corresponding to the out-of-boundary weight item in reverse order of trigger time to determine the standard sequence that forms the out-of-boundary weight item and the corresponding edge relationship, output the penetration path, and output the smart park operation risk identification result based on the penetration path. S5 includes: In this embodiment, addressing the issue that identified over-boundary permissions in a smart park only indicate the risk outcome but fail to explain the underlying rules and their order in which the risk was formed, a process for authorization penetration path tracing and risk localization based on a propagation ledger is constructed. This process uses over-boundary permissions as the starting point for tracing back and the permission propagation process recorded in the ledger as the evidence chain. It reverse-engineers the permission evolution path within the digital twin runtime environment, thereby outputting interpretable and verifiable risk identification results. This implementation process includes the following steps: First, the process of locating candidate over-boundary backtracking is performed to filter out the range of propagation records directly related to over-boundary permissions from the ledger. Specifically, taking the set of over-boundary permissions and the ledger as input, for each over-boundary permission in the set of over-boundary permissions, its corresponding object identifier and the final outgoing direction determined in the previous steps are read. Then, a filtering operation is performed on the propagation records in the ledger, selecting propagation records that contain both the object identifier and the current over-boundary permission in their outgoing direction, and writing the filtered records into the candidate backtracking record set. This filtering process is completed by permission item matching and does not rely on manual rule setting. When a certain over-boundary permission does not match a corresponding propagation record in the ledger, the over-boundary permission is marked as unbacktrackable and an anomaly is recorded to avoid affecting the backtracking process of other over-boundary permissions. Secondly, the backtracking starting point determination process is performed to identify the rule node closest to the time when the overbound result was formed among the candidate records. Based on the candidate backtracking record set, the records are sorted in reverse order according to the trigger time of the records in the propagation records. The trigger time comes from the timestamp information written to the ledger during the permission propagation process. The most recent propagation record containing the current overbound weight is selected from the sorted records, and the rule marker in the propagation record is read as the current backtracking rule marker and output as the current backtracking node. If the candidate backtracking record set is empty, the backtracking process of the overbound weight is terminated directly and the abnormal state is recorded. Subsequently, the rule sequence is reversed and backtracked to restore the complete rule triggering order that led to the out-of-bounds permission. Starting from the current backtracking marker, the ledger continues to filter the preceding propagation records in reverse order of trigger time that are related to the current object identifier and whose outgoing direction can deduce the current incoming direction. Whenever a preceding propagation record that meets the conditions is found, the marker in the record is read and appended to the marker sequence, and the incoming direction in the record is used as the new backtracking reference state. The above backtracking process continues until it is detected that the current incoming direction is consistent with the base direction, that is, the permission state has fallen back to the initial reachable permission set, corresponding to the rule propagation starting point. When no preceding propagation record that meets the conditions can be found during the backtracking process, the backtracking is terminated and the incomplete path state is recorded. Finally, the complete marker sequence that forms the out-of-bounds permission is output. Next, a penetration path mapping process is performed to convert the rule sequence into a structured rule association path. Based on the previously obtained label sequence, the directed edge relationships between adjacent labels in the label sequence are read one by one in the chain graph. The directed edge relationships are derived from the structural modeling results of the rule continuous execution relationship. According to the order of the label sequence, the corresponding directed edge relationships are combined in sequence to form a penetration path that corresponds one-to-one with the label sequence. If a directed edge relationship corresponding to a certain pair of adjacent labels cannot be found in the chain graph, the label sequence is marked as structurally inconsistent and an anomaly is recorded to ensure the verifiability of the penetration path results. Finally, risk result generation processing is performed to transform the backtracked path information into directly usable risk identification results. The penetration path and corresponding boundary-crossing rights are written into the risk result record, which includes at least the object identifier, boundary-crossing rights, and corresponding penetration path information. Based on the penetration path, the system outputs smart park operation risk identification results to indicate potential authorization penetration risks in the real operating environment. The risk identification results can be used for subsequent alarm display, audit analysis, or manual handling, but do not directly affect the permission configuration of the real system, thereby avoiding interference with normal operation. Through the above implementation process, a complete reverse derivation from the result of exceeding the scope of permissions to the rule combination path is realized. This enables the risk of authorization penetration in smart parks to not only be discovered, but also explained and located. In practical applications, such as in park security audits or permission compliance checks, managers can view the penetration path given in the risk result record to clarify which rules, in what order, worked together to cause a certain person or device to obtain abnormal permissions. This allows them to adjust rule configurations or strengthen control in a targeted manner, thereby improving the security, transparency, and controllability of smart park operations.

[0016] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for risk identification in smart parks based on operational association rules, characterized in that, include: S1. Collect and align the operation rules, permission configurations and action logs of each subdomain of the smart park with fields, construct a digital twin operation state that corresponds one-to-one with the current real operation state of the park, and output a rule table and baseline weights based on the digital twin operation state. The rule table includes at least a rule, trigger field, action field and object identifier, and the baseline weights are used to characterize the initial set of reachable permissions corresponding to the object identifier. S2. Without triggering the execution of real system rules, perform the calculation of the connection between the trigger field and the action field of the rule table. With the rule as the point and the connection relationship as the edge, and each edge associated with the action field of the preceding rule and the trigger field of the subsequent rule, output the chain graph. S3. In the digital twin's operational state, perform edge-by-edge propagation calculations on the baseline weights based on the chain graph, record the object identifier, standard, incoming weight, outgoing weight, and trigger time for each item, and output the ledger. S4. Perform reachability set calculation on the outgoing directions recorded in the ledger. Compare the final outgoing direction corresponding to each object identifier with the initial reachable permission set corresponding to the base permission direction item by item. Identify permission items that exist in the final outgoing direction but not in the initial reachable permission set, and output the outbound permission items. S5. When there is an out-of-boundary weight, perform backtracking calculation on the records in the ledger corresponding to the out-of-boundary weight in reverse order of the trigger time to determine the standard sequence that forms the out-of-boundary weight and the corresponding edge relationship, output the penetration path, and output the smart park operation risk identification result based on the penetration path.

2. The smart park risk identification method based on operational association rules according to claim 1, characterized in that: S1 includes: S1-1. Extract the object identifier field from the operation rules, permission configurations and action logs collected from each subdomain of the smart park, and construct a candidate set of object identifiers; Perform key-value normalization on the candidate set of object identifiers and generate an object identifier alignment key, wherein the object identifier alignment key is formed by concatenating the subdomain identifier, the object type field and the object original identifier field; When the same object identifier alignment key corresponds to multiple object original identifiers in different subdomains, an object identifier conflict record is written and the corresponding object identifier alignment key is marked as inconsistent; otherwise, the object identifier alignment key and the corresponding object original identifier are written into the object identifier alignment table and marked as consistent, and the object identifier alignment table is output. S1-2. Based on the object identifier alignment table, extract the field name, field type and field value range from the trigger field and action field in the running rule to form the trigger field set and the action field set; Perform field matching calculations on the trigger field set and the action field set to generate a field mapping table, wherein the field matching calculations include: When the trigger field name and the action field name are the same and the field types are the same, it is determined that the name matches and the types match; otherwise, when the trigger field name and the action field name are different, the name equivalence relationship is determined based on the preset field synonym comparison set, and the field type consistency relationship is determined when the name equivalence is established; when the name matches or the name is equivalent and the field types are the same, the comparability determination is further performed on the value range of the trigger field and the value range of the action field. If there is a non-empty intersection between the two records, mark them as semantically comparable and write them to the field mapping table; otherwise, mark them as semantically incomparable and write them to the field exclusion record; output the field mapping table.

3. The smart park risk identification method based on operational association rules according to claim 2, characterized in that: S1 also includes: S1-3. Based on the field mapping table, extract the rule identifier from the running rules to generate the rule identifier. The rule identifier is formed by concatenating the subdomain identifier, the rule name field and the rule version field and is written into the rule table. Perform association matching between the action log and the rule identifier according to the object identifier alignment key, map the actual action result field recorded in the action log to the corresponding action field in the rule table, and output the rule action mapping record; The trigger satisfaction determination is performed on the rule action mapping record. The trigger satisfaction determination includes: locating the trigger field corresponding to the action result field based on the field mapping table, reading the value conditions of the trigger field and performing condition validation on the action result field. When the condition validation passes, the rule identifier and object identifier are aligned and written into the established record and marked as established; otherwise, an invalid record is written and marked as invalid. The set of established rule records is output. S1-4. Based on the rule-established record set, extract the corresponding establishment marker for each rule identifier as a trigger state, and summarize the associated rule identifiers and corresponding trigger states for each object identifier by alignment key. Perform state aggregation calculation to output the digital twin running state, wherein the state aggregation calculation includes: For multiple rule records that are true within the same time window with the same object identifier alignment key, deduplication and merging are performed, and the latest trigger time is retained. Different rule identifiers corresponding to the same object identifier alignment key are sorted by trigger time to form a rule status sequence. The rule status sequence is written into the digital twin runtime state, which includes at least the rule identifier, the object identifier alignment key, and the rule status. S1-5. Based on the digital twin's operational state, extract the set of rule identifiers in the corresponding rule state sequence for each object identifier alignment key, where the rule is established, and read the set of permission change items corresponding to the rule identifier set based on the rule table. Perform a union calculation on the set of permission change items and the permission grant range corresponding to the alignment key of the object identifier in the permission configuration to output the reachable permission set. The union calculation includes: writing the permission grant range into the initial permission set, writing the newly added permission items in the set of permission change items into the initial permission set and removing duplicate items; the output is a baseline weight that represents the initial reachable permission set of the object identifier in the current real running state.

4. The smart park risk identification method based on operational association rules according to claim 3, characterized in that: S2 includes: S2-1. Taking the rule table as input, read the corresponding action field list for each rule in the rule table and form a rule action field pair. At the same time, read the corresponding trigger field list and form a rule trigger field pair. Output the rule action field pair set and the rule trigger field pair set. S2-2. Based on the set of action field pairs and the set of trigger field pairs of the standard, perform pairwise combination calculations for any two different standards, and select the action field of the first standard and the trigger field of the second standard as the field pair to be judged; for the field pair to be judged, check whether there is a field correspondence according to the field mapping table, and if there is a field correspondence, further read the value range of the corresponding action field and trigger field, perform the intersection calculation of the value range, and when the intersection is not empty, determine that the first standard and the second standard can be connected; S2-3. When it is determined that the first standard mark and the second standard mark can be connected, a connection record from the first standard mark to the second standard mark is generated, and the corresponding connection record is written into the connection record set. The connection record includes at least the preceding standard mark, the following standard mark, and the field mapping identifier used to support the connection determination. S2-4. Execute graph construction calculation based on the connection record set, wherein the graph construction calculation includes: taking all the rules appearing in the connection record set as the node set, and writing each connection record as a directed edge from the previous rule to the subsequent rule between the node sets, and outputting a chain graph to represent the continuous execution relationship of the rules. S2-5. Perform structural purification calculations on the chain graph. The structural purification calculations include: traversing the set of directed edges in the chain graph; marking an edge as a self-loop edge when the preorder label and subsequent label are the same; marking multiple edges as duplicate edges when multiple edges have the same preorder label, subsequent label, and field mapping identifier; removing the marked self-loop edges and duplicate edges; and outputting the deredundant chain graph.

5. The smart park risk identification method based on operational association rules according to claim 4, characterized in that: S3 includes: S3-1. Taking the digital twin running state, chain graph and base weight as input, read the base weight corresponding to the current object identifier for each object identifier in the chain graph as the initial value of the input weight of the current object identifier, and write the initial value of the input weight into the current input weight variable. S3-2. Based on the directed edges in the chain graph from the previous label to the subsequent label, perform edge-by-edge propagation calculation on the current input weight according to the pointing order of the edges; The edge-by-edge propagation calculation includes: reading the permission change rules corresponding to the previous rules in the rule table, the permission change rules include at least a set of new permission items and a set of removed permission items; for the current incoming direction, first perform the permission item removal operation to delete the permission item in the removed permission item set, then perform the permission item addition operation to add the permission item in the new permission item set, and output the outgoing direction as the propagation result; S3-3. When there is a difference in the set of permission items between the current permission outgoing direction and the current permission incoming direction, write the object identifier, the preceding rule, the current permission incoming direction, the permission outgoing direction and the current trigger time into the ledger and mark it as a change propagation record; otherwise, write the object identifier, the preceding rule and the current trigger time into the ledger and mark it as no change propagation record. S3-4. Write the outgoing weight direction into the current incoming weight direction variable as the current incoming weight direction corresponding to the subsequent standard, and continue to perform edge-by-edge propagation calculation along the directed edges in the chain graph until there are no more directed edges in the chain graph with the current standard as the preceding standard, and output the complete ledger. S3-5. During the edge-by-edge propagation computation, when a propagation record with the same object identifier, the same specification, and the same current input weight is detected in the ledger, the propagation computation on the corresponding directed edge is terminated, and the corresponding termination status is written to the ledger to mark that the corresponding propagation path has been processed.

6. The smart park risk identification method based on operational association rules according to claim 5, characterized in that: S4 includes: S4-1. Using the ledger and the base weight as input, sort the propagation records corresponding to each object identifier in the ledger according to the trigger time, extract the outgoing weight from the last propagation record of the current object identifier, and use it as the final outgoing weight of the current object identifier. S4-2. Based on the final outgoing permission direction, perform reachability set generation calculation for each object identifier, wherein the reachability set generation calculation includes: reading all permission items contained in the final outgoing permission direction and forming a final reachable permission set; S4-3. Based on the baseline permissions, read the corresponding initial reachable permission set for each object identifier to form the baseline reachable permission set; S4-4. Perform item-by-item difference calculation on the final reachable permission set and the baseline reachable permission set. The item-by-item difference calculation includes: traversing each permission item in the final reachable permission set, performing an existence matching judgment on each permission item in the baseline reachable permission set, writing the corresponding permission item into the superboundary weight set when the matching fails, skipping the corresponding permission item when the matching succeeds, and outputting the superboundary weight set. S4-5. When the set of outbound weights is empty, write the corresponding object identifier and the no outbound state into the result record; when the set of outbound weights is not empty, write the object identifier and the corresponding set of outbound weights into the outbound record.

7. The smart park risk identification method based on operational association rules according to claim 6, characterized in that: S5 includes: S5-1. Using the set of superboundary weights and the ledger as input, locate the corresponding object identifier and final outgoing direction for each superboundary weight, and filter out the propagation records in the ledger that simultaneously contain the current object identifier and the current superboundary weight to form a candidate backtracking record set. S5-2. Based on the candidate backtracking record set, select the most recent propagation record containing the outbound weight in reverse order of trigger time, read the marker in the corresponding propagation record as the current backtracking marker, and output the current backtracking node. S5-3. Starting from the current backtracking standard, continue to filter the corresponding preceding propagation records in the ledger in reverse order of trigger time, and add the filtered preceding standards to the standard sequence in turn until the corresponding input weight direction is consistent with the base weight direction, and output the complete standard sequence. S5-4. Based on the standard sequence, read the directed edge relationship between adjacent standard in the chain graph one by one, and combine the directed edge relationship according to the standard sequence order to output the penetration path corresponding to the standard sequence. S5-5. Write the penetration path and the corresponding boundary weight into the risk result record, and output the smart park operation risk identification result based on the penetration path to indicate the potential authorized penetration risk in the real operating environment.

8. A smart park risk identification system based on operational association rules, comprising a smart park risk identification method based on operational association rules as described in claim 7, including a twin modeling module, a rule connection module, a permission propagation module, an out-of-bounds determination module, and a path backtracking module, characterized in that: The twin modeling module is used to collect and align the operation rules, permission configurations, and action logs of each subdomain of the smart park with fields, and to construct a digital twin operation state that corresponds one-to-one with the current real operation state of the park. Based on the digital twin operation state, it outputs a rule table and a baseline weight. The rule table includes at least a rule, trigger field, action field, and object identifier. The baseline weight is used to characterize the initial set of achievable permissions corresponding to the object identifier in the current real operation state. The rule connection module is used to perform connection calculations on the trigger fields and action fields of the rule table without triggering the execution of real system rules. It uses the rule as the point and the connection relationship as the edge, and each edge is associated with the action field of the preceding rule and the trigger field of the subsequent rule. The output is a chain graph that represents the continuous execution relationship of rules. The permission propagation module is used to perform edge-by-edge propagation calculations on the baseline weight direction based on the chain graph in the digital twin runtime state, simulate the continuous triggering process that may occur in the real runtime environment, record the object identifier, rule, input weight direction, output weight direction and trigger time for each rule, and output the ledger. The outbound determination module is used to perform reachability set calculation on the outbound directions recorded in the ledger. It compares the final outbound direction corresponding to each object identifier with the initial reachable permission set corresponding to the base direction item by item, identifies permission items that exist in the final outbound direction but not in the initial reachable permission set, and outputs outbound permission items. The path backtracking module is used to perform backtracking calculations on the records in the ledger corresponding to the out-of-bounds weights in reverse order of the trigger time when out-of-bounds weights exist. It determines the standard sequence that forms the out-of-bounds weights and the corresponding edge relationship, outputs the penetration path, and outputs the smart park operation risk identification results based on the penetration path to indicate the potential authorized penetration risk in the real operating environment.

Images