A cloud-edge collaborative industrial control network security protection method based on a policy library

Abstract

This invention discloses a cloud-edge collaborative industrial control network security protection method based on a policy library, belonging to the field of industrial control network protection technology. The method includes the following steps: constructing a policy resource metadata identification system; performing exclusive modeling on key resources such as log files, tag caches, and configuration interfaces to generate a unified resource access identification gene; constructing a resource mutual exclusion directed graph based on the resource access identification gene; generating potential deadlock loop information through graph structure analysis; and calculating a resource scheduling priority ranking matrix accordingly. This invention achieves structured identification of policy resource conflicts through exclusive identification genes and mutual exclusion graph modeling. It combines static verification and transaction segmentation to prevent execution conflicts, employs serial hosting and lock release mechanisms to ensure the atomicity of resource access, and dynamically optimizes the scheduling order through telemetry feedback and hot reconfiguration. This significantly improves the conflict control and adaptive capabilities of the edge security engine, constructing an efficient and stable industrial control network security protection closed loop.

Description

Technical Field

[0001] This invention relates to the field of industrial control network protection technology, specifically to a cloud-edge collaborative industrial control network protection method based on a policy library. Background Technology

[0002] Cloud-edge collaborative industrial control network security protection based on a policy library refers to the multi-layered and dynamic security protection of industrial control networks by constructing a unified security policy knowledge base and forming a linkage mechanism between the cloud and the edge. Specifically, the cloud aggregates security events, attack samples, and system behavior data from multiple edge nodes, and uses artificial intelligence models to perform deep learning on attack characteristics and generate policies, constructing a structured and scalable policy library. The edge dynamically issues matching policies from the policy library according to its local operating environment, enabling real-time detection and response to abnormal traffic, illegal commands, and intrusion behaviors. This mechanism not only enhances the rapid response capability of the edge but also leverages the global perspective and policy evolution capabilities of the cloud to achieve rapid identification and dynamic adaptation to new threats, thereby constructing a closed-loop industrial control network security system covering the entire chain of perception, defense, response, and tracking.

[0003] The existing technology has the following shortcomings:

[0004] Existing cloud-edge collaborative industrial control network security protection systems based on policy libraries suffer from a lack of mutual exclusion mechanisms at the resource access level among multiple policy entries. Particularly during policy execution, multiple policy entries may simultaneously initiate read / write operations on the same type of resource object (such as log files, tag caches, and configuration interfaces), leading to resource access interlocking. When interlocking is not effectively identified and handled, it can easily cause the policy engine to fall into a loop of repeated calls or rule parsing. This not only results in continuous occupation of edge device computing resources and ultimately causes the security engine to crash, but also renders the system's security monitoring and blocking functions completely ineffective. Attack traffic can then directly penetrate the industrial control network without protection, causing serious consequences such as tampering with critical control commands, loss of control over core equipment operation, or distortion of sensitive process data, severely threatening the stability and security of industrial control systems.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide a cloud-edge collaborative industrial control network security protection method based on a policy library. By constructing an exclusive identifier gene and a resource mutual exclusion directed graph, it achieves structured modeling of resource access relationships between policies, enabling early identification of deadlock paths. Combined with static conflict verification and transaction segmentation mechanisms, it establishes controllable resource boundaries before policy issuance to prevent execution conflicts. Through serial management and synchronous lock release, it ensures the atomicity and cleanup of policy execution, preventing the recurrence of resource interlocks. A telemetry feedback mechanism enables real-time monitoring of execution status and resource contention assessment, supplemented by a hot reconfiguration mechanism to dynamically optimize scheduling order and alleviate resource bottlenecks. Overall, it improves the stability, adaptability, and closed-loop protection capabilities of the edge security engine, thus solving the problems mentioned in the background technology.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a cloud-edge collaborative industrial control network security protection method based on a policy library, comprising the following steps:

[0008] Step 1: Construct a policy resource metadata identification system. Perform exclusive metadata modeling on key resource objects in the industrial control network. Key resource objects include log files, tag caches, and configuration interfaces. Establish corresponding exclusive identification genes for each of them to uniformly represent resource access types and conflict relationships, providing a modeling foundation for the structured expression of subsequent resource mutual exclusion relationships.

[0009] Step 2: Based on the exclusive identifier gene, activate the resource mutual exclusion graph construction engine, map the access conflict relationship between each resource object into a resource mutual exclusion directed graph structure, generate potential deadlock closed loop information through graph structure analysis, and calculate the resource scheduling priority sorting matrix according to topology characteristics to provide static boundary basis for strategy conflict analysis.

[0010] Step 3: Activate the policy exclusivity static verification mechanism. For each policy item to be issued to the edge device, perform an exclusive conflict scan based on the resource scheduling priority sorting matrix to identify and mark high-risk policy combination relationships with resource access conflicts, and generate a policy transaction segment execution list with controllable resource boundaries to guide resource scheduling in the subsequent execution process.

[0011] Step 4: Load the fine-grained strategy transaction management container, and execute each strategy unit in the strategy transaction segment execution list as an independent transaction unit in a serial management mode. After each strategy unit completes the access operation on the resource objects involved, the resource lock release status is submitted synchronously to ensure that resource access remains atomic and cleanable during the entire strategy transaction execution process, and to prevent the recurrence of resource interlocking.

[0012] Step 5: Construct a telemetry feedback mechanism for strategy transaction execution. During the operation of the strategy transaction managed container, collect information such as the execution time, queuing depth, and resource lock wait count of each strategy unit in real time. Combine this with the parameter adaptive model to calculate the resource contention intensity index of the current system, which is used to dynamically assess the resource conflict density and strategy scheduling pressure.

[0013] Step 6: Based on the resource contention intensity index, trigger the policy scheduling hot reconfiguration mechanism, dynamically recalculate the resource scheduling priority ranking matrix, and perform plug-and-play optimization on the execution sequence of the policy transaction units being executed, including reordering, lazy loading, or priority promotion operations, in order to alleviate resource conflict hotspots and optimize policy execution efficiency.

[0014] Preferably, the steps for constructing a strategy resource metadata identification system include:

[0015] Extract three key resource objects that are frequently accessed during policy execution: log files, tag cache, and configuration interfaces. Then, classify and organize them according to their functional attributes, access methods, and operation frequency to form a resource list and assign a unique identifier.

[0016] A resource access behavior matrix is ​​established based on access granularity, operation type, and temporal dependency to make resource conflict relationships explicit.

[0017] An exclusive identifier gene consisting of a resource category code, access mode code, access unit code, and conflict priority code is generated, and the identifier gene is bound to the resource operation description of each policy entry to realize a structural mapping between policies and resource access relationships.

[0018] Preferably, the steps for constructing a resource mutual exclusion map based on exclusive marker genes include:

[0019] The strategy entries carrying the identifier genes are parsed to extract the relevant resource access attributes and construct resource access conflict pairs.

[0020] The conflict pairs are mapped to a directed graph structure of mutually exclusive resources, where nodes represent resource access units and edges represent access dependencies.

[0021] Deadlock closed-loop paths are identified using graph traversal and loop detection algorithms, and topological characteristic indices of each node are calculated.

[0022] A resource scheduling priority ranking matrix is ​​generated based on topological features, which serves as the input for static policy verification.

[0023] Preferably, the steps for generating a strategy transaction segment execution list with controllable resource boundaries include:

[0024] Based on the resource scheduling priority ranking matrix, a conflict scan is performed on the resource access identifier genes contained in each policy entry to identify policy combination relationships with potential resource access conflicts.

[0025] The identified conflict relationships are risk-classified and feature-annotated to generate a summary of strategy conflict features;

[0026] Based on the conflict risk nodes, the policy entries are segmented into transaction segments to form independently schedulable policy units. All policy units are then aggregated to generate a policy transaction segment execution list to guide subsequent scheduling and execution.

[0027] Preferably, the steps of managing and executing each strategy unit serially based on the execution list and synchronously releasing the resource lock after the resource operation is completed include:

[0028] Organize the policy units in the policy transaction segmentation execution list into a serial execution queue, and schedule and request resource access permissions in sequence;

[0029] After completing the resource operation, verify the operation log and submit the resource lock release command synchronously after confirming that there are no errors.

[0030] Update the execution status of the policy unit and return control to schedule the next policy unit;

[0031] During the scheduling process, the execution order is dynamically adjusted according to the resource availability status, forming an atomic, closed-loop resource access control process.

[0032] Preferably, the steps for calculating the resource contention intensity index using a parameter adaptive model include:

[0033] Initialize the telemetry status record structure for each policy unit before starting the policy transaction managed container;

[0034] During execution, telemetry data is collected and updated in real time to construct an execution status table;

[0035] The resource contention intensity index is calculated based on the adaptive model of data call parameters, and the resource contention intensity index is returned to the scheduling management logic as the triggering basis for policy scheduling hot reconfiguration.

[0036] Preferably, the steps of dynamically adjusting the resource scheduling priority ranking matrix based on the contention intensity index and performing plug-and-play optimization on the strategy execution sequence include:

[0037] When the resource contention intensity index exceeds the preset threshold, the scheduling hot reconfiguration process is initiated, and the current policy execution status and resource access data are loaded.

[0038] Based on the data, the resource scheduling priority ranking matrix is ​​dynamically recalculated to adjust the access priority level of each resource.

[0039] Based on the new sorting matrix, plug-and-play optimizations are performed on the strategy transaction execution sequence, including reordering, lazy loading, and priority promotion. The scheduling table is then updated to resume strategy execution, ensuring that the scheduling order adjustment maintains consistency between resource dependencies and transaction integrity.

[0040] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0041] This invention constructs an exclusive identifier gene and a resource mutual exclusion directed graph to achieve a structured expression and graph-based modeling of resource access relationships between strategies, enabling early identification of potential deadlock paths. Combined with static conflict verification and transaction segmentation mechanisms, controllable resource boundaries can be built before strategy issuance to prevent conflicts during execution. Through serial management and synchronization lock release mechanisms, the atomicity and cleanupability of resource usage during strategy execution are ensured, effectively preventing resource interlocking from recurring. A telemetry feedback mechanism enables real-time monitoring of strategy operation status and quantitative assessment of resource contention intensity. Coupled with a hot reconfiguration mechanism, the execution order can be dynamically adjusted to alleviate execution bottlenecks. Overall, this method improves the edge security engine's ability to control resource conflicts and its adaptive ability to schedule strategies, significantly enhancing the stability, responsiveness, and sustainable operation of industrial control networks when facing high-concurrency protection strategies. This constructs a closed-loop security protection system with intelligent perception, dynamic control, and fault self-recovery capabilities. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0043] Figure 1 This is a flowchart of a cloud-edge collaborative industrial control network security protection method based on a policy library, according to the present invention. Detailed Implementation

[0044] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0045] This invention provides, for example Figure 1 The cloud-edge collaborative industrial control network security protection method based on a policy library, as shown, includes the following steps:

[0046] Step 1: Construct a policy resource metadata identification system. Perform exclusive metadata modeling on key resource objects in the industrial control network. Key resource objects include log files, tag caches, and configuration interfaces. Establish corresponding exclusive identification genes for each of them to uniformly represent resource access types and conflict relationships, providing a modeling foundation for the structured expression of subsequent resource mutual exclusion relationships.

[0047] In this embodiment, the process of constructing a policy resource metadata identification system is mainly used to structurally model the access characteristics of key resource objects in the industrial control network. By constructing an identifier gene with exclusive characteristics, it uniformly describes the access category, conflict characteristics, and dependency attributes of resources to support subsequent resource mutual exclusion graph construction and policy conflict analysis. This process specifically includes the following steps:

[0048] Key resource objects in industrial control networks that are frequently invoked and prone to resource conflicts during policy execution are extracted, mainly including three categories: log files, tag caches, and configuration interfaces. Log files are used to record event trajectories, tag caches are used for intermediate storage of behavioral states, and configuration interfaces are used for dynamic parameter tuning and command distribution. Each type of resource may be accessed by multiple policy entries simultaneously, inherently possessing a potential for conflict. Therefore, in the resource identification phase, each type of resource object needs to be classified and organized according to its functional attributes, access methods (read / write / read / write), and operation frequency to form a resource list, and a globally unique identifier code is assigned to each type of resource as the index basis for subsequent identification genes.

[0049] An exclusive resource access dimension is established to characterize the potential access conflicts between different resource objects during policy execution. Specifically, an access behavior matrix is ​​constructed according to three dimensions: "access granularity," "operation type," and "temporal dependency." For example, if a policy entry requires continuous write operations to the tag cache during execution, while other policies simultaneously have read requests, a write-read exclusive relationship is formed; if a policy needs to write to the configuration interface first and then record logs, a write-write-temporal dependency relationship is formed between it and the configuration interface and the log file. Through matrix modeling, the conflict boundaries between different resource accesses can be initially made explicit.

[0050] Based on the above matrix structure, an exclusive identifier gene is generated for each resource object. This identifier gene expresses the resource's category code, access permission attribute, access granularity code, and conflict level code in a structured encoding format. For example, the identifier gene can consist of four segments: resource category code (e.g., L=log, C=cached, P=configuration), access mode code (R / W / B represents read-only, write-only, and bidirectional read / write), access unit code (representing block, byte, or segment-level operations), and conflict priority code (used for priority scheduling during conflict detection). For example, a resource access identifier gene representing segment-level writing to a log file with a high conflict level is "LWDH".

[0051] By binding the aforementioned exclusive identifier genes to the resource operation call description of each policy entry, a structural mapping of the access relationships between policy entries and key resources is achieved. Through this mapping, each policy entry can carry a corresponding set of resource access genes, facilitating subsequent automated mutual exclusion relationship modeling, deadlock path identification, and scheduling and ranking analysis of the policy set. This mechanism significantly improves the predictability and controllability of resource conflicts during the policy design phase, laying a reliable data and structural foundation for resource mutual exclusion graph construction and static verification.

[0052] Step 2: Based on the exclusive identifier gene, activate the resource mutual exclusion graph construction engine, map the access conflict relationship between each resource object into a resource mutual exclusion directed graph structure, generate potential deadlock closed loop information through graph structure analysis, and calculate the resource scheduling priority sorting matrix according to topology characteristics to provide static boundary basis for strategy conflict analysis.

[0053] In this embodiment, based on the aforementioned constructed exclusive identifier gene, the access relationship between strategy entries and key resource objects is structurally analyzed, and a resource mutual exclusion graph is constructed based on graph theory. This identifies potential deadlock risks and generates a resource scheduling priority ranking matrix, providing static boundary constraints for the exclusivity verification of strategy entries. The entire process includes the following steps:

[0054] Batch parsing of strategy entries carrying exclusive identifier genes extracts key resource objects and their access attributes, constructing a set of resource access conflict pairs. Each conflict pair consists of resource identifier genes involved in two strategy entries, judged based on read-write pattern conflicts (e.g., one write multiple reads or multiple write concurrency) and temporal dependency conflicts (e.g., strategy A requires access to resource X before accessing Y, and strategy B does the opposite). This method generates a list of conflict pairs, labeling the access priority tendency between each pair (e.g., preemption, waiting, strong dependency, weak dependency, etc.), providing basic semantics for subsequent graph structure construction.

[0055] All identified resource access conflict pairs are mapped to a directed graph structure of resource mutual exclusion. In this graph structure, each node represents a resource access behavior unit corresponding to a resource identifier gene, and each directed edge represents a directional dependency or potential blocking relationship in resource access. The edge weight is used to represent the intensity of the access conflict or the scheduling priority. By traversing the resource operation order in the policy entries, multiple sets of directed edges with policy execution as the link path can be constructed and merged into the overall graph structure to achieve a unified expression of global resource mutual exclusion relationships.

[0056] For the constructed resource-exclusive directed graph structure, graph traversal and cycle detection algorithms are applied to identify potential deadlock loop paths. If a loop path exists in the graph, indicating a circular dependency structure between multiple resource objects, it is identified as a high-risk deadlock area. Based on this, topological characteristic indicators such as the number of loop structures, in-degree ratio, and total edge weight of each resource node can be calculated to further assess its resource conflict sensitivity. The results of this topological analysis can not only be used to warn of high-risk resources but also as a reference for constructing scheduling priorities.

[0057] Based on the topological characteristics of the resource-mutually exclusive directed graph structure, a resource scheduling priority ranking matrix is ​​generated. This ranking matrix uses resource identifiers as row and column indices, and calculated conflict intensity, topological level, and dependency weights as ranking factors to construct priority relationships between each pair of resources. In this matrix, higher-priority resource access requests will receive priority execution during policy scheduling, thereby avoiding resource preemption conflicts and deadlock backlogs in subsequent policy execution. Finally, this ranking matrix will be provided as static input to the resource scheduling control logic in the policy exclusivity verification process, statically defining the policy execution boundary, reducing the uncertainty of resource conflicts in policy interactions, and improving the overall security and stability of the policy engine.

[0058] Step 3: Activate the policy exclusivity static verification mechanism. For each policy item to be issued to the edge device, perform an exclusive conflict scan based on the resource scheduling priority sorting matrix to identify and mark high-risk policy combination relationships with resource access conflicts, and generate a policy transaction segment execution list with controllable resource boundaries to guide resource scheduling in the subsequent execution process.

[0059] To ensure that policy entries do not cause resource access conflicts and deadlock risks before being distributed to edge devices, exclusive static verification is required before policy execution. This verification mechanism calls the aforementioned resource scheduling priority ranking matrix to perform conflict scanning and dependency analysis on each policy, ultimately outputting a policy transaction segment execution list with clearly defined resource access boundaries to guide the safe scheduling of subsequent execution phases. The entire verification process includes the following steps:

[0060] The system receives a set of policy entries to be issued, extracts and parses the resource access identifiers contained in each policy entry, and searches for other policy entries with potential conflict relationships based on a pre-generated resource scheduling priority ranking matrix. During the search, resource call behaviors between policies are cross-compared based on dimensions such as access type (read / write / bidirectional), resource granularity, and access time window to identify whether there are concurrent accesses to the same resource object with overlapping priorities. The core of this step is to use the scheduling priority information in the ranking matrix to perform ordered filtering of policy pairs, thereby improving conflict detection efficiency and reducing the false positive rate.

[0061] The identified policy conflict pairs are risk-classified and feature-labeled. Specifically, based on dimensions such as conflict type, sensitivity of resources involved, and strength of access order dependence, each conflict policy relationship is assigned a conflict risk level label, such as "high risk," "medium risk," or "low risk." Building on this, a conflict feature summary is generated for each policy entry, including information such as the access order of its dependent resources, the risk of being blocked, and the probability of being preempted. This step provides a policy-level conflict context for subsequent transaction partitioning and scheduling policy formulation.

[0062] After obtaining the conflict relationships and risk levels, the policy entries are segmented into transaction segments. Policy transaction segmentation refers to dividing a policy entry containing multiple resource access behaviors into several independently schedulable policy units according to resource call logic and risk nodes. Segmentation rules are implemented based on high-incidence conflict points or resource priority demarcation points, ensuring that each policy unit only accesses a set of non-conflicting or controlled resources during its lifecycle and can be independently incorporated into subsequent serial scheduling processes. This segmentation method avoids the risk of resource deadlock caused by the overall execution of policies and improves the security and flexibility of concurrent policy execution on edge devices.

[0063] The transaction segmentation results of all policy entries are aggregated to generate a policy transaction segmentation execution list. This execution list is structured according to factors such as policy unit priority, resource access boundaries, and scheduling order, guiding subsequent policy management and serial scheduling processes. Each policy unit in the execution list includes its resource access permission table and execution dependency description, ensuring that it can be accurately included in the management sequence at runtime without triggering resource conflicts or access conflict paths. By using this list, the policy exclusivity verification results are explicitly and structurally expressed in the static stage, effectively reducing the uncertainty and risk during policy execution.

[0064] Step 4: Load the fine-grained strategy transaction management container, and execute each strategy unit in the strategy transaction segment execution list as an independent transaction unit in a serial management mode. After each strategy unit completes the access operation on the resource objects involved, the resource lock release status is submitted synchronously to ensure that resource access remains atomic and cleanable during the entire strategy transaction execution process, and to prevent the recurrence of resource interlocking.

[0065] To ensure ordered access and secure release of critical resource objects during the execution phase of policy entries, and to prevent the recurrence of resource deadlocks and access conflicts, policy units that have undergone exclusive static verification and completed transaction segmentation must be loaded into a fine-grained policy transaction management container for scheduled execution. This execution process follows a strict serial management principle, ensuring that each policy unit executes sequentially as an independent transaction and commits its resource lock release status after resource access is completed, thus maintaining the atomicity and cleanupability of resource access during policy execution. The specific execution flow includes the following steps:

[0066] The generated policy transaction segment execution list is loaded, and the policy units are organized into a serial execution queue according to the order information in the list. Each policy unit carries the identifier of its associated transaction, a resource access permission table, access type (e.g., read, write, read-write), and required execution conditions. When loading the queue, the possibility of resource conflicts between policy units should be given priority to ensure that only one policy unit holds resource access permissions at any given time, thereby avoiding resource contention caused by concurrent scheduling. After loading, the policy transaction queue will serve as the execution entry point, sequentially calling policy units for scheduling.

[0067] Each policy unit is executed sequentially. When a policy unit is scheduled to run, it first sends a resource access request to the resource scheduling management logic. The scheduling management logic determines the resource request based on the resource access permission table carried by the policy unit, ensuring that the requested resource is not currently occupied by other policy units. Once the resource access permission is confirmed, the policy unit enters the execution state and begins the actual resource operation process, such as log writing, cache tag updating, or configuration interface writing. During execution, all resource access operations must be recorded in the transaction operation log to form a traceable access path for status verification during the subsequent resource release phase.

[0068] After a policy unit completes all its defined resource operations, it immediately enters the resource lock release determination phase. This phase first verifies, based on the operation log, whether the current policy unit has completed all its resource access actions and confirms that no anomalies occurred during the access operations. If the verification passes, a resource lock release command is issued to the resource scheduling and management logic. The release process is a synchronous operation; the resource handle must be cleared, the access status reset, and the access permissions revoked before the policy unit exits execution. This synchronous release mechanism effectively prevents policy units from leaving locked resources due to unexpected interruptions, execution failures, or logical jumps, avoiding the system entering an unrecoverable interlocked state.

[0069] After the resource release of a strategy unit is completed, its execution status is marked as "completed," and execution control is returned to the strategy transaction queue. The queue then schedules the next strategy unit according to a predetermined order. To improve scheduling controllability and execution efficiency, a scheduling status evaluation should be triggered after each strategy unit completes. This evaluation checks the resource availability of the remaining strategy units. If temporary resource conflicts exist, the scheduling order can be adjusted by inserting waiting or avoidance strategies, thereby achieving adaptive dynamic optimization within the queue. The entire strategy transaction execution process is marked by the complete release of the resource lock, ensuring a one-to-one correspondence between the resource lifecycle and the strategy execution lifecycle, forming an atomic, closed-loop resource access control structure.

[0070] This implementation method ensures strict resource isolation and orderly access during strategy transaction segmentation, preventing resource interlocking between strategy units and maintaining system stability and response efficiency in the face of high-frequency concurrent strategy scheduling. Compared to traditional stateless scheduling strategies, this approach offers greater execution reliability and fault recovery capabilities, providing a robust operational support foundation for the strategy engine on edge devices.

[0071] Step 5: Construct a telemetry feedback mechanism for strategy transaction execution. During the operation of the strategy transaction managed container, collect information such as the execution time, queuing depth, and resource lock wait count of each strategy unit in real time. Combine this with the parameter adaptive model to calculate the resource contention intensity index of the current system, which is used to dynamically assess the resource conflict density and strategy scheduling pressure.

[0072] To achieve observability of the state and dynamic adjustment capability of scheduling behavior during the execution of strategic transactions, a complete telemetry feedback mechanism for strategic transaction execution needs to be constructed. This mechanism can continuously collect key execution indicators during the operation of the strategic transaction managed container and, through real-time analysis, calculate the current system's resource contention intensity index, thereby quantitatively assessing resource conflict density and strategic scheduling pressure, serving as a trigger factor for subsequent scheduling hot reconfiguration. The entire telemetry feedback process includes the following steps:

[0073] Before the strategy transaction managed container starts, a telemetry status record structure is initialized for each strategy unit to be executed, and key operational metrics to be collected during its execution lifecycle are predefined. These metrics include, but are not limited to, the cumulative execution time of the strategy unit, the queuing depth of the strategy unit in the execution queue, resource lock wait count, and resource lock holding duration. To ensure accuracy and low intrusion in data collection, telemetry data is collected through a non-blocking event listening mechanism. Updates to each key metric are bound to corresponding lifecycle event trigger points, such as entering the queue, acquiring execution rights, completing resource access, and releasing locks, achieving seamless data capture integrated with the execution process.

[0074] Telemetry data generated by each strategy unit during actual operation is collected and recorded in real time. An execution status table is maintained in the strategy transaction management container to centrally store the current and historical execution status of each strategy unit. Execution time is calculated from the time difference between the strategy unit's scheduling initiation and lock release completion. Queue depth is determined based on the length of the preceding queue when the strategy unit enters the execution queue. Resource lock wait count reflects the number of polling times or latency periods it has waited for available resources after entering the scheduler. Each metric has a timestamp and context label for subsequent statistical modeling and trend analysis. Telemetry data in this stage is buffered and updated in a structured manner, ensuring historical data traceability and real-time data sampleability.

[0075] Based on the aforementioned telemetry data, a parameter adaptive model is invoked to dynamically model the execution status of policy transactions and calculate a resource contention intensity index. This index is a comprehensive scoring metric used to reflect the current resource usage intensity and policy scheduling congestion within the system. The parameter adaptive model employs a multi-dimensional weighted fusion approach, using execution time, average queuing depth, and resource lock wait count as input variables. A real-time contention score is generated through sliding window calculation and weighted regression. The model dynamically adjusts the weight configuration based on factors such as the complexity of policy entries, the sensitivity level of resource objects, and the system's operating status, ensuring that the calculation results accurately reflect the actual system load. The resource contention intensity index is output as a percentage; a higher value indicates more severe resource conflicts, greater policy execution congestion, and lower scheduling efficiency.

[0076] After the resource contention intensity index is generated, it is immediately returned to the policy scheduling management logic as a key judgment parameter for dynamic scheduling reconfiguration. Multiple contention threshold levels are preset, such as "normal," "warning," and "critical." When the resource contention intensity index crosses a set threshold, the policy scheduling evaluation mechanism is triggered, and a snapshot of the telemetry status of all policy units is recorded. This provides real-time driving evidence and execution context reference for subsequent policy hot reconfiguration phases. Furthermore, this telemetry mechanism supports historical data aggregation and periodic review analysis, which can be used to generate policy scheduling optimization suggestions, identify resource hotspot trends, and further improve the system's adaptability to large-scale policy sets and resource governance capabilities.

[0077] Through the telemetry feedback mechanism of this implementation, the entire process of policy transactions is visualized and its status quantified during operation, greatly enhancing the policy engine's ability to perceive operational pressure and its early warning capability for resource conflict risks. This mechanism not only possesses real-time response characteristics but also predicts trends in resource contention, making it a key supporting technology for ensuring the security, stability, and efficiency of policy scheduling.

[0078] Step 6: Based on the resource contention intensity index, trigger the policy scheduling hot reconfiguration mechanism, dynamically recalculate the resource scheduling priority sorting matrix, and perform plug-and-play optimization on the execution sequence of the policy transaction units being executed, including reordering, lazy loading, or priority promotion operations, in order to alleviate resource conflict hotspots and optimize policy execution efficiency.

[0079] In this embodiment, to further alleviate potential resource access hotspots, execution congestion, and scheduling bottlenecks during policy execution in industrial control networks, and to improve policy execution efficiency and system stability, a policy scheduling hot reconfiguration mechanism needs to be dynamically triggered based on the established resource contention intensity index. This mechanism can dynamically reconfigure the resource scheduling priority ranking matrix and, based on the latest resource load status and policy queuing situation, perform plug-and-play optimization adjustments to the policy transaction execution sequence, thereby achieving rapid resolution of resource conflict hotspots and continuous optimization of system performance. The hot reconfiguration process mainly includes the following steps:

[0080] During the operation of the strategy transaction managed container, the resource contention intensity index generated by the telemetry feedback mechanism is continuously monitored and compared with pre-set multi-level response thresholds. When the resource contention intensity index is detected to exceed the scheduling trigger threshold, such as reaching the "severe contention" level, it indicates that there are relatively dense resource conflicts, policy blocking, or resource starvation in the current policy queue. At this time, the scheduling hot reconfiguration process is immediately initiated. The triggering action simultaneously loads data such as the current policy execution status table, resource access frequency statistics, and policy priority level table into the scheduling reconfiguration control process, providing complete context information for subsequent operations.

[0081] Based on telemetry data such as resource access history, lock wait time, and execution time of all policy transaction units in the current policy queue, the resource scheduling priority ranking matrix is ​​dynamically recalculated. The new ranking matrix, based on the original topology, incorporates indicators such as the conflict frequency, scheduling failure count, and average waiting latency of each resource node at the current moment to adjust the priority level of each resource object in access scheduling. The recalculation of scheduling priorities aims to minimize resource access conflicts. A weighted directed graph sorting algorithm is used to rearrange the resource sequence, ensuring that highly contested resources are allocated later or released first, while low-conflict resources are executed first. This results in a more rational resource distribution and load balance in the execution order of policy entries.

[0082] Based on the new resource scheduling priority sorting matrix, a plug-and-play optimization operation is initiated on the execution sequence of policy transaction units in the current execution queue. This optimization process includes three key actions: (1) Reordering: Delaying the execution of policy units on low-priority resource access paths in the original scheduling sequence and scheduling high-priority policies in advance to eliminate blocking chains; (2) Delayed loading: Temporarily removing policy units involving severely contentious resources from the scheduling queue and reloading them after one or more rounds of delay to wait for the resource contention situation to ease; (3) Priority boosting: Implementing priority boosting operations for lightweight policy units with short execution time and few resource dependencies, enabling them to complete quickly and release resources, and then scheduling high-load policy units, thereby achieving a dynamic scheduling effect of "unblocking first and then blocking". This plug-and-play optimization method supports real-time changes in policy order during execution without relying on queue reconstruction, thereby greatly improving the response speed and practicality of scheduling.

[0083] After the scheduling sequence adjustment is completed, the execution scheduling table in the policy transaction managed container will be updated, and the policy transaction recovery process will be triggered to restore the execution of policy units according to the optimized order. Simultaneously, the entire scheduling process is recorded and analyzed. Data such as resource load curves, policy execution trajectories, and conflict resolution effects involved in the hot refactoring process are written to the log archive for subsequent training and optimization of the policy scheduling algorithm. Furthermore, the system automatically performs consistency checks during the hot refactoring process to ensure that the scheduling order adjustment does not disrupt existing resource dependencies and transaction integrity between policies, guaranteeing semantic consistency and resource isolation. Through the implementation of this mechanism, even in resource-contested operating environments, the system can maintain the continuity of policy execution and scheduling stability.

[0084] Through the policy scheduling hot reconfiguration mechanism of this implementation, the system can autonomously detect and alleviate resource access pressure during policy execution, forming a closed-loop optimization process of "detection-response-adjustment-recovery". This significantly enhances the adaptability and recovery capability of the policy scheduling engine when facing sudden loads, resource congestion or execution bottlenecks, and further ensures the safe and stable operation of the industrial control network.

[0085] The cloud-edge collaborative industrial control network security protection method based on a policy library provided by this invention can effectively solve the problems of resource conflicts, execution deadlocks, and system downtime caused by the lack of mutual exclusion mechanisms at the resource access level for multiple policy entries in existing technologies. This method constructs an exclusive identifier gene and a directed graph of resource mutual exclusion to achieve a structured expression and graph-based modeling of resource access relationships between policies, enabling early identification of potential deadlock paths. Combined with static conflict verification and transaction segmentation mechanisms, controllable resource boundaries can be built before policy issuance to prevent conflicts during execution. Through serial management and synchronous lock release mechanisms, the atomicity and cleanupability of resource use during policy execution are ensured, effectively preventing resource interlocks from recurring. A telemetry feedback mechanism enables real-time monitoring of policy operation status and quantitative assessment of resource contention intensity. Supplemented by a hot reconfiguration mechanism, the execution order can be dynamically adjusted to alleviate execution bottlenecks. Overall, this method improves the edge security engine's ability to control resource conflicts and its adaptive ability to schedule policies, significantly enhancing the stability, responsiveness, and sustainable operation of industrial control networks when facing high-concurrency protection strategies, thereby constructing a closed-loop security protection system with intelligent perception, dynamic control, and fault self-recovery capabilities.

[0086] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A cloud-edge collaborative industrial control network security protection method based on a policy library, characterized in that, Includes the following steps: Step 1: Construct a policy resource metadata identification system, perform exclusive modeling of log files, tag caches, and configuration interfaces, and generate a unified resource access identification gene; Step 2: Construct a resource mutual exclusion directed graph based on the resource access identifier gene, generate potential deadlock loop information through graph structure analysis, and calculate the resource scheduling priority ranking matrix accordingly. Step 3: Based on the sorting matrix, perform an exclusive conflict scan on the policy items to be issued, identify high-risk policy combinations, and generate a policy transaction segment execution list with controllable resource boundaries. Step 4: Based on the execution list, each strategy unit is executed serially and the resource lock is released synchronously after the resource operation is completed. Step 5: During execution, the resource contention intensity index is calculated using the parameter adaptive model to assess the current resource conflict density and scheduling pressure. Step 6: Dynamically adjust the resource scheduling priority ranking matrix based on the contention intensity index, and perform plug-and-play optimization on the strategy execution sequence to alleviate resource conflict hotspots and improve strategy execution efficiency.

2. The cloud-edge collaborative industrial control network security protection method based on a policy library as described in claim 1, characterized in that, The steps to construct a policy resource metadata identification system include: Extract three key resource objects that are frequently accessed during policy execution: log files, tag cache, and configuration interfaces. Then, classify and organize them according to their functional attributes, access methods, and operation frequency to form a resource list and assign a unique identifier. A resource access behavior matrix is ​​established based on access granularity, operation type, and temporal dependency to make resource conflict relationships explicit. An exclusive identifier gene consisting of a resource category code, access mode code, access unit code, and conflict priority code is generated, and the identifier gene is bound to the resource operation description of each policy entry to realize a structural mapping between policies and resource access relationships.

3. The cloud-edge collaborative industrial control network security protection method based on a policy library according to claim 2, characterized in that, The steps for constructing a resource mutual exclusion map based on exclusive marker genes include: The strategy entries carrying the identifier genes are parsed to extract the relevant resource access attributes and construct resource access conflict pairs. The conflict pairs are mapped to a directed graph structure of mutually exclusive resources, where nodes represent resource access units and edges represent access dependencies. Deadlock closed-loop paths are identified using graph traversal and loop detection algorithms, and topological characteristic indices of each node are calculated. A resource scheduling priority ranking matrix is ​​generated based on topological features, which serves as the input for static policy verification.

4. The cloud-edge collaborative industrial control network security protection method based on a policy library according to claim 1, characterized in that, The steps for generating a strategy transaction segment execution list with controllable resource boundaries include: Based on the resource scheduling priority ranking matrix, a conflict scan is performed on the resource access identifier genes contained in each policy entry to identify policy combination relationships with potential resource access conflicts. The identified conflict relationships are risk-classified and feature-annotated to generate a summary of strategy conflict features; Based on the conflict risk nodes, the policy entries are segmented into transaction segments to form independently schedulable policy units. All policy units are then aggregated to generate a policy transaction segment execution list to guide subsequent scheduling and execution.

5. A cloud-edge collaborative industrial control network security protection method based on a policy library according to claim 1, characterized in that, The steps for managing the execution of each policy unit serially based on the execution list and synchronously releasing resource locks after resource operations are completed include: Organize the policy units in the policy transaction segmentation execution list into a serial execution queue, and schedule and request resource access permissions in sequence; After completing the resource operation, verify the operation log and submit the resource lock release command synchronously after confirming that there are no errors. Update the execution status of the policy unit and return control to schedule the next policy unit; During the scheduling process, the execution order is dynamically adjusted according to the resource availability status, forming an atomic, closed-loop resource access control process.

6. The cloud-edge collaborative industrial control network security protection method based on a policy library according to claim 1, characterized in that, The steps for calculating the resource contention intensity index using a parametric adaptive model include: Initialize the telemetry status record structure for each policy unit before starting the policy transaction managed container; During execution, telemetry data is collected and updated in real time to construct an execution status table; The resource contention intensity index is calculated based on the adaptive model of data call parameters, and the resource contention intensity index is returned to the scheduling management logic as the triggering basis for policy scheduling hot reconfiguration.

7. A cloud-edge collaborative industrial control network security protection method based on a policy library as described in claim 6, characterized in that, The steps for dynamically adjusting the resource scheduling priority ranking matrix based on the contention intensity index and performing plug-and-play optimization on the strategy execution sequence include: When the resource contention intensity index exceeds the preset threshold, the scheduling hot reconfiguration process is initiated, and the current policy execution status and resource access data are loaded. Based on the data, the resource scheduling priority ranking matrix is ​​dynamically recalculated to adjust the access priority level of each resource. Based on the new sorting matrix, plug-and-play optimizations are performed on the strategy transaction execution sequence, including reordering, lazy loading, and priority promotion. The scheduling table is then updated to resume strategy execution, ensuring that the scheduling order adjustment maintains consistency between resource dependencies and transaction integrity.

Images