An implementation method of an Internet of Things alarm based on a dynamic editable rule engine
By using a dynamic and editable rule engine, the problem of static rule engines in IoT alarm systems being unable to adapt to changes is solved. It enables dynamic rule editing and efficient alarm management without restarting the system, thus meeting the flexible monitoring needs of IoT platforms.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- MULTI IR OPTOELECTRONICS
- Filing Date
- 2023-04-21
- Publication Date
- 2026-05-29
AI Technical Summary
Traditional IoT alarm systems are based on static rule engines, which cannot be dynamically adjusted or changed, making it difficult to adapt to rapidly changing business needs and data traffic. Furthermore, the system needs to be restarted after the rules are modified, which affects monitoring efficiency.
Employing a dynamic and editable rule engine, the system allows users to dynamically set alarm rules by setting up a data transmission and reception module on the IoT server and a rule configuration module on the client side. The dynamic rule pool makes judgments and generates alarms. Rule conditions include time interval, frequency, numerical logic, and time window. It supports the concatenation of multiple sub-conditions, and rules can be edited at any time.
It enables dynamic adjustment of alarm rules to meet rapidly changing business needs, and rules can be updated without system restart, improving monitoring efficiency and flexibility.
Smart Images

Figure CN116800584B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet of Things (IoT) technology, and more specifically, to an IoT alarm implementation method based on a dynamic and editable rule engine. Background Technology
[0002] IoT alarms refer to alerts or notifications generated when anomalies or malfunctions occur in devices or sensors connected to the Internet of Things (IoT). IoT devices typically capture data through sensors or other monitoring equipment and send this data to an IoT platform or central server for processing and analysis. When devices or sensors detect abnormal data, such as excessively high temperature, low battery power, or connection interruption, they automatically generate alarms so that operators or administrators can take timely measures to ensure the normal operation of the equipment and maintain service quality.
[0003] In existing IoT monitoring systems, alarms are triggered when anomalies are detected in device operation. However, IoT alarms are based on specific alarm judgment conditions. Traditional IoT alarm systems are implemented using static rule engines or processing engines, whose rules or processes are fixed and cannot be dynamically adjusted or changed. Such systems struggle to adapt to rapidly changing business needs and data traffic, and cannot flexibly adjust alarm rules. Furthermore, editing or modifying the rule engine requires restarting the system and clearing memory, thus impacting the efficiency of the IoT platform's monitoring and alarm functions. Summary of the Invention
[0004] The purpose of this invention is to provide an IoT alarm implementation method based on a dynamic and editable rule engine to solve the problems mentioned in the background art.
[0005] To achieve the above objectives, the present invention provides the following technical solution: an IoT alarm implementation method based on a dynamic and editable rule engine, comprising the following steps:
[0006] S1. Set up a data transceiver module on the IoT server side, and obtain and send the collected IoT device data through the interface in the data transceiver module;
[0007] S2. Set up a rule configuration module in the IoT client. The rule configuration module is open to users, who can set alarm rules according to their actual needs.
[0008] S3. The rule configuration module connects to the dynamic rule pool. The dynamic rule pool receives IoT device data sent by the data transceiver module and determines whether the data generates an alarm.
[0009] S4. The dynamic rule pool can determine whether to execute newly generated rules, and it can also execute rules in the rule configuration module.
[0010] S5. The dynamic rule pool is connected to the alarm generation module. The alarm generation module receives the judgment result from the dynamic rule pool. When the judgment result indicates that an alarm is required, the alarm is generated through the alarm generation module.
[0011] Preferably, in S2, the alarm rules inside the rule configuration module consist of multiple sub-conditions, and the rule configuration module is configured with a time window. Each sub-condition includes a time interval, numerical logic, and frequency.
[0012] The time interval is used to set the time length for receiving multiple effective data;
[0013] The numerical logic is used to perform logical calculations and settings on the values reported by specific devices.
[0014] The frequency is used to set the number of times that the specific device reports data that meets the numerical logic conditions within the validity period of the sub-condition calculation;
[0015] The time window is used to set the duration for all sub-condition judgments.
[0016] Preferably, step S2 specifically includes the following steps:
[0017] S21. Once each sub-condition is met, sub-condition 2, sub-condition 3, ..., sub-condition n can be set.
[0018] S22. All sub-conditions must be effective within the time window. Once the time window expires, all conditions will become invalid, and the sub-conditions will be recalculated with the next new data.
[0019] Preferably, in step S4, the dynamic rule pool obtains the sub-conditions from the rule configuration module, determines whether the sub-conditions meet the execution conditions, and if the execution conditions are met, executes the new rule; if the execution conditions are not met, returns a new rule execution exception keyword.
[0020] Preferably, in step S4, the dynamic rule pool obtains the sub-conditions from the rule configuration module and performs judgment and calculation one by one. If the judgment duration is less than or equal to the time window, it means that the calculation is within the time window. If the judgment duration is greater than the time window, the calculation of all rules ends.
[0021] Preferably, in step S5, the alarm generation module generates alarms through the front-end display page of the IoT monitoring platform.
[0022] Preferably, the alarm generation module stores alarm logs to the local database in real time during the alarm process.
[0023] Preferably, the rule configuration module is initialized and loaded into memory when the system starts for the first time, and the initial rules are stored in the database in JSON format.
[0024] Compared with the prior art, the beneficial effects of the present invention are:
[0025] I. In this invention, the dynamic rules set four dimensions of rule conditions: time interval, frequency, numerical logic, and time window. Multiple sub-conditions can be chained together to form new rules. Alarms of various complexities can be dynamically edited. These rule conditions can be edited and executed at any time through the client, thereby achieving dynamic adjustment or change to meet rapidly changing business needs and data traffic.
[0026] Second, in this invention, the new rules that take effect will enter the dynamic rule pool. The data received from the device at the same time will be alarmed according to the new rules. The old rules that are halfway through the calculation will automatically become invalid after the time window expires, and there is no need to restart the system to clean up memory after each editing and modification. Attached Figure Description
[0027] Figure 1 This is a flowchart illustrating the IoT alarm implementation method based on a dynamic editable rule engine according to an embodiment of the present invention.
[0028] Figure 2 This is another flowchart illustrating the IoT alarm implementation method based on a dynamic editable rule engine, according to an embodiment of the present invention. Detailed Implementation
[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0030] Please see Figures 1-2 The present invention provides an IoT alarm implementation method based on a dynamic and editable rule engine, specifically including the following steps:
[0031] S1. Set up a data transceiver module on the IoT server side, and obtain and send the collected IoT device data through the interface in the data transceiver module;
[0032] S2. Set up a rule configuration module in the IoT client. The rule configuration module is open to users, who can set alarm rules according to their actual needs.
[0033] S3. The rule configuration module connects to the dynamic rule pool. The dynamic rule pool receives IoT device data sent by the data transceiver module and determines whether the data generates an alarm.
[0034] S4. The dynamic rule pool can determine whether to execute newly generated rules, and it can also execute rules in the rule configuration module.
[0035] S5. The dynamic rule pool is connected to the alarm generation module. The alarm generation module receives the judgment result from the dynamic rule pool. When the judgment result indicates that an alarm is required, the alarm is generated through the alarm generation module.
[0036] In this embodiment, in step S2, the alarm rules inside the rule configuration module consist of multiple sub-conditions. The rule configuration module is configured with a time window, and each sub-condition includes a time interval, numerical logic, and frequency.
[0037] The time interval is used to set the time length for receiving multiple effective data; the numerical logic is used to perform logical calculations on the values reported by specific devices; the frequency is used to set the number of times the data reported by the specific device meets the numerical logic conditions within the validity period of the sub-condition calculation; and the time window is used to set the duration for judging all sub-conditions.
[0038] Furthermore, in the numerical logic, it is possible to set the numerical range of a specific device's reported value, such as greater than, less than, equal to, or not equal to. At the same time, it is possible to perform numerical range logical calculations on multiple values of a specific device. For example, if the device reports temperature or humidity, the numerical logic can be set to temperature greater than 10 and humidity less than 10.
[0039] Furthermore, when generating a sub-condition, for example, if the sub-condition is set to a time interval of less than 1 minute, a frequency of 2 times, and a logical value greater than 100, then the sub-condition will take effect as long as the device receives a value greater than 100 twice within 1 minute. If the setting is more than 1 minute, a frequency of 2 times, and a logical value greater than 100, then it means that if a value greater than 100 is received for the first time, and then another value greater than 100 is received 1 minute later, then the sub-condition will be valid. Finally, all the sub-conditions combined become the total condition of the rule.
[0040] In this embodiment, step S2 specifically includes the following steps:
[0041] S21. Once each sub-condition is met, sub-condition 2, sub-condition 3, ..., sub-condition n can be set.
[0042] S22. All sub-conditions must be effective within the time window. Once the time window expires, all conditions will become invalid, and the sub-conditions will be recalculated with the next new data.
[0043] In this embodiment, in step S4, the dynamic rule pool obtains the sub-conditions from the rule configuration module, determines whether the sub-conditions meet the execution conditions, and if the execution conditions are met, executes the new rule; if the execution conditions are not met, returns a new rule execution exception keyword.
[0044] Furthermore, in S4, the dynamic rule pool obtains the sub-conditions in the rule configuration module and performs judgment and calculation one by one. If the judgment duration is less than or equal to the time window, it means that the calculation is within the time window. If the judgment duration is greater than the time window, the calculation of all rules ends.
[0045] It should be noted that abnormal keywords can be obtained by the IoT client, which can then notify the customer that the alarm rule settings are incorrect and prompt them to edit and modify the alarm rule.
[0046] In this embodiment, in step S5, the alarm generation module sends an alarm through the front-end display page of the IoT monitoring platform, and at the same time, the alarm generation module can store alarm logs to the local database in real time during the alarm process.
[0047] Specifically, the rule configuration module is initialized and loaded into memory when the system starts for the first time, and the initial rules are stored in the database in JSON format.
[0048] In summary, this invention sets four dimensions of rule conditions in the dynamic rules: time interval, frequency, numerical logic, and time window. Multiple sub-conditions can be chained together to form new rules, and alarms of varying complexity can be dynamically edited. These rule conditions can be edited and executed at any time through the client, thereby achieving dynamic adjustment or modification to meet rapidly changing business needs and data traffic. In addition, the new rules that take effect will enter the dynamic rule pool. For the data received from the device at the same time, alarms will be issued according to the new rules, while the calculation of old rules that are halfway through will automatically expire when the time window expires, eliminating the need for system restarts and memory cleanup operations after each edit.
[0049] All parts not described in this invention are the same as or can be implemented using existing technology. Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for implementing IoT alarms based on a dynamic, editable rule engine, characterized in that, Includes the following steps: S1. Set up a data transceiver module on the IoT server side, and obtain and send the collected IoT device data through the interface in the data transceiver module; S2. Set up a rule configuration module in the IoT client. The rule configuration module is open to users, who can set alarm rules according to their actual needs. S3. The rule configuration module connects to the dynamic rule pool. The dynamic rule pool receives IoT device data sent by the data transceiver module and determines whether the data generates an alarm. S4. The dynamic rule pool can determine whether to execute newly generated rules, and the dynamic rule pool can execute rules in the rule configuration module; S5. The dynamic rule pool is connected to the alarm generation module. The alarm generation module receives the judgment result from the dynamic rule pool. When the judgment result indicates that an alarm is required, the alarm is generated through the alarm generation module. In S2, the alarm rules inside the rule configuration module consist of multiple sub-conditions. The rule configuration module is configured with a time window, and each sub-condition includes a time interval, numerical logic, and frequency. The time interval is used to set the time length for receiving multiple effective data; The numerical logic is used to perform logical calculations and settings on the values reported by specific devices. The frequency is used to set the number of times that the specific device reports data that meets the numerical logic conditions within the validity period of the sub-condition calculation; The time window is used to set the duration for all sub-condition judgments; S2 specifically includes the following steps: S21. Once each sub-condition is met, sub-condition 2, sub-condition 3, ..., sub-condition n can be set. S22. All sub-conditions must be effective within the time window. Once the time window expires, all conditions will become invalid, and the sub-conditions will be recalculated with the next new data.
2. The IoT alarm implementation method based on a dynamic editable rule engine according to claim 1, characterized in that: In step S4, the dynamic rule pool obtains the sub-conditions from the rule configuration module and determines whether the sub-conditions meet the execution conditions. If the execution conditions are met, the new rule is executed; otherwise, the execution exception keyword for the new rule is returned.
3. The IoT alarm implementation method based on a dynamic editable rule engine according to claim 1, characterized in that: In step S4, the dynamic rule pool obtains the sub-conditions from the rule configuration module and performs judgment and calculation one by one. If the judgment duration is less than or equal to the time window, it means that the calculation is within the time window. If the judgment duration is greater than the time window, the calculation of all rules ends.
4. The IoT alarm implementation method based on a dynamic editable rule engine according to claim 1, characterized in that: In step S5, the alarm generation module issues alarms through the front-end display page of the IoT monitoring platform.
5. The IoT alarm implementation method based on a dynamic editable rule engine according to claim 4, characterized in that: The alarm generation module stores alarm logs to the local database in real time during the alarm process.
6. The IoT alarm implementation method based on a dynamic editable rule engine according to claim 1, characterized in that: The rule configuration module is initialized and loaded into memory when the system starts for the first time, and the initial rules are stored in the database in JSON format.