A cloud-edge synchronization method and system of a distributed internet of things rule engine

Abstract

The application belongs to the technical field of Internet of Things, and discloses a cloud edge synchronization method and system of a distributed Internet of Things rule engine, wherein a state of a rule set is constructed as a verifiable Merkle-CRDT rule state tree, efficient and auditable final consistency is realized through synchronization of a state root hash; before a new rule state is activated, the system performs dynamic behavior verification on the new rule set in a pre-execution simulation sandbox based on digital twinning to find logical conflicts that cannot be identified by static detection; after the rule is activated, a causal anomaly detection engine driven by a large language model continuously monitors system operation, and once a causal anomaly is found that is contrary to physical common sense, the relevant rule is immediately dynamically placed in a runtime isolation sandbox to deprive it of control over the physical executor. Through the three-layer defense system of pre-verification, pre-rehearsal and in-process controllability, the application realizes cloud edge rule collaboration with high reliability and high resilience.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, specifically relating to a cloud-edge synchronization method and system for a distributed IoT rule engine. Background Technology

[0002] In a cloud-edge collaborative IoT architecture, the rule engine is the core for achieving scenario automation. Business rules defined in the cloud need to be reliably, securely, and correctly distributed to and executed on massive edge nodes. However, this process faces three major challenges: 1. Consistency and auditability challenges: In unstable network environments, the rule states between the cloud and edge nodes are prone to inconsistencies. Simple version control or basic conflict-free replication data types (CRDT) can guarantee eventual consistency, but they cannot provide tamper-proof protection against configuration changes or historical traceability, making it difficult to audit and assign responsibility once problems occur. 2. Deep logical correctness challenges: Even if the rule text is synchronized and consistent, the rule set itself may contain hidden logical conflicts. Traditional static semantic analysis can only find obvious contradictions (such as "simultaneously on and off"), but cannot find behavioral conflicts caused by dynamic environmental interactions (such as two rules triggering each other, causing high-frequency oscillations in the device actuator). Such dynamic conflicts are a major source of system instability. 3. Unknown risks and challenges during runtime: A rule that appears perfect in logic and simulation may have catastrophic consequences in the real physical world due to sensor attacks, physical failures of actuators, or unforeseen environmental interactions. Existing synchronization mechanisms completely ignore the ability to continuously monitor and intervene intelligently in real time during the rule execution phase, lacking resilience to cope with unknown risks. Summary of the Invention

[0003] The present invention aims to at least partially solve the aforementioned technical problems. Therefore, the objective of the present invention is to provide a cloud-edge synchronization method and system for a distributed Internet of Things (IoT) rules engine.

[0004] The technical solution adopted in this invention is as follows:

[0005] A cloud-edge synchronization system for a distributed IoT rules engine, comprising a cloud and at least one edge node, is based on a three-layer defense mechanism:

[0006] The first layer is the Merkle-CRDT rule state tree module located in the cloud and at the edge nodes. It records each evolution of the rule set as a verifiable node on a Merkle tree. Through the synchronization root hash, it ensures the immutability, traceability and eventual consistency of data synchronization, providing a trust foundation for the entire system.

[0007] The second layer is the pre-execution simulation sandbox module located at the edge node. Before activating any new rules, this module uses digital twin technology to dynamically rehearse the new rule set, aiming to discover dynamic behavioral risks that cannot be exposed by static analysis, thereby nipping the risks in the bud before activation.

[0008] The third layer is the runtime security monitoring and isolation module, which works in collaboration between the edge runtime agent and the cloud-based causal anomaly detection engine. During rule execution, this module monitors the system's causal chain (i.e., the logical relationship between behavior and outcome) in real time. Once an anomaly violating common sense is detected, the problematic rule is immediately confined to a runtime isolation sandbox, achieving precise and real-time risk control.

[0009] Specifically, both the cloud and the edge nodes are configured with:

[0010] A Merkle-CRDT rule state tree module is used to manage the state of a rule set as a Merkle tree consisting of content-addressed nodes, wherein the root hash of the Merkle tree uniquely identifies the state of a rule set, and verifiable eventual consistency of the rule set is achieved by synchronizing the root hash.

[0011] The edge node is also configured with:

[0012] A pre-execution simulation sandbox module is configured to pre-execute the set of rules identified by the new rule state tree root hash in a digital twin simulating the edge node's operating environment before activating a new rule state tree root hash synchronized from the cloud, in order to detect dynamic behavior conflicts.

[0013] A runtime security monitoring and isolation module, comprising:

[0014] A runtime agent deployed on an edge node is used to monitor causal data between rule triggering and device behavior; and a causal anomaly detection engine deployed in the cloud is used to analyze the causal data and, when an anomaly is detected, instruct the edge node to place the rule that triggered the anomaly into a runtime isolation sandbox to restrict the execution permissions of the rule.

[0015] Preferably, the Merkle-CRDT rule state tree module can calculate and synchronize only the differences in the state tree by comparing the old and new root hashes. The structural characteristics of the Merkle-CRDT rule state tree enable the cloud and edge nodes to efficiently calculate the differences by comparing the root hashes and synchronize only incremental data, significantly improving synchronization efficiency.

[0016] Preferably, the pre-execution simulation sandbox module can detect complex dynamic behavioral conflicts, such as executor loop oscillation caused by mutual triggering between rules (i.e., loop oscillation of rule execution), or excessive use of computing or network resources by a certain rule in a specific scenario (i.e., excessive use of simulation resources).

[0017] Preferably, the runtime agent is responsible for transforming the underlying, raw device behavior data into structured causal data. The typical format of the causal data collected by the runtime agent is a time-series tuple containing rule identifiers, trigger conditions, execution actions, and associated sensor feedback, providing high-quality input for upper-level analysis.

[0018] Preferably, the core of the causal anomaly detection engine is built on a large language model (LLM). Through learning from massive amounts of normal operation data, the model can understand the physical common sense and normal causal relationship models of specific IoT scenarios.

[0019] Preferably, the runtime isolation sandbox is a flexible soft isolation mechanism that blocks risks by depriving isolated rules of the right to call the direct control application programming interface (API) of critical physical executors, rather than abruptly stopping the entire rule engine.

[0020] One of the collaborative innovations of this invention is that the data generated by the pre-execution simulation sandbox module during normal simulation verification can be used as high-quality baseline training data for the causal anomaly detection engine, helping it to quickly and accurately establish a normal causal relationship model and realize closed-loop gain of data flow within the system.

[0021] For ease of management, the cloud also provides a management interface that can not only visualize the complete change history of the Merkle-CRDT rule state tree in a way similar to a version control system, but also provide centralized alerts and presentations for conflicts detected by the pre-execution sandbox and causal anomalies detected at runtime.

[0022] The present invention also provides a corresponding cloud-edge synchronization method, which fully realizes the collaborative workflow of the above three-layer defense system, including: synchronization based on Merkle-CRDT rule state tree, pre-activation verification based on pre-execution simulation sandbox, and post-execution protection based on runtime monitoring and isolation.

[0023] Specifically, the steps include:

[0024] The rule set states of the cloud and edge nodes are managed as a Merkle-CRDT rule state tree, and eventual consistency is achieved by synchronizing the state root hash. Before a new rule state is activated on an edge node, the rule set corresponding to that state is dynamically verified in a pre-execution simulation sandbox. After the rule set is activated, its execution is continuously monitored by a runtime agent and a causal anomaly detection engine. When a causal anomaly is detected, the rule that triggered the anomaly is placed in a runtime isolation sandbox for permission restriction.

[0025] Preferably, the method further clarifies the specific steps of the runtime monitoring, namely, using a large language model to perform in-depth analysis of the causal data reported by the runtime agent, identifying anomalies by comparing them in real time with the learned normal physical causal relationship model, and automatically triggering the runtime isolation mechanism based on this.

[0026] The beneficial effects of this invention are as follows:

[0027] Based on Merkle-CRDT, this invention achieves strong consistency, immutability, and full auditability of rule configuration, establishing a solid root of trust for the system. Based on a digital twin-based simulated sandbox, this invention pushes the risk defense line from static logic checks to dynamic behavior prediction, enabling the discovery of deeper and more hidden design flaws. Based on an AI-driven runtime causal monitoring and isolation mechanism, this invention provides the system with immunity to unknown threats and runtime failures, enabling precise and rapid removal of risk points without interrupting overall service, greatly improving the system's resilience and security. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the architecture of the distributed IoT rule engine cloud-edge synchronization system of the present invention.

[0029] Figure 2 This is a flowchart of the cloud-edge synchronization method for the distributed IoT rule engine of this invention. Detailed Implementation

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

[0031] This embodiment takes an automated vertical farm environmental control system as an example. The system includes a cloud management platform and an edge computing gateway deployed within the farm.

[0032] like Figure 1As shown, the system in this embodiment includes a cloud 70 and an edge node 80.

[0033] Both cloud node 70 and edge node 80 include:

[0034] The Merkle-CRDT rule state tree module manages the set of all environmental control rules (such as light duration, nutrient solution pH, carbon dioxide concentration, etc.). In the cloud, any modification (addition, deletion, or modification) to a rule by the administrator generates a new, unique root hash, for example, evolving from Root_Hash_V1 to Root_Hash_V2. This tree structure ensures that any historical version is traceable and immutable.

[0035] Edge node 80 uniquely includes:

[0036] Pre-execution simulation sandbox module 81: It contains a lightweight digital twin model of the farm environment, which can simulate the relationship between light intensity and plant photosynthetic rate, nutrient solution consumption and plant growth, etc.

[0037] The runtime security monitoring and isolation module consists of two parts:

[0038] Runtime Agent 82: A lightweight process responsible for real-time monitoring of rule triggering and device responses on edge node 80.

[0039] Runtime isolation sandbox 83: The local secure execution environment of edge node 80, which can dynamically manage the permissions of rules.

[0040] The cloud-based 70 uniquely includes:

[0041] Causal Anomaly Detection Engine 71: A cloud service based on Large Language Models (LLM).

[0042] Management Interface 72: A web interface for administrators to operate and monitor.

[0043] Combination Figure 2 The method flow of this embodiment is described in detail using a scenario where an administrator deploys a new rule set with potential dynamic risks in the cloud:

[0044] Step S201: Rule state evolution and synchronization.

[0045] The cloud administrator added two new rules to the existing rule set (whose state is represented by the root hash RH_V1): "Rule A: If the carbon dioxide concentration is below 800 ppm, turn on the carbon dioxide generator" and "Rule B: If the current grid energy consumption cost is higher than a preset threshold, turn off the carbon dioxide generator." The addition of these two rules caused the rule set's state to evolve, generating a new target state, represented by the root hash RH_V2. The cloud node 70 synchronizes the target root hash RH_V2 to the edge node 80 via the network.

[0046] Step S202: Perform a pre-performance simulation verification.

[0047] After receiving RH_V2, the Merkle-CRDT rule state tree module of edge node 80 first passes it to the pre-execution simulation sandbox module 81 for verification before activating it. The pre-execution simulation sandbox module 81 loads the complete rule set identified by RH_V2 and starts a simulation scenario: setting the carbon dioxide concentration in the simulation environment to 790ppm, while simulating that the current electricity price is at its peak and the energy cost is higher than the threshold.

[0048] In the simulation, rule A is triggered, sending an on command to the simulated carbon dioxide generator. This causes an increase in the simulation's energy consumption, which in turn triggers rule B, sending a off command to the generator. After the generator is turned off, the simulated carbon dioxide concentration drops again, triggering rule A again. The pre-execution simulation sandbox module 81 detects that the carbon dioxide generator is frequently turned on and off within a very short time (1-2 seconds), constituting a typical cyclic oscillation dynamic behavior conflict.

[0049] Step S203: Verification failed, activation rejected.

[0050] The pre-execution simulation sandbox module 81 determines that the verification has failed and generates a conflict report. Edge node 80 refuses to activate RH_V2 and uploads the conflict report to the cloud 70. An alarm will pop up on the management interface 72, notifying the administrator that RH_V2 has been rejected by the edge node due to dynamic conflicts. The administrator then modifies the rules accordingly (adding a delay judgment or cooldown time to "Rule B"), generates a new root hash RH_V3, and resynchronizes. Assume that RH_V3 eventually passes the simulation verification.

[0051] Step S204: Activate and enter runtime monitoring.

[0052] Rule set RH_V3 is officially activated on edge node 80. Runtime agent 82 then begins operation. It continuously collects and structures system runtime data, forming causal data tuples: {timestamp: 1678886400, rule_id: 'RuleA', trigger: 'co2 < 800ppm', action: 'co2_generator_on', feedback: {co2_sensor: 850ppm, power_meter: 1.2kW}}. These tuples are sent in real-time or in batches to the causal anomaly detection engine 71 in the cloud.

[0053] It should be noted that the data from the successful execution of RH_V3 in the pre-execution simulation sandbox module 81 was used as high-quality labeled data for the baseline training of the causal anomaly detection engine 71, helping LLM learn the normal physical causal pattern that "after the carbon dioxide generator is turned on, the power consumption should be around 1.2kW and the carbon dioxide concentration should rise steadily within a few minutes".

[0054] Step S205: Runtime physical fault occurrence and data acquisition.

[0055] One day, a physical valve in the carbon dioxide generator malfunctioned and became stuck. When rule A was triggered again, the data reported by runtime agent 82 showed that the action of co2_generator_on was executed and the power consumption rose to 1.2kW. However, a few minutes later, the reading of the carbon dioxide sensor was still hovering around 790ppm and did not rise as expected.

[0056] Step S206: Cloud-based causal anomaly detection and judgment.

[0057] The LLM model of the Causal Anomaly Detection Engine 71 immediately identified that this violated the learned physical causal relationship (i.e., "the start action was performed, but the expected effect was not produced"), and determined that this was a high-confidence causal anomaly.

[0058] Step S207: Automatically trigger runtime isolation.

[0059] The causal anomaly detection engine 71 immediately issues a high-priority command to edge node 80. The runtime isolation sandbox 83 of edge node 80 is activated, dynamically modifying the execution permissions of rule A, depriving it of the API to call the control relay of the carbon dioxide generator, but retaining its permission to read sensor data. Thus, although rule A will still be triggered, it can no longer perform harmful (or invalid) actions. Simultaneously, the management interface 72 displays a critical alarm, prompting maintenance personnel to check for hardware faults in the carbon dioxide generator.

[0060] Through the above process, the system and method of the present invention not only prevent rules with dynamic logical defects by simulation before deployment, but also automatically and safely handle causal anomalies caused by unforeseen hardware failures during operation, ensuring the safety and stability of the overall system without affecting the operation of other automated systems in the farm.

[0061] This invention is not limited to the above-described optional embodiments. Anyone can derive other various forms of products under the guidance of this invention. However, regardless of any changes made in their shape or structure, any technical solution that falls within the scope of the claims of this invention shall be protected by this invention.

Claims

1. A cloud-edge synchronization system for a distributed Internet of Things (IoT) rules engine, characterized in that, Includes the cloud and at least one edge node; Both the cloud and the edge nodes are configured with: A Merkle-CRDT rule state tree module is used to manage the state of a rule set as a Merkle tree consisting of content-addressed nodes, wherein the root hash of the Merkle tree uniquely identifies the state of a rule set, and verifiable eventual consistency of the rule set is achieved by synchronizing the root hash. The edge node is also configured with: A pre-execution simulation sandbox module is configured to pre-execute the set of rules identified by the new rule state tree root hash in a digital twin simulating the edge node's operating environment before activating a new rule state tree root hash synchronized from the cloud, in order to detect dynamic behavior conflicts. A runtime security monitoring and isolation module, comprising: A runtime agent deployed on edge nodes is used to monitor causal data between rule triggering and device behavior; and A cloud-based causal anomaly detection engine is used to analyze the causal data. When an anomaly is detected, the edge node is instructed to place the rule that triggered the anomaly into a runtime isolation sandbox to restrict the execution permission of the rule.

2. The system according to claim 1, characterized in that, The Merkle-CRDT rule state tree module is able to calculate and synchronize only the differences in the state tree by comparing the old and new root hashes.

3. The system according to claim 1, characterized in that, The dynamic behavioral conflicts detected by the pre-execution simulation sandbox module include: cyclical oscillations in rule execution, or excessive use of simulation resources.

4. The system according to claim 1, characterized in that, The causal data collected by the runtime agent consists of time-series tuples containing rule identifiers, triggering conditions, executed actions, and associated sensor feedback.

5. The system according to claim 1, characterized in that, The causal anomaly detection engine is based on a large language model and is trained to learn and understand the normal physical causal relationship model of the scene in which the edge node is located.

6. The system according to claim 1, characterized in that, The runtime isolation sandbox achieves isolation by revoking the direct control application interface access permissions of the placed rules to the physical executor.

7. The system according to claim 5, characterized in that, The simulation results of the pre-execution simulation sandbox module are used as baseline training data for the causal anomaly detection engine to establish a normal causal relationship model.

8. The system according to claim 1, characterized in that, The cloud also includes a management interface for visually displaying the change history of the Merkle-CRDT rule state tree and alerting on conflicts and anomalies detected by the sandbox.

9. A cloud-edge synchronization method for a distributed Internet of Things (IoT) rules engine, applied to the system as described in any one of claims 1 to 8, characterized in that, The method includes: The rule set states of the cloud and edge nodes are managed as a Merkle-CRDT rule state tree, and eventual consistency is achieved by synchronizing the state root hash. Before activating a new rule state at an edge node, the rule set corresponding to that state is dynamically validated in a pre-execution simulation sandbox. After the rule set is activated, its execution is continuously monitored through the runtime agent and the causal anomaly detection engine. When a causal anomaly is detected, the rule that triggered the anomaly is placed into the runtime isolation sandbox for permission restriction.

10. The method according to claim 9, characterized in that, The continuous monitoring steps further include: Analyze causal data reported by runtime agents using large language models; Real-time causal data is compared with normal physical causal relationships learned by the model to identify anomalies; Based on the identified anomalies, a runtime isolation sandbox is automatically triggered.

Images