A scene linkage-based asynchronous load internet of things rule engine design method

Abstract

This invention discloses a design method for an asynchronous load-based IoT rule engine based on scene linkage. It includes the following steps: Step 1: Triggering rules for scene linkage; Step 2: Rule scheduling by the rule engine, packaging rules into executable tasks; Step 3: Publishing a task scheduling request to the event bus of the basic module; Step 4: The event bus sends the request to the listening task scheduler; Step 5: The task scheduler marks the task according to the task information and assigns it to scene linkage, then publishes it to the event bus; Step 6: The worker listens for the published task, executes the task, and returns the task result to the event bus; Step 7: After listening to the result, the rule engine performs the next round of rule triggering judgment or directly returns the result. This invention has the advantage of enabling real-time and intelligent processing of data between devices.

Description

Technical Field

[0001] This invention relates to a design method for an asynchronous load IoT rule engine based on scene linkage. Background Technology

[0002] A rule engine is a software system used to manage and enforce rules to automate decision-making and behavior. A rule engine typically includes modules for rule definition, rule management, rule execution, and result processing, helping users implement complex business logic and decision-making processes. As business decisions in information applications become increasingly varied and complex with the development of information technology, rule engines have become an important tool for many enterprises and organizations, helping them manage complex rule sets and achieve intelligent decision-making and automated processes. The development of rule engines has also benefited from advancements in artificial intelligence, big data, and machine learning, enabling them to perform better when handling more complex and diverse rules and scenarios.

[0003] IoT systems typically consist of devices and platforms from multiple vendors, using different data formats and communication protocols. To achieve interoperability between devices and unified data processing, a unified rules engine can act as middleware to integrate and process data. Furthermore, as IoT applications expand, the demands for system intelligence and automation are increasing. A powerful rules engine can help achieve intelligent control, automated decision-making, and data analysis in IoT systems, improving system efficiency and performance.

[0004] Faced with the complex and diverse business rules of different industries, including not only the complex processing of business rules for equipment data, but also the requirement for stability and timeliness in the management and control of a large number of equipment, it is necessary to comprehensively consider the determinism, interpretability, adaptability, operability and scalability of the establishment of various rules.

[0005] Existing rule engine technology primarily functions to handle data input and output. It defines a rule base, loads it into the rule engine, and then matches the input data against a rule decision table to execute the corresponding rules and output the results. However, this approach ignores the complexity of business processes. Once rules enter the rule engine, they become uncontrollable and only support simple business flow processing. Furthermore, the timeliness of business processing and the quantification of the number of business processes are inaccurate. When faced with large and complex business cluster scenarios (simple scenarios involve triggering an action based on certain conditions; complex scenarios involve executing a series of business scenarios after a single action is completed; and scenarios involving multiple business scenarios executed in parallel or sequentially after a single action is completed), the rule engine configuration becomes chaotic, resource consumption increases, and IoT data becomes difficult to manage and maintain.

[0006] Current IoT rule engines primarily focus on device management, lacking a robust rule engine model and facing limitations in handling concurrent device requests. This restricts their usability. For instance, IoT devices typically report data at specific times, usually on the hour. When there are many such devices, the amount of information to process at each hour becomes enormous. Insufficient service concurrency handling can easily lead to server lag or crashes. Furthermore, the proliferation of IoT devices and their expanding applications have made data interaction and collaboration between devices increasingly complex. Traditional data processing methods can no longer meet the demands for real-time and intelligent processing. For example, consider intelligent valve control. If water level monitoring is needed to maintain a healthy level, the valve would need to be opened or closed after the device reports the water level data. However, if the valve opening / closing command cannot be responded to in real-time, the water level could easily exceed the limit under high flow conditions, causing losses. Therefore, this data processing method cannot meet the requirements for real-time and intelligent processing.

[0007] Therefore, designing an asynchronous load IoT rule engine based on scenario linkage to achieve intelligent data processing and decision-making becomes an inevitable choice. Summary of the Invention

[0008] The purpose of this invention is to provide a design method for an asynchronous load IoT rule engine based on scene linkage, which improves the concurrent processing capability of devices, enables real-time and intelligent processing of data between devices, solves the problem of complex scene design, and improves rule processing capability.

[0009] To achieve the above objectives, the technical solution of the present invention is as follows: a design method for an asynchronous load IoT rule engine based on scene linkage, characterized in that: an asynchronous load IoT rule engine system based on scene linkage is used for engine control, the asynchronous load IoT rule engine system based on scene linkage includes a basic module, a rule engine, and scene linkage; the basic module supports the operation of the rule engine; scene linkage is operated through the rule engine;

[0010] The specific method includes the following steps:

[0011] Step 1: Triggering the rules for scene linkage;

[0012] Step 2: Rule scheduling by the rule engine, where rules are packaged into executable tasks;

[0013] Step 3: The task scheduling request is sent to the event bus of the basic module;

[0014] Step 4: The event bus sends the message to the listening task scheduler;

[0015] Step 5: The task scheduler marks the task based on the task information and hands it over to the scene linkage, and publishes it to the event bus;

[0016] Step Six: The worker listens for the published task, executes the task, and returns the task result to the event bus;

[0017] Step 7: After the rule engine listens for the result, it will either trigger the next round of rule judgment or return the result directly.

[0018] In the above technical solution, the basic modules include a log module, a service module, a scenario module, and an event bus module;

[0019] The logging module is used to record the flow of rules and the location of problems. A logging service is added to the task executor. Log records are added as needed during the task executor definition process. Logs are gradually stored in the database for querying through an asynchronous processing mechanism.

[0020] In the service module, when single-instance services are short of memory resources, they can automatically expand service nodes as needed to improve service reliability and concurrency. Service nodes communicate with each other through data caching.

[0021] The scenario module enables modular scenarios, which take a series of business processes and device controls as scenarios. Scenarios can be freely combined to build scenario models. The scenario module is divided into meta-scenarios and fused scenarios. Meta-scenarios are defined as basic elements of scenarios, including basic definitions such as scenario triggering conditions and execution actions. Fusion scenarios are composed of meta-scenarios and meta-scenarios. The triggering conditions of fused scenarios are triggered by either meta-scenarios or fused scenarios.

[0022] The event bus module, which connects multiple service nodes to handle load balancing, contains three elements: event model, subscribers, and publishers.

[0023] In the above technical solution, in step five, scene linkage includes meta-scene linkage and fused scene linkage; the different scene linkages differ in the execution steps as follows:

[0024] The execution steps for the meta-scene are as follows:

[0025] A. Triggered or manual based on equipment data reporting information;

[0026] B. Execution of meta-scenario rules;

[0027] The steps for executing the fusion scenario are as follows:

[0028] A. After one or more meta-scenes are triggered, a fusion scene is triggered;

[0029] B. Integrate scenario rule execution.

[0030] In the above technical solution, the rule engine includes a decision scheduling engine and a task execution engine;

[0031] The rule execution steps of the rule engine are as follows:

[0032] Step 11: Configure the rule model;

[0033] The rule model, as the main body of the rules, defines the rule information;

[0034] Step 12: Scheduler processing;

[0035] After the rule model is published, the scheduler schedules and processes the rules.

[0036] Step 13: Worker subscription processing;

[0037] Each worker is a service node. When the scheduler selects a suitable service node to execute a task, it selects the worker based on the worker's status.

[0038] Step 14: The task executor executes the task;

[0039] The task executor is used to execute local tasks, providing methods for starting, stopping, and listening to tasks, and recording the execution process and problems through the logging module.

[0040] In the above technical solution, in step 11, the rule model includes rule nodes, rule connections, and rule conditions; wherein,

[0041] The rule node defines the node's ID, scheduling rules, custom rule configurations, input / output rules, and event listener connections.

[0042] Rule connections define the next execution node for rules to be executed in parallel or sequentially;

[0043] The rule conditions define the judgment method and conditions for the next rule execution.

[0044] In the above technical solution, in step 12, the scheduler includes:

[0045] When a rule is published, the rule model is converted into a task and sent to the corresponding task scheduler for scheduling and execution.

[0046] The task scheduler obtains information about tasks in the schedule and workers, and / or executes scheduled tasks and cancels or closes tasks; there are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler.

[0047] The scheduler selector selects the appropriate task scheduler to implement the rule-based task load balancing based on the execution status of the task scheduler or the definition of the rule model.

[0048] Scheduling rules define the type of task scheduler to be executed by the rule model, specifying whether all cluster task schedulers should execute the scheduled tasks, or whether the task scheduler should execute the scheduled tasks with minimum load.

[0049] In the above technical solution, scene linkage is used to realize scene model construction and linkage control between scenes.

[0050] The scene linkage control method includes the following steps:

[0051] Step 21: Perform scene presets, supporting the flow and execution of scenes through basic modules. Scene presets include:

[0052] Service nodes are instantiated, and all distributed services are registered with the cache service and listen for cache service events on the corresponding nodes.

[0053] The event bus process involves the rules of a specific scenario being converted into events and then executed through a publish-subscribe cycle.

[0054] In the implementation of the distributed rule engine, service node identifiers are added to published events and event subscribers. The event bus directly processes events of the current service node. If an event contains identifiers of other service nodes, it needs to be stored in other nodes of the cache service. Other service nodes listen to the information of other service nodes and perform event subscription processing to achieve load balancing of the rule engine.

[0055] Step 22: Construct a scene linkage model and implement rule flow through scene presets;

[0056] The methods for constructing scene linkage models include:

[0057] Step 221: Meta-scene establishment;

[0058] Define scene triggers and scene content, and define simple scenes as meta-scenes; scene triggers include manual triggers, timed triggers, device triggers, and scene triggers; scene content includes rule engine processes and device linkages;

[0059] Step 222: Establishing the scene linkage model;

[0060] Establish relationships between meta-scenes to form a scene linkage model;

[0061] Once the meta-scene or fusion scene has been executed, it will publish an event to the event bus. After the scene linkage model subscribes to the event, it will determine whether to execute the scene based on the scene trigger.

[0062] The present invention has the following advantages:

[0063] (1) Visual rule engine configuration;

[0064] This invention employs the node-red visualization component to design scenario triggering conditions (configurable data sources, data-controlled flow), handle concurrent events, and cache concurrency (process forwarding and distribution via an event bus). Simultaneously, it provides data visualization configuration, allowing for the configuration of data sources and event distribution, making data flow transparent and visible, thus enhancing process control. It integrates scenario design, providing a more intuitive display and configuration of rules and processes, achieving visualized scenario linkage. The rule flow is defined as a scenario, and the inter-scenario linkage model design more closely resembles various business scenario designs. In other words, this invention decomposes complex businesses into individual businesses, each corresponding to a scenario, allowing for arbitrary combinations of businesses and facilitating the recurrence of businesses under different conditions, reducing the duplication of business scenario creation. Furthermore, this invention uses scenario-based rules to decompose and configure businesses, ensuring that the data flow executes the appropriate scenario, facilitating control and problem troubleshooting. It overcomes the shortcomings of existing process engines, which typically only configure process conditions and parameters, lacking sufficient data configuration. Data processing is generally implemented through code, obscuring the specific process (existing process engines focus on results, while business data processing is a process; if processing deviations occur due to conditions, it is difficult to handle).

[0065] (2) Scene linkage modeling;

[0066] This invention modularizes scenarios and achieves scenario linkage modeling through the combination of multiple scenarios. Multi-scenario approach not only breaks down business processes, making data flow easier to control and understand, but also allows business processes to be combined arbitrarily and reused, solving the problem of complex scenario design and improving rule processing capabilities. It overcomes the problems of existing technologies that usually establish rule processes for a single scenario, achieving single-scenario processing, and the process engine configuration only configures process conditions and process parameters, with insufficient data configuration. Data processing is generally implemented through code, and the specific process is not visible.

[0067] (3) Asynchronous load rule scheduling;

[0068] This invention combines an event bus to eventify rule nodes, converts each process node task into a thread to achieve asynchronous execution, and publishes it to a load-bearing server for load execution, thus optimizing the use of process resources in the rule engine; it overcomes the problem in existing rule engines that the process execution process cannot be controlled by the established process execution rules.

[0069] (4) Distributed rule engine;

[0070] The service nodes of this invention are distributed services, with process nodes distributed and scheduled to be executed on different servers, maximizing the use of server resources by load-bearing task threads; this invention adopts a distributed rule engine, breaking away from the traditional rule engine's characteristic as a rule flow container, and transforming it into a rule engine service flow by optimizing the rule engine's structure;

[0071] (5) Event bus design;

[0072] This invention enables configurable process logs and subscription to node logs, which facilitates the analysis of rule processes.

[0073] The node eventification of this invention facilitates the analysis and control of each node;

[0074] The event publish-subscribe model of this invention is more conducive to business expansion;

[0075] The process node granularity of this invention allows for more precise control of the rule-based process. Attached Figure Description

[0076] Figure 1 This is a schematic diagram of the log module operation in this invention.

[0077] Figure 2 This is a load diagram of the service cluster in this invention.

[0078] Figure 3 This is a scene composition diagram in the present invention.

[0079] Figure 4 This is a diagram illustrating the operation of the event bus in this invention.

[0080] Figure 5 This is a flowchart of the rule execution process of the rule engine in this invention.

[0081] Figure 6 This is a diagram of the rule publishing mechanism of the rule engine in this invention.

[0082] Figure 7 This is a schematic diagram of scene linkage in the present invention.

[0083] Figure 8 This is the overall flowchart of the present invention.

[0084] Figure 9 This is a multi-scenario configuration diagram of an example of the present invention.

[0085] Figure 10 This is a configuration diagram of a fusion scenario example used in an embodiment of the present invention. Detailed Implementation

[0086] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, these descriptions do not constitute a limitation of the present invention and are merely illustrative. The advantages of the present invention will become clearer and easier to understand through this description.

[0087] Referring to the attached diagram, a design method for an asynchronous load IoT rule engine based on scene linkage is presented. This method employs an asynchronous load IoT rule engine system based on scene linkage for engine control. The system includes a basic module, a rule engine, and scene linkage. The basic module serves as a supporting module, supporting the operation of the rule engine. Scene linkage operates through the rule engine; a scene linkage is a collection of one or more scenes, and a single scene is a collection of multiple rules. The execution of these rules is carried out through the rule engine.

[0088] The specific engine control method includes the following steps.

[0089] Step 1: Triggering the rules for scene linkage;

[0090] Step 2: Rule scheduling by the rule engine, where rules are packaged into executable tasks;

[0091] Step 3: The task scheduling request is sent to the event bus of the basic module;

[0092] Step 4: The event bus sends the message to the listening task scheduler;

[0093] Step 5: The task scheduler marks the task based on the task information and hands it over to the scene linkage, and publishes it to the event bus;

[0094] Step Six: The worker listens for the published task, executes the task, and returns the task result to the event bus;

[0095] Step 7: After the rule engine detects the result, it will either trigger the next round of rule judgment or directly return the result (e.g., ...). Figure 8 (As shown).

[0096] Furthermore, the basic modules include a logging module, a service module, a scenario module, and an event bus module;

[0097] The logging module records the flow of rules and process information, and identifies potential problems. A logging service is added to the task executor; log entries can be added as needed during the task executor definition process, and the logs are progressively stored in the database for later retrieval through an asynchronous processing mechanism. Figure 1 As shown, during the execution of the rule process, logs are placed in a log queue, and the log queue is read and recorded into the database service by a thread in a loop;

[0098] The service module, when single-instance services lack sufficient memory resources, can automatically expand service nodes as needed to improve service reliability and concurrency. Service nodes communicate data through data caching; for example... Figure 2As shown, service nodes in each service cluster register with the cache service, and messages from each node are published to the message event bus. The message bus then publishes the messages to the cache events for sharing. Registered nodes read the cache events for processing. Typically, IoT devices report data at specific times, usually on the hour. When there are many such devices, the amount of information to be processed at the top of the hour becomes enormous. If the service's concurrency processing capacity is insufficient, it can easily lead to server lag or crashes. This invention has a solution for this situation: it caches concurrent data through the event bus, and the concurrent data processing is handled by the load-balanced servers. This asynchronous caching of concurrent data increases the concurrency capacity, while load balancing enables concurrent data processing. The concurrency processing capacity is determined by the number of load-balanced servers.

[0099] The scenario module enables modular scenarios. Since IoT applications often involve repetitive business processes and rules, a series of business processes and device controls are defined as scenarios. These scenarios can be freely combined to facilitate the construction of scenario models. Based on this, the scenario module is divided into meta-scenarios and fused scenarios; for example... Figure 3 As shown, the meta-scene is composed of basic elements, and the fused scene is composed of the fused scene and the meta-scene. The scene construction can freely combine the meta-scene and the fused scene.

[0100] The event bus module, which runs across multiple service nodes to handle load balancing, comprises three elements: an event model (equivalent to the message body, roughly including message type, source, destination, and content; the event model facilitates message propagation and processing by subscribers and publishers), subscribers, and publishers. The event bus module reduces coupling and improves scalability. Here, subscribers need to be cached and tagged with service node labels; for example... Figure 4 As shown, the event bus design adds service nodes. Event publishers publish events to the event queue, and service nodes, as subscribers, read events in a loop.

[0101] Furthermore, the main function of the rule engine is to define and execute rules. Scenarios are rule chains. After a scenario is triggered, the rule engine executes the rules. Scenario linkage refers to multiple scenarios being associated to trigger and execute rules.

[0102] In step five, scene linkage includes meta-scene linkage and fused scene linkage; the different scene linkages differ in the execution steps as follows:

[0103] The execution steps for the meta-scene are as follows:

[0104] A. Triggered or manual based on equipment data reporting information;

[0105] B. Execution of meta-scenario rules;

[0106] The steps for executing the fusion scenario are as follows:

[0107] A. After one or more meta-scenes are triggered, a fusion scene is triggered;

[0108] B. Integrate scenario rule execution.

[0109] Furthermore, the rules engine includes a decision scheduling engine and a task execution engine;

[0110] The rule execution steps of the rule engine are as follows:

[0111] Step 11: Configure the rule model;

[0112] The rule model, as the main body of the rules, defines the rule information;

[0113] Step 12: Scheduler processing;

[0114] After the rule model is published, the scheduler schedules and processes the rules.

[0115] Step 13: Worker subscription processing;

[0116] Each worker is a service node. When the scheduler selects a suitable service node to execute a task, it can select the worker based on the worker's status.

[0117] Step 14: The task executor executes the task;

[0118] The task executor is the place where local tasks are actually executed. It provides methods to start, stop, and monitor tasks, and records the execution process and problems through the log module.

[0119] like Figure 5 As shown, the rule engine uses the node-red component for visual rule configuration, task scheduling configuration, and service node configuration. A rule task first needs to establish a rule model, then the scheduler transforms the rule model into a task and publishes it to the event bus. The corresponding worker executes the task through the task executor, and returns the corresponding result upon completion. If the rule definition is not finished in the next step, the scheduler continues forwarding; otherwise, the task ends. The node-red component: node-red is a stream-based low-code programming tool used to connect hardware devices, APIs, and online services in novel and interesting ways. It provides a browser-based editor; here, rule configuration uses node-red for visual rule configuration.

[0120] The rule tasks are published to the event bus, and each service node subscribes to the event to update, reload, and execute the rules;

[0121] like Figure 6As shown, the rule engine packages rules into events and publishes them to the event bus, where service nodes subscribe to the rule events and process them.

[0122] Furthermore, in step 11, the rule model includes information such as multiple rule node information, rule connections, and rule conditions; among which,

[0123] The rule node defines the node's ID, scheduling rules, custom rule configurations, input / output rules, and event listener connections.

[0124] Rule connections define the next execution node for rules to be executed in parallel or sequentially;

[0125] The rule conditions define the judgment method and conditions for the next rule execution; such as device control rules, business function rules, data compilation and calculation, data forwarding and routing, etc. are all rule models.

[0126] Furthermore, in step 12, the scheduler includes:

[0127] When a rule is published, the rule model is converted into a task and sent to the corresponding task scheduler for scheduling and execution.

[0128] The task scheduler can obtain information about the tasks in the schedule and the workers, and can also execute scheduled tasks, cancel or close tasks, etc. through the task executor; there are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler.

[0129] The scheduler selector selects the appropriate task scheduler to implement the rule task load based on the execution status of the task scheduler or the definition of the rule model.

[0130] Scheduling rules define the type of task scheduler to be executed by the rule model. You can specify that all task schedulers in the cluster should execute the scheduled tasks, or that the task scheduler should execute the scheduled tasks with the minimum load, or that a specific task scheduler should execute the scheduled tasks.

[0131] Furthermore, scene linkage is used to realize scene model construction and linkage control between scenes.

[0132] The scene linkage control method includes the following steps:

[0133] Step 21: Perform scene presets, supporting the flow and execution of scenes through basic modules. Scene presets include:

[0134] Service nodes are instantiated, and all distributed services are registered with the cache service and listen for cache service events on the corresponding nodes.

[0135] The event bus process involves the rules of a specific scenario being converted into events and then executed through a publish-subscribe cycle.

[0136] In the implementation of the distributed rule engine, service node identifiers are added to published events and event subscribers. The event bus directly processes events of the current service node. If an event contains identifiers of other service nodes, it needs to be stored in other nodes of the cache service. Other service nodes listen to the information of other service nodes and perform event subscription processing to achieve load balancing of the rule engine.

[0137] Step 22: Construct a scene linkage model and implement rule flow through scene presets;

[0138] The methods for constructing scene linkage models include:

[0139] Step 221: Meta-scene establishment;

[0140] Set scene triggers (manual trigger, timed trigger, device trigger, scene trigger) and scene content (rule engine process, device linkage). Define simple scenes as meta-scenes, such as timed pump valve shutdown, valve opening operation based on water level monitoring, etc.

[0141] Step 222: Establishing the scene linkage model;

[0142] Scene linkage refers to the establishment of relationships between meta-scenes, forming a scene linkage model;

[0143] Once the meta-scene or fusion scene is completed, it will publish an event to the event bus. After the scene linkage model subscribes to the event, it will determine whether to execute the scene based on the scene trigger. For example, after the pump valve is closed on a timer, it needs to perform the valve opening operation when the water level is too low. This kind of scene model is built on the basis of the meta-scene for scene linkage.

[0144] like Figure 7 As shown, due to the diversity of scenarios, the triggering methods can be linked between scenarios. The rules and processes defined in the scenario are assembled into events and published to the event bus. After the service nodes defined by the rules execute the rules, they are repeatedly sent to the scenarios for decision-making and linkage.

[0145] Example

[0146] The present invention will now be described in detail using an example of its application in controlling the opening and closing of a gate pump. This invention also provides guidance for the application of the invention in other water conservancy and hydropower fields to achieve asynchronous loads based on scenario linkage.

[0147] This embodiment is a case study of a gate pump scenario linkage, involving water level and flow equipment and gate pump equipment, requiring a continuous and sufficient water supply within a specified time period (e.g., Figure 9 As shown):

[0148] (1) Timed opening of gate pump valve scenario: The rule model is a functional node that triggers equipment instructions (valve opening) at a timed time, and the scenario triggering condition is timed triggering;

[0149] (2) Scenario of periodically acquiring monitoring water level, flow rate, and valve status: The rule model is a functional node that triggers equipment commands (acquiring real-time data and acquiring equipment status) at regular intervals. In addition to timed triggering, to ensure normal valve opening, a scenario triggering method of periodically opening the gate pump valve is also needed. After the valve is opened at regular intervals, the equipment status is acquired. If the equipment malfunctions, an abnormal event needs to be published, such as... Figure 10 As shown;

[0150] (3) Valve closing scenario: After the water supply is completed each day, the valve closing device command is triggered at regular intervals. If an abnormal device event is received, the device event data triggering method needs to be added to protect the device.

[0151] (4) Low water level handling scenario: During the water supply process, the water level triggering method of the monitoring device attributes is used. If the water level is too low, the device command needs to be executed to close the outlet valve and open the inlet valve.

[0152] (5) Water level over-limit handling scenario: During the water supply process, the water level triggering method of the monitoring device attributes is used. In the case of water level overflow, the device command needs to be executed to close the inlet valve and open the outlet valve.

[0153] The above scenarios include both individual and integrated scenarios. Each scenario is flexible and can be combined with others to handle both simple and complex gate pump control business. Decomposing the business into multiple scenarios can effectively avoid the problem of complex business requiring large and complex rule configurations. The monitoring, operation and maintenance, and changes of each scenario also become simple and controllable. If this business is implemented directly without decomposing the scenarios, the process will be lengthened, and troubleshooting or adding rules in the middle of the business will be more chaotic when the configuration is complex.

[0154] The existing technology uses a business rule chain to control the opening and closing of the gate pump in this embodiment. Each business corresponds to a rule chain. The rule chain is not easy to change and has poor scalability. The overall time is determined by the complexity of the business. In this embodiment, the gate pump scenario is complex, the control time is long, and the gate pump opening and closing control efficiency is low.

[0155] This invention adopts a business scenario-based approach to control the opening and closing of the gate pump in this embodiment. It decomposes the business into multiple simple scenarios, simplifying the business process. Furthermore, the method of this invention allows for arbitrary combination of scenarios (as shown in the example configuration of the fusion scenario instance in this embodiment). Figure 10 As shown in the figure, it has good scalability. Although the process of dividing multiple scenarios into steps may take longer, it has load service execution. In the face of more complex and parallel execution, the control time of the present invention is shorter and the gate pump opening and closing control efficiency is high.

[0156] All other unspecified parts belong to the prior art.

Claims

1. A design method for an asynchronous load-based IoT rule engine based on scene linkage, characterized in that: An asynchronous load IoT rule engine system based on scene linkage is used for engine control. The asynchronous load IoT rule engine system based on scene linkage includes a basic module, a rule engine, and scene linkage. The basic module supports the operation of the rule engine. Scene linkage is run through the rule engine. The method is applied to gate pump control, and the scenarios include timed opening of gate pump valves, timed acquisition and monitoring of water level and flow rate valve status, valve closing, low water level, and water level exceeding limit. The scenarios are modularized, and scenario linkage modeling is achieved through the combination of multiple scenarios. Scenario-based rules are used to decompose and configure business processes, breaking down complex business processes into individual business processes, allowing for arbitrary combination of business processes. The rule engine configures the rule model; the rule model contains rule nodes, rule connections, and rule conditions; the rule model includes device control rules; when a rule is published, the rule model is converted into a task and sent to the corresponding task scheduler for scheduling and execution; The specific method includes the following steps: Step 1: Triggering the rules for scene linkage; Step 2: Rule scheduling by the rule engine, where rules are packaged into executable tasks; Step 3: The task scheduling request is sent to the event bus of the basic module; Step 4: The event bus sends the message to the listening task scheduler; Step 5: The task scheduler marks the task based on the task information and hands it over to the scene linkage, and publishes it to the event bus; Scene linkage is used to realize scene model construction and linkage control between scenes. The scene linkage control method includes the following steps: Step 21: Pre-set the scene and support the flow and execution of the scene through basic modules; Step 22: Construct a scene linkage model and implement rule flow through scene presets; The methods for constructing scene linkage models include: Step 221: Meta-scene establishment; Define scene triggers and scene content, and define simple scenes as meta-scenes; scene triggers include manual triggers, timed triggers, device triggers, and scene triggers; scene content includes rule engine processes and device linkages; Step 222: Establishing the scene linkage model; Establish relationships between meta-scenes to form a scene linkage model; Once the meta-scene or fusion scene has been executed, it will publish an event to the event bus. After the scene linkage model subscribes to the event, it will determine whether to execute the scene based on the scene trigger. Step Six: The worker listens for the published task, executes the task, and returns the task result to the event bus; Step 7: After the rule engine listens for the result, it will either trigger the next round of rule judgment or return the result directly.

2. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 1, characterized in that: The basic modules include a logging module, a service module, a scenario module, and an event bus module; The logging module is used to record the flow of rules and the location of problems. A logging service is added to the task executor. Log records are added as needed during the task executor definition process. Logs are gradually stored in the database for querying through an asynchronous processing mechanism. In the service module, when single-instance services are short of memory resources, they can automatically expand service nodes as needed to improve service reliability and concurrency. Service nodes communicate with each other through data caching. The scenario module enables modular scenarios, which take a series of business processes and device controls as scenarios. Scenarios can be freely combined to build scenario models. The scenario module is divided into meta-scenarios and fused scenarios. Meta-scenarios are defined as the basic elements of a scenario, including scenario triggering conditions and execution actions. A merged scene is composed of a merged scene and a meta-scene. The triggering condition for a merged scene is either triggered by a meta-scene or a merged scene. The event bus module, which connects multiple service nodes to handle load balancing, contains three elements: event model, subscribers, and publishers.

3. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 1 or 2, characterized in that: In step five, scene linkage includes meta-scene linkage and fused scene linkage; The execution steps for the meta-scene are as follows: A. Triggered or manual based on equipment data reporting information; B. Execution of meta-scenario rules; The steps for executing the fusion scenario are as follows: A. After one or more meta-scenes are triggered, a fusion scene is triggered; B. Integrate scenario rule execution.

4. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 3, characterized in that: The rules engine includes a decision scheduling engine and a task execution engine; The rule execution steps of the rule engine are as follows: Step 11: Configure the rule model; The rule model, as the main body of the rules, defines the rule information; Step 12: Scheduler processing; After the rule model is published, the scheduler schedules and processes the rules. Step 13: Worker subscription processing; Each worker is a service node. When the scheduler selects a suitable service node to execute a task, it selects the worker based on the worker's status. Step 14: The task executor executes the task; The task executor is used to execute local tasks, providing methods for starting, stopping, and listening to tasks, and recording the execution process and problems through the logging module.

5. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 4, characterized in that: The rule node defines the node's ID, scheduling rules, custom rule configurations, input / output rules, and event listener connections. Rule connections define the next execution node for rules to be executed in parallel or sequentially; The rule conditions define the judgment method and conditions for the next rule execution.

6. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 5, characterized in that: In step 12, the scheduler includes: The task scheduler obtains information about the tasks in the schedule and the workers, and / or executes the scheduled tasks and cancels or closes the tasks. There are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler. The scheduler selector selects the appropriate task scheduler to implement the rule-based task load balancing based on the execution status of the task scheduler or the definition of the rule model. Scheduling rules define the type of task scheduler to be executed by the rule model, specifying whether all cluster task schedulers should execute the scheduled tasks, or whether the task scheduler should execute the scheduled tasks with minimum load.

7. The design method for an asynchronous load-based IoT rule engine based on scene linkage according to claim 6, characterized in that: Scene presets include: Service nodes are instantiated, and all distributed services are registered with the cache service and listen for cache service events on the corresponding nodes. The event bus process involves the rules of a specific scenario being converted into events and then executed through a publish-subscribe cycle. In the implementation of the distributed rules engine, service node identifiers are added to the published events and event subscribers, and the event bus directly processes the events of the current service node. If the event contains identifiers of other service nodes, it needs to be stored in the other nodes published to the cache service. Other service nodes listen to the information of other service nodes and perform event subscription processing to achieve load balancing of the rule engine.

Images