IoT point-oriented visual real-time rule calculation method

Abstract

This application provides a visualized real-time rule calculation method for IoT points. The method is executed based on a corresponding rule calculation system. The method includes configuring the required basic information in the rule calculation system and synchronizing IoT metadata from the IoT platform to the rule calculation system; selecting corresponding IoT points and constructing rule chains by dragging and dropping operators based on the required basic information, and parsing the rule chains to obtain rule DSLs; in the scheduling service, dynamically scheduling tasks are supplied in frequency groups, and Akka Cluster cluster sharding is used to notify the scheduling tasks via messages; each scheduling task corresponds to several rule DSLs with the same frequency; the relevant operators corresponding to the rule DSLs are executed according to the message notifications, and the relevant data is stored. This application solves the problems of insufficient compatibility, high latency, and inability to visualize and orchestrate existing IoT point rule calculation schemes through the above solution.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) network communication technology, and in particular to a visualized real-time rule calculation method for IoT points. Background Technology

[0002] In the fields of IoT and Industrial Internet, real-time monitoring, analysis, and early warning of massive amounts of device location data are core requirements. Currently, the mainstream technical solutions for achieving these requirements rely on the combined application of general-purpose rule engines and general-purpose streaming computing platforms. Typical architectures often use platforms such as Drools and Flink as the core, integrated and extended through programming. Such systems generally consist of a rule development and management interface, a runtime rule engine and computation task scheduling module, and a computation result storage and visualization module; their standard implementation process covers three stages: rule development and definition, rule deployment and task initiation, and real-time processing of streaming data and result persistence.

[0003] However, when the above-mentioned general technical solutions are directly applied to real-time data processing scenarios in the Industrial Internet of Things, a series of significant technical bottlenecks and challenges are encountered, specifically in the following aspects: The existing rule engines suffer from insufficient flexibility and maintainability in rule configuration: Most are designed for software developers, with rule definitions relying on configuration files containing code or code-like structures, lacking intuitive, visual orchestration interfaces for business analysts. More importantly, they lack built-in understanding and verification capabilities for semantics in the Industrial Internet of Things (IIoT) domain (such as unique physical location identifiers, data types, and information about the associated equipment and production unit). This results in lengthy cycles for creating, modifying, testing, and deploying business rules, high configuration barriers, and difficulty in quickly responding to changes in production processes or adjustments to operational strategies.

[0004] The native support for complex temporal state determination is weak: Industrial early warning logic is usually not a simple instantaneous threshold comparison, but involves state machine determination combining "duration," "threshold level," and "data quality." For example, it may be necessary to determine whether a certain measurement point's value exceeds a threshold and remains above it for a certain period before triggering an alarm of a specific level. Furthermore, during the alarm state, repeated alarms must be suppressed, and the alarm state can only be lifted if the value returns to normal and does not exceed the threshold within a certain time. Simultaneously, rule execution must consider the quality markers of data points (such as validity or whether they are substitutes) and equipment status (such as pausing rule calculations when offline). This type of time-series logic with memory characteristics and multiple coupled conditions lacks direct and efficient native support in general-purpose rule engines and process orchestration tools oriented towards stateless or simple stateful computation, making implementation complex and error-prone.

[0005] The system suffers from insufficient performance and stability in handling massive, high-concurrency data streams: In industrial IoT scenarios, the number of connected points is enormous, and data collection frequency is high. General-purpose rule scheduling and streaming computing engines are often not optimized for millisecond-level throughput and massive parallel rule computation at the architectural level. Some existing visualization rule engine solutions have limited concurrent processing capabilities in their underlying execution engines and lack dynamic, automatic elastic scaling and task rebalancing strategies based on load changes in resource scheduling. This easily leads to drastic fluctuations in throughput and increased processing latency under high load, while resources remain idle under low load, resulting in low overall resource utilization and failing to meet the stable and efficient processing requirements of industrial scenarios.

[0006] The handling mechanism for out-of-order and late-arriving event data is inadequate: Due to differences in sampling cycles of industrial field equipment and the complexity and variability of network transmission links, out-of-order event timestamps and late arrivals are common phenomena in data streams. If general processing solutions lack a watermark-driven mechanism based on event time and an alignment and calculation triggering mechanism based on time windows, the aggregated statistics based on time windows (such as minute-by-minute averages) will be inaccurate, potentially leading to erroneous alarms (such as alarms that should be merged being triggered repeatedly) or alarm loss, severely impacting the accuracy of data analysis and early warning.

[0007] Balancing consistency and efficiency in real-time and historical data queries is challenging: the system needs to simultaneously satisfy low-latency real-time queries of the latest calculation results (e.g., for monitoring dashboards) and flexible traceability and retrieval analysis of historical calculation results. A single storage system typically struggles to optimize both data models, write performance, and query efficiency at the same time. Common solutions require compromises between real-time computation links and batch backtracking computations, and between real-time and historical storage, or the establishment of complex data synchronization links, increasing system complexity and maintenance costs. Summary of the Invention

[0008] This application provides a visualized real-time rule calculation method for IoT points to solve the problems of insufficient versatility, high latency, and inability to perform visualized orchestration in existing IoT point rule calculation schemes.

[0009] The method is executed based on a corresponding rule calculation system, and the method includes: Configure the required basic information in the rule calculation system, and synchronize the IoT metadata of the IoT platform to the rule calculation system; Select the corresponding IoT point and construct a rule chain by dragging and dropping operators based on the required basic information, and parse the rule DSL according to the rule chain; In the scheduling service, dynamic scheduling tasks are supplied in groups based on frequency, and Akka Cluster cluster sharding is used to notify the scheduling tasks via messages to achieve consistent routing from rules to computing nodes; each scheduling task corresponds to several rules DSL with the same frequency. The relevant operators corresponding to the rule DSL are executed according to the message notification, and the relevant data is stored.

[0010] Preferably, the required basic information includes location basic information and operator basic information; the location basic information includes relevant information about the IoT location selected by the user.

[0011] Preferably, the step of selecting the corresponding IoT location and constructing a rule chain based on the required basic information by dragging and dropping operators includes: The rule calculation system calls the IoT location selected by the user and constructs a rule chain by dragging and dropping operators based on the required basic information; The rule chain is then graphically verified using the rule calculation system.

[0012] Preferably, the operator includes mathematical calculation, statistical operation, threshold judgment, early warning classification, result push and API call; The graph verification includes verification of operator type, operator unit, operator time window, and DAG loop.

[0013] Preferably, the step of parsing the rule DSL from the rule chain includes: The backend of the rule calculation system parses the rule chain into DSL syntax to obtain the rule DSL, and generates a version number corresponding to the rule DSL; the version number is used for hot updates and rollbacks of the rule calculation system.

[0014] Preferably, the step of allocating scheduling tasks according to a certain frequency in the scheduling service and using Akka Cluster cluster sharding to send message notifications to the scheduling tasks includes: The scheduling task is allocated according to the rule execution frequency of the DSL, and new scheduling tasks are created periodically based on the number of rules to be allocated and the remaining capacity of currently available rules; the allocation method of the scheduling task includes placing the same rule in the same computing node.

[0015] Preferably, the step of allocating scheduling tasks at a certain frequency in the scheduling service and using Akka Cluster cluster sharding to send message notifications to the scheduling tasks further includes: Rebalance rules that are unassigned, have frequency mismatch due to modification, or exceed capacity, and automatically reclaim scheduling tasks that have been without rules for a long time. Placing the same rule on the same computing node includes: The hash ring is set up based on the dynamic number of physical computing nodes and virtual nodes. The first and second clockwise landing points are obtained according to the hash value of the rule ID. The rules are then placed consistently according to the affinity strategy of the first and second clockwise landing points.

[0016] Preferably, the step of executing the relevant operator corresponding to the rule DSL according to the message notification includes: Upon receiving the message notification, the real-time value of the IoT point is obtained, and the real-time rule DSL is executed in parallel through the Akka Actor thread model and LiteFlow engine to calculate the relevant operators.

[0017] Preferably, the step of storing the relevant data includes: The corresponding data is stored in a relational database, a distributed memory database, and a time-series database. The relevant data of the IoT points, the operators, and the rules are consistently written to both the relational database and the distributed memory database. The real-time values ​​of the IoT points are consistently written to both the distributed memory database and the time-series database. The intermediate data of rule execution is written to the distributed memory database.

[0018] Preferably, the execution of each rule has an independent circuit breaker mechanism, which includes stopping execution for a certain number of minutes after a certain number of consecutive execution failures; The message notification adopts a hash-consistent notification based on the rule ID, and the same rule ID is executed as a string.

[0019] As described above, this application provides a visualized real-time rule calculation method for IoT points. The method is executed based on a corresponding rule calculation system. The method includes configuring the required basic information in the rule calculation system and synchronizing the IoT metadata of the IoT platform to the rule calculation system; selecting the corresponding IoT point and constructing a rule chain by dragging and dropping operators based on the required basic information, and parsing the rule chain to obtain a rule DSL; in the scheduling service, dynamically scheduling tasks are supplied in frequency groups, and Akka Cluster cluster sharding is used to notify the scheduling tasks via messages to achieve consistent routing from rules to computing nodes; each scheduling task corresponds to several rule DSLs with the same frequency; the relevant operators corresponding to the rule DSL are executed according to the message notification, and the relevant data is stored. This application solves the problems of insufficient compatibility, high latency, and inability to perform visualized orchestration in existing IoT point rule calculation schemes through the above solution. Attached Figure Description

[0020] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of a visual real-time rule calculation method for IoT points according to this application; Figure 2 This is a schematic diagram of a real-time rule calculation method for IoT locations according to this application. Detailed Implementation

[0022] 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0023] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0024] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0025] Figure 1 This is a flowchart of a visual real-time rule calculation method for IoT points according to this application.

[0026] Figure 2 This is a schematic diagram of a real-time rule calculation method for IoT locations according to this application.

[0027] See Figure 1 As can be seen, this embodiment provides a visualized real-time rule calculation method for IoT points, the method being based on Figure 2 The rule calculation system shown executes the method, which includes: S1, Configure the required basic information in the rule calculation system, and synchronize the IoT metadata of the IoT platform to the rule calculation system.

[0028] Specifically, in this embodiment, the basic information of the IoT points and the basic information of the operators are synchronized from the IoT platform to the rule calculation system; the IoT points are information nodes in the IoT platform, and the IoT points and the rule calculation system have a calling relationship.

[0029] The required basic information includes basic location information and basic operator information; the basic location information includes relevant information about the IoT location selected by the user.

[0030] For example, the necessary location metadata is synchronized from the IoT platform to the system, along with basic information that some operators depend on (such as the data source for storing calculation results and the topic for pushing early warning results). This is typically a one-time action; once completed, rules can be created and their basic metadata, such as name, code, and execution frequency, can be set.

[0031] The method further includes: S2, select the corresponding IoT point and construct a rule chain by dragging and dropping operators according to the required basic information, and parse the rule chain to obtain the rule DSL.

[0032] Specifically, in this embodiment, the rule calculation system calls the IoT location selected by the user, and constructs a rule chain in the IoT location by dragging and dropping operators based on the required basic information; and performs graphical verification on the rule chain through the rule calculation system.

[0033] Furthermore, in some embodiments, the step of parsing the rule chain to obtain the rule DSL includes parsing the rule chain into DSL syntax through the backend of the rule calculation system to obtain the rule DSL, and generating a version number corresponding to the rule DSL; the version number is used for hot updates and rollbacks of the rule calculation system.

[0034] Specifically, in this embodiment, as described in step S2, the user selects the desired IoT location and constructs a rule chain by dragging and dropping process operators (mathematical / statistical operations, threshold judgment, early warning classification, result push, API call, etc.). The system performs graph-level verification (operator type / unit / time window, DAG loop). Upon saving, the backend parses the link into DSL syntax and generates a new version number, providing a basis for subsequent hot updates and rollbacks.

[0035] The method further includes: S3, in the scheduling service, dynamic scheduling tasks are supplied in groups according to frequency, and Akka Cluster cluster sharding is used to notify the scheduling tasks via messages to achieve consistent routing from rules to computing nodes; each scheduling task corresponds to several rules DSL with the same frequency.

[0036] Specifically, in this embodiment, scheduling tasks are allocated according to the rule execution frequency of the rule DSL, and new scheduling tasks are created periodically based on the number of rules to be allocated and the remaining capacity of currently available rules; the allocation method of the scheduling tasks includes placing the same rule in the same computing node.

[0037] The specific method for allocating the scheduling tasks includes setting a hash ring based on the dynamic number of physical computing nodes and virtual nodes, obtaining the first and second clockwise landing points according to the hash value of the rule ID, and placing the rules in a consistent manner according to the affinity strategy of the first and second clockwise landing points.

[0038] Furthermore, in some embodiments, the step of dynamically allocating scheduling tasks according to the rule DSL further includes rebalancing rules that are not allocated, have frequency mismatches due to modifications, or exceed capacity, and automatically reclaiming scheduling tasks that have been without rules for a long time.

[0039] Specifically, in this embodiment, as can be seen from step S3, according to the execution frequency grouping set by the rules, the system periodically scans the number of rules to be allocated R and the current available remaining capacity A under each frequency. When R>A, N new scheduling tasks are automatically created according to the formula N=ceil((RA) / C) (C is the single task capacity threshold).

[0040] Meanwhile, rebalancing is performed on unallocated rules, rules that have frequency mismatch due to modifications, or rules that exceed capacity, and empty tasks that have been without rules for a long time are automatically reclaimed, so as to achieve dynamic and stable supply of resources. This strategy is particularly important in scenarios where new rules are added in batches, rules are paused in batches, and rule frequencies are adjusted in batches.

[0041] The system sets up a hash ring based on the dynamic number of physical computing nodes and virtual nodes. The first and second clockwise landing points are obtained by using the hash value of the rule ID. Rules are placed consistently using an affinity strategy that places the first and second clockwise landing points, ensuring that the same rule is placed on the same computing node as much as possible.

[0042] Ultimately, scheduling is achieved through Akka ClusterSharding cluster sharding for message notification.

[0043] Among them, PowerJob (a distributed scheduler) is used for rule triggering, which can support down to the millisecond level.

[0044] The method further includes: S4. Execute the relevant operators corresponding to the rule DSL according to the message notification, and store the relevant data.

[0045] Specifically, in this embodiment, upon receiving the message notification, the real-time value of the IoT point is obtained, and the real-time rule DSL is executed in parallel using the Akka Actor thread model (a distributed computing framework, a concurrency framework based on Actors) and the LiteFlow engine (a rule orchestration and execution engine) to calculate the relevant operators. The corresponding data is stored in a relational database, a distributed memory library, and a time-series database. The relevant data of the IoT point, the operators, and the rules are consistently written to both the relational database and the distributed memory library. The real-time value of the IoT point is consistently written to both the distributed memory library and the time-series database. The intermediate data of rule execution is written to the distributed memory library.

[0046] For example, after receiving the rule calculation notification, the system will obtain the current real-time value of the point and execute the rule chain (the parsed DSL) in parallel through the AkkaActor thread model (a distributed computing framework, a concurrency framework based on Actors) and the LiteFlow engine (a rule orchestration and execution engine). A single rule execution is regarded as an Actor, and each rule has an independent circuit breaker mechanism. If it fails N times in a row, it will stop running for A minutes.

[0047] Each operator has its own execution logic, and new operators can be added to the system through operator registration. Typically, early warning result push and calculation result storage are result-type operators for rule execution, respectively targeting early warning rules and calculation rules.

[0048] Read and write operations are performed using the co-location storage capabilities of Ignite (a distributed memory library), reducing cross-node network latency. Some cold data is cached locally, and any changes are broadcast to all computing nodes via Akka (a distributed computing framework, a concurrency framework based on Actors) for updates. Hash-based consistent notification based on rule IDs is used instead of polling, and the same rule ID is executed serially, achieving a lock-free design and avoiding the performance loss caused by using distributed locks.

[0049] Combining the above targeted performance optimizations with system architecture design (refer to system schematic) Figure 2 With a configuration of 3 8c8g compute nodes, the system concurrency can reach 10,000+ rules executed per second, a figure verified in real-world scenarios.

[0050] This embodiment generally follows the design principle of "dual writing of configuration data, low-latency reading and writing of runtime data, and storage of timing results in the timing library".

[0051] The system's configuration information, such as IoT locations, operators, and rule information (configuration data), enables multi-data source transactions in the relational database and the distributed memory database Ignite (distributed memory database), and consistently writes to both the relational database and the distributed memory database.

[0052] Start the Kafka consumer node and write the real-time data points to both the in-memory database and the time-series database TDengine (time-series database). Based on the data distribution of the data points in the time-series database over the past hour, calculate whether the data points are offline or have resumed being online, and update the rule status synchronously. The rule judgment can be used to stop running or ignore offline data points.

[0053] Intermediate data (runtime data) of rule execution is written to the memory database. Rule calculation / alert results and execution records are written to the time series database in batches by a sub-thread. The rule results can be optionally written to the database or pushed to the message queue according to the rule configuration.

[0054] The system has a built-in data service module that exposes the early warning / calculation results as an external data service API. It can dynamically select to read data from memory storage or time series database according to the timeliness and scope of the query request, and supports aggregation and downsampling.

[0055] Case 1: In a blast furnace production temperature early warning scenario, it is necessary to monitor the high steam flow temperature point T1 at low frequency. The early warning rule is as follows: If the current temperature is less than 0.55°C (last month's average) or the current temperature is greater than 48°C for 1 hour, it is considered a Level 2 alarm. If the current temperature is less than 0.5°C (the average of the previous month) or the current temperature is greater than 50°C for 1 hour, it is considered a Level 1 alarm.

[0056] Implementation process: 1. Select point T1 in the point management section and click "Synchronize" to synchronize the point's metadata to the system.

[0057] 2. Create a new rule "Abnormal High-Steam Temperature in Blast Furnace", set the execution frequency (15 seconds / time), and drag and drop operators (Average Value), (Logical Operation), (Early Warning Classification), and (Result Push) on the rule arrangement page. Set operator attributes (select time range for Average Value, configure formula for Logical Operation, specify formula result judgment and duration for Early Warning Classification, specify push topic for Early Warning Push), and connect operators to form a link graph. After the system verifies and passes the verification, save the rule, parse the DAG into a DSL and store it, broadcast a notification to the computing nodes that a new rule has been added, and the computing nodes compile the DSL to register the rule into the rule pool.

[0058] 3. Upon receiving real-time location data, the consumer of the location service saves the real-time location value to both the memory database and the time-series database. A sub-thread continuously checks the location status (offline / restored online) every 30 seconds and records it to the memory database.

[0059] 4. The scheduling service identifies the addition of a new rule and assigns it a scheduling task. The system determines that there is one scheduling task every 15 seconds, with a current capacity of 170 (170 rules are attached to this task), and a maximum capacity of 200. This meets the addition criteria, so the rule is attached to the scheduling task. During scheduling, these 171 rules are hashed and a physical computing node is specified. Computation notifications are then sent within the Akka cluster.

[0060] 5. Upon receiving the computation notification, the compute node assigns a rule actor and starts LiteFlow (the rule orchestration and execution engine) to execute the rule flow. During runtime, the average value operator outputs a statistical value R1 based on the sliding window; the logical operation operator performs formula calculations by substituting the values ​​of T1 and R1, and outputs the result value R2; the warning classification operator determines that if R2 is true, it is considered a warning and starts timing. When the cumulative duration exceeds 1 hour, the corresponding level of warning is triggered; the warning result is pushed to the message topic specified by the result push operator.

[0061] 6. Alarm results are written to the memory database and time series database, and the data is provided through the data service API and displayed on the monitoring dashboard.

[0062] Case 2: In a continuous casting production line shutdown early warning scenario, it is necessary to monitor the straightening machine's line speed T1 and the casting position T2 at high frequency. The early warning rules are as follows: Shutdown: The linear speed of the straightening machine and the pouring position are both 0, and an early warning will be issued if this continues for 5 minutes.

[0063] Resume production: No shutdown required; warning will be canceled after 5 seconds.

[0064] Implementation process (same as Case 1, will not be repeated): 1. The scheduling frequency is 500 milliseconds / time. The system determines that the current scheduling task capacity of 500 milliseconds / time is full (maximum capacity 100). According to the formula ceil((RA) / C), it is calculated that one scheduling task needs to be created. The new task is created and attached.

[0065] 2. When the rule-based warning lasts for 4 minutes, location T1 goes offline. Since the rule is configured to stop running when offline, the rule stops running and triggers a circuit breaker. The process retryes every minute after the circuit breaker time until the location returns to online status, at which point the rule restarts.

[0066] 3. The rule chain contains data storage operators. When an alert is issued or canceled, the alert result is synchronously written to the corresponding data source for use by the business system.

[0067] The advantages of this embodiment include: The process transforms complex engineering coding into a user-friendly graphical drag-and-drop interface, with built-in semantic validation for pre-emptive error interception. This significantly improves the efficiency and accuracy of rule configuration by lowering the operational threshold and implementing pre-emptive validation.

[0068] It natively supports complex continuous status alarm logic in industrial scenarios (e.g., >10 for 30 minutes constitutes a Level 1 alarm) and corrects statistical biases caused by out-of-order and delayed data through a water level mechanism. This ensures the accuracy of industrial early warnings and reduces false alarms and missed alarms.

[0069] It achieves dynamic and precise matching of computing resources and rule load, and can quickly adapt when rules are added, removed, or their frequency adjusted in batches, thus avoiding load skew. Through a proactive and quantitative resource scheduling mechanism, it ensures low latency and system stability under high concurrency.

[0070] By employing an Actor thread model and hash-consistent fixed-node scheduling, avoiding distributed locks, implementing memory-based high-frequency read / write operations, and prioritizing computation based on proximity, lock contention, network I / O, and serialization overhead are minimized. Through extreme performance optimization, ultra-high concurrency processing capabilities (e.g., 10,000 TPS with 3 compute nodes) are achieved with limited resources.

[0071] By separating low-latency real-time computing (in-memory) from highly reliable historical tracing (time-series database), the data service API intelligently routes queries based on their timeliness. This satisfies both real-time querying and historical analysis requirements without sacrificing performance.

[0072] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the discussion in some embodiments is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the contents of this disclosure, thereby enabling those skilled in the art to better utilize the embodiments.

Claims

1. A visualized real-time rule calculation method for IoT points, characterized in that, The method is executed based on a corresponding rule calculation system, and the method includes: Configure the required basic information in the rule calculation system, and synchronize the IoT metadata of the IoT platform to the rule calculation system; Select the corresponding IoT point and construct a rule chain by dragging and dropping operators based on the required basic information, and parse the rule DSL according to the rule chain; In the scheduling service, dynamic scheduling tasks are supplied in groups according to frequency, and Akka Cluster cluster sharding is used to notify the scheduling tasks via messages to achieve consistent routing from rules to computing nodes; each scheduling task corresponds to several rules DSL with the same frequency. The relevant operators corresponding to the rule DSL are executed according to the message notification, and the relevant data is stored.

2. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The required basic information includes basic location information and basic operator information; the basic location information includes relevant information about the IoT location selected by the user.

3. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The step of selecting the corresponding IoT location and constructing a rule chain based on the required basic information by dragging and dropping operators includes: The rule calculation system calls the IoT location selected by the user and constructs a rule chain by dragging and dropping operators based on the required basic information; The rule chain is then graphically verified using the rule calculation system.

4. The method for visual real-time rule calculation for IoT points according to claim 3, characterized in that, The operators include mathematical calculations, statistical operations, threshold judgments, early warning classifications, result push notifications, and API calls; The graph verification includes verification of operator type, operator unit, operator time window, and DAG loop.

5. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The step of parsing the rule DSL based on the rule chain includes: The backend of the rule calculation system parses the rule chain into DSL syntax to obtain the rule DSL, and generates a version number corresponding to the rule DSL; the version number is used for hot updates and rollbacks of the rule calculation system.

6. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The steps of dynamically scheduling tasks grouped by frequency in the scheduling service and using Akka Cluster sharding to notify the scheduling tasks via messages include: The scheduling task is allocated according to the rule execution frequency of the DSL, and new scheduling tasks are created periodically based on the number of rules to be allocated and the remaining capacity of currently available rules; the allocation method of the scheduling task includes placing the same rule in the same computing node.

7. The method for visual real-time rule calculation for IoT points according to claim 6, characterized in that, The steps of providing dynamically scheduled tasks in frequency-grouped batches in the scheduling service, and using Akka Cluster sharding to notify the scheduled tasks via message notification, further include: Rebalance rules that are unassigned, have frequency mismatch due to modification, or exceed capacity, and automatically reclaim scheduling tasks that have been without rules for a long time. Placing the same rule on the same computing node includes: The hash ring is set up based on the dynamic number of physical computing nodes and virtual nodes. The first and second clockwise landing points are obtained according to the hash value of the rule ID. The rules are then placed consistently according to the affinity strategy of the first and second clockwise landing points.

8. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The step of executing the relevant operator corresponding to the rule DSL according to the message notification includes: Upon receiving the message notification, the real-time value of the IoT point is obtained, and the real-time rule DSL is executed in parallel through the Akka Actor thread model and LiteFlow engine to calculate the relevant operators.

9. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, The steps for storing the relevant data include: The corresponding data is stored in a relational database, a distributed memory database, and a time-series database. The relevant data of the IoT points, the operators, and the rules are consistently written to both the relational database and the distributed memory database. The real-time values ​​of the IoT points are consistently written to both the distributed memory database and the time-series database. The intermediate data of rule execution is written to the distributed memory database.

10. The method for visual real-time rule calculation for IoT points according to claim 1, characterized in that, Each rule has an independent circuit breaker mechanism, which includes stopping execution for a certain number of minutes after a certain number of consecutive execution failures; The message notification adopts a hash-consistent notification based on the rule ID, and the same rule ID is executed as a string.

Images