A rule engine system of intelligent parking internet of things

Abstract

This invention belongs to the technical field of rule engine systems, specifically relating to a rule engine system for smart parking IoT. A rule management unit converts input rule description information into rules and stores them in a database. A knowledge base management unit generates and updates the knowledge base. A data receiving unit receives completed object model data and generates device twin data. A rule engine unit searches the knowledge base, loads rules, evaluates rule triggering conditions, and triggers rule execution actions. This invention effectively reduces the complexity of components implementing complex business logic, lowers the maintenance and scalability costs of IoT applications, improves decision-making flexibility, and increases demand response speed, making it highly suitable for smart parking business scenarios.

Description

Technical Field

[0001] This invention belongs to the technical field of rule engine systems, specifically relating to a rule engine system for smart parking IoT. Background Technology

[0002] Smart parking integrates wireless communication, mobile terminal, GPS positioning, and GIS technologies to collect, manage, query, reserve, and navigate urban parking spaces. This achieves real-time updates, queries, reservations, and navigation services for parking resources, maximizing parking space utilization, parking lot profits, and optimizing parking services for drivers. Smart parking involves diverse terminal data types, each processed differently. Rule engines, as a business framework technology, are used to separate decision-making and technology in large-scale, complex business scenarios such as smart parking. However, existing rule engines for smart parking scenarios are often unsuitable for complex rules and cannot simultaneously meet the various other business needs of smart parking. Summary of the Invention

[0003] To address the technical problems in this field, the present invention proposes a rule engine system for intelligent parking scenarios, such as... Figure 1 It includes a rule management unit, a knowledge base management unit, a data receiving unit, and a rule engine unit, among which:

[0004] The rule management unit is used to convert the entered rule description information into rules and store them in the database;

[0005] The knowledge base management unit is used to generate multiple knowledge bases and update the knowledge bases.

[0006] The data receiving unit is used to receive and / or complete object model data, and generate device twin data based on the object model data;

[0007] The rule engine unit is used to search for relevant knowledge bases based on the device twin data, load rules from the knowledge base, evaluate the triggering conditions of the rules using the device twin data, and execute the execution actions of the rules.

[0008] This invention can use object model attributes, events, and service call results as triggering conditions to combine them into complex rules, effectively reducing the complexity of components that implement complex business logic, reducing the maintenance and scalability costs of IoT applications, improving decision-making flexibility, and increasing demand response speed. It is very suitable for smart parking business scenarios. Attached Figure Description

[0009] Figure 1 : Schematic diagrams of some rule engines. Detailed Implementation

[0010] First, let's explain the following terms:

[0011] Smart parking integrates wireless communication technology, mobile terminal technology, GPS positioning technology, GIS technology and other technologies to collect, manage, query, reserve and navigate urban parking spaces, realize the integration of real-time updates, queries, reservation and navigation services for parking space resources, maximize the utilization rate of parking space resources, maximize parking lot profits and optimize parking services for car owners.

[0012] A rule is a logical expression based on domain constraints, used to represent a piece of business logic in a business rule application. It includes a set of conditions and the operations to be performed under these conditions. Typically, a rule can consist of multiple triggers and multiple executions.

[0013] Knowledge base: A collection of rules.

[0014] Rule engine: A technology that separates business decisions from technical implementation. Typically, the process of a rule engine involves first inputting rules, which contain matching conditions and actions to be performed. When input data matches the rule conditions, the specified action is executed. After execution, the conditions are evaluated again, and actions are executed again, until the process ends. The data processing by a rule engine typically includes:

[0015] 1. The rule engine listens for data from the event bus and matches it with the entered rules.

[0016] 2. The rule engine triggers corresponding executions through the event bus.

[0017] The Internet of Things (IoT) refers to the use of various information sensors, radio frequency identification (RFID) technology, global positioning systems (GPS), infrared sensors, laser scanners, and other devices and technologies to collect real-time data on any object or process that needs to be monitored, connected, or interacted with. This data includes information on sound, light, heat, electricity, mechanics, chemistry, biology, location, and other relevant parameters. Through various possible network access methods, IoT enables ubiquitous connectivity between things and between things and people, achieving intelligent perception, identification, and management of objects and processes.

[0018] Item Model: Used to describe the device twin of an IoT terminal. An item model represents a characteristic of a terminal through attributes, events, and services. In the IoT, the device twin of a terminal is represented by a set of item models.

[0019] Business Concept Dictionary: A tool for abstracting and encapsulating changing concepts in business processes.

[0020] Cloud-to-cloud integration: Sending data from the first cloud platform to the second cloud platform via API or SDK.

[0021] The following embodiments further illustrate the content of the present invention, but should not be construed as limiting the present invention. Any modifications or substitutions made to the methods, steps, or conditions of the present invention without departing from the spirit and essence of the invention are within the scope of the present invention.

[0022] Some rule engine systems for smart parking scenarios include a rule management unit, a knowledge base management unit, a data receiving unit, and a rule engine unit, wherein: the rule management unit is used to convert the input rule description information into rules and store them in the database;

[0023] The knowledge base management unit is used to generate multiple knowledge bases and update the knowledge bases.

[0024] The data receiving unit is used to receive and / or complete object model data, and generate device twin data based on the object model data;

[0025] The rule engine unit is used to search for relevant knowledge bases based on the device twin data, load rules from the knowledge base, evaluate the triggering conditions of the rules using the device twin data, and execute the execution actions of the rules.

[0026] In some implementations, the rule management unit converts the entered rule description information into the rules, specifically including: converting the rule description information into the terminal scope, triggering conditions, and execution actions of the rules through the matching relationship of the business concept dictionary; automatically setting priorities; (converting the rule description information into multiple rules, sorting the rules, with the priority of the first rule being 0 and the priority of other rules being set to -10); and converting the relevant terminal scope, triggering conditions (triggers), execution actions, and priorities into rules. The triggering conditions (triggers) consist of the following concepts:

[0027] 1. Types: Manual trigger, device trigger, timed trigger

[0028] 2. Equipment Scope: Determined by product model identifier (single choice), equipment identifier (multiple choice), and equipment path identifier (multiple choice).

[0029] 3. Filter: The device can only trigger the next step of execution when certain filtering conditions are met.

[0030] The execution action is broken down into details: device output will include information such as the device range and the called object model capabilities (setting attributes, calling services).

[0031] The cloud-to-cloud interface output includes cloud-to-cloud interface instance information.

[0032] Alarm outputs include alarm configurations, and if notifications are included, notification channels / templates / personnel will also be provided.

[0033] The data flow output includes the flow address and configuration.

[0034] The rule configuration data is relatively flexible. It is preferable to use JSON format to store the rule configuration, which includes the following basic fields: information describing the use case and precautions of the rule, information describing the trigger types contained in the rule, a list of triggers, and an executor description field.

[0035] The trigger has the following fields: trigger type (supported values: manual trigger, device trigger, timed trigger), timed expression, the range of devices associated with the trigger, filter list, and duration threshold (in seconds). The trigger will only be activated when the duration meets the threshold. The trigger device range is determined by an array of model / device IDs / device path IDs, with specific fields including: product model identifier, device identifier list, and device path identifier list. A trigger can support multiple filters, which work in a logical AND combination. A single filter has the following fields: filter type (supported values: attribute, event), keywords used to filter compared values ​​(e.g., "attribute identifier"), comparison operators, and comparison values. A single executor has the following fields: executor type (supported values: c2c (cloud-to-cloud integration), alarm (notification and alert), device (device output), flow (data flow); and executor configuration (different executor types have different configuration parameters). The notification and alert configuration has the following fields: alarm configuration; and a list of notification channel configurations. A single notification channel configuration has the following fields: notification channel, list of notification personnel; a cloud-to-cloud integration configuration has the following field: list of cloud-to-cloud integration instances; a device output configuration has the following fields: product model identifier, device identifier list, device path identifier list, device output operation, and supports the following values: setting attribute, calling service, operation identifier (i.e., "attribute identifier" or "service identifier"), and operation data (i.e., "attribute data" or "service call input data"); and data flow configuration fields include: data flow destination and data flow configuration.

[0036] In other implementations, the business concept dictionary is configured according to the following matching relationship:

[0037] Match the fields in the rule description information, including parking lot set, lane set, terminal set, and terminal type, to define the terminal range of the rule;

[0038] Match the comparison set fields in the rule description information, including object model attributes, events, and services, as the triggering conditions for the rule;

[0039] Match the fields in the rule description information, including device linkage, cloud-to-cloud integration, data flow, and alarm set, to determine the execution action of the rule.

[0040] A type of business concept dictionary data:

[0041]

[0042]

[0043] In some implementations, the knowledge base management unit is configured to perform the following steps: reading rules from the database, constructing the knowledge base in batches according to the terminal scope of the rules, and reading changed rules from the database and refreshing the knowledge base related to the changed rules. In a preferred implementation, the knowledge base management unit is configured to refresh one or more knowledge bases related to the changed rules in real time.

[0044] In one specific implementation, the rule management unit performs the following steps:

[0045] 1. Convert the grouping identifiers in the parking lot set and lane set into terminal range representations.

[0046] 2. Convert the device IDs in the terminal set into a terminal range representation.

[0047] 3. Convert the device model ID of the terminal type into a terminal range representation.

[0048] 4. Transform the comparison logic of individual object models into a single condition.

[0049] 5. The set of conditions for comparing multiple object models is converted into a JSON array representing the triggering conditions.

[0050] 6. Convert the device ID to be linked and the object model identifier of the linked action (such as the gate lifting action) into the execution action.

[0051] 7. Convert the cloud platform identifier into an action to be executed.

[0052] 8. Convert the external service configuration for data flow into execution actions.

[0053] 9. Convert alarm templates and alarm channel configurations into actionable actions.

[0054] 10. Convert the terminal scope, triggering conditions, execution actions, and rule priorities into JSON representations of the rules.

[0055] 11. Save the rules to the MySQL database.

[0056] In some implementations, the data receiving unit is configured to perform the following steps: receiving terminal data from terminal equipment in the parking lot; converting the terminal data into object model data; obtaining the corresponding object model definition and data conversion method through the device identifier of the terminal data; converting the terminal data into object model data conforming to the object model definition using the data conversion method; and adding the object model data to the object model data set to generate device twin data. Using the data receiving unit to uniformly complete the device data facilitates the construction of more complex processing rules.

[0057] In other implementations, the rule engine unit is configured to perform the following steps:

[0058] S1 reads device twin data;

[0059] S2 searches the corresponding knowledge base based on the device twin data;

[0060] S3 extracts rules based on the triggering conditions of all rules in the knowledge base and adds the extracted rules that meet the triggering conditions to the matching rule set;

[0061] S4 executes the action of the highest priority rule in the matching rule set;

[0062] Repeat steps S3-S4 until the set of matching rules is empty, or until the number of repetitions reaches the threshold.

[0063] In some implementations, the S4 steps executed by the rule engine unit specifically include: executing the device linkage step, executing the cloud-to-cloud connection step, executing the data flow step, and executing the device alarm step;

[0064] The specific steps of device linkage include: finding the range of terminals affected by the execution action of the rule, and issuing device linkage instructions to all terminal devices included in the range of terminals;

[0065] The cloud-to-cloud connection steps specifically include: finding the cloud instance identifier in the rule description information, finding the third-party cloud platform connection method according to the cloud instance identifier, establishing a first connection path with the third-party cloud platform according to the connection method, and sending the device twin data according to the first connection path; it should be noted that the third-party cloud platform refers to a general IoT cloud platform developed or maintained by other companies, or a parking IoT cloud platform.

[0066] The data transfer steps specifically include: finding the transfer identifier and transfer configuration in the rule description information, obtaining the data conversion method and connection method according to the transfer configuration, converting the device twin data into data to be transferred according to the data conversion method, establishing a second connection path pointing to the transfer destination according to the connection method, and sending the data to be transferred according to the second connection path;

[0067] The device alarm process includes: reading the alarm display template and alarm channel configuration from the rule description information, filling the alarm display template with device twin data, generating alarm data, establishing a third connection path to the alarm channel service using the alarm channel configuration, and sending the alarm data through the third connection path.

[0068] In most implementations, the database used to store multiple knowledge bases is implemented based on MySQL, and the rule description information is described using a domain-specific language (DSL).

[0069] The rule description information described by the domain-specific language DSL simplifies the construction of rules, simplifies the writing of rules by using multiple knowledge bases, refines the application scenarios of rules, reduces conflicts between rules, reduces the complexity of the system, and improves the flexibility of rule construction.

[0070] Although the present invention has been described in detail above with general descriptions, specific embodiments, and experiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A rule engine system for intelligent parking scenarios, characterized in that, The rule engine system includes a rule management unit, a knowledge base management unit, a data receiving unit, and a rule engine unit, wherein: The rule management unit is used to convert the entered rule description information into rules and store them in the database; The knowledge base management unit is used to generate multiple knowledge bases and update the knowledge bases. The data receiving unit is used to receive and / or complete object model data, and generate device twin data based on the object model data; The rule engine unit is used to search for relevant knowledge bases based on the device twin data, load rules in the knowledge base, evaluate the triggering conditions of the rules using the device twin data, and execute the execution actions of the rules. The data receiving unit performs the following steps: Receive terminal data from the terminal equipment in the parking lot; The corresponding object model definition and data conversion method are obtained through the device identifier of the terminal data; The data conversion method described above is used to convert the terminal data into object model data that conforms to the object model definition. The object model data is added to the object model data set to generate device twin data; The rule engine unit performs the following steps: S1 reads the device twin data; S2 searches the corresponding knowledge base based on the device twin data; S3 extracts all rules in the knowledge base that meet the triggering conditions and adds them to the matching rule set; S4 Execute the action of the highest priority rule in the set of matching rules; Repeat steps S3-S4 until the set of matching rules is empty, or until the number of repetitions reaches a threshold.

2. The rule engine system as described in claim 1, characterized in that, The specific steps by which the rule management unit converts the entered rule description information into the rule include: The rule description information is converted into the terminal scope, triggering conditions, and execution actions of the rule by matching the business concept dictionary. Automatically set priority; The relevant terminal range, triggering conditions, execution actions, and priorities are converted into the rules.

3. The rule engine system as described in claim 2, characterized in that, The business concept dictionary is configured as follows: Match the parking lot set, lane set, terminal set, and terminal type fields to the terminal range of the rule; Match the comparison set fields of the object model attributes, events, and services as the triggering conditions for the rule; The rules define the execution actions based on matching fields such as device linkage, cloud-to-cloud integration, data flow, and alarm set.

4. The rule engine system as described in claim 2, characterized in that, The knowledge base management unit is configured to perform the following steps: Rules are read from the database, the knowledge base is constructed in batches according to the terminal scope of the rules, and the changed rules are read from the database and the knowledge base related to the changed rules is refreshed.

5. The rule engine system as described in claim 1, characterized in that, The S4 step specifically includes: executing the device linkage step, executing the cloud-to-cloud docking step, executing the data transfer step, and executing the device alarm step; The device linkage step specifically includes: finding the range of terminals affected by the execution action of the rule, and issuing a device linkage instruction to all terminal devices included in the range of terminals; The cloud-to-cloud connection steps specifically include: finding the cloud instance identifier in the rule description information, finding the connection method of the third-party cloud platform according to the cloud instance identifier, establishing a first connection path with the third-party cloud platform according to the connection method, and sending the device twin data according to the first connection path; The data transfer steps specifically include: searching for the transfer identifier and transfer configuration in the rule description information; obtaining the data conversion method and connection method according to the transfer configuration; converting the device twin data into data to be transferred according to the data conversion method; establishing a second connection path pointing to the transfer destination according to the connection method; and sending the data to be transferred according to the second connection path. The device alarm steps include: reading the alarm display template and alarm channel configuration from the rule description information, filling the alarm display template with the device twin data, generating alarm data, establishing a third connection path pointing to the alarm channel service using the alarm channel configuration, and sending the alarm data through the third connection path.

6. The rule engine system as described in any one of claims 1-5, characterized in that, The database includes, but is not limited to, a MySQL database, and the database includes multiple knowledge bases.

7. The rule engine system as described in any one of claims 1-6, characterized in that, The rule description information is described using a domain-specific language (DSL).

8. The rule engine system as described in claim 4, characterized in that, The knowledge base management unit refreshes one or more knowledge bases related to the changed rules in real time.

Images