Asynchronous load Internet of Things rule engine design method based on scene linkage

Abstract

The invention discloses an asynchronous load Internet of Things rule engine design method based on scene linkage. The method comprises the following steps of: 1, triggering a scene linkage rule; 2, rule scheduling of a rule engine, and rule packaging into an executable task; 3, a task issues a scheduling request to an event bus of the basic module; 4, the event bus sends the data to a monitored task scheduler; 5, the task scheduler marks the task according to the task information, sends the task to the scene for linkage, and issues the task to an event bus; step 6, the working device monitors the released task, executes the task and returns a task result to the event bus; and step 7, after the rule engine monitors a result, performing a next round of rule triggering judgment or directly returning the result. The method has the advantage of being capable of performing real-time and intelligent processing on the data between the devices.

Description

Technical Field

[0001] The present invention relates to a scenario-linkage-based asynchronous load Internet of Things rule engine design method. Background Art

[0002] A rule engine is a software system used to manage and execute rules to achieve automated decisions and behaviors. A rule engine usually includes functional modules such as rule definition, rule management, rule execution, and result processing, which can help users implement complex business logic and decision-making processes. As business decisions in applications become more and more varied and complex with the development of informatization, rule engines have become an important tool for many companies 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 advances in fields such as artificial intelligence, big data, and machine learning, making them perform better in handling more complex and diverse rules and scenarios.

[0003] IoT systems are usually composed of devices and platforms from multiple different manufacturers, and there are different data formats and communication protocols between these devices and platforms. In order to achieve interoperability between devices and unified data processing, a unified rule engine can be used as middleware to achieve data integration and processing. In addition, with the continuous expansion of IoT application scenarios, the requirements for system intelligence and automation are also getting higher and higher. A powerful rule engine can help realize intelligent control, automated decision-making and data analysis of IoT systems, and improve system efficiency and performance.

[0004] Faced with the complex and diverse business rules of different industries, there are not only complex processing of business rules for device data, but also stability and timeliness requirements for the management of a large number of equipment. It is necessary to comprehensively consider the certainty, explainability, adaptability, operability and scalability of the establishment of various rules.

[0005] The main function of the existing rule engine technology is to realize data input and output. The rule base is defined and loaded into the rule engine. The data input is matched according to the rule decision table, and then the corresponding rules are executed to obtain data results for output. This approach ignores the complexity of the business. The rules become uncontrollable after entering the rule engine, and only support simple business flow processing. At the same time, the timeliness of business processing and the quantitative quantity of business are not accurate. Once faced with a large and complex business group scenario (a simple business scenario is to meet a certain condition and trigger the execution of something; a complex business scenario is to continue to execute a series of business scenarios after a certain business is executed, which is a complex business scenario; after executing a certain business scenario, multiple business scenarios need to be executed in parallel or serially, which is a business group scenario), the rule engine configuration is chaotic and resource consumption increases, making it difficult to manage and operate IoT data.

[0006] At present, the IoT rule engine is mainly at the device management level, lacks the establishment of the rule engine model, and faces the problem of insufficient device concurrency processing, which limits the use of the IoT rule engine. For example, in general, IoT devices report by time period, usually on the hour. When there are many such devices, there will be a huge amount of information to be processed at the hour. If the service processing concurrency capacity is insufficient, it is easy to cause the server to freeze or crash. At the same time, with the popularization and expansion of the application scope of IoT devices, the data interaction and collaborative work between devices have become increasingly complex. Traditional data processing methods can no longer meet the needs of real-time and intelligent processing, such as the need for intelligent adjustment of valve opening and closing. For example, if it is necessary to monitor the water level data to keep the water level in a relatively healthy position, after the device reports the water level data, it judges the water level and sends the valve to open or close to maintain the water level. If it is unable to respond to the valve opening and closing command in real time, the water level is likely to exceed the water level line and cause losses when the flow is large, then the data processing method cannot meet the needs of real-time and intelligent processing.

[0007] Therefore, it is inevitable to design an asynchronous load IoT rule engine based on scenario linkage to realize intelligent data processing and decision-making. Summary of the invention

[0008] The purpose of the present invention is to provide a method for designing an asynchronous load Internet of Things rule engine based on scene linkage, improve the concurrent processing capability of devices, perform real-time and intelligent processing of data between devices, solve complex problems in scene design, and improve rule processing capabilities.

[0009] In order to achieve the above-mentioned purpose, the technical solution of the present invention is: a method for designing an asynchronous load Internet of Things rule engine based on scene linkage, characterized in that: an asynchronous load Internet of Things rule engine system based on scene linkage is used to control the engine, and the asynchronous load Internet of Things 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; the scene linkage is operated through the rule engine;

[0010] The specific method includes the following steps:

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

[0012] Step 2: Schedule rules in the rule engine and package the rules into executable tasks;

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

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

[0015] Step 5: The task scheduler marks the task according to the task information and assigns it to the scene linkage, and publishes it to the event bus;

[0016] Step 6: The worker listens to the published tasks, executes the tasks and returns the task results to the event bus;

[0017] Step 7: After the rule engine receives the result, it will trigger the next round of rules or directly return the result.

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

[0019] The log module is used to record the direction of the rule process and locate the problem. The log service is added to the task executor. During the task executor definition process, log records are added according to the situation. The logs are gradually stored in the database for query through the asynchronous processing mechanism.

[0020] Service module: When the memory resources of a single instance service are insufficient, the service node can be expanded automatically as needed to improve service reliability and concurrency. Service nodes communicate data through data cache.

[0021] The scenario module implements modular scenarios. It takes a series of business processing and device control as scenarios. The scenarios are freely combined to build scenario models. The scenario module is divided into meta-scenario and fusion scenario. Meta-scenario is defined as the basic element of the scenario, including basic definitions such as scenario triggering conditions and execution actions. Fusion scenario is composed of meta-scenario and meta-scenario. The triggering condition of fusion scenario is triggered by meta-scenario or fusion scenario.

[0022] Event bus module, the event bus in the event bus module runs through multiple service nodes to implement load. The event bus contains three elements: event model, subscriber, and publisher.

[0023] In the above technical solution, in step 5, scene linkage includes meta-scene linkage and fusion scene linkage; different scene linkages have the following differences in execution steps:

[0024] The meta-scenario execution steps are as follows:

[0025] A. Triggered or manually based on device data reporting information;

[0026] B. Meta-scenario rule execution;

[0027] The steps for implementing the fusion scene are as follows:

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

[0029] B. Fusion 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 flow execution steps of the rule engine are as follows:

[0032] Step 11: Configure the rule model;

[0033] The rule model defines the rule information as the rule body;

[0034] Step 12: Scheduler processing;

[0035] After the rule model is published, the scheduler schedules 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, provides methods for starting, stopping, and monitoring tasks, and records the execution process and problems through the log module.

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

[0041] The rule node defines the node ID, scheduling rules, rule custom configuration, input and output, and event monitoring rule connections;

[0042] Rule connections define the next execution node of the rule in parallel or serial;

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

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

[0045] Scheduling tasks: When rules are published, the rule model is converted into tasks and sent to the corresponding task scheduler for scheduling and execution;

[0046] Task scheduler, which obtains the task information and workers being scheduled, and / or executes scheduled tasks, cancels and closes tasks; there are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler;

[0047] The scheduling selector selects the corresponding task scheduler to implement the rule task load according to the execution status of the task scheduler or the definition of the rule model;

[0048] Scheduling rules define the type of task scheduler executed by the rule model, specifying that all cluster task schedulers execute scheduled tasks, or that the minimum load and the specified task scheduler execute scheduled tasks.

[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 and support the flow execution of scenes through basic modules. Scene presets include:

[0052] The service node is instantiated, and the distributed services are registered with the cache service and listen to the cache service events of the corresponding nodes;

[0053] Event bus transfer: scenario-based rules will eventually be converted into events by the event bus for publishing and subscription transfer execution;

[0054] In the distributed rule engine implementation process, the service node identifier is added to the event publisher and event subscriber, and the event bus directly processes the event of the current service node; if the event contains the identifier of other service nodes, it needs to be stored and published to other nodes of the cache service, and other service nodes listen to the information of other service nodes to perform event subscription processing to achieve the loadability of the rule engine;

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

[0056] The construction method of the scene linkage model includes:

[0057] Step 221: Meta scene establishment;

[0058] Set 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 linkage;

[0059] Step 222: establishing a scene linkage model;

[0060] Establish the relationship between meta-scenes and form a scene linkage model;

[0061] When the meta-scene or fusion scene is executed, an event will be published 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] The present invention adopts node-red visualization components, designs scene trigger conditions (configurable data sources, control processes through data), handles event concurrency, caches concurrency (process forwarding and distribution is realized through event bus), and at the same time, data visualization configuration is configured, data sources, event distribution, etc. can be configured, data flow becomes transparent and visible, making the process more controllable, integrating scene design, more intuitively displaying and configuring rule processes, realizing visualization scene linkage, defining rule flows as scenes, and the scene linkage model design is closer to various business scene designs, that is, the present invention disassembles complex businesses into single businesses, and single businesses correspond to scenes one by one, so that businesses can be combined arbitrarily, and businesses can be repeated under different conditions, reducing repeated creation of business scenes; and the present invention adopts scenario-based rules to disassemble and configure businesses, and the data flow is executed to which scene, which is conducive to control and troubleshooting; it overcomes the problem that the general process engine configuration of the prior art only configures process conditions and process parameters, and the data configuration is insufficient, and the data processing is generally implemented through code, but the specific process cannot be seen (the existing general process engine focuses on results, and business data processing is a process. If the processing is biased due to conditional problems and the results cannot be obtained, it is difficult to handle);

[0065] (2) Scenario linkage modeling;

[0066] The present invention modularizes the scenarios and realizes scenario linkage modeling through the combination of multiple scenarios. The multi-scenario modeling not only disassembles the business to make the data flow easier to control and understand, but also allows the business to be arbitrarily combined and the rules to be reused, thereby solving the complex problem of scenario design and improving the rule processing capability. It overcomes the problem that the prior art usually establishes a rule process for a single scenario to achieve the processing of a single scenario, the process engine configuration only configures the process conditions and process parameters, and the data configuration is insufficient. The data processing is generally implemented through code and the specific process cannot be seen.

[0067] (3) Asynchronous load rule scheduling;

[0068] The present invention combines the event bus to event the rule node, transforms each process node task into a thread to achieve the purpose of asynchronous execution, and publishes it to the load server for load execution, thereby optimizing the use of rule engine process resources; it overcomes the problem that the rule engine of the prior art cannot control the process execution process through the established process execution rules;

[0069] (4) Distributed rule engine;

[0070] The service nodes of the present invention are distributed services, and the process nodes are distributed and scheduled to different servers for execution. The load execution task threads can maximize the use of server resources. The present invention adopts a distributed rule engine, breaking the traditional rule engine as a rule flow container feature, and converts it into a rule engine service flow by optimizing the structure of the rule engine.

[0071] (5) Event bus design;

[0072] The present invention can realize configurable process logs and subscribe to node logs, which is conducive to analyzing rule processes;

[0073] The node eventing of the present invention is conducive to analyzing and controlling each node;

[0074] The event publishing and subscription model of the present invention is more conducive to business expansion;

[0075] The process node granularity of the present invention can control the rule process in more detail. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] Figure 1 This is a working diagram of the log module in the present invention.

[0077] Figure 2 This is the service cluster load diagram in the present invention.

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

[0079] Figure 4 This is the event bus operation diagram of the present invention.

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

[0081] Figure 6 This is a rule publishing diagram for the rule engine in the present invention.

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

[0083] Figure 8 It is the overall flow chart of the present invention.

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

[0085] Fig.10 This is a configuration diagram of a fusion scene instance adopted in an embodiment of the present invention. DETAILED DESCRIPTION

[0086] The following is a detailed description of the implementation of the present invention in conjunction with the accompanying drawings, but they do not constitute a limitation of the present invention and are only given as examples. At the same time, the advantages of the present invention are made clearer and easier to understand through the description.

[0087] Referring to the attached drawings, it can be seen that: a method for designing an asynchronous load IoT rule engine based on scenario linkage, using an asynchronous load IoT rule engine system based on scenario linkage for engine control, the asynchronous load IoT rule engine system based on scenario linkage includes a basic module, a rule engine and scenario linkage; the basic module serves as a supporting module and supports the operation of the rule engine; the scenario linkage is operated through the rule engine, the scenario linkage is a collection of one or more scenarios, a single scene is a collection of multiple rules, and the execution of the rules is operated through the rule engine;

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

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

[0090] Step 2: Schedule rules in the rule engine and package the rules into executable tasks;

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

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

[0093] Step 5: The task scheduler marks the task according to the task information and assigns it to the scene linkage, and publishes it to the event bus;

[0094] Step 6: The worker listens to the published tasks, executes the tasks and returns the task results to the event bus;

[0095] Step 7: After the rule engine monitors the result, it will trigger the next round of rule judgment or directly return the result (such as Figure 8 shown).

[0096] Furthermore, the basic module includes a log module, a service module, a scenario module and an event bus module;

[0097] The log module is used to record the direction of the rule process and locate the problem. The log service is added to the task executor. During the definition of the task executor, log records can be added according to the situation. The logs are gradually stored in the database for query through the asynchronous processing mechanism; Figure 1 As shown, during the execution of the rule process, logs are placed in the log queue, and the log queue is read by the thread loop and recorded in the database service;

[0098] Service module: When the memory resources of a single instance service are insufficient, the service node can be expanded as needed to improve service reliability and concurrency. Service nodes communicate data through data cache. Figure 2As shown, the service nodes in each service cluster are registered in the cache service, and the messages of each node are published to the message event bus. The message bus publishes the message to the cache event for sharing, and the registered node reads the cache event for processing; under normal circumstances, IoT devices report by time period, usually on the hour. When there are many such devices, a huge amount of information needs to be processed at the hour. If the service processing concurrency capacity is insufficient, it is easy to cause the server to freeze or crash; the present invention has a solution for this situation, which caches concurrent data through the event bus, and concurrent data processing is processed by the loaded server, so that the asynchronous caching of concurrent data increases the concurrent capacity, and concurrent data processing is realized through load balancing, and the concurrent processing capacity is determined by the number of loaded servers;

[0099] Scenario module realizes modular scenarios. Since IoT services often have repetitive services and rules, a series of business processing and device control are used as scenarios. The scenarios can be freely combined to facilitate the construction of scenario models. Based on this situation, scenario modules are divided into meta-scenario and fusion scenario. Figure 3 As shown in the figure, the meta-scene is composed of the basic elements, and the fusion scene is composed of the fusion scene and the meta-scene. The scene construction can freely combine the meta-scene and the fusion scene.

[0100] Event bus module, the event bus in the event bus module runs through multiple service nodes to realize load. The event bus contains three elements, namely: event model (the event model is equivalent to the message body, which roughly includes the message type, source, destination and message content. The event model is to allow the message to be passed on, which is convenient for subscribers and publishers to process), subscribers, and publishers. The event bus module can reduce coupling and improve scalability. Here, subscribers need to be put into the cache and labeled with service nodes; Figure 4 As shown, the event bus design adds service nodes, event publishers publish events to the event queue, and service nodes read events cyclically as subscribers.

[0101] Furthermore, the main function of the rule engine is to define the rules for executing rules. The scenario is a rule chain. After the scenario is triggered, the rule is executed through the rule engine. The scenario linkage is the association of multiple scenarios to trigger the execution of rules;

[0102] In step 5, scene linkage includes meta-scene linkage and fusion scene linkage. Different scene linkages differ in the following execution steps:

[0103] The meta-scenario execution steps are as follows:

[0104] A. Triggered or manually based on device data reporting information;

[0105] B. Meta-scenario rule execution;

[0106] The steps for implementing the fusion scene are as follows:

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

[0108] B. Fusion scenario rule execution.

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

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

[0111] Step 11: Configure the rule model;

[0112] The rule model defines the rule information as the rule body;

[0113] Step 12: Scheduler processing;

[0114] After the rule model is published, the scheduler schedules 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 a worker based on the worker's status.

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

[0118] The task executor is where local tasks are executed. It provides methods for starting, stopping, and monitoring 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 to perform visual rule configuration, task scheduling configuration, and service node configuration. The rule task first needs to establish a rule model, and then the scheduler converts 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 after execution. If the rule definition is not completed in the next step, the scheduler will continue to forward it, otherwise the task will be terminated. Node-red component: Node-red is a low-code programming tool based on flow, which is used to connect hardware devices, APIs, and online services in novel and interesting ways; it provides a browser-based editor, where the rule configuration uses node-red to visually configure the rules.

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

[0121] like Figure 6As shown, the rule engine packages the rules into events and publishes them to the event bus, and the service node subscribes to the rule events for processing.

[0122] Further, in step 11, the rule model includes relevant information such as a plurality of rule node information, rule connections and rule conditions; wherein,

[0123] The rule node defines the node ID, scheduling rules, rule custom configuration, input and output, and event monitoring rule connections;

[0124] Rule connections define the next execution node of the rule in parallel or serial;

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

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

[0127] Scheduling tasks: When rules are published, the rule model will be converted into tasks and sent to the corresponding task scheduler for scheduling and execution;

[0128] The task scheduler can be used to obtain the task information and workers being scheduled. The task executor can also be used to execute scheduled tasks, cancel and close tasks, etc. There are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler.

[0129] The scheduling selector selects the corresponding task scheduler to implement the rule task load according to the execution status of the task scheduler or the definition of the rule model;

[0130] Scheduling rules define the type of task scheduler executed by the rule model. You can specify that all cluster task schedulers execute scheduled tasks, or that the minimum load and the specified task scheduler execute 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 and support the flow execution of scenes through basic modules. Scene presets include:

[0134] The service node is instantiated, and the distributed services are registered with the cache service and listen to the cache service events of the corresponding nodes;

[0135] Event bus transfer: scenario-based rules will eventually be converted into events by the event bus for publishing and subscription transfer execution;

[0136] In the distributed rule engine implementation process, the service node identifier is added to the event publisher and event subscriber, and the event bus directly processes the event of the current service node; if the event contains the identifier of other service nodes, it needs to be stored and published to other nodes of the cache service, and other service nodes listen to the information of other service nodes to perform event subscription processing to achieve the loadability of the rule engine;

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

[0138] The construction method of the scene linkage model includes:

[0139] Step 221: Meta scene establishment;

[0140] Set scene triggers (manual trigger, timed trigger, device trigger, scene trigger), scene content (rule engine process, device linkage), and define simple scenes as meta-scenes, such as timed closing of pumps and valves, monitoring of water levels to open valves, etc. as meta-scenes;

[0141] Step 222: establishing a scene linkage model;

[0142] Scene linkage is to establish the relationship between meta-scenes to form a scene linkage model;

[0143] When the meta-scene or fusion scene is executed, an event will be published to the event bus. After the scene linkage model subscribes to the event, it determines whether to execute the scene based on the scene trigger. For example, after the pump valve is closed at a scheduled time, the valve needs to be opened when the water level monitoring is too low. This scene model is based on the meta-scene for scene linkage.

[0144] like Figure 7 As shown, due to the diversity of scenarios, the triggering method can be triggered and linked between scenarios. The rule flow defined by the scenario is assembled into events and published to the event bus. The service node defined by the rule executes the rules and then repeatedly sends them to the scenario for decision linkage.

[0145] Example

[0146] The present invention is now described in detail by taking the application of the present invention to a gate pump to control the opening and closing of a gate pump as an example. It also has a guiding role in the application of the present invention to other water conservancy and hydropower fields to realize asynchronous loads based on scene linkage.

[0147] This embodiment is an example of the linkage between a gate and a pump scene. The scene involves water level flow equipment and gate and pump equipment, requiring continuous and sufficient water supply within a specified time period (such as Fig. 9 shown):

[0148] (1) Scenario of timing to open the gate pump valve: The rule model is a functional node that triggers the device instruction (opening the valve) at the timing node, and the scenario triggering condition is timing triggering;

[0149] (2) Timed acquisition and monitoring of water level flow and valve status scenarios: The rule model is a functional node for timing node triggering device instructions (obtaining real-time data and obtaining device status). In addition to the timed trigger, in order to ensure the normal opening of the valve, it is also necessary to add a timed opening of the gate pump valve scenario trigger method. After the timed valve is opened, the device status is obtained. If the device is abnormal, an abnormal event needs to be issued, such as Fig.10 As shown;

[0150] (3) Valve closing processing scenario: After the water supply is completed every day, the valve closing device command is triggered regularly. If an abnormal device event is received, the device event data trigger method needs to be added to protect the device;

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

[0152] (5) Water level overlimit processing scenario: During the water supply process, the water level trigger mode of the monitoring device attributes is monitored. If the water level overflows, the device command needs to be executed to close the water inlet valve and open the water outlet valve;

[0153] The above multiple scenarios include both single scenarios and integrated scenarios. Each scenario is flexible and can be combined with each other to cope with simple and complex businesses of gate pump control. Decomposing the business into multiple scenarios can effectively avoid the problem that complex businesses require huge and complex rule configurations. The monitoring, operation and maintenance, and changes of each scenario also become simple and controllable. If the business is implemented directly without decomposing the scene, the link will be lengthened. It will be confusing to troubleshoot problems or add rules in the middle of the business when the configuration is complex.

[0154] The prior art uses a business rule chain to control the opening and closing of the gate pump of 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. The gate pump scene of this embodiment is complex, the control time is long, and the gate pump opening and closing control efficiency is low.

[0155] The present invention uses a business scenario approach to control the opening and closing of the gate pump in this embodiment, decomposes the business into multiple simple scenarios, simplifies the business, and uses the method of the present invention to arbitrarily combine scenarios (this embodiment uses the fusion scenario instance configuration of the present invention as shown in the following example) Fig.10 As shown), it has good scalability. Although the present invention divides multiple scenes into steps, which may take a long time, there is 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] Other parts not described belong to the prior art.

Claims

1. A method for designing an asynchronous load IoT rule engine based on scenario linkage, characterized in that: The asynchronous load IoT rule engine system based on scenario linkage is used for engine control. The asynchronous load IoT rule engine system based on scenario linkage includes a basic module, a rule engine and scenario linkage; the basic module supports the operation of the rule engine; the scenario linkage is operated through the rule engine; The specific method includes the following steps: Step 1: Triggering the rules of scene linkage; Step 2: Schedule rules in the rule engine and package the rules into executable tasks; Step 3: The task publishes the scheduling request to the event bus of the basic module; Step 4: The event bus sends the message to the monitoring task scheduler; Step 5: The task scheduler marks the task according to the task information and assigns it to the scene linkage, and publishes it to the event bus; Step 6: The worker listens to the published tasks, executes the tasks and returns the task results to the event bus; Step 7: After the rule engine receives the result, it will trigger the next round of rules or directly return the result.

2. According to claim 1, the method for designing an asynchronous load IoT rule engine based on scenario linkage is characterized in that: The basic modules include log module, service module, scenario module and event bus module; The log module is used to record the direction of the rule process and locate the problem. The log service is added to the task executor. During the task executor definition process, log records are added according to the situation. The logs are gradually stored in the database for query through the asynchronous processing mechanism. Service module: When the memory resources of a single instance service are insufficient, the service node can be expanded automatically as needed to improve service reliability and concurrency. Service nodes communicate data through data cache. The scenario module implements modular scenarios, taking a series of business processing and device control as scenarios, and freely combining scenarios to build scenario models. The scenario module is divided into meta-scenes and fusion scenarios. Meta-scenes are defined as the basic elements of scenarios, including scenario triggering conditions and execution actions. The fusion scene is composed of the fusion scene and the meta-scene, and the fusion scene trigger condition is triggered by the meta-scene or the fusion scene; Event bus module: The event bus in the event bus module runs through multiple service nodes to implement load. The event bus contains three elements: event model, subscriber, and publisher.

3. The method for designing an asynchronous load IoT rule engine based on scenario linkage according to claim 1 or 2, characterized in that: In step 5, scene linkage includes meta-scene linkage and fusion scene linkage. The meta-scenario execution steps are as follows: A. Triggered or manually based on device data reporting information; B. Meta-scenario rule execution; The steps for implementing the fusion scene are as follows: A. After one or more meta-scenes are triggered, the fusion scene is triggered; B. Fusion scenario rule execution.

4. The method for designing an asynchronous load IoT rule engine based on scenario linkage according to claim 3 is characterized in that: The rule engine includes a decision scheduling engine and a task execution engine; The rule flow execution steps of the rule engine are as follows: Step 11: Configure the rule model; The rule model defines the rule information as the rule body; Step 12: Scheduler processing; After the rule model is published, the scheduler schedules 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, provides methods for starting, stopping, and monitoring tasks, and records the execution process and problems through the log module.

5. The method for designing an asynchronous load IoT rule engine based on scenario linkage according to claim 4 is characterized in that: In step 11, the rule model includes rule nodes, rule links and rule conditions; wherein, The rule node defines the node ID, scheduling rules, rule custom configuration, input and output, and event monitoring rule connections; Rule connections define the next execution node of the rule in parallel or serial; The rule conditions define the judgment method and conditions for the next step of rule execution.

6. The method for designing an asynchronous load IoT rule engine based on scenario linkage according to claim 5 is characterized in that: In step 12, the scheduler includes: Scheduling tasks: When rules are published, the rule model is converted into tasks and sent to the corresponding task scheduler for scheduling and execution; Task scheduler, which obtains the task information and workers being scheduled, and / or executes scheduled tasks, cancels and closes tasks; there are three types of task schedulers: local task scheduler, remote task scheduler, and cluster task scheduler; The scheduling selector selects the corresponding task scheduler to implement the rule task load according to the execution status of the task scheduler or the definition of the rule model; Scheduling rules define the type of task scheduler executed by the rule model, specifying that all cluster task schedulers execute scheduled tasks, or that the minimum load and the specified task scheduler execute scheduled tasks.

7. The method for designing an asynchronous load IoT rule engine based on scenario linkage according to claim 6 is characterized in that: 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: Perform scene presets and support the flow execution of scenes through basic modules. Scene presets include: The service node is instantiated, and the distributed services are registered with the cache service and listen to the cache service events of the corresponding nodes; Event bus transfer: scenario-based rules will eventually be converted into events by the event bus for publishing and subscription transfer execution; In the distributed rule engine implementation process, the service node identifier is added to the event publisher and event subscriber, and the event bus directly processes the event of the current service node; If the event contains the identifier of other service nodes, it needs to be stored and published to other nodes of the cache service. Other service nodes listen to the information of other service nodes to perform event subscription processing to achieve load-bearing of the rule engine; Step 22: Build a scene linkage model and implement rule flow through scene presets; The construction method of the scene linkage model includes: Step 221: Meta scene establishment; Set 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 linkage; Step 222: establishing a scene linkage model; Establish the relationship between meta-scenes and form a scene linkage model; When the meta-scene or fusion scene is executed, an event will be published 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.

Images