Strategy automatic negotiation system of data space connector

Abstract

The invention relates to the technical field of policy negotiation, in particular to an automatic policy negotiation system of a data space connector, which comprises an association module used for establishing a mapping relation in a data space; the trigger module is used for continuously monitoring the change of the network topology level position and generating a trigger instruction when the change is detected; the arbitration module is used for receiving the trigger instruction; the arbitration module is configured to analyze the trigger instruction, locate a strategy inheritance source of an affected node according to the trigger instruction and obtain a current strategy state of the affected node; and furthermore, by comparing the version identifiers of the strategy inheriting source and the influenced node on the corresponding strategy hierarchy, calculating to obtain a strategy increment needing to be synchronized to the influenced node, and controlling the synchronous execution of the strategy increment in the data space and the strategy to take effect. According to the method and the device, dynamic mapping of topology and strategies can be established, low-delay increment synchronization and hierarchical strategy adaptation during node change are realized, and global consistency is guaranteed.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of policy negotiation, and in particular to a policy automatic negotiation system of a data space connector. BACKGROUND

[0002] In the process of industrial internet and industrial digitization, the data interaction network of an enterprise is evolving from a traditional centralized and flat architecture to a distributed and multi-layered "cloud-edge-end" data space. For example, in the field of intelligent manufacturing, a typical data space architecture includes a cloud data center as a root node, a factory workshop edge server as an intermediate parent node, and various intelligent devices on the production line as end child nodes. In such a dynamic and hierarchical data environment, ensuring consistency among all nodes in terms of data format, security policy, transmission protocol, etc. is the basis for ensuring cross-level business collaboration and smooth data interaction. The policy automatic negotiation system, as the "nerve center" connecting various data space components, needs to efficiently and reliably synchronize and coordinate policy rules when nodes join, leave or the network topology changes dynamically. Its performance directly determines the agility, stability and operational safety of the entire data space.

[0003] Currently, common policy negotiation methods mostly rely on centralized distribution or network-wide broadcast mechanisms. When a new node joins the network, the central node usually issues a complete set of policies to it, or the new node broadcasts queries to all known nodes in the network and integrates the policies by itself. Such methods can run in an environment with simple structure and static nodes, but in essence, they treat policies as static configuration items independent of the network topology. The logic of policy synchronization is not closely related to the actual physical or logical hierarchical structure of the data space, and lacks awareness and utilization of the hierarchical position and belonging path of the nodes. Therefore, in a multi-layer data space with dynamic topology structure, such methods are difficult to achieve efficient and accurate policy coordination.

[0004] Taking a three-tiered data space—"cloud data platform—workshop edge gateway—production line welding robot"—built by an automobile manufacturing company as an example, when a brand-new intelligent production line (containing 10 welding robots) needs to be connected, the existing negotiation mechanism will trigger a series of chain problems. First, because the system cannot perceive that the newly added robot belongs only to the specific topology path of "workshop A → production line B", it will lead to full-broadcast policy synchronization: each robot initiates a policy request to all nodes in the network, and the cloud integrates all policies before uniformly distributing them. This process generates an end-to-end delay of up to 12 seconds, causing the data initialization time before the production line starts to be too long, seriously delaying the production rhythm. Second, the more fundamental problem lies in the disorder of policy inheritance relationship: the new robot directly obtains the global basic policy from the cloud node, which may include the rule of "data sampling frequency of 1 minute / time" applicable to other workshops, but this directly conflicts with the high-frequency monitoring requirement of "sampling frequency of 10 seconds / time" stipulated by its direct superior workshop edge gateway. This cross-level inheritance conflict, caused by the lack of hierarchical policy constraints, can result in data uploads from robots that do not conform to the expectations of their direct parent nodes, triggering system alarms or even production line shutdowns. The underlying reason is that existing technologies have failed to establish a metadata model with a strong correlation between "policy rules" and "network topology." This means they cannot intelligently identify and push only the differences during synchronization, nor can they apply the correct constraint rules based on the node's topological hierarchy during policy inheritance. Furthermore, they lack a closed-loop verification mechanism that traces back from child nodes to the root node to ensure global consistency after synchronization. This makes it impossible to detect and correct the risk of local tampering or drifting of policies during dynamic synchronization in a timely manner. Therefore, the core technical deficiency of existing technologies when facing dynamic, multi-layered industrial data spaces can be summarized as follows: the policy negotiation process is severely disconnected from the dynamic topology of the data space, lacking an end-to-end mechanism for deep collaboration between topology awareness and policy synchronization. This results in the system's inability to simultaneously achieve low-latency difference synchronization, hierarchical policy adaptation, and reliable global consistency guarantees when nodes dynamically change. Summary of the Invention

[0005] To establish a dynamic mapping between topology and policy, achieve low-latency incremental synchronization and hierarchical policy adaptation during node changes, and ensure global consistency, this application provides an automatic policy negotiation system for a data space connector.

[0006] This application provides an automatic policy negotiation system for a data space connector, employing the following technical solution: An automatic policy negotiation system for a data space connector, comprising: The association module is used to establish and maintain a globally unified mapping relationship in the data space. This mapping relationship associates and synchronizes the network topology level position of each node with the policy rules it needs to follow in real time. The triggering module, connected to the association module, is used to continuously monitor changes in the network topology hierarchical position, and when a change is detected, to generate a triggering command containing topology context information of the affected node based on the mapping relationship; An arbitration module, connecting the association module and the triggering module, is used to receive the triggering instruction. The arbitration module is configured to: parse the topology context information in the triggering instruction, thereby locating the policy inheritance source of the affected node from the mapping relationship and obtaining its current policy state; then, by comparing the version identifiers of the policy inheritance source and the affected node at the corresponding policy level, and based on the hierarchical constraints defined in the mapping relationship, calculate the policy increment that needs to be synchronized to the affected node, and control the synchronous execution of the policy increment and the policy activation in the data space.

[0007] Optionally, the network topology hierarchy position in the mapping relationship is defined by multiple interrelated topology attributes to determine the position of the node and its hierarchical affiliation in the mapping relationship; the topology attributes include at least the node's hierarchy type, the identifier of its direct parent node, and the complete affiliation path from the root node to that node.

[0008] Optionally, the mapping relationship further divides the policy rules of each node into two interrelated levels: a basic policy level that is inherited from the node's direct parent node and constrains the node and its subordinate levels, and a personalized policy level that allows the node to extend its policies while adhering to the basic policy level; each policy level is associated with an independent identifier for identifying its content version.

[0009] Optionally, the arbitration module identifies policy differences by comparing the independent identifiers of the affected node and its direct parent node at the corresponding policy level, and merges the policy differences with the current policy state of the affected node to achieve incremental synchronization based on version comparison.

[0010] Optionally, the arbitration module further includes a rules engine configured to: automatically verify whether the content of the personalized strategy level conflicts with the rules of the basic strategy level when the arbitration module processes the personalized strategy level based on the independent identifier, and prevent it from taking effect when a conflict is found.

[0011] Optionally, the arbitration module is further configured to trigger a verification process along the complete home path of the affected node after the synchronous execution of the policy increment is completed; the verification process ensures global consistency by comparing the synchronized policy rules and their cryptographic digests between nodes level by level.

[0012] Optionally, the verification process is specifically implemented as a three-level consistency verification structure: the first level is executed between the policy rules of the affected node and its direct superior node; the second level is executed between the direct superior node and the root node; the third level is executed between the affected node and the root node; each level of verification is completed by comparing the cryptographic digests of the policy rules between the corresponding nodes.

[0013] Optionally, it also includes an evidence storage and traceability module, which is configured to record synchronization information, including the affected node identifier, the independent identifier of its policy level, and the verification results at each level generated by the verification process, into a tamper-proof distributed log after the verification process is completed.

[0014] Optionally, the triggering module is configured to: monitor three types of changes based on the mapping relationship: node addition, node removal, and network topology level adjustment; for each monitored change, extract information including the change type, the identifier of the affected node, and its current complete home path, and use this information to generate the topology context information in the triggering instruction.

[0015] In summary, this application includes the following beneficial technical effects: 1. This system establishes a dynamic mapping between network topology and policy rules. When a node change is detected, it accurately locates the source of policy inheritance based on the mapping relationship. It calculates and synchronizes policy increments by comparing version identifiers only. This fundamentally solves the problem of high full-scale synchronization latency caused by the disconnect between policy negotiation and topology structure in existing technologies. It achieves low-latency and accurate policy synchronization when nodes join, leave, or adjust their levels, significantly improving the overall response agility and operational efficiency of the dynamic data space.

[0016] 2. This system distinguishes node policy rules into two related levels: basic policies and personalized policies. By introducing a rule engine, it automatically verifies semantic conflicts between personalized policies and basic policies inherited from their superiors during the synchronization process. This effectively prevents rule contradictions caused by disordered cross-level policy inheritance relationships, ensuring the adaptability and coordination of policies in multi-layer topologies. This avoids system alarms or business interruptions caused by such issues and guarantees the stability and security of data interaction.

[0017] 3. After the policy synchronization is completed, this system triggers a three-level consistency verification process along the complete ownership path of the nodes. By comparing the cryptographic digests of the policy rules at each level and combining with the evidence storage and traceability module, key information of the entire process is recorded in the anti-tampering log. This constructs a closed-loop verification and auditing mechanism that traces back from the child nodes to the root node. This completely solves the problem that traditional methods cannot guarantee global consistency and are difficult to trace the synchronization process. It provides reliable consistency guarantee and post-event traceability for the policy synchronization results, greatly enhancing the credibility and maintainability of the system. Attached Figure Description

[0018] Figure 1 This is a flowchart for establishing dynamic mapping of topology strategies. Detailed Implementation

[0019] The following is in conjunction with the appendix Figure 1 This application will be described in further detail.

[0020] This application discloses an automatic policy negotiation system for data space connectors. For example... Figure 1 As shown, an automatic policy negotiation system for a data space connector establishes a dynamic mapping between network topology hierarchical locations and policy rules through the collaborative operation of an association module, a triggering module, an arbitration module, and an evidence storage and traceability module. This system achieves low-latency incremental synchronization, hierarchical policy adaptation, and global consistency guarantees when node topology changes. It specifically addresses the problems of policy negotiation being disconnected from topology structure, high synchronization latency, frequent policy conflicts, and unreliable consistency guarantees in existing technologies. The following section details the specific implementation process using a three-tiered data space scenario of the Industrial Internet ("cloud-edge-device").

[0021] The S1 association module constructs and maintains global mapping relationships. The association module constructs a globally unified mapping relationship within the data space, which associates and synchronizes the network topology level position of each node with the policy rules that the node must follow in real time.

[0022] S11 defines the topological attributes of the network topology hierarchy. To ensure that the location and hierarchical affiliation of each node within the data space are uniquely identifiable, the mapping relationship precisely defines the network topology hierarchy through three interrelated topological attributes. The hierarchy type clearly defines the node's category within the "cloud-edge-device" architecture, specifically categorized into root nodes, intermediate parent nodes, and terminal child nodes. This classification conforms to the general industry standard for industrial internet node hierarchy division and uses "Root / Parent / Child" enumeration values ​​for identification, facilitating data interaction and parsing between modules. For example, the cloud data center is labeled as Root, the workshop edge gateway as Parent, and the production line welding robot as Child.

[0023] Each node is assigned a unique UUID as its identifier, and this attribute directly records the UUID of the current node's direct parent node. Using this identifier, the system can quickly pinpoint the direct source of policy inheritance, reducing redundant calculations during policy tracing. For example, if the UUID of the end-point child node, the production line welding robot, is Device001, and its direct parent is the workshop edge gateway with the UUID Edge001, then the direct parent node identifier of Device001 is recorded as Edge001.

[0024] The complete attribution path adopts a chain structure of "root node UUID - intermediate parent node UUID - current node UUID", which fully presents the attribution link of a node extending from the root node to itself. This path structure provides a clear verification link for subsequent global consistency verification, avoiding omissions in the verification scope. For example, the complete attribution path of Device001 is Cloud001-Edge001-Device001, where Cloud001 is the UUID of the cloud root node.

[0025] Hierarchical structure of S12 node partitioning strategy rules With the topology attributes already defined, the mapping relationship further divides the policy rules of each node into two interconnected levels, with each level configured with an independent version identifier. This hierarchical division ensures the uniformity of the global policy while reserving space for personalized adaptation by nodes. The independent version identifier provides a clear basis for the subsequent identification of differences by the arbitration module, thereby improving the efficiency of incremental synchronization.

[0026] The rules at the basic policy level are inherited from the node's direct parent node. These rules impose mandatory constraints on the current node and its subordinate nodes, covering general rules that ensure the foundation of data interaction, such as data encryption standards, transmission protocols, and basic data formats. For example, Edge001's basic policy includes core rules such as the AES-256 encryption algorithm, the MQTT 3.1.1 transmission protocol, and a data sampling frequency of 10 seconds per iteration. These rules are directly synchronized to its subordinate end-point child nodes, such as Device001, and are enforced.

[0027] The personalized strategy hierarchy allows nodes to extend specific rules based on their own business needs, while strictly adhering to the basic strategy hierarchy rules. These hierarchical rules only apply to the current node and can meet the differentiated business scenario needs of different nodes. For example, the welding robot Device001 can set personalized rules such as equipment fault alarm thresholds within the basic strategy framework based on production line fault response requirements.

[0028] Both policy levels are associated with independent identifiers used to identify content versions. These version identifiers use semantic version numbers, following the SemanticVersioning 2.0.0 industry standard, in the format "major version number.minor version number.revision number". Major version numbers correspond to significant rule changes such as changes to the encryption algorithm, minor version numbers correspond to the addition of non-conflicting rules, and revision version numbers correspond to rule detail optimizations. For example, Edge001's basic policy version is V1.2.0, and its personalized policy version is V1.0.1, clearly reflecting the update status of the two types of policies.

[0029] S13 maintains real-time synchronization of mapping relationships. To ensure the accuracy and validity of the mapping data acquired by the triggering and arbitration modules, the association module employs a distributed storage architecture, storing the mapping data in the root node, all intermediate parent nodes, and key end child nodes. The selection of key end child nodes is based on the importance of the node's business, typically covering core equipment such as production line control and data acquisition. The stability of the strategy for these nodes directly impacts production continuity.

[0030] The distributed storage nodes employ the Raft consensus mechanism to ensure data consistency. This mechanism is a commonly used consistency guarantee algorithm in distributed systems, combining high reliability with ease of implementation. When the topology attributes or policy rules of a node change, the association module immediately initiates a synchronization process, pushing the changed information to all storage nodes. The average time of this synchronization process can be stably controlled within 100ms. This speed meets the real-time requirements of policy response in industrial scenarios, effectively avoiding policy synchronization direction deviations or conflicts caused by data inconsistency.

[0031] The S2 trigger module monitors topology changes and generates trigger commands. The triggering module continuously acquires topology attribute data from the mapping relationship, and monitors node topology changes by dynamically analyzing this data. This ensures that the subsequent policy synchronization process can be triggered in a timely manner when the node state changes, providing accurate decision input for the arbitration module.

[0032] S21 clarifies the types of topology change monitoring. The triggering module adopts a dual mechanism of "active detection + passive response" to realize change monitoring. The core technical solution is based on the topology detection protocol and heartbeat detection mechanism commonly used in industrial networks.

[0033] The network topology detection protocol uses the LLDP protocol, commonly used in industrial scenarios. This protocol quickly obtains the port connection relationships and hierarchical affiliation of nodes through neighbor discovery messages exchanged between devices, providing underlying data support for identifying topology hierarchical adjustments. Simultaneously, a trigger module, coupled with a heartbeat detection mechanism, enables node online status awareness. The heartbeat interval is set to 5 seconds; if no response is received after three consecutive heartbeats, the node is considered offline. This parameter has been verified through simulations in 100 different industrial scenarios, avoiding the excessive network bandwidth consumption caused by intervals below 5 seconds and resolving the excessive delay in offline determination caused by intervals above 10 seconds, fully adapting to the response speed requirements of production line equipment.

[0034] Based on the aforementioned technologies, the triggering module can accurately monitor three types of core topology changes. The first type is node joining. When a new node accesses the data space, it sends an LLDP neighbor message. The triggering module identifies the event through this message. For example, when five welding robots sequentially access the workshop edge gateway Edge001, the initial access broadcast of each robot will be captured by the triggering module. The second type is node leaving. When an existing node leaves the network due to a fault or human intervention, the triggering module determines the event through heartbeat timeout. For example, after a sudden power outage, the triggering module confirms the node's exit status after receiving three consecutive heartbeat responses. The third type is network topology hierarchy adjustment. When a node's parent node affiliation changes, the "parent node identifier" field in its sent LLDP message will change accordingly. The triggering module identifies the event through this change. For example, when the workshop edge gateway Edge002 is moved from being a subordinate of root node Cloud001 to being a subordinate of Cloud002, the root node UUID in its LLDP message changes from Cloud001 to Cloud002, and the triggering module determines the topology hierarchy adjustment based on this.

[0035] S22 Extract Topology Context Information Upon detecting various changes, the triggering module immediately extracts key topology context information from the global mapping relationship of the associated modules. This information comes from the topology attributes defined in the mapping relationship, which ensures that the data is compatible with the subsequent arbitration logic.

[0036] The triggering module first identifies the type of change and records it using three fixed identifiers: "node join," "node leave," and "topology level adjustment." This provides a direct basis for the arbitration module to differentiate its processing logic. Then, it extracts the identifier of the affected node, which is the unique UUID assigned to the node by the association module. For example, in a node join event, the UUID of Device002 is extracted, and in a node leave event, the UUID of Device003 is extracted, ensuring that subsequent policy synchronization can accurately locate the target node.

[0037] The complete attribution path is one of the core pieces of information extracted. The triggering module directly calls the chained attribution path data of the node in the mapping relationship. For example, the complete attribution path of Device002 is Cloud001-Edge001-Device002. This path clearly presents the hierarchical link of the nodes, laying a solid foundation for the arbitration module to locate the source of policy inheritance. Finally, the current policy status is extracted, mainly recording the currently effective basic policy version and personalized policy version identifier of the affected nodes. The version identifier of newly added nodes is empty, while existing nodes directly obtain the current version stored in the mapping relationship. For example, the basic policy version of Device006 is V1.1.0. This information provides benchmark data for subsequent version comparisons.

[0038] Extracting all this information allows triggering commands to have the characteristics of "clear event, clear objective, and sufficient evidence," avoiding the arbitration process being stalled due to "incomplete information" in traditional triggering signals.

[0039] S23 generates trigger command The trigger module encapsulates the extracted topology context information into trigger commands in a fixed format. These commands are encapsulated in JSON format, which is lightweight and easy to parse, meeting the needs of data interaction between modules in industrial scenarios. The trigger commands have a predefined structured format, specifically including the following fields: 1. Change type: Indicates the type of topology event that triggers policy negotiation. Its value is a predefined enumeration type, including "node joins", "node leaves" or "topology level adjustment"; 2. Affected Node Identifier: Used to uniquely identify the node that has undergone topology changes. Its value is the unique identifier (UUID) assigned to the node by the associated module, such as "Device002"; 3. Complete home path: Used to describe the complete topology link from the root node to the affected node. Its value is a sequence of node UUIDs connected by hyphens "-", such as "Cloud001-Edge001-Device002"; 4. Current policy status: This records the policy version information associated with the affected node at the time of triggering. Its value is an object containing the following subfields; Base policy version: The version identifier of the base policy currently in effect for the affected node. If the node is newly added, this value is an empty string. Personalized policy version: The version identifier of the currently effective personalized policy level for the affected node. If the node is newly added or not configured, this value is an empty string.

[0040] 5. Trigger timestamp: Used to record the time when the instruction was generated. Its value is a UTC time string conforming to the ISO 8601 standard, such as "2024-06-10T09:15:23.456Z".

[0041] Trigger commands are pushed to the arbitration module via the MQTT 3.1.1 protocol. This protocol is consistent with the transmission protocol defined in the basic policy of the associated module, ensuring protocol compatibility. Verified through 1000 transmission tests, the transmission latency of this push method can be stably controlled within 10ms, far below the typical 100ms response threshold in industrial scenarios, meeting the real-time requirements of policy synchronization. Simultaneously, the "publish-subscribe" mode of the MQTT protocol ensures no command transmission loss. Even with network fluctuations, message retransmission can be achieved through QoS level 1 settings, providing a reliable guarantee for the stable startup of the subsequent arbitration process.

[0042] S3 Arbitration Module Execution Strategy Incremental Synchronization and Conflict Verification The arbitration module receives the trigger command pushed by the trigger module. Based on the global mapping relationship of "network topology hierarchical location - policy rule" constructed by the associated module, it locates the policy source by parsing the topology context information in the command, and then achieves incremental synchronization by combining the version identifier. It avoids policy conflicts with the help of the rule engine, ensuring that the policy synchronization is accurate, efficient and in compliance with hierarchical constraints.

[0043] S31 parses the trigger command and locates the source of policy inheritance. The arbitration module has a built-in JSON parser that conforms to the RFC8259 standard. This parser can quickly extract topology context information from the trigger command. This information includes core content such as the affected node identifier, the complete ownership path, and the current policy status, all of which are compatible with the data format in the mapping relationship of the associated modules.

[0044] The arbitration module uses both the "direct parent node identifier" and the "complete ownership path" as dual criteria to accurately pinpoint the policy inheritance source of the affected node from the mapping relationship. This source explicitly points to the node's direct parent node. For example, the direct parent node identifier of the affected node Device002 is Edge001, and the complete ownership path is Cloud001-Edge001-Device002. The arbitration module cross-validates these two attributes to ultimately determine that Edge001 is the policy inheritance source of Device002.

[0045] After location is established, the arbitration module retrieves the complete policy status of Edge001 from the mapping relationship, including the basic policy level version V1.2.0, the personalized policy level version V1.0.1, and the specific rule content corresponding to the two levels. Simultaneously, the arbitration module extracts the current policy status of Device002. The newly added Device002's basic and personalized policy versions are both empty. This data provides a direct benchmark for subsequent version comparisons and incremental calculations.

[0046] S32 compares the version identifier and calculates the policy increment. The arbitration module employs a semantic versioning-based comparison algorithm, which adheres to the SemanticVersioning 2.0.0 industry standard. This algorithm accurately identifies policy differences through a hierarchical comparison of major version numbers, minor version numbers, and revision version numbers. The comparison process is executed independently at both the basic policy level and the personalized policy level, ensuring comprehensive difference identification.

[0047] The incremental calculation at the basic policy level follows the principle of "difference extraction". If the affected node is a newly added node, such as Device002, which has no basic policy record, the arbitration module will determine the complete basic policy of the policy inheritance source as the policy increment. If the affected node already has a basic policy version, such as Device006's current basic policy version is V1.1.0, while its parent node Edge001's basic policy version is V1.2.0, the algorithm will identify the difference in minor version number by comparison and extract the new rule "data format changed from JSON to Parquet" as the policy increment.

[0048] Incremental calculations at the personalized strategy level are based on compatibility with the basic strategy. If the affected node lacks a personalized strategy and the mapping relationship indicates that the node allows strategy extension, the arbitration module will generate a personalized strategy increment based on the node's business attributes, such as configuring a "welding current abnormal threshold" rule for the welding robot Device002. If the affected node already has a personalized strategy, the arbitration module only synchronizes new rules that do not conflict with the policies of the superior node. This incremental synchronization mode significantly reduces data transmission volume, and the strategy response efficiency of the dynamic data space is significantly improved.

[0049] S33 rule engine performs policy conflict verification. The arbitration module has a built-in lightweight rule engine that uses a logical semantic matching verification algorithm. It is the core component that ensures the validity of policy-level constraints. Its core function is to automatically complete the rule conflict verification with the basic policy level when processing personalized policy levels.

[0050] The rule engine's verification logic revolves around the "priority of the basic policy." The engine breaks down each rule of the personalized policy into semantic units and matches them one by one with the constraint rules of the basic policy. For example, if the basic policy explicitly specifies the encryption algorithm as AES-256, and the personalized policy includes a configuration requirement for DES encryption, the engine quickly identifies this conflict through semantic comparison of the encryption algorithm type library.

[0051] Regarding the verification results, the rule engine executes a clear processing mechanism. If a conflict is detected, the engine immediately prevents the personalized policy from taking effect and returns detailed prompts to the corresponding node, including the conflict content and the basic policy requirements, along with compliance suggestions, such as "It is recommended to use AES-256 or its compatible algorithm SM4". If no conflict is detected, the engine allows the personalized policy to take effect in conjunction with the basic policy, thereby improving the conflict detection accuracy of the rule engine, reducing the policy conflict rate, and effectively avoiding system alarms or production line downtime caused by policy conflicts.

[0052] S4 executes the global consistency check process. After the arbitration module completes policy incremental synchronization and conflict verification, it will automatically trigger the global consistency verification process. This process uses the complete ownership path of the affected nodes as a clue and compares the policy rules level by level to ensure that the data is transmitted from the root node to the end child nodes without deviation or tampering.

[0053] S41 initiates the home path verification process. After the strategy increment is executed synchronously, the arbitration module starts the verification process asynchronously. This asynchronous design avoids the verification operation from occupying the main business thread resources, ensuring the continuous and stable operation of core businesses such as production line equipment data acquisition and instruction execution.

[0054] The trigger signal for the verification process contains two core pieces of information: the complete attribution path of the affected node and the synchronized policy version identifier. The complete attribution path ensures that the verification scope accurately covers the entire link from the root node to the affected node. For example, the path of Device002 is Cloud001-Edge001-Device002, which clearly indicates that the verification needs to involve three nodes: Cloud001, Edge001, and Device002. The synchronized version identifier provides a clear policy content benchmark for hash value calculation, avoiding inaccurate verification due to policy version confusion.

[0055] S42 performs a level 3 consistency check. The three-level verification uses the SHA-256 cryptographic digest algorithm. The verification is achieved by comparing the hash values ​​of the policy rules. The same policy content will generate a fixed and unique hash value. If the hash values ​​are inconsistent, it directly indicates that there is a difference in the policy.

[0056] The first-level verification focuses on the policy consistency between the affected node and its direct parent node. The arbitration module calculates the policy hash value of the affected node after synchronization, as well as the policy hash value of its direct parent node, and then performs a comparison operation. Taking Device002 as an example, the system calculates the policy hash value H2 of Device002 after synchronization, and then calculates the policy hash value H1 of its direct parent Edge001. If H2 and H1 are completely consistent, the first-level verification passes, indicating that the policies of the affected node and its direct parent node are completely matched.

[0057] The second-level verification aligns the policies of the direct parent node and the root node. The arbitration module calculates the policy hash value of the direct parent node and then retrieves the policy hash value of the root node for comparison. Taking Edge001 and Cloud001 as an example, the policy hash value H1 of Edge001 and the policy hash value H0 of the root node Cloud001 are calculated. If H1 and H0 are completely identical, the second-level verification passes, indicating that the policy of the direct parent node conforms to the global constraints of the root node.

[0058] The third-level verification forms a closed loop across the entire link. It directly compares the policy hash values ​​of the affected node and the root node. The system calculates the policy hash value H2 of the affected node and the policy hash value H0 of the root node. If H2 and H0 are completely consistent, the third-level verification passes, proving that the policy of the affected node remains consistent with that of the root node after being passed through the hierarchy.

[0059] This three-level verification structure forms a complete verification closed loop, effectively avoiding the omissions of single-level verification and greatly reducing the risk of policy drift.

[0060] S43 processes and verifies the results. The arbitration module summarizes the results of the three-level verification and performs the corresponding processing. If all three-level verifications pass, the arbitration module determines that the global consistency meets the standard, the verification process ends normally, and the policy of the affected nodes officially takes effect and is put into use.

[0061] If any level of verification fails, i.e., a hash value mismatch occurs, the arbitration module will immediately trigger a resynchronization process. The resynchronization process will backtrack to the policy incremental calculation step S3, re-executing operations such as version comparison, incremental extraction, and conflict verification. After completion, the three-level consistency verification will be restarted until all levels of verification pass. This retry mechanism ensures that the policy achieves end-to-end consistency in a dynamically changing topology environment, providing reliable guarantees for cross-level data interaction.

[0062] The S5 evidence storage and traceability module records synchronization information. After the global consistency verification process in step S4 is completed, the evidence storage and traceability module starts working. This module records key information of the entire policy synchronization process to an anti-tampering distributed log, and realizes the traceability and immutability of synchronization behavior by solidifying process data.

[0063] S51 collects synchronization information The evidence storage and traceability module follows the principle of "full-process coverage" in information collection, ensuring that the collected content fully reflects the entire chain of policy synchronization from initiation to verification completion, providing sufficient evidence for subsequent traceability. The collected information is divided into three categories according to functional attributes. Each category is independent yet interconnected, together forming a complete event file.

[0064] The core identification information is used to accurately locate the subject of the synchronization event, mainly including the affected node identifier, the basic policy-level independent identifier, and the personalized policy-level independent identifier. The affected node identifier is the unique UUID assigned by the associated module, such as Device002; the two policy-level independent identifiers correspond to the version number that takes effect after synchronization, such as basic policy V1.2.0 and personalized policy V1.0.0. This information can be directly associated with the specific policy version of a specific node, effectively avoiding confusion of the event subject.

[0065] The verification results provide direct proof of synchronization validity, including the specific results of the three-level consistency verification and the number of resynchronization attempts. The three-level verification results record the verification status of the affected node and its direct parent node, the direct parent node and the root node, and the affected node and the root node, respectively, all clearly marked with "pass" or "fail." The number of resynchronization attempts records the number of times a retry was initiated due to verification failure in step S4; if no retry occurred, it is recorded as 0. These data can intuitively reflect the stability of the synchronization process.

[0066] Timestamp information is used to construct the time sequence chain of synchronization events, covering the strategy synchronization start time, synchronization end time, and verification completion time. The timestamps use the UTC standard time format with millisecond-level precision, such as 2024-06-10T09:16:30.123Z. This high-precision time sequence record can clearly distinguish the order of occurrence of different events in multi-node concurrent synchronization scenarios, providing a time sequence basis for troubleshooting cross-node issues.

[0067] S52 writes to distributed log The evidence storage and traceability module writes the collected complete information into a distributed log. This log system is built on a mature consortium blockchain architecture used in industrial scenarios. The participating nodes of the consortium blockchain explicitly include the root node, all intermediate parent nodes, and key end child nodes, ensuring the distributed storage characteristics of the log data.

[0068] Log consistency is achieved between nodes through the Raft consensus mechanism, which is widely used in the field of distributed storage and has mature fault tolerance capabilities. Even if some nodes are temporarily offline, log records can still be synchronized normally and the content is consistent, meeting the reliability requirements of industrial scenarios.

[0069] The log system employs a role-based authorization permission management mechanism, strictly defining read and write permissions. Only management nodes are authorized to query logs, while ordinary nodes only have log writing permissions and no modification permissions. This permission isolation design can prevent log data from being maliciously tampered with at the source and achieve full traceability of the policy synchronization process.

[0070] If data interaction anomalies occur in subsequent production lines, managers can query the synchronization logs of the corresponding nodes through authorized accounts. By combining core identification information, verification results, and timestamps, they can quickly locate the root cause of the anomaly, determine whether the problem lies in the strategy synchronization deviation or the equipment itself, shorten the average troubleshooting time for strategy-related faults, and significantly improve operation and maintenance efficiency.

[0071] The implementation principle of the automatic policy negotiation system for a data space connector in this application embodiment is as follows: This system establishes a dynamic mapping relationship between network topology and policy rules. When the node topology changes, it performs incremental synchronization and hierarchical policy adaptation based on version identifiers, effectively solving the problems of high synchronization latency, frequent policy conflicts, and insufficient global consistency guarantees caused by the disconnect between traditional policy negotiation and topology structure. It adopts a topology-aware triggering mechanism and incremental calculation strategy, synchronizing only the differences, which greatly reduces the latency and bandwidth consumption of policy synchronization. At the same time, the rule engine performs conflict verification when expanding personalized policies, avoiding system anomalies caused by policy inheritance errors. Furthermore, by using three-level consistency verification and cryptographic digest comparison along the belonging path, it ensures the consistency and tamper-proofness of policy transmission from the root node to the end node. The entire process is recorded in the anti-tampering log through the evidence storage and traceability module, realizing the traceability and reliability improvement of policy synchronization behavior. Thus, it achieves low-latency, high-consistency, and highly auditable automatic policy negotiation in a dynamic multi-layer data space.

[0072] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A strategy automatic negotiation system for a data space connector, characterized in that, include: The association module is used to establish and maintain a globally unified mapping relationship in the data space. This mapping relationship associates and synchronizes the network topology level position of each node with the policy rules it needs to follow in real time. The triggering module, connected to the association module, is used to continuously monitor changes in the network topology hierarchical position, and when a change is detected, to generate a triggering command containing topology context information of the affected node based on the mapping relationship; An arbitration module, connecting the association module and the triggering module, is used to receive the triggering instruction. The arbitration module is configured to: parse the topology context information in the triggering instruction, thereby locating the policy inheritance source of the affected node from the mapping relationship and obtaining its current policy state; then, by comparing the version identifiers of the policy inheritance source and the affected node at the corresponding policy level, and based on the hierarchical constraints defined in the mapping relationship, calculate the policy increment that needs to be synchronized to the affected node, and control the synchronous execution of the policy increment and the policy activation in the data space.

2. The system according to claim 1, characterized in that, The network topology hierarchy in the mapping relationship is defined by multiple interrelated topology attributes to determine the location and hierarchical affiliation of nodes in the mapping relationship; the topology attributes include at least the node's hierarchy type, the identifier of its direct parent node, and the complete affiliation path from the root node to that node.

3. The system according to claim 2, characterized in that, The mapping relationship further divides the policy rules of each node into two interrelated levels: a basic policy level that is inherited from the node's direct parent node and constrains the node and its subordinate levels, and a personalized policy level that allows the node to extend its policies while adhering to the basic policy level; each policy level is associated with an independent identifier for identifying its content version.

4. The system according to claim 3, characterized in that, The arbitration module identifies policy differences by comparing the independent identifiers of the affected node and its direct parent node at the corresponding policy level, and merges the policy differences with the current policy state of the affected node to achieve incremental synchronization based on version comparison.

5. The system according to claim 3, characterized in that, The arbitration module also includes a rule engine, which is configured to: when the arbitration module processes the personalized policy level based on the independent identifier, automatically verify whether its content conflicts with the rules of the basic policy level, and prevent it from taking effect when a conflict is found.

6. The system according to claim 2, characterized in that, The arbitration module is also configured to trigger a verification process along the complete home path of the affected node after the synchronous execution of the policy increment is completed; the verification process ensures global consistency by comparing the synchronized policy rules and their cryptographic digests between nodes level by level.

7. The system according to claim 6, characterized in that, The verification process is specifically implemented as a three-level consistency verification structure: the first level is executed between the policy rules of the affected node and its direct superior node; the second level is executed between the direct superior node and the root node; the third level is executed between the affected node and the root node; each level of verification is completed by comparing the cryptographic digests of the policy rules between the corresponding nodes.

8. The system according to claim 6 or 7, characterized in that, It also includes an evidence storage and traceability module, which is configured to record synchronization information, including the affected node identifier, the independent identifier of its policy level, and the verification results at each level generated by the verification process, into a tamper-proof distributed log after the verification process is completed.

9. The system according to claim 2, characterized in that, The triggering module is configured to: monitor three types of changes based on the mapping relationship: node addition, node removal, and network topology level adjustment; for each monitored change, extract information including the change type, the identifier of the affected node, and its current complete home path, and use this information to generate the topology context information in the triggering command.

Images