Design architecture of ultra-lightweight embedded IoT rule engine

Abstract

The present invention discloses a design architecture of an ultra-lightweight embedded Internet of Things rule engine. It has the following advantages: 1. It does not rely on a cloud platform and can work completely offline; 2. It only requires very few system resources (memory does not exceed 5K, Flash does not exceed 34K), which reduces the system resource usage by two orders of magnitude compared to the prior art, and can easily run on a conventional Internet of Things MCU (such as STM32). To achieve similar functions, the Internet of Things device using this method has lower cost, smaller size, and lower power consumption; 3. It is comprehensive in function and can support time planning, compound rules, multiple scenarios, combined actions, and data statistics with very small resources, while the prior art usually requires the Internet of Things device to have a very high hardware configuration or to use the cloud platform to participate in order to achieve similar functions; 4. It has high execution efficiency, with the matching and triggering time of the rules within 50ms and the execution time less than 10ms, which is one to two orders of magnitude higher than the prior art.

Description

Technical Field

[0001] The present invention relates to the field of Internet of Things, and in particular to a design architecture of an ultra-lightweight embedded Internet of Things rule engine. Background Art

[0002] Generally speaking, IoT devices are typically composed of three parts: sensors, actuators, and controllers. As IoT devices develop towards greater intelligence, the number of components required to be loaded into the controller and the business logic required to be processed are increasing, making the controller the most core module of IoT devices. On the other hand, most IoT terminals are limited by factors such as size, power consumption, and cost. Their computing power and storage space are very limited, at least two orders of magnitude lower than those of PCs and even smartphones. To address these contradictions, trade-offs must be made when designing IoT controllers. There are generally three approaches:

[0003] 1. Simplify the processing logic of the IoT controller itself, and the controller only processes simple logical rules

[0004] 2. Place the main processing logic on the server or cloud platform

[0005] 3. Use more powerful IoT processors and increase storage space

[0006] The limitations of the above method are very obvious: 1. It sacrifices functionality and cannot achieve intelligence; 2. It relies on servers or cloud platforms, cannot work offline, and the response speed is also affected; 3. It increases costs and power consumption.

[0007] As users demand ever-higher intelligence for IoT devices, the functionality and performance of rule engines have become crucial indicators of the IoT system's intelligence. However, IoT terminals are limited by size, power consumption, and cost, resulting in extremely limited computing power and storage space, making it difficult to support conventional rule engines. Existing technologies have shortcomings in addressing these challenges:

[0008] A significant number of IoT systems place their rule engines on servers or cloud platforms. While this approach is not constrained by computing and storage resources, it prevents devices from operating offline, and network transmission latency can impact the system's real-time and reliability. Therefore, IoT devices with strict requirements for offline operation, real-time performance, and reliability require embedded rule engines that can execute entirely locally. Existing embedded rule engines not only place high demands on IoT device hardware, resulting in bulky, power-intensive, and expensive devices, but also offer limited functionality and subpar performance. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a design architecture for an ultra-lightweight embedded Internet of Things rule engine, which has obvious advantages in terms of functionality, efficiency and cost.

[0010] In order to solve the above technical problems, the present invention provides a design architecture of an ultra-lightweight embedded Internet of Things rule engine, wherein the rule engine includes five types of objects: scenes, timers, actions, rules and statistical reports; wherein the scene corresponds to a specific user context environment, in which relevant environmental parameters need to reach set values, or relevant devices need to be controlled to adjust the environmental parameters; the timer is used for timing control, and a timer for single triggering or periodic triggering can be set, and the periodic trigger supports setting an end time; the action is a collection of control messages for one or more nodes; the rule associates scenes, timers and actions together, and can specify trigger conditions; the rule defines what action to take at what time and under what circumstances; in the attributes of the rule, either scene or action is selected; and at least one of the timer and trigger condition is required; the statistical report is used to set data statistics for specific sensor data, actuator status and rule execution status, and the data in the statistical report can not only be used for analysis and display, but also can be used as a trigger condition for the rule.

[0011] Beneficial effects of the present invention:

[0012] 1. Low resource requirements: Requires minimal system resources (no more than 5K of memory, no more than 34K of Flash), reducing system resource usage by two orders of magnitude compared to existing technologies, allowing it to easily run on conventional IoT MCUs (such as the STM32). 2. Small size and low power consumption: IoT devices using this method can achieve similar functions at lower cost, smaller size, and lower power consumption. 3. Comprehensive functionality: With minimal resources, it can support time scheduling, compound rules, multiple scenarios, combined actions, and data statistics. Existing technologies typically require IoT devices with advanced hardware configurations or the participation of cloud platforms to achieve similar functions. 4. High execution efficiency: Rule matching and triggering times are within 50ms, and execution times are less than 10ms. Furthermore, time-consuming cloud communication is avoided, resulting in performance improvements of one to two orders of magnitude over existing technologies. 5. High adaptability and reliability: IoT devices using the "SMART" model have a streamlined structure and can operate completely offline. Rule execution is not affected by the network, significantly improving both software and hardware reliability.

[0013] In one embodiment, all sensors and actuators associated with the IoT device in the rule engine, whether built-in or external, are identified by a node ID. For sensors and actuators that need to be managed by the rule engine, the NodeID is required, and in addition, an optional sub-node ID can be assigned. Nodes of the same type can use independent NodeIDs or share the same NodeID. When sensors or actuators share the same NodeID, they can be further selected by SubID. NodeID and SubID each occupy 1 byte, where the NodeID value range is 1-254; SubID uses a bit mask. mode, thus supporting single selection and multiple selection; in the setting or control message of the rule engine, the node selection / matching algorithm is as follows: first, match the NodeID, including two cases: the target NodeID is consistent with the NodeID of the selected sensor and actuator, or the target NodeID is 255, that is, broadcast, then all sensors and actuators will be selected; second, match the SubID, this step is optional and is performed only when the setting or control message of the rule engine specifies the target SubID; if the target SubID is greater than 0, calculate the bitwise AND of the target SubID and the SubID of the selected sensor or actuator, and select the sensor or actuator only when the bitwise AND is "true".

[0014] In one embodiment, if a rule only sets a timer but does not set a trigger condition, this rule is called a "timer-driven rule", which means that the action is executed or the scene is switched at the specified time; if a rule contains a trigger condition, then regardless of whether a timer is set, this rule is called a "condition-driven rule", which means that the action is executed or the scene is switched when the specified conditions are met and at the specified time; the trigger condition can be one or more, and the logical relationship between multiple conditions is indicated by the "or" or "and" condition connector.

[0015] In one embodiment, the timer-driven rule uses the timer instance as the trigger source: scan all the timer running instances referenced in the rules, and if a timer is triggered and the trigger interval meets the settings, the rule is triggered; the condition-driven rule "data interface" is used as the trigger source: (1) the data interface receives internal and external sensor data, as well as statistical data; (2) if the data changes, scan the data change handles associated with the changed data item in turn to find the corresponding rule object; (3) judge the conditions in the rule, and if all the conditions are met and the trigger interval meets the settings, the rule is triggered.

[0016] In one embodiment, the specific operations triggered by the rule include: (1) switching scenarios according to rule attributes, the scenarios including modifying system-level switches and executing actions; or (2) directly executing actions according to rule attributes.

[0017] In one embodiment, the specific operations of executing the action include: (1) searching the action index according to the action identifier, determining whether the command list of the action has been loaded, and if so, executing the action; (2) if the command list has not been loaded, determining whether the command list buffer is full, and if not, loading the command list and executing it; (3) if the command list buffer is full, marking the command list space with the smallest total execution count in the action index as unused, loading the command list of the action to be executed into this space, marking it as used, and then executing it; (4) after execution, the total execution count of the action is increased by 1.

[0018] In one embodiment, the rule engine loads model data when it starts, wherein the scenes, timers, rules, and indexes of actions and statistical reports are all loaded into memory, and the action command list and statistical data items are dynamically loaded on demand;

[0019] A scene occupies 8 bytes, a timer occupies 8 bytes, an action occupies 512 bytes and includes up to 16 commands, a rule occupies 32 bytes, and a statistical report includes current and historical data and occupies a maximum of 512 bytes;

[0020] The standard configuration of the rule engine supports 32 scenarios, 16 timers, 32 actions, 32 groups of rules, and 32 statistical reports. This configuration requires less than 34K of FLASH storage and no more than 5K of memory.

[0021] The rule engine supports increasing or decreasing the model size according to actual needs to more effectively utilize the resources of IoT devices.

[0022] In one embodiment, the configuration interface of the rule engine allows configuration of objects, and configuration operations include query, addition, modification and deletion; the interface format includes JSON, serial port protocol and binary data packet; if the rule engine receives a model "configuration" message, it updates and saves the model data, and updates the timer instance and data change callback handle.

[0023] In one embodiment, the IoT device transmits data to the rule engine through the rule engine's "data interface", including but not limited to the IoT device's built-in sensor data and built-in actuator data, as well as external sensor and external actuator data received through the IoT device's communication module; the rule engine instructs the IoT device to perform relevant operations through the "command interface", and the operation objects include the IoT device's built-in actuator and the external actuator controlled by the IoT device's communication module;

[0024] In one embodiment, the built-in and external sensors include but are not limited to temperature and humidity, brightness, human infrared, noise, pressure, vibration, PM2.5, PM10, carbon dioxide, formaldehyde, TVOC, smoke, electricity meter and water meter; the built-in and external actuators include but are not limited to lighting control, curtain control, air conditioning control, fan control, fresh air system control, access control, power switch, valve, etc.; the Internet of Things communication module includes Wi-Fi, RF2.4, RF433, Bluetooth, ZigBee, LoRa and NB-IoT. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 This is a schematic diagram of the design architecture of the ultra-lightweight embedded IoT rule engine of the present invention and its location in a typical IoT device.

[0026] Figure 2 This is a schematic diagram of the storage allocation of the SMART model in the design architecture of the ultra-lightweight embedded Internet of Things rule engine of the present invention.

[0027] Figure 3 This is a complete flowchart of the SMART engine loading model data in the design architecture of the ultra-lightweight embedded IoT rule engine of the present invention.

[0028] Figure 4 This is a schematic diagram of the workflow of the SMART rule engine in the design architecture of the ultra-lightweight embedded Internet of Things rule engine of the present invention. DETAILED DESCRIPTION

[0029] The present invention will be further described below with reference to the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention.

[0030] The present invention discloses a design architecture and implementation method of an ultra-lightweight embedded Internet of Things rule engine. The rule engine only requires very few system resources to implement functions such as time planning, composite rules, multiple scenarios, combined actions, and data statistics. It has high execution efficiency and supports offline work.

[0031] (I) Overall Architecture of Ultra-Lightweight Embedded IoT Rule Engine: "SMART" Model The system architecture of the rule engine disclosed in this invention can be summarized as the "SMART" model: S stands for scenario; M stands for alarm & timer; A stands for action; R stands for rule; and T stands for table & report. Its overall architecture in a typical IoT device is as follows: Figure 1 As shown, the typical IoT devices include but are not limited to IoT terminals and IoT gateways.

[0032] like Figure 1 As shown in the figure, the basic workflow of the "SMART" embedded rule engine in IoT devices is:

[0033] 1. The "SMART" ultra-lightweight rule engine is embedded in IoT devices, occupying no more than 5K of memory and no more than 34K of Flash. For details, see Table 2 "Object Data Structure of SMART Model" and Figure 2 "Storage Allocation for the SMART Model".

[0034] 2. The IoT device transmits data to the rule engine through the "data interface" of the "SMART" rule engine. The data includes but is not limited to the built-in sensor data and built-in actuator data of the IoT device, as well as the external sensor and external actuator data received through the IoT device communication module.

[0035] 3. The "SMART" rule engine instructs IoT devices to perform relevant operations through the "command interface". The operation objects include but are not limited to the built-in actuators of IoT devices and external actuators controlled by the communication module of IoT devices.

[0036] 4. The built-in and external sensors include, but are not limited to, temperature and humidity, brightness, human infrared, noise, pressure, vibration, PM2.5, PM10, carbon dioxide, formaldehyde, TVOC, smoke, electricity meters, water meters, etc.; the built-in and external actuators include, but are not limited to, lighting control, curtain control, air conditioning control, fan control, fresh air system control, access control, power switches, valves, etc. The IoT communication modules include, but are not limited to, Wi-Fi, RF2.4, RF433, Bluetooth, ZigBee, LoRa, NB-IoT, etc.

[0037] 5. The configuration interface of the "SMART" rule engine allows configuration of "SMART" objects. Configuration operations include query, add, modify, and delete. For details on the configuration content, see Table 2 "Object data structure of the SMART model".

[0038] (2) Identification of sensors and actuators in the “SMART” model

[0039] In the "SMART" rules engine, all sensors and actuators associated with an IoT device, whether internal or external, are identified by a NodeID. While a NodeID is mandatory for sensors and actuators managed by the rules engine, an optional Subnode ID (SubID) can also be assigned. Nodes of the same type can use separate NodeIDs or share the same NodeID. When sensors or actuators share the same NodeID, they can be further selected using the SubID.

[0040] NodeID and SubID each occupy 1 byte. NodeID values ​​range from 1 to 254 (0 and 255 are reserved for the system; 0 represents the IoT device itself, and 255 represents all nodes, i.e., broadcasting). SubID uses a bit mask, thus supporting both single and multiple selections. In the rule engine's configuration or control messages, the node selection / matching algorithm is as follows:

[0041] 1. First, match the NodeID, which includes two cases: the target NodeID is consistent with the NodeID of the selected sensor and actuator (for example, if the target NodeID is 8, only the sensor and actuator with NodeID 8 will be selected), or the target NodeID is 255, which is broadcast, so all sensors and actuators will be selected;

[0042] 2. Next, match the SubID. This step is optional and is performed only if the rule engine's setup or control message specifies a target SubID (non-zero). If the target SubID is greater than 0, the target SubID is calculated (using the C language "&" operator) with the selected sensor or actuator's SubID. Only when the bitwise AND is true is the sensor or actuator selected.

[0043] The above algorithm is illustrated in Table 1:

[0044] Table 1: Example of the algorithm used by the “SMART” rule engine to select sensors and actuators

[0045]

[0046] (3) Objects of the “SMART” model

[0047] The core architecture of the ultra-lightweight embedded IoT rule engine disclosed in this invention is the "SMART" model, which is mainly composed of five types of objects: S represents scenario; M represents timer (alarm & timer); A represents action (Action); R represents rule (Rule); T represents statistical report (Table & report). The details are as follows:

[0048] 1. Scenario (S): corresponds to a specific user context in which relevant environmental parameters need to reach set values, or in other words, relevant devices need to be controlled to adjust environmental parameters. Environmental parameters include but are not limited to brightness, color temperature, temperature, humidity, air quality, and device status.

[0049] 2. Timer (M): used for timing control. You can set a single trigger or periodic trigger timer. Periodic trigger supports setting the end time.

[0050] 3. Action (A): A collection of one or more node (NodeID) control messages. An action can include up to 16 control messages, each corresponding to a NodeID (required) and a SubID (optional).

[0051] 4. Rules (R): Rules associate scenes, timers, and actions, and can specify trigger conditions, such as sensor NodeID, data items, threshold values, conditional operators, and conditional connectors. Intuitively, rules define what actions (changing scenes, sending control messages, etc.) are to be performed at what time and under what circumstances (conditions). Among the attributes of a rule, you can choose between scenes (S) and actions (A); while at least one of the timer (M) and trigger condition is required. In particular,

[0052] If a rule only sets a timer (M) but no trigger conditions, it is called a "timer-driven rule", which means that the action (A) is executed or the scene (S) is switched at the specified time.

[0053] If a rule contains a trigger condition, regardless of whether a timer (M) is set, it is called a "condition-driven rule." This means that the action (A) or scene switch (S) is executed when the specified condition is met and at the specified time (if any). There can be one or more trigger conditions, and the logical relationship between multiple conditions is indicated by the "or" or "and" condition connector.

[0054] 5. Statistical Report (T): This is used to set data statistics for specific sensor data, actuator status, and rule (R) execution. Statistical indicators include but are not limited to extreme values, average values, cumulative values, variances, etc., and statistical periods include but are not limited to hours, days, weeks, and months. The "SMART" rule engine automatically aggregates and cleans data according to the settings. The data in the statistical report (T) can not only be used for analysis and presentation, but can also be used as a trigger condition for the rule (R). In other words, a statistical value can be defined as a data item for the trigger condition (in this case, NodeID = 0, indicating the system data item of this IoT device), stipulating that when the statistical data reaches a specific value, this rule (R) is triggered.

[0055] Table 2: Object data structure of the “SMART” model

[0056]

[0057]

[0058]

[0059]

[0060]

[0061] (IV) Storage design of “SMART” model data

[0062] As an ultra-lightweight embedded IoT rule engine, the "SMART" engine occupies no more than 5K of memory and no more than 34K of Flash. The capacity configuration of the "SMART" model can be flexibly adjusted according to actual needs to achieve smaller storage resource usage. Figure 2 This chapter describes the "SMART model storage allocation" using 34K storage space configuration as an example, and notes the adjustable parts.

[0063] according to Figure 2 The configured "SMART" engine supports 32 scenes, 16 timers, 32 actions (each action can include 16 commands), 32 sets of rules, and 32 statistical reports, basically meeting the intelligent control needs of most IoT edge devices. This configuration requires less than 34KB of FLASH storage and less than 5KB of RAM.

[0064] Furthermore, the "SMART" engine supports scaling models up or down based on actual needs, enabling more efficient use of IoT device resources. For example, if the number of rules, actions, and statistical reports is reduced to eight, the required Flash memory and memory are reduced to less than 9KB and 3KB, respectively, making this configuration suitable for small smart IoT devices. For highly complex rule requirements, the "SMART" engine can seamlessly scale up to a maximum of 256 rules, actions, statistical reports, and scenarios based on data structure definitions. Even at this scale, the required Flash memory and memory requirements do not exceed 268KB and 24KB, respectively.

[0065] Also, note that the command lists in actions (A) are loaded into memory based on the number of times each action is called (calledTimes). Each time an action is triggered, if the command list for that action is not already loaded, the command list for the action with the least number of calls is removed from the existing list, and then the new command list is loaded.

[0066] Scenes (S), timers (M) and rules (R) are all loaded into memory when the program starts; the index of the statistical report and the current statistical data items are also all loaded into memory when the program starts, and the historical statistical data of the statistical report are only loaded when they need to be updated, and the trigger conditions are determined at the same time as the update.

[0067] The complete process of loading model data into the "SMART" engine is as follows Figure 3 shown.

[0068] The above storage design and memory loading method can effectively utilize system resources.

[0069] (V) Processing flow of the “SMART” rule engine

[0070] See Figure 4 As shown in the figure, the workflow of the "SMART" rule engine: The "SMART" rule engine consists of five types of objects: scenes (S), timers (M), actions (A), rules (R) and statistical reports (T). The model data is loaded when the rule engine starts. The scenes, timers, rules, and indexes of actions and statistical reports are all loaded into the memory, and the action command list and statistical data items are dynamically loaded on demand.

[0071] After the model is loaded, for timer-driven rules, a timer instance is created; for condition-driven rules, a data change callback handler is added for each sensor and statistical data item.

[0072] The "SMART" rule engine has a model "configuration" interface, whose formats include but are not limited to JSON, serial port protocol, and binary data packets (corresponding to the "SMART" object data structure). Upon receiving a model "configuration" message, the rule engine updates and saves the model data and updates (including adding, modifying, and deleting) timer instances and data change callback handles.

[0073] Condition-driven rules are triggered by the "data interface":

[0074] (1) The data interface receives internal and external sensor data, as well as statistical data (considered as a special type of "sensor");

[0075] (2) If the data changes, scan the data change handles associated with the changed data item in turn to find the corresponding rule object;

[0076] (3) Determine the conditions in the rule. If all conditions are met and the trigger interval meets the settings, the rule is triggered.

[0077] Timer-driven rules are triggered by timer instances: all timer instances referenced in rules (R) are scanned. If a timer is triggered and the trigger interval meets the settings, the rule is triggered.

[0078] The specific actions triggered by the rule include:

[0079] (1) Switching scenarios based on rule attributes, which includes modifying system-level switches and executing actions;

[0080] Or (2) directly execute actions based on rule attributes.

[0081] The specific operations to perform the action include:

[0082] (1) Search the action index according to the action identifier (A_uid) and determine whether the action command list has been loaded. If so, execute the action;

[0083] (2) If the command list is not loaded, determine whether the command list buffer is full. If not, load the command list and execute it.

[0084] (3) If the command list buffer is full, replace the command list with the smallest calledTimes in the action index and execute it.

[0085] A specific application scenario of the present invention is given below:

[0086] Example 1: Smart Gateway

[0087] In this embodiment, the "SMART" ultra-lightweight embedded IoT rules engine is implemented within an IoT gateway based on an STM32F103TB MCU. This MCU has 20KB of RAM and 128KB of Flash memory. Due to the simplicity and efficiency of the "SMART" engine, it consumes less than 5KB of RAM and 34KB of Flash memory, leaving sufficient resources for other functional modules in the gateway. As a result, this IoT gateway boasts a simple structure, low cost, and low power consumption. Less than the size of a matchbox, it is extremely easy to install and deploy. Furthermore, the rules engine operates completely offline, supporting up to 32 scenarios, 16 timers, 32 actions, 32 rule groups, and 32 statistical reports. This allows for efficient automated control even in unstable or even unavailable network environments. For example, in a classroom, scenario-based control of lighting, air conditioning, curtains, fans, projectors, and fresh air systems can be implemented. Rules include timed on / off devices, constant illumination lighting, occupancy sensing, linkage between lighting and curtains and projectors, and linkage between air quality and fresh air.

[0088] Example 2: Smart Sensor

[0089] In this embodiment, the "SMART" ultra-lightweight embedded IoT rules engine is implemented in a smart sensor based on the STM32L151C6 MCU. This MCU has 10KB of RAM and 32KB of Flash memory. Due to the simplicity and efficiency of the "SMART" engine, it consumes less than 3KB of RAM and 9KB of Flash memory, supporting 32 scenarios, 8 rules, 8 timers, 8 actions, and 8 statistical reports. This smart sensor boasts a simple structure, low cost, and low power consumption, making it very easy to install and deploy. It can collect indicators such as temperature and humidity, light intensity, carbon dioxide concentration, formaldehyde concentration, and PM2.5 concentration. Leveraging its built-in "SMART" rules engine, it can directly and intelligently control peripheral electrical devices such as air switches, relays, and curtain motors, eliminating the need for additional gateway devices and complex integration, significantly reducing system costs.

[0090] The key technologies of the present invention are summarized as follows:

[0091] The present invention discloses a design architecture and implementation method of an ultra-lightweight embedded Internet of Things rule engine "SMART". The rule engine requires very few system resources to implement functions such as time planning, composite rules, multiple scenarios, combined actions, and data statistics. It has high execution efficiency and supports offline operation. The algorithm can run on mainstream 32-bit single-chip microcomputers (MCUs), such as STM32. The "SMART" rule engine consists of five types of objects: scenarios (S), timers (M), actions (A), rules (R), and statistical reports (T).

[0092] A scene (S) corresponds to a specific user context in which relevant environmental parameters need to reach set values, or in other words, relevant devices need to be controlled to adjust environmental parameters. These environmental parameters include but are not limited to brightness, color temperature, temperature, humidity, air quality, and device status.

[0093] The timer (M) is used for timing control. You can set a timer for single trigger or periodic trigger. Periodic trigger supports setting the end time.

[0094] An action (A) is a collection of control messages for one or more nodes (NodeIDs). An action can include a maximum of 16 control messages, and one control message corresponds to one NodeID (required) and one SubID (optional).

[0095] A rule (R) associates scenarios, timers, and actions, and can specify trigger conditions, such as sensor NodeID, data item, threshold, conditional operator, and conditional connector. A rule defines the time and circumstances (conditions) under which action (such as changing the scenario or sending a control message) is to be performed. A rule's attributes require either scenario (S) or action (A); however, at least one of the timer (M) and trigger condition is required.

[0096] Statistical reports (T) are used to set data statistics for specific sensor data, actuator status, and rule (R) execution status. Statistical indicators include but are not limited to extreme values, average values, cumulative values, variances, etc., and statistical periods include but are not limited to hours, days, weeks, and months. The "SMART" rule engine automatically aggregates and cleans data according to the settings. The data in the statistical report (T) can not only be used for analysis and presentation, but also as a trigger condition for the rule (R). In other words, a statistical value can be defined as the data item of the trigger condition (in this case, NodeID = 0, indicating the system data item of this IoT device), stipulating that when the statistical data reaches a specific value, this rule (R) is triggered.

[0097] All sensors and actuators associated with this IoT device in the "SMART" rule engine, whether built-in or external, are identified by a node ID (NodeID). For sensors and actuators that need to be managed by the rule engine, NodeID is required. In addition, an optional sub-node ID (SubID) can be assigned. Nodes of the same type can use independent NodeIDs or share the same NodeID. When sensors or actuators share the same NodeID, they can be further selected by SubID. NodeID and SubID each occupy 1 byte, where the NodeID value range is 1-254 (0 and 255 are reserved for the system, 0 represents the IoT device itself, and 255 represents all nodes and broadcasts). In particular, SubID uses a bit mask method, so single selection and multiple selection are supported. In the rule engine's setup or control messages, the node selection / matching algorithm is as follows: First, the NodeID is matched. This includes two cases: if the target NodeID is the same as the NodeID of the selected sensor or actuator (for example, if the target NodeID is 8, only sensors and actuators with NodeID 8 will be selected), or if the target NodeID is 255, i.e., broadcast, all sensors and actuators will be selected. Next, the SubID is matched. This step is optional and is performed only when the rule engine's setup or control message specifies a target SubID (non-zero). If the target SubID is greater than 0, the bitwise AND (C language "&" operation) of the target SubID and the selected sensor or actuator's SubID is calculated. The sensor or actuator is selected only if the bitwise AND is true.

[0098] If a rule only sets a timer (M) but no triggering conditions, it is called a "timer-driven rule", which means that an action (A) is executed or a scene (S) is switched at a specified time.

[0099] If a rule contains a trigger condition, regardless of whether a timer (M) is set, it is called a "condition-driven rule." This means that the action (A) or scene switch (S) is executed when the specified condition is met and at the specified time (if any). There can be one or more trigger conditions, and the logical relationship between multiple conditions is indicated by the "or" or "and" condition connector.

[0100] Timer-driven rules are triggered by timer instances: all timer instances referenced in rules (R) are scanned. If a timer is triggered and the trigger interval meets the settings, the rule is triggered.

[0101] The condition-driven rule "data interface" serves as the trigger source: (1) The data interface receives internal and external sensor data, as well as statistical data (considered as a special type of "sensor"); (2) If the data changes, the data change handles associated with the changed data item are scanned in turn to find the corresponding rule object; (3) The conditions in the rule are judged. If all the conditions are met and the trigger interval meets the settings, the rule is triggered.

[0102] The specific operations triggered by the rule include: (1) switching scenarios based on the rule attributes, which include modifying system-level switches and executing actions; or (2) directly executing actions based on the rule attributes.

[0103] The specific operations of executing an action include: (1) searching the action index according to the action identifier (A_uid) to determine whether the action's command list has been loaded. If so, executing the action; (2) if the command list has not been loaded, determining whether the command list buffer is full. If not, loading the command list and executing it; (3) if the command list buffer is full, marking the command list space with the smallest total execution count (calledTimes) in the action index as unused, loading the command list of the action to be executed into this space, marking it as used, and then executing it. (4) After execution, the total execution count (calledTimes) of the action increases by 1.

[0104] The "SMART" rule engine loads model data when it starts, including scenes, timers, rules, and indexes of actions and statistical reports, which are all loaded into memory. The action command list and statistical data items are dynamically loaded on demand.

[0105] A scene (S) occupies 8 bytes, a timer (M) occupies 8 bytes, an action occupies 512 bytes and includes up to 16 commands, a rule occupies 32 bytes, and a statistical report includes current data and historical data, and occupies a maximum of 512 bytes. For the specific data structure, see Table 2: Object data structure of the "SMART" model.

[0106] The standard configuration of the "SMART" engine supports 32 scenes, 16 timers, 32 actions (each action can include 16 commands), 32 groups of rules and 32 statistical reports. Under this configuration, the FLASH storage required is less than 34K and the memory usage does not exceed 5K.

[0107] The "SMART" engine supports scaling models based on actual needs, enabling more efficient use of IoT device resources. For example, if the number of rules, actions, and statistical reports is reduced to eight, the required Flash memory and memory are reduced to less than 9KB and 3KB, respectively. This configuration is suitable for small, intelligent IoT devices. For highly complex rule requirements, the "SMART" engine can seamlessly scale up to a maximum of 256 rules, actions, statistical reports, and scenarios based on data structure definitions, requiring no more than 268KB of Flash memory and 24KB of memory.

[0108] The IoT device transmits data to the rule engine through the "data interface" of the "SMART" rule engine. The data includes but is not limited to the built-in sensor data and built-in actuator data of the IoT device, as well as the external sensor and external actuator data received through the IoT device communication module.

[0109] The "SMART" rule engine instructs IoT devices to perform relevant operations through the "command interface". The operation objects include but are not limited to the built-in actuators of IoT devices and external actuators controlled by the communication module of IoT devices.

[0110] The built-in and external sensors include, but are not limited to, temperature and humidity, brightness, human infrared, noise, pressure, vibration, PM2.5, PM10, carbon dioxide, formaldehyde, TVOC, smoke, electricity meters, water meters, etc.; the built-in and external actuators include, but are not limited to, lighting control, curtain control, air conditioning control, fan control, fresh air system control, access control, power switches, valves, etc. The IoT communication modules include, but are not limited to, Wi-Fi, RF2.4, RF433, Bluetooth, ZigBee, LoRa, NB-IoT, etc.

[0111] The SMART rule engine's configuration interface allows for configuration of SMART objects. Configuration operations include querying, adding, modifying, and deleting. Interface formats include, but are not limited to, JSON, serial port protocols, and binary data packets (corresponding to the SMART object data structure). Upon receiving a model "configuration" message, the rule engine updates and saves the model data and updates (including adding, modifying, and deleting) timer instances and data change callback handlers.

[0112] The above embodiments are merely preferred embodiments for the purpose of fully illustrating the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are within the scope of protection of the present invention. The scope of protection of the present invention shall be subject to the claims.

Claims

1. A design architecture for an ultra-lightweight embedded IoT rule engine, characterized by: The rule engine includes five types of objects: scenes, timers, actions, rules and statistical reports; wherein the scene corresponds to a specific user context environment, in which the relevant environmental parameters need to reach the set value, or the relevant equipment needs to be controlled to adjust the environmental parameters; the timer is used for timing control, and a single trigger or a periodic trigger timer can be set, and the periodic trigger supports setting the end time; the action is a collection of one or more node control messages; the rule associates scenes, timers and actions together, and can specify trigger conditions; the rule defines what action to take at what time and under what circumstances; in the attributes of the rule, either scene or action is optional; and at least one of the timer and trigger condition is required; the statistical report is used to set data statistics for specific sensor data, actuator status and rule execution status. The data in the statistical report can not only be used for analysis and display, but also as the trigger condition of the rule; wherein all sensors and actuators associated with this IoT device in the rule engine, whether built-in or external, are identified by a node ID; for sensors and actuators that need to be managed by the rule engine, N The NodeID is required, and an optional subnode ID can also be assigned. Nodes of the same type can use independent NodeIDs or share the same NodeID. When sensors or actuators share the same NodeID, they can be further selected using the SubID. NodeID and SubID each occupy one byte, with the NodeID value range being 1-254. SubID uses a bit mask, thus supporting both single and multiple selections. In the rule engine's setup or control messages, the node selection / matching algorithm is as follows: First, the NodeID is matched, including two cases: the target NodeID matches the NodeID of the selected sensor or actuator, or the target NodeID is 255, which is a broadcast, in which case all sensors and actuators are selected. Next, the SubID is matched. This step is optional and is performed only when the target SubID is specified in the rule engine's setup or control message. If the target SubID is greater than 0, the bitwise AND of the target SubID and the selected sensor or actuator's SubID is calculated. The sensor or actuator is selected only if the bitwise AND is true.

2. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 1, wherein: If a rule only sets a timer but no trigger conditions, it is called a "timer-driven rule," meaning that the action is executed or the scene is switched at the specified time. If a rule contains trigger conditions, regardless of whether a timer is set, it is called a "condition-driven rule," meaning that the action is executed or the scene is switched when the specified conditions are met and at the specified time. There can be one or more trigger conditions, and the logical relationships between multiple conditions are indicated by "or" or "and" conditional connectors.

3. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 2, wherein: Timer-driven rules use timer instances as trigger sources: scan all timer running instances referenced in the rules. If a timer is triggered and the trigger interval meets the settings, the rule is triggered. Condition-driven rules use the "data interface" as the trigger source: (1) The data interface receives internal and external sensor data, as well as statistical data; (2) If the data changes, scan the data change handles associated with the data item in turn to find the corresponding rule object; (3) Judge the conditions in the rule. If all conditions are met and the trigger interval meets the settings, the rule is triggered.

4. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 2, wherein: The specific operations triggered by the rule include: (1) switching scenarios according to the rule attributes, which include modifying system-level switches and executing actions; or (2) directly executing actions according to the rule attributes.

5. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 4, wherein: The specific operations of executing the action include: (1) searching the action index according to the action identifier, determining whether the command list of the action has been loaded, and if so, executing the action; (2) if the command list has not been loaded, determining whether the command list buffer is full, and if not, loading the command list and executing it; (3) if the command list buffer is full, marking the command list space with the smallest total execution count in the action index as unused, loading the command list of the action to be executed into this space, marking it as used, and then executing it; (4) after execution, the total execution count of the action increases by 1.

6. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 1, wherein: The rule engine loads model data when it starts, including scenes, timers, rules, and indexes of actions and statistical reports into memory, while action command lists and statistical data items are dynamically loaded on demand; A scene occupies 8 bytes, a timer occupies 8 bytes, an action occupies 512 bytes and includes up to 16 commands, a rule occupies 32 bytes, and a statistical report includes current and historical data and occupies a maximum of 512 bytes; The standard configuration of the rule engine supports 32 scenarios, 16 timers, 32 actions, 32 groups of rules, and 32 statistical reports. This configuration requires less than 34K of FLASH storage and no more than 5K of memory. The rule engine supports increasing or decreasing the model size according to actual needs to more effectively utilize the resources of IoT devices.

7. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 1, wherein: The configuration interface of the rule engine allows objects to be configured, and configuration operations include querying, adding, modifying and deleting; the interface formats include JSON, serial port protocol and binary data packets; if the rule engine receives a model "configuration" message, it updates and saves the model data, and updates the timer instance and data change callback handle.

8. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 1, wherein: The IoT device transmits data to the rule engine through the rule engine's "data interface", which includes but is not limited to the built-in sensor data and built-in actuator data of the IoT device, as well as external sensor and external actuator data received through the IoT device communication module; the rule engine instructs the IoT device to perform relevant operations through the "command interface", and the operation objects include the built-in actuator of the IoT device and the external actuator controlled by the IoT device communication module.

9. The design architecture of the ultra-lightweight embedded IoT rule engine according to claim 8, wherein: The built-in and external sensors include but are not limited to temperature and humidity, brightness, human infrared, noise, pressure, vibration, PM2.5, PM10, carbon dioxide, formaldehyde, TVOC, smoke, electricity meter and water meter; the built-in and external actuators include but are not limited to lighting control, curtain control, air conditioning control, fan control, fresh air system control, access control, power switch and valve; the IoT device communication modules include Wi-Fi, RF2.4, RF433, Bluetooth, ZigBee, LoRa and NB-IoT.

Images