A method and system for parsing, data forwarding and device linkage control of an internet of things platform rule engine

Abstract

The application discloses a kind of Internet of Things platform rule engine analysis, data forwarding and device linkage control method and system.The method receives the original equipment message reported by Internet of Things equipment, carries out analysis and standardization processing;Determine the version of the object model corresponding to the standardized equipment event, analysis template version, rule set version and action definition version, carry out compatible check to each version, and combine each version, version dependency and rule matching network into immutable processing snapshot;Respectively generate source event idempotent key, processing instance key and semantic action idempotent key to distinguish source event, rule processing process and action execution effect;With semantic action idempotent key as the only constraint atom writing in action execution record, and execute lease and monotonic increasing execution token are distributed to action execution node.The application can improve the consistency of rule version, reduce repeated processing and repeated control, and improve the reliability of Internet of Things equipment linkage.

Description

Technical Field

[0001] This invention relates to the field of data processing technology for Internet of Things (IoT) platforms, and in particular to a method and system for IoT platform rule engine parsing, data forwarding, and device linkage control. Background Technology

[0002] With the development of IoT technology, a large number of sensors, controllers, gateways, and smart terminals are connected to IoT platforms, continuously reporting data such as device attributes, device status, device events, and service call results to the platforms. IoT platforms typically use rule engines to parse device messages, perform condition matching, data forwarding, alarm generation, and device linkage control, thereby decoupling device data from upper-layer business applications.

[0003] Existing IoT devices use different communication protocols, data formats, field definitions, and units of measurement, requiring rule engines to configure separate parsing logic for different devices or products. When device protocols, object models, or parsing templates are updated, incompatibility between device messages and parsing versions can easily occur. Furthermore, factors such as device clock drift, network fluctuations, offline retransmission, and gateway forwarding latency can cause device messages to be out of order, late, duplicated, or have missing sequences. Processing them directly according to the platform's received order may lead to incorrect device status calculations, further triggering incorrect data forwarding or device control actions. Additionally, when rule execution nodes load different versions at different times, they may combine versions with different validity periods or incompatible relationships, resulting in inconsistent processing logic for the same device event during parsing, rule matching, and action execution. This is especially problematic during hot rule updates or historical message retransmissions, leading to issues such as mismatched fields, incompatible action parameters, or repeated execution of the same event under different rule versions. Existing solutions typically perform simple deduplication based on message identifiers, but this struggles to simultaneously distinguish the processing of the same source event under different rule snapshots and the semantically equivalent actions generated by different rules. This can lead to the duplicate creation and execution of device control commands, alarm notifications, or data forwarding tasks. In a distributed rule execution environment, multiple action execution nodes may concurrently acquire the same action to be executed. When the original execution node times out and another node takes over the task, the original execution node may continue to send control commands after resuming operation. Furthermore, the lack of a response after an action is sent does not necessarily mean that the action has not been executed; if the platform directly retryes, it can easily result in the device being controlled repeatedly. Summary of the Invention

[0004] The present invention aims to solve existing problems by providing a method and system for IoT platform rule engine parsing, data forwarding, and device linkage control.

[0005] To address the aforementioned technical problems, this invention provides a method for IoT platform rule engine parsing, data forwarding, and device linkage control, comprising: S1. Receive raw device messages reported by IoT devices, parse and standardize the raw device messages, generate standardized device events, and perform partitioning, caching, and timing processing according to device identifiers; S2. When outputting the standardized device event, obtain the corresponding object model version, parsing template version, rule set version, and action definition version; when the output field set of the parsing template covers the input field set of the rule set, and the action parameters generated by the rule set conform to the parameter signature of the action definition, combine the versions, version dependencies, and rule matching network into an immutable processing snapshot and generate a snapshot identifier, and use the rule matching network to match the standardized device event to obtain the matching rule identifier and the action to be executed; S3. Generate a source event idempotent key that does not contain the snapshot identifier based on the device identifier, device startup cycle identifier, message unique identifier and message payload digest; generate a processing instance key based on the source event idempotent key, snapshot identifier and matching rule identifier; and generate a semantic action idempotent key that does not contain the snapshot identifier based on the source event idempotent key, action target, action type and normalized action parameters. S4. Using the semantic action idempotent key as a unique constraint, atomically write an action execution record containing the processing instance key, snapshot identifier, action to be executed, and action execution status, and allocate an execution lease with a valid time limit and a monotonically increasing execution token to the action execution node that successfully occupies the action execution record. S5. The action execution node executes the action to be executed based on the semantic action idempotent key and the execution token, and performs acknowledgment and abnormal retry control according to the action execution result.

[0006] Specifically, S1 includes: Identify the protocol type of the original device message, call the corresponding parsing template, and convert the original device message into a standardized device event; Based on the device event time, platform reception time, and historical time deviation of the corresponding device in the standardized device event, a correction event time is generated, and the standardized device event is partitioned and cached using device identifier and device startup cycle identifier.

[0007] Specifically, S1 further includes: The timing output boundary is determined based on the historical message arrival delay and message sequence continuity of the corresponding device. The standardized device event is output according to the corrected event time and message sequence information. Standardized device events that exceed the timing output boundary or whose message sequences are repeated, rolled back, or have gaps are isolated.

[0008] Specifically, S2 includes: Based on the product identifier, device identifier, and event time corresponding to the standardized device event, a candidate version group consisting of the object model version, parsing template version, rule set version, and action definition version is determined from the version dependency index. Extract event field signatures, parse template output field signatures, rule set input field signatures, and action parameter signatures of action definitions. Determine whether the event field signature matches the output field signature, whether the output field signature covers the input field signature, and whether the action parameters generated by the rule set match the action parameter signature.

[0009] Specifically, S2 further includes: When the compatibility check passes, the rule set version is compiled into a rule matching network containing condition nodes, shared matching nodes, and action nodes; The candidate version group, version dependency relationship, field mapping relationship, rule matching network and action parameter structure are serialized in a preset order. The serialization result is digested to generate a snapshot identifier, forming an immutable processing snapshot. The snapshot identifier is then atomically associated with the standardized device event.

[0010] Specifically, S3 includes: The device identifier, device startup cycle identifier, message unique identifier, and message payload in the standardized device event are sorted by field and data type unified to generate a payload summary. The source event idempotent key is generated based on the device identifier, device startup cycle identifier, message unique identifier, and payload summary. A processing instance key is generated based on the source event idempotent key, snapshot identifier, matching rule identifier, and rule matching branch identifier. The rule matching branch identifier is generated based on the sequence of condition nodes traversed by the standardized device event.

[0011] Specifically, S3 also includes: The action target, action type and action parameters to be executed are sorted by field, data types are standardized, units of measurement are converted and numerical precision is normalized. The semantic action idempotency key is generated based on the source event idempotency key, the normalized action target, the action type, the action parameter summary, and the action valid range, so that actions to be executed with the same above items have the same semantic action idempotency key; when the semantic action idempotency keys are the same but the data lengths of the normalized action parameters are different, the complete normalized action parameters are compared to determine whether the actions to be executed are the same.

[0012] Specifically, S4 includes: The semantic action idempotent key is used as the unique index for the action execution record; when no corresponding action execution record exists, an action execution record containing the processing instance key, snapshot identifier, action to be executed, action parameter summary, action execution status, and status version number is written through an atomic transaction; when a corresponding action execution record already exists, the current processing instance key is associated with the existing action execution record. When the action execution status is pending execution or the original execution lease expires, the action execution node updates the action execution status, node identifier, lease expiration time and status version number with the current status version number as the comparison condition to obtain the execution lease, and generates an incremental execution token bound to the action execution node according to the number of lease allocations.

[0013] Specifically, S5 includes: After the node identifier, execution lease and execution token are verified, the action execution node sends the semantic action idempotent key, execution token and action parameter digest along with the action to be executed to the target end, which is a device gateway, message queue consumer or Hypertext Transfer Protocol server. When the target terminal does not have a corresponding historical execution record and the execution token is not less than the maximum execution token of its idempotent key record for the semantic action, it executes the action to be executed and returns an action execution receipt containing a summary of actual execution parameters, target state version and execution result. If no action execution receipt is received, the action execution status is marked as execution result unknown, and the execution result is verified according to the target's historical execution record or target status version. If it is confirmed that the action has not been executed, it is resent using the same semantic action idempotent key. If it is confirmed that the action has been executed, an action execution receipt is added, and action execution requests with a smaller execution token than the current execution token in the action execution record are rejected.

[0014] On the other hand, the present invention also provides a system applied to the above-described IoT platform rule engine parsing, data forwarding, and device linkage control method, comprising: The message processing module is used to receive raw device messages reported by IoT devices, parse and standardize the raw device messages, generate standardized device events, and perform partitioning, caching, and timing processing according to device identifiers; The snapshot and rule matching module is used to obtain the object model version, parsing template version, rule set version, and action definition version. When the output field set of the parsing template covers the input field set of the rule set and the action parameters generated by the rule set match the parameter signature of the action definition, an immutable processing snapshot and snapshot identifier containing the versions, version dependencies, and rule matching network are generated. The module then performs rule matching on the standardized device events to obtain the matching rule identifier and the action to be executed. An idempotent key generation module is used to generate a source event idempotent key that does not contain the snapshot identifier, generate a processing instance key based on the source event idempotent key, the snapshot identifier, and the matching rule identifier, and generate a semantic action idempotent key that does not contain the snapshot identifier based on the source event idempotent key and the normalized action to be executed. The action scheduling module is used to atomically write the action execution record with the semantic action idempotent key as a unique constraint, and to allocate an execution lease and an incrementing execution token to the action execution node that successfully occupies the action execution record; The action execution module is used to execute the action to be executed after the execution lease and execution token verification are passed, confirm the execution result according to the action execution receipt returned by the target end, and re-execute the action to be executed using the same semantic action idempotent key when it is confirmed that the action to be executed has not been executed.

[0015] Compared with the prior art, the present invention has at least the following beneficial effects: This invention reduces the impact of device clock deviation, message out-of-order delivery, and offline retransmission on rule judgment results by parsing, standardizing, partitioning, caching, and isolating abnormal timing of device messages. By performing compatibility checks on the object model version, parsing template version, rule set version, and action definition version, and combining them with the rule matching network into an immutable processing snapshot, the standardized device events adopt consistent and traceable processing logic in the parsing, matching, and action generation processes. By setting idempotent keys for source events, processing instances, and semantic actions, the system can retain cross-snapshot processing records for the same source event while merging semantically equivalent actions generated by different rule snapshots, reducing redundant data forwarding and device control. Through unique constraints on action execution records, atomic writes, execution leases, and monotonically increasing execution tokens, the system can prevent multiple action execution nodes from concurrently executing the same action and prevent failed nodes from continuing execution after recovery. By using target-side execution receipts, target status verification, and retrying exceptions using the same semantic action idempotent key, the system can distinguish between action execution failures and unknown execution results, thereby reducing the risk of duplicate executions caused by communication timeouts and improving the data processing consistency, device linkage reliability, and distributed execution fault tolerance of the IoT rule engine. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the method for parsing, forwarding data, and controlling device linkage in an IoT platform according to the present invention.

[0017] Figure 2 This is a schematic diagram of the device message scenario matching logic in this invention.

[0018] Figure 3 This is a schematic diagram of the snapshot storage structure in this invention. Detailed Implementation

[0019] The present invention will be further described below with reference to specific embodiments. It should be understood that the following embodiments are used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention.

[0020] like Figures 1-3 As shown, in one possible implementation, the IoT platform rule engine parsing, data forwarding, and device linkage control method includes the following steps: S1. Receive raw device messages reported by IoT devices, parse and standardize the raw device messages, generate standardized device events, and perform partitioning, caching, and timing processing according to device identifiers; S2. When outputting the standardized device event, obtain the corresponding object model version, parsing template version, rule set version, and action definition version; when the output field set of the parsing template covers the input field set of the rule set, and the action parameters generated by the rule set conform to the parameter signature of the action definition, combine the versions, version dependencies, and rule matching network into an immutable processing snapshot and generate a snapshot identifier, and use the rule matching network to match the standardized device event to obtain the matching rule identifier and the action to be executed; S3. Generate a source event idempotent key that does not contain the snapshot identifier based on the device identifier, device startup cycle identifier, message unique identifier and message payload digest; generate a processing instance key based on the source event idempotent key, snapshot identifier and matching rule identifier; and generate a semantic action idempotent key that does not contain the snapshot identifier based on the source event idempotent key, action target, action type and normalized action parameters. S4. Using the semantic action idempotent key as a unique constraint, atomically write an action execution record containing the processing instance key, snapshot identifier, action to be executed, and action execution status, and allocate an execution lease with a valid time limit and a monotonically increasing execution token to the action execution node that successfully occupies the action execution record. S5. The action execution node executes the action to be executed based on the semantic action idempotent key and the execution token, and performs acknowledgment and abnormal retry control according to the action execution result.

[0021] In this embodiment, the IoT platform sequentially completes the following steps: receiving original device messages, parsing messages, standardizing events, sorting messages from the same device, determining processing snapshots, matching rules, generating idempotent identifiers, occupying action records, and confirming action execution results. Each stage retains the device identifier, the device startup cycle identifier, and the unique message identifier, ensuring a one-to-one correspondence between device-reported data, rule processing results, and action execution records.

[0022] After an IoT device completes its registration on the platform, the platform assigns it a unique device identifier and saves the device's product, device type, communication protocol, and current object model version. A new device startup cycle identifier is generated each time the device restarts. This identifier is formed by deterministically encoding the startup time, the device's internal startup count, and the device identifier. Even if the device reports data starting from the initial message sequence number after a restart, the platform can still distinguish messages generated within two consecutive operating cycles based on the different device startup cycle identifiers.

[0023] The raw device messages reported by the device include a protocol header and a message payload. The protocol header contains the device identifier, device startup cycle identifier, message unique identifier, message type, message sequence number, device time, and payload length. The message payload contains device attribute data, device event data, or device service execution results. The message unique identifier is generated by the device in the order of message generation within the current startup cycle, and any two raw device messages within the same startup cycle have different message unique identifiers.

[0024] After receiving the original device message, the IoT platform first verifies whether the actual received payload length matches the payload length recorded in the protocol header, and then recalculates the message checksum according to the protocol. If the actual payload length is inconsistent or the recalculated checksum is inconsistent with the checksum carried in the message, the platform records the message in the abnormal message table and terminates the subsequent processing of the message. Messages that pass the integrity check enter the parsing process. The parsing template used for parsing is determined based on the device's product, communication protocol, message type, and template effective time. The platform uses the original device message reception time as a benchmark and selects the parsing template with the largest version number and effective time no later than the reception time from the parsing templates for the corresponding product and message type. The parsing template records the location, field length, data type, byte order, scaling factor, offset value, original unit of measurement, target unit of measurement, and standard field name of each original field.

[0025] When the raw device message is in binary format, the parsing node extracts consecutive bytes from the message payload according to the starting byte position and field length recorded in the parsing template. Then, based on the high-order byte-first or low-order byte-first arrangement specified in the template, the extracted bytes are converted into integers or floating-point numbers. When the raw device message is in structured text format, the parsing node reads the corresponding fields according to the field hierarchy path recorded in the template and converts the reading results into the data type specified by the object model.

[0026] Specifically, when a raw field value needs to be proportionally converted, the parsing node first multiplies the raw field value by the proportionality coefficient recorded in the parsing template, and then adds the offset value recorded in the template. For example, if a temperature sensor reports an integer of 253, the proportionality coefficient is 0.1, and the offset value is 0, the converted temperature value is 25.3. If the raw unit of measurement is inconsistent with the unit of measurement specified in the object model, it is converted according to the unit conversion relationship fixed in the parsing template. The unit conversion relationship is verified before the parsing template is published, and conversion is only allowed between the same physical quantities. Enumerated fields are converted according to the enumeration mapping table in the parsing template. After reading the raw enumeration value, the parsing node queries the corresponding standard enumeration value in the enumeration mapping table. If no corresponding relationship is found, the field is marked as an illegal enumeration field, and the error location, raw enumeration value, and parsing template version are written to the field exception record. Boolean fields only accept the two raw values ​​explicitly specified in the parsing template, which are converted to Boolean true and Boolean false values ​​respectively; other raw values ​​are treated as illegal fields.

[0027] After field parsing is complete, the parsing node performs range verification based on the field constraints in the object model. Each numerical field records its allowed minimum and maximum values ​​in the object model. These minimum and maximum values ​​are derived from the sensor's rated range, the allowable range of the equipment control interface, or manufacturing process limitations, and are fixed when the object model version is released. Parsed field values ​​between the minimum and maximum values ​​pass verification; values ​​below the minimum or above the maximum are marked as out of bounds. Out-of-bounds fields, along with their original values, converted values, and corresponding object model versions, are written into the event context for subsequent rule judgments.

[0028] After data type conversion, ratio conversion, unit standardization, enumeration mapping, and range verification, the platform generates standardized equipment events. Standardized equipment events include equipment identifier, equipment start-up cycle identifier, message unique identifier, product identifier, event type, equipment time, platform reception time, message sequence number, standard field set, and message payload digest.

[0029] The message payload digest is generated based on the deterministic processing results. For structured text messages, the platform first sorts the field names in ascending order according to their unified character encoding values, standardizes the representation of integers, decimals, time, and Boolean values, removes spaces, newlines, and indentation characters that do not affect the meaning of the data, and then concatenates all processed fields into consecutive bytes. For binary messages, the original payload bytes are used directly. The platform performs a secure hash operation on the resulting bytes, outputting a 256-bit length, to generate the message payload digest. The same message payload will produce the same digest after undergoing the same processing; the probability of different message payloads producing the same digest is lower than the platform's data integrity requirements.

[0030] After a standardized device event is generated, the platform determines the message partition based on the device identifier. The platform first performs a secure hash on the device identifier, then converts the hash result into a non-negative integer, and uses the remainder of this non-negative integer divided by the total number of partitions as the target partition number. Since the hash result for the same device identifier is fixed, standardized device events generated by the same device will always enter the same partition.

[0031] The total number of partitions is determined based on the platform's actual message volume. The platform continuously collects the number of messages received per second over seven consecutive days, arranging all sampled values ​​from smallest to largest. The number of messages covering 99.9% of the sampled values ​​is selected as the peak message arrival rate. Subsequently, the stable processing rate of a single partition is measured under the condition that the processing latency of a single partition does not exceed 100 milliseconds. The number of partitions is determined according to the principle that the peak message arrival rate does not exceed 70% of the stable processing capacity of all partitions, with the remaining 30% of the processing capacity used to absorb centralized reporting from devices, node migration, and short-term traffic increases. The calculated number of partitions is adjusted upwards to an integer power of 2 and written into the current partition configuration version.

[0032] Standardized device events entering the same partition are sorted sequentially by device startup cycle identifier, message sequence number, device time, and platform reception time. Events with different device startup cycle identifiers are arranged according to their corresponding startup times; events with the same device startup cycle identifier are arranged according to their message sequence number from smallest to largest; if the message sequence numbers are the same, they are arranged according to their device times; if the device times are still the same, they are arranged according to their platform reception times.

[0033] When network jitter causes a later-sent message to arrive at the platform first, the partition processing node caches standardized device events for a predetermined out-of-order waiting time. This waiting time is updated daily. During the update, the platform calculates the difference between the platform's reception time and the device's time for device messages within the previous 7 days, removes messages whose device clocks have not been calibrated, and then sorts the remaining transmission delays from smallest to largest, taking the delay covering 99.9% of the messages. The platform also reads the maximum clock error recorded by the device clock calibration module, adds the transmission delay, the maximum clock error, and a 200-millisecond platform queuing margin, and uses the result as the out-of-order waiting time for the next day. A result less than 500 milliseconds is used, and a result greater than 30,000 milliseconds is used.

[0034] The partition processing node continuously records the maximum device time received. This maximum device time is subtracted from the out-of-order waiting time, and the resulting time is used as the current event output limit. Events with device times no later than this output limit are output according to the sorting result; events with times later than this output limit remain in the partition buffer. Messages arriving after the event output limit has been crossed are marked as late events, and the actual delay time is recorded. Late events are not directly discarded but still enter the rule matching process, allowing the rule set to determine whether to perform compensation processing based on the lateness identifier.

[0035] When standardized device events are output from the partition cache, the platform retrieves the object model version, parsing template version, rule set version, and action definition version based on the product identifier, event type, and event time. Each version has a unique version identifier, effective time, and expiration time. A version is valid for the current event if its event time is no earlier than the version's effective time but earlier than its expiration time. If no version expiration time is set, the version remains valid until a new version becomes effective.

[0036] The object model version records the data type, unit of measurement, and value range of standard fields; the parsing template version records the processing method for converting raw fields into standard fields; the rule set version records the rule conditions, priority, validity period, and rule actions; and the action definition version records the action type, action target type, parameter name, parameter type, required relationships, and parameter range.

[0037] After determining the above version, the platform first verifies whether the fields output by the parsing template meet the field requirements of the rule set. The platform then summarizes all standard fields directly output by the parsing template and adds derived fields obtained by converting these standard fields through fixed arithmetic, fixed time, or fixed unit conversions, forming a complete set of output fields. Subsequently, it extracts all fields actually referenced by conditions in the rule set and queries them one by one in the complete set of output fields. If all rule input fields can be found, a field coverage check is performed; if any field cannot be found, the release or loading of that version combination is terminated, and the missing field name, rule identifier, and parsing template version are recorded.

[0038] The calculation process for derived fields is fixed when the rule set is published. Taking the duration field as an example, the platform subtracts the state start time from the current event time, and the resulting number of milliseconds is taken as the duration. Taking the average field as an example, the platform adds up the valid values ​​within the specified time window and then divides by the number of valid values. The calculation of derived fields does not call the real-time interface outside of snapshot processing to prevent the same event from obtaining different results when processed at different times.

[0039] After completing field coverage validation, the platform verifies whether the rule action parameters conform to the action definition. The platform first reads all required parameters from the action definition, and then verifies whether the rule action outputs the corresponding parameters one by one. If any required parameter is missing, parameter validation fails. If all required parameters are complete, the platform continues to verify the parameter name, data type, parameter level, and value range. Numerical parameters must not be lower than the minimum allowed value in the action definition, nor higher than the maximum allowed value; enumerated parameters must exist in the enumeration set of the action definition; the string length must not exceed the maximum number of characters in the action definition; time parameters are uniformly converted to millisecond-level standard time before range judgment.

[0040] Once the parsed template output fields cover the rule input fields, and all action parameters conform to the action definition, the platform generates an immutable processing snapshot. The platform arranges version identifiers in a fixed order: object model version, parsed template version, rule set version, and action definition version. It then arranges version dependencies according to the identifiers of dependents and dependents, and arranges the rule matching network according to the rule node number. The platform converts the above content into consecutive bytes and performs a secure hash operation with an output length of 256 bits. The resulting hash value serves as the snapshot identifier.

[0041] Immutable snapshots are written to the snapshot storage area using a snapshot identifier as the unique storage key. If the same snapshot identifier already exists, the existing content is not overwritten. Whenever there are any changes to the object model, parsing template, rule set, or action definition, a new version and a new snapshot identifier are generated. Existing snapshots are not modified, thus ensuring that the same snapshot identifier always corresponds to the same field structure, parsing relationships, rule conditions, and action parameter constraints.

[0042] When a rule set is published, it is converted into a rule matching network. Field reading, data type conversion, numerical comparison, status judgment, and logical relationships within a rule form processing nodes. When multiple rules read the same field or perform the same precondition judgment, they share the corresponding processing node. After a standardized device event enters the rule matching network, the platform retrieves the field value, performs type conversion, completes condition comparison, and merges the judgment results according to the node connection relationship.

[0043] When rule conditions involve numerical thresholds, the thresholds are determined and written into the rule set version before the rule set is published. Equipment safety upper limits, equipment safety lower limits, and process control boundaries directly use the values ​​recorded in the equipment technical documents or process documents. Anomaly thresholds based on historical data are calculated using a fixed sample range. The platform extracts no less than 10,000 valid samples from the past 30 days, arranges the sample values ​​in ascending order, and obtains the median value. Then, it calculates the absolute difference between each sample value and the median, arranges all absolute differences in ascending order, and obtains the median value. This median absolute difference is then multiplied by 1.4826, then by 3, and finally added to the sample median. The result is used as the anomaly upper limit threshold. The anomaly lower limit threshold is determined by subtracting the above result from the sample median.

[0044] The calculated thresholds must be compared with the field ranges specified in the object model. If the upper limit of the anomaly threshold is higher than the maximum permissible value of the field, the maximum permissible value is used; if the lower limit of the anomaly threshold is lower than the minimum permissible value of the field, the minimum permissible value is used. Thresholds are released with the rule set version and remain unchanged during the validity period of that rule set version. Event processing nodes directly read the thresholds from the snapshot and do not recalculate them for each event.

[0045] When a standardized device event meets all the conditions of a rule, the rule matching network outputs the matching rule identifier and the action to be executed. If not all conditions are met, no action corresponding to that rule is output. When multiple rules match the same event, they are arranged in ascending order of rule priority value; if the priorities are the same, they are arranged in ascending order of rule identifier. If a rule has a stop propagation flag set and the rule matches successfully, rules following this rule and belonging to the same mutually exclusive group will no longer output actions.

[0046] After completing rule matching, the platform generates the source event idempotency key, processing instance key, and semantic action idempotency key, respectively. The field length in bytes is written for each field involved in the calculation before the content is written, to prevent different field combinations from resulting in the same concatenation result.

[0047] The source event idempotency key is obtained by concatenating the device identifier, device startup cycle identifier, message unique identifier, and message payload digest in a fixed order and then performing secure hashing. The calculation of the source event idempotency key does not include the snapshot identifier. When the same original device message is reprocessed using different snapshots, the above four items remain unchanged; therefore, the source event idempotency key remains the same.

[0048] The processing instance key is obtained by concatenating the source event idempotency key, snapshot identifier, and matching rule identifier in a fixed order and then performing secure hashing. When the same source event is processed under different snapshots, different processing instance keys are formed due to the different snapshot identifiers. Similarly, when the same source event matches different rules in the same snapshot, different processing instance keys are formed due to the different matching rule identifiers. Before generating the semantic action idempotency key, the platform normalizes the action target, action type, and action parameters. The action target is encoded in the order of tenant identifier, target category, and target unique identifier. The action type uses the fixed type number recorded in the action definition version. The action parameters are sorted in ascending order according to the unified character encoding value of the parameter name.

[0049] Integer parameters are uniformly converted to decimal representation without leading zeros; decimal parameters are rounded to the number of decimal places specified in the action definition and trailing zeros are removed; Boolean parameters are uniformly converted to the numerical value 0 or 1; time parameters are uniformly converted to Coordinated Universal Time (UTC) in milliseconds; strings uniformly use the same character encoding; object parameters are sorted hierarchically according to field names; array parameters maintain the element order specified in the action definition. When the action definition specifies an array as an unordered set, the platform first normalizes each array element separately, and then arranges them in ascending order according to the normalization results.

[0050] The platform concatenates the source event idempotency key, the normalized action target, the action type, and the normalized action parameters in a fixed order, and then performs secure hashing to generate a semantic action idempotency key. The semantic action idempotency key calculation does not include snapshot identifiers or matching rule identifiers. Therefore, when the same source event generates the same action target, action type, and action parameters under different rule versions, the resulting semantic action idempotency key remains consistent.

[0051] The action record storage area establishes uniqueness constraints using semantic action idempotent keys. Within the same database transaction, the platform writes the processing instance key, snapshot identifier, matching rule identifier, action to be executed, action status, execution count, execution node identifier, execution token, and lease expiration time. If no identical semantic action idempotent key exists in the storage area, a new action execution record with the status "pending execution" is added; if an identical semantic action idempotent key already exists in the storage area, the uniqueness constraint refuses to write again, and the existing action execution record is returned. Therefore, only one valid action execution record is created for the same semantic action.

[0052] Before an action execution node obtains an action execution record, it initiates a condition update to the action record storage area. Condition updates are only permitted when the action execution record is in a pending execution state, a retry state, or when the original execution lease has expired. Upon successful update, the action execution count is incremented by 1, the execution token is incremented by 1, the action status is changed to "in execution," and the action execution node identifier and the new lease expiration time are written to the record.

[0053] The execution lease duration is determined based on the historical execution duration of similar actions. The platform daily calculates the time taken for similar actions within the previous 7 days from start to valid receipt, excluding parameter validation failures and manual termination records. The remaining durations are then sorted from smallest to largest, and the execution duration covering 99% of the records is selected. Simultaneously, the round-trip latency from the execution node to the target end for similar actions is calculated, covering 99% of the records. The aforementioned execution duration is multiplied by 3, and then doubled by the round-trip latency; the result is used as the execution lease duration. A result less than 30 seconds is used, and a result greater than 600 seconds is used. When there are fewer than 1000 valid samples for a new action type, the execution lease duration is fixed at 60 seconds.

[0054] The lease expiration time is calculated based on the database time of the action record storage area, not the local time of the action execution node. The action execution node initiates a lease renewal every one-third of the total lease duration. The renewal request carries the semantic action idempotent key, the execution node identifier, and the execution token. If all three items match the action execution record, the storage area extends the lease; if any item is inconsistent, the renewal fails, and the original action execution node stops sending new action requests.

[0055] The execution token monotonically increases for the same action execution record. When an action execution record is first acquired, the execution token increases from 0 to 1; when another action execution node reacquires the record after the lease expires, the execution token increases to 2. The execution node identifier, execution token, and lease expiration time are written in the same transaction to prevent two action execution nodes from simultaneously acquiring valid acquisition rights.

[0056] After acquiring the execution lease and execution token, the action execution node calls the corresponding execution interface based on the action type. Device control actions enter the device command interface, data forwarding actions enter the message forwarding interface, and service call actions enter the business interface. The execution request sent to the target carries the semantic action idempotent key, execution token, action target, action type, and normalized action parameters.

[0057] The target device stores the largest execution token received for the same semantic action idempotent key. If a new request carries an execution token smaller than the stored execution token, the target device rejects the request; if the new request carries an execution token equal to the stored execution token and an execution result already exists, the original execution result is returned directly; if the new request carries an execution token greater than the stored execution token, the target device updates the execution token and executes the corresponding action. If the target device does not have idempotent storage capabilities, the device instruction gateway stores the semantic action idempotent key and execution token, and sends control commands to the device after token verification.

[0058] After an action is completed, the action execution node submits a receipt. The receipt contains the semantic action idempotency key, execution token, execution result code, a summary of the content returned by the target, and the completion time. The action record storage area queries the corresponding record based on the semantic action idempotency key and compares the execution token in the receipt with the current execution token. If the two execution tokens match and the action status is "in execution," the receipt is valid; if the execution token in the receipt is less than the current execution token, the receipt is considered to originate from an action execution node that has lost its lease, and the action status is not updated.

[0059] When the execution result code is a success code, the action status is updated to successful execution. When the execution result code is an error such as parameter error, permission error, target non-existent, interface non-existent, or action parameter out of bounds, the action status is updated to failed execution, and automatic retry is no longer performed. Network interruption, target-side rate limiting, target-side temporary unavailability, and response timeout are identified as retryable exceptions.

[0060] For retryable anomalies, the initial wait time is taken from the latency covering 95% of the network round-trip latency records for the same type of action within the last 7 days. If this latency is less than 500 milliseconds, 500 milliseconds is used. The second wait time is twice the initial wait time, the third wait time is four times the initial wait time, and each subsequent wait time is doubled from the previous wait time. The wait time stops increasing after reaching 300 seconds. To avoid a large number of actions being retried at the same time, the platform generates a fixed perturbation duration, not exceeding 20% ​​of the initial wait time, based on the semantic action idempotency key and the current retry count, and adds this perturbation duration to the current wait time.

[0061] The maximum number of retries is determined based on the action's valid duration. Starting from the action's creation time, the platform sequentially accumulates the waiting time of each retrieval and the execution time of 99% of records for the same type of action. If adding one more retrieval would cause the accumulated time to exceed the action's valid duration, the number of retries will not be increased. When the action's execution count reaches the maximum number of retries, or when the current time has exceeded the action's valid deadline, the action status is updated to "execution failed."

[0062] For timeout records where an action request has been sent but no response has been received, the action execution node first uses the semantic action idempotent key to query the target's execution result before retrying. If a successful result already exists on the target, the query result is written as a valid response to the action execution record, and the same action is not sent again; if no execution record exists on the target, the action execution node reacquires an execution lease and a larger execution token before initiating the action request.

[0063] Through the above processing, the source event idempotent key is used to identify messages from the same original device, the processing instance key is used to distinguish the processing procedures corresponding to different snapshots and different rules, and the semantic action idempotent key is used to constrain the execution records of actions with the same business meaning. The immutable processing snapshot fixes the object model, parsing template, rule set, action definition, and rule matching network used for a single rule match. The execution lease limits the effective occupancy period of the action execution node, and the monotonically increasing execution token prevents execution nodes that have lost their leases from submitting action requests or modifying action results.

[0064] In one example implementation, step S1 includes identifying the protocol type of the original device message, calling the parsing template corresponding to the protocol type, converting the original device message into a standardized device event, generating a correction event time based on the device event time, the platform receiving time, and the historical time deviation of the corresponding device, and then partitioning and caching the standardized device event using the device identifier and the device startup cycle identifier.

[0065] In this embodiment, after receiving the original device message, the message access node reads the product identifier, device identifier, and allowed protocol types bound to the current communication connection, and sequentially verifies the message header identifier, protocol version, payload length, and checksum. When all the above verification contents conform to the data structure specified by a certain protocol, that protocol is determined as the protocol type of the current original device message; when protocol features conflict, the actual payload length is inconsistent with the declared length, or the checksum is inconsistent, the original device message is written to the protocol exception area and no longer enters the parsing process.

[0066] Furthermore, after the protocol type is determined, the parsing node queries the parsing template according to the product identifier, device model, message type, and platform reception time, selecting the parsing template with the largest version number that is within the validity period of the platform reception time. The parsing template records the field position, field length, byte order, data type, ratio coefficient, offset value, unit of measurement, and enumeration mapping relationship. The parsing node extracts the original fields according to the above content and completes data type conversion, ratio conversion, unit of measurement unification, and enumeration mapping.

[0067] When the original field is a proportionally compressed value, the original value is first multiplied by the proportional coefficient recorded in the parsing template, and then the corresponding offset value is added. When the unit of measurement of the original field is inconsistent with the unit of measurement specified by the object model, it is converted according to the unit conversion relationship already fixed in the parsing template. After the field processing is completed, a standardized device event is generated, which includes device identifier, device start-up cycle identifier, message unique identifier, message sequence, device event time, platform reception time, and standard field set.

[0068] As a preferred implementation, the platform saves historical time deviations for each device startup cycle. When a device comes online for the first time or restarts, it performs three consecutive time calibrations, and writes the sending time of each time calibration request, the receiving time of the response, and the device return time into the calibration record. The time deviation corresponding to each calibration is obtained by subtracting the device return time from the midpoint between the request sending time and the response receiving time, and the one with the shortest round-trip latency is selected as the initial time deviation for the current device startup cycle.

[0069] In this embodiment, during device operation, the difference between the platform reception time and the device event time of valid messages within the most recent 24 hours is continuously calculated. All differences are sorted by numerical value to determine the median value, and then the absolute deviation between each difference and the median value is calculated. Samples that deviate from the median value by more than three times the median absolute deviation are not included in the update, and the median value of the remaining samples is used as the updated historical time deviation. If the number of valid samples is less than 5, the initial time deviation is continued to be used.

[0070] In addition, the corrected event time is obtained by adding the current historical time deviation to the device event time. When the corrected event time is later than the platform's reception time, the platform calculates the normal time difference between the corrected event time and the platform's reception time within the corresponding device in the last 24 hours, takes the time difference covering 99.9% of historical messages, and adds it to the access node's clock error to obtain the time anomaly judgment range. When the corrected event time exceeds this judgment range, it is corrected to the platform's reception time, and a device clock anomaly flag is written into the standardized device event.

[0071] In one optional implementation, the device identifier and the device startup cycle identifier are encoded in a fixed order, and a digest operation is performed on the encoding result. After converting the digest result into a non-negative integer, the remainder obtained by dividing the integer by the total number of partitions is used as the partition number, so that standardized device events generated by the same device within the same startup cycle enter the same partition.

[0072] In this embodiment, after the device restarts, the device startup cycle identifier changes, and new standardized device events form new partition keys, preventing confusion with message sequences that may have been reused in the previous startup cycle. The partition cache saves standardized device events sequentially according to the correction event time, message sequence, and platform reception time, thereby providing a definite data order for subsequent timing output.

[0073] In another specific implementation, the protocol type is pre-bound by the device certificate, access port, or message topic. The message access node no longer performs full protocol identification on each original device message, but only verifies the protocol version, message length, and checksum. When the device does not have time calibration capabilities, the median difference between the platform reception time and the device event time of the first 5 valid messages after the device goes online is taken as the initial time deviation for the current startup cycle.

[0074] As shown above, the above processing can reduce the probability of erroneous parsing between different communication protocols and reduce the impact of device clock drift on event sequence by utilizing historical time deviations. The joint participation of device identifier and device startup cycle identifier in partitioning can also avoid timing disorder caused by message sequence recounting after device restart.

[0075] In one example implementation, step S1 further includes determining the timing output boundary based on the historical message arrival delay and message sequence continuity of the corresponding device, outputting standardized device events according to the correction event time and message sequence information, and isolating standardized device events that exceed the timing output boundary or whose message sequences are repeated, rolled back, or have gaps.

[0076] In this embodiment, the platform calculates message arrival delays based on both device identifier and device startup cycle identifier. The arrival delay of each message is obtained by subtracting the correction event time from the platform's reception time, and only messages with successful protocol parsing, valid message sequences, and whose device clocks are not marked as abnormal are included in the statistical samples.

[0077] Select at least 100 valid messages from the most recent 24 hours, arrange their arrival times in ascending order, and take the arrival time that covers 99.5% of the valid messages. Then add a 200-millisecond internal platform processing margin to obtain the out-of-order waiting time for the device. If there are fewer than 100 valid messages, use the normal maximum arrival time measured during the access testing phase of the corresponding product.

[0078] It should be noted that this application executes out-of-order waiting time as 500 milliseconds when it is less than 500 milliseconds and as 30000 milliseconds when it is greater than 30000 milliseconds, thereby avoiding insufficient sample size or short-term abnormality of communication link that leads to waiting time being too short or too long.

[0079] Furthermore, the partition processing node records the maximum correction event time received by the current partition, and subtracts the out-of-order waiting time from this maximum correction event time, with the resulting time serving as the current time output boundary. Standardized device events whose correction event time is not later than the time output boundary and whose message sequence is continuous are output in order of earliest to latest correction event time; if the correction event times are the same, they are output in order of smallest to largest message sequence.

[0080] The continuity of the message sequence is determined based on the previously confirmed output message sequence. A message sequence is considered continuous if the current message sequence equals the previous message sequence plus one; it is considered duplicated if the current message sequence is the same as a previously processed message sequence; it is considered to have rolled back if the current message sequence is less than the previously confirmed output message sequence; and it is considered to have a gap in the message sequence if the current message sequence is greater than the expected sequence.

[0081] In some embodiments, upon discovering a message sequence gap, the partition processing node retains the standardized device events following the gap within the current out-of-order waiting time and waits for the missing message to arrive. If the missing message arrives before the waiting time expires, it is output according to the restored continuous sequence; if the missing message is not received after the waiting time expires, the events before and after the gap, the range of the missing sequence, and the actual waiting time are written into the isolation record.

[0082] In addition, if the correction event time of a standardized device event is earlier than the time output boundary but arrives after the boundary has been crossed, the standardized device event is identified as an out-of-boundary late event. Duplicate events, rollback events, gap events, and out-of-boundary late events are not directly deleted, but their original message digest, correction event time, message sequence, isolation reason, and isolation processing status are preserved.

[0083] Optionally, after isolation events are manually confirmed or determined by compensation rules, they are re-associated with immutable processing snapshots consistent with the original processing procedure before entering the rule matching process. When messages do not carry a continuous sequence, the corrected event time is used as the primary sorting criterion, and the message's unique identifier is used as the secondary sorting criterion under the same time condition.

[0084] In another specific implementation, for devices that allow for a small amount of packet loss, standardized device events following the gap are continued to be output after the gap isolation record is formed; for devices that require strict message continuity, events following the gap remain isolated until the missing message is filled or the platform generates a compensation event corresponding to the missing message.

[0085] As can be seen from the foregoing embodiments, the method of this application can adjust the timing output boundary according to the device's own historical arrival delay, and identify repeated, backtracking and gap events in combination with the continuous state of the message sequence, thereby reducing the interference of abnormal timing messages on the state judgment rules and continuous event rules.

[0086] In one example implementation, step S2 includes determining a candidate version group from the version dependency index based on the product identifier, device identifier, and event time corresponding to the standardized device event, and extracting the event field signature, the output field signature of the parsed template, the input field signature of the rule set, and the action parameter signature of the action definition to perform version compatibility verification.

[0087] In this embodiment, the version dependency index is established according to product identifier, device identifier, version effective time, and version expiration time, and stores the dependency relationships between object model version, parsing template version, rule set version, and action definition version. The platform first queries the product-level version configuration, and then queries the device-level overriding configuration; if a device-level overriding configuration exists, the device-level configuration is used; otherwise, the product-level configuration is used.

[0088] Specifically, if the event time is no earlier than the version's effective time but earlier than the version's expiration time, the version is considered valid for the current standardized device events. If no expiration time is set for a version, it is considered to remain valid until a subsequent version becomes effective. The platform will form a candidate version group consisting of the object model version, parsing template version, rule set version, and action definition version that are all currently valid and have complete dependencies.

[0089] Furthermore, field signatures are composed of field name, data type, unit of measurement, whether it is required, field level, and array element type in a fixed order. Event field signatures are derived from fields that actually exist in standardized device events, output field signatures are derived from fields that can be output by parsing template declarations, input field signatures are derived from fields actually referenced by rule conditions, and action parameter signatures are derived from parameter constraints recorded in action definitions.

[0090] In one optional implementation, compatibility checks first verify that each event field exists in the output fields of the parsing template, and then checks the corresponding data type and unit of measurement. Numeric types are allowed to be converted from low-precision to high-precision types only if there is no reduction in the numerical range or loss of precision during the conversion process; if the units of measurement are inconsistent, the check will only pass if the unit conversion relationship is already recorded in the parsing template.

[0091] In addition, the platform checks whether all input fields referenced by the rule set are included in the output fields of the parsing template. When a rule input field is generated by a derived rule, it also needs to verify that all the base fields used to generate the derived field are included in the output fields of the parsing template, and verify that the calculation method and result type used by the derived rule are fixed.

[0092] Action parameter validation is performed sequentially according to parameter name, parameter type, required relationship, value range, and parameter level. If any required parameter is missing, the data type is inconsistent, the value exceeds the allowed range, or the parameter level does not conform to the action definition, the candidate version group must not generate a processing snapshot, and the incompatible field name, parameter name, and corresponding version identifier must be recorded.

[0093] Therefore, the method of this application can enable standardized device events to obtain version combinations corresponding to their event times, and detect missing fields, type conflicts, and incorrect action parameters before rule execution, thus avoiding the use of the current configuration to process historical events or discovering parameter incompatibility only during the action execution phase.

[0094] In one example implementation, after the compatibility check passes, the rule set version is compiled into a rule matching network containing condition nodes, shared matching nodes, and action nodes. The candidate version group, version dependency relationship, field mapping relationship, rule matching network, and action parameter structure are serialized in a preset order to form an immutable processing snapshot.

[0095] In this embodiment, the rule compilation node breaks down each rule into field reading, comparison and judgment, logical combination, and action output. Field reading and comparison and judgment form condition nodes. Preconditions with the same field names, comparison methods, and comparison values ​​in multiple rules are merged into shared matching nodes, which are then connected to the corresponding action nodes after the complete rule conditions are met.

[0096] In this rule-matching network, nodes are assigned fixed numbers based on field name, operation type, comparison value, rule priority, and rule identifier. Node content and node numbers generated under the same rule set version and compilation conditions remain consistent.

[0097] Furthermore, the serialization process first writes the object model version, parsing template version, rule set version, and action definition version, then sequentially writes the version dependencies, field mapping relationships, rule node connection relationships, and action parameter structure. Collection-type data is sorted in ascending order of identifier values, with numerical values ​​using fixed precision, time expressed in milliseconds under a unified time zone, and null values ​​using a preset encoding.

[0098] A 256-bit digest operation is performed on the serialized consecutive bytes. The resulting digest is used as a snapshot identifier, and the snapshot identifier, serialized content, and generation time are written to read-only snapshot storage. If the same snapshot identifier already exists, the original immutable processing snapshot is directly reused. If any version of the content, field mapping, or rule node changes, a new snapshot identifier is generated. Before a standardized device event enters the rule matching network, the platform writes the event processing record and snapshot identifier in the same transaction. Only when the event processing record is successfully written and the corresponding snapshot is in a valid state is the standardized device event submitted to the rule matching network; if the transaction fails, the event remains in a pending association state.

[0099] In another specific implementation, snapshot storage and event processing records reside on different storage nodes. The platform associates snapshot identifiers using transaction messages with a conditional write status. Only after the transaction message is in a committed state can standardized device events enter the rule matching network.

[0100] As can be seen, the rule matching network in this application embodiment can reuse the same preconditions in multiple rules, reducing repeated field reading and condition judgment; deterministic serialization enables the same version combination to form the same snapshot identifier, and the atomic association between the snapshot identifier and the event enables each standardized device event to perform rule matching according to the already solidified version content.

[0101] In one example implementation, the device identifier, device startup cycle identifier, message unique identifier, and message payload in a standardized device event are sorted and their data types are unified to generate a payload summary. Then, an idempotent key for the source event is generated based on the device identifier, device startup cycle identifier, message unique identifier, and payload summary.

[0102] In this embodiment, before generating the payload digest, the platform arranges the fields in the message payload according to the character encoding order of the field names. Integers are removed from invalid leading zeros, decimals retain the precision specified by the parsing template, times are converted to milliseconds in a unified time zone, boolean values ​​are converted to 0 or 1, object fields are sorted layer by layer, and arrays are saved according to the element order specified by the protocol.

[0103] Furthermore, after field normalization, the normalization result is converted into consecutive bytes, and a 256-bit digest operation is performed to obtain the payload digest. The device identifier, device startup cycle identifier, message unique identifier, and payload digest are concatenated in a fixed order, with the byte length of each field written before it. Then, a digest operation is performed on the concatenation result to generate the source event idempotent key.

[0104] Therefore, in this embodiment, the calculation of the source event idempotent key does not include the snapshot identifier. Thus, when the same original device message is reprocessed using different snapshots, the same source event idempotent key can still be obtained.

[0105] In this embodiment, when a standardized device event passes through the rule matching network, the identifiers of the condition nodes it actually traverses are recorded sequentially. When a condition node has different judgment branches, the branch direction in which the event actually enters at that condition node is also recorded, and the node identifiers and branch directions are connected according to the order in which the nodes are traversed.

[0106] In addition, a digest operation is performed on the connection results of the node identifier and branch direction to generate a rule matching branch identifier. The source event idempotency key, snapshot identifier, matching rule identifier, and rule matching branch identifier are connected in a fixed order and a digest operation is performed again to obtain the processing instance key.

[0107] As can be seen from the foregoing embodiments, the method of this application can form different processing instance keys when the same source event passes through different condition nodes or enters different judgment branches under the same snapshot, thereby preserving the snapshot, matching rules and actual matching path used by the event.

[0108] In one example implementation, the action target, action type, and action parameters of the action to be performed are sorted by field, data types are unified, units of measurement are converted, and numerical precision is normalized. Then, a semantic action idempotent key is generated based on the source event idempotent key, the normalized action target, action type, action parameter summary, and action valid range.

[0109] In this embodiment, the action target is encoded in the order of tenant identifier, target category, and target unique identifier, and the action type is converted to a fixed type number recorded in the action definition. The action parameters are arranged in the character encoding order of the parameter names, integers are in decimal form without leading zeros, decimals are rounded according to the precision specified in the action definition, time is converted to milliseconds, strings use a unified character encoding, and object parameters are sorted hierarchically.

[0110] When the action parameters include units of measurement, they are converted to standard units according to the unit conversion relationships already established in the action definition. The numerical precision is determined based on the minimum resolution that the target device or target interface can recognize; if the numerical precision is not specified in the action definition, the precision specified in the corresponding object model field is used.

[0111] Furthermore, a summary operation is performed on the normalized action parameters to obtain an action parameter summary. The start and end times of the action's valid interval are both converted to milliseconds; if no start time is set, the action creation time is used; if no end time is set, the end time is determined based on the action creation time and the longest valid duration recorded in the action definition.

[0112] The source event idempotency key, the normalized action target, the action type, the action parameter summary, and the action valid range are concatenated in a fixed order, and a summary operation is performed on the concatenation result to generate a semantic action idempotency key. Actions to be executed with the same content form the same semantic action idempotency key, regardless of the rule version from which the action originates.

[0113] It should be noted that this application saves both the data length of the normalized action parameters and the complete parameters when writing the action execution record. When the semantic actions have the same idempotent key but different data lengths of the normalized action parameters, the complete normalized action parameters are compared field by field.

[0114] In some embodiments, the complete parameter comparison includes the number of fields, field names, data types, parameter values, and hierarchical structure. If any comparison content differs, the corresponding action to be executed is identified as a summary conflict action, written into the conflict handling record, and the existing action execution record is not reused.

[0115] Action normalization can eliminate differences in field order, units of measurement, and numerical representation, enabling actions with the same business meaning to obtain the same semantic idempotent key; full parameter comparison can prevent actions with the same summary result but different actual action parameters from being incorrectly merged.

[0116] In one example implementation, a semantic action idempotent key is used as the unique index for the action execution record. The action execution record is established through atomic transactions or the current processing instance key is associated with an existing action execution record. The execution node obtains execution rights through the state version number, execution lease, and incrementing execution token.

[0117] In this embodiment, the action scheduling node queries action execution records using semantic action idempotent keys. If no corresponding record exists, the processing instance key, snapshot identifier, action to be executed, action parameter summary, execution status, and initial status version number are written into the same transaction. If a corresponding record already exists, no new action execution record is added; instead, the correspondence between the current processing instance key and the existing action execution record is written into the processing instance association table.

[0118] Furthermore, when an action execution node requests execution rights, it reads the action execution status, status version number, and lease expiration time. If the action execution status is pending, or if the current database time has exceeded the lease expiration time, the read status version number is used as a condition to perform an update. In the same update operation, the execution status, the action execution node identifier, and the new lease expiration time are written, and the status version number is incremented by 1.

[0119] When a condition update affects one action execution record, the action execution node is deemed to have acquired an execution lease; when a condition update does not affect any action execution record, the corresponding status version number is deemed to have changed, and the current action execution node is not allowed to execute the pending action.

[0120] As a preferred implementation, the lease duration is determined based on the most recent 7 days of valid execution records for similar actions. All valid execution durations are arranged in ascending order, and the completion duration that covers 99% of the execution records is selected. This completion duration is then multiplied by 3, and a round-trip latency margin is added to the target end.

[0121] In this embodiment of the application, when the lease duration calculation result is less than 30 seconds, 30 seconds is used, and when it is greater than 600 seconds, 600 seconds is used; when the number of valid samples of the same type of action is less than 1,000, 60 seconds is used as the lease duration.

[0122] In addition, for each successful allocation of an execution lease, the lease allocation count is incremented by 1, and the increased lease allocation count is used as the execution token. The execution token and the action execution node identifier that acquired the execution lease are written to the action execution record simultaneously. When an action execution node requests lease renewal, the semantic action idempotent key, node identifier, execution token, and status version number must all be consistent with the current action execution record.

[0123] In another specific implementation, action execution records and processing instance relationships are stored in a relational database, and atomic updates are performed through unique indexes and database transactions. When using distributed key-value storage, the same state change control is achieved through conditional writes and version comparisons.

[0124] Therefore, the method of this application can ensure that only one valid action execution record is formed for the same semantic action by using a unique index, prevent multiple action execution nodes from updating the execution status at the same time by using a status version number, and realize the takeover of failed nodes and the identification of expired requests by using execution leases and incrementing execution tokens.

[0125] In one example implementation, after the node identifier, execution lease, and execution token are verified, the action execution node sends the semantic action idempotent key, execution token, and action parameter summary along with the action to be executed to the target end. The target end then determines whether to execute the action to be executed based on the historical execution records and the maximum execution token.

[0126] In this embodiment, the action execution node rereads the action execution record before sending the action. When the node identifier in the record is consistent with the current node, the current database time has not exceeded the lease expiration time, and the execution token in the action execution record is consistent with the execution token held by the current node, the execution qualification verification is considered successful.

[0127] Furthermore, after the execution qualification verification is passed, the semantic action idempotent key, execution token, action parameter summary, and action to be executed are sent to the device gateway, message queue consumer, or Hypertext Transfer Protocol server. The target end queries historical execution records using the semantic action idempotent key and reads the maximum execution token stored for that semantic action idempotent key.

[0128] If the target does not have a corresponding historical execution record, and the execution token carried in the request is not less than the maximum execution token already saved, the execution token for this instance is saved first, and then the action to be executed is executed. After the action is executed, the target regenerates the actual execution parameter summary based on the actual action parameters used, and returns an action execution receipt containing the actual execution parameter summary, the target status version, and the execution result.

[0129] In this embodiment of the application, if the target already has a successful execution record, the action to be executed will not be executed again, but the original execution result will be returned; if the execution token carried in the request is less than the maximum execution token saved by the target, the action request will be rejected and the currently saved maximum execution token will be returned.

[0130] As a preferred implementation, if the action execution node does not receive an action execution receipt within the receipt waiting time, it updates the action execution status to "execution result unknown". The receipt waiting time is determined based on the value that covers 99% of the execution records in the response time of the corresponding target end in the last 7 days, plus one network round-trip delay.

[0131] Additionally, a 3-second wait time is used when the receipt waiting time is less than 3 seconds, and a 120-second wait time is used when the wait time is greater than 120 seconds. When the action execution status is "execution result unknown", the target's historical execution record is queried using the semantic action idempotent key first; if the target does not support historical record query, the target status version is read and compared with the target status version recorded before the action was sent.

[0132] Optionally, if the target-side historical record exists, or the target state version has changed as expected according to the action to be executed, the action to be executed is considered to have been executed, and an action execution receipt is added. If the target-side historical record does not exist and the target state has not changed as expected, the action to be executed is considered not to have been executed, the action execution node reacquires the execution lease, and resends the action using the same semantic action idempotent key and a new execution token.

[0133] It should be noted that the action record storage node and target end of this application only accept action requests, status updates, and execution receipts that are not less than the current execution token. If the execution token is less than the current execution token, the corresponding request or receipt will be rejected.

[0134] In another specific implementation, the message queue consumer writes the semantic action idempotent key into the consumption deduplication table; when the device itself does not have the ability to save historical execution records, the device gateway saves the semantic action idempotent key, execution token, and device status version. When the target does not provide a status version, the verifiable target attribute value is used as the basis for judging the execution result.

[0135] As can be seen, in this embodiment of the application, the target's historical execution record, target status version, and execution token can be used together to determine whether an action has been implemented, reduce duplicate device control or duplicate data forwarding caused by lost receipts, and prevent action execution nodes that have lost their leases from continuing to change the action execution results.

[0136] In one example implementation, the IoT platform rule engine parsing, data forwarding, and device linkage control system includes a message processing module, a snapshot and rule matching module, an idempotent key generation module, an action scheduling module, and an action execution module.

[0137] In this embodiment, the message processing module includes a message access unit, a protocol identification unit, a parsing unit, and a timing processing unit. The message access unit receives raw device messages reported by IoT devices and writes them into the platform's receiving time. The protocol identification unit determines the protocol type of the raw device messages. The parsing unit calls a parsing template and generates standardized device events.

[0138] The timing processing unit partitions and caches standardized device events according to device identifiers and device startup cycle identifiers, generates corrected event times based on historical time deviations, and determines the timing output boundaries by combining historical message arrival delays and message sequence continuity. The snapshot and rule matching module includes a version indexing unit, a compatibility verification unit, a snapshot generation unit, and a rule matching unit. The version indexing unit is used to obtain the object model version, parsing template version, rule set version, and action definition version. The compatibility verification unit is used to verify the compatibility relationships between event fields, parsing template output fields, rule input fields, and action parameters.

[0139] The snapshot generation unit is used to generate immutable processing snapshots and snapshot identifiers, and the rule matching unit is used to call the rules in the immutable processing snapshots to match network processing standardized device events and output the matching rule identifier and the action to be executed.

[0140] In addition, the idempotency key generation module is used to generate idempotency keys for source events, processing instances, and semantic actions. During the idempotency key generation process, the data involved in the calculation is sorted by field, data types are standardized, units of measurement are converted, numerical precision is processed, and a summary operation is performed. The normalized complete data is then saved.

[0141] As a preferred embodiment, the action scheduling module includes an action record storage unit, a uniqueness verification unit, and a lease management unit. The uniqueness verification unit establishes unique constraints using semantic action idempotent keys, the action record storage unit writes action execution records through atomic transactions, and the lease management unit allocates execution leases and incrementing execution tokens to action execution nodes based on the status version number.

[0142] In some embodiments, the action execution module includes a device instruction adapter, a message forwarding adapter, a service call adapter, and an acknowledgment processing unit. The device instruction adapter is used to send control actions to the device gateway, the message forwarding adapter is used to forward data to the message queue consumer, and the service call adapter is used to send service call requests to the Hypertext Transfer Protocol (HTTP) server.

[0143] It should be noted that in this application, the receipt processing unit is used to verify the semantic action idempotent key and the execution token, and update the action execution record to a state of successful execution, execution failure, or unknown execution result. When it is confirmed that the target has not executed the corresponding action, the action execution module resubmits the action to be executed using the same semantic action idempotent key.

[0144] In another specific implementation, each module transmits standardized device events, snapshot identifiers, and action execution record identifiers through a persistent message channel. After processing, the module submits the data to the corresponding consumption location. If a module fails to process the data, the original consumption location is retained, allowing the failed node to recover and continue processing the incomplete data.

[0145] Therefore, in this embodiment, version data, snapshot data, and action execution records can be stored separately and associated with each other through version identifiers, snapshot identifiers, processing instance keys, and semantic action idempotent keys. When modules are deployed on the same server, data is transmitted through in-process interfaces; when modules are deployed in a distributed manner, data is transmitted through message middleware or remote call interfaces.

[0146] As shown above, the module configuration enables message parsing, rule matching, idempotent control, and action execution to be extended separately, and maintains consistency across the processing chain through immutable processing snapshots and action execution records. In the event of a node failure, incomplete standardized device events and pending actions can be recovered based on persistent records, and duplicate actions will not occur due to repeated consumption.

[0147] 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 alterations 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 rule engine parsing, data forwarding, and device linkage control of an Internet of Things (IoT) platform, characterized in that, include: S1. Receive raw device messages reported by IoT devices, parse and standardize the raw device messages, generate standardized device events, and perform partitioning, caching, and timing processing according to device identifiers; S2. When outputting the standardized device event, obtain the corresponding object model version, parsing template version, rule set version, and action definition version; when the output field set of the parsing template covers the input field set of the rule set, and the action parameters generated by the rule set conform to the parameter signature of the action definition, combine the versions, version dependencies, and rule matching network into an immutable processing snapshot and generate a snapshot identifier, and use the rule matching network to match the standardized device event to obtain the matching rule identifier and the action to be executed; S3. Generate a source event idempotent key that does not contain the snapshot identifier based on the device identifier, device startup cycle identifier, message unique identifier and message payload digest; generate a processing instance key based on the source event idempotent key, snapshot identifier and matching rule identifier; and generate a semantic action idempotent key that does not contain the snapshot identifier based on the source event idempotent key, action target, action type and normalized action parameters. S4. Using the semantic action idempotent key as a unique constraint, atomically write an action execution record containing the processing instance key, snapshot identifier, action to be executed, and action execution status, and allocate an execution lease with a valid time limit and a monotonically increasing execution token to the action execution node that successfully occupies the action execution record. S5. The action execution node executes the action to be executed based on the semantic action idempotent key and the execution token, and performs acknowledgment and abnormal retry control according to the action execution result.

2. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 1, characterized in that, S1 includes: Identify the protocol type of the original device message, call the corresponding parsing template, and convert the original device message into a standardized device event; Based on the device event time, platform reception time, and historical time deviation of the corresponding device in the standardized device event, a correction event time is generated, and the standardized device event is partitioned and cached using device identifier and device startup cycle identifier.

3. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 2, characterized in that, S1 further includes: The timing output boundary is determined based on the historical message arrival delay and message sequence continuity of the corresponding device. The standardized device event is output according to the corrected event time and message sequence information. Standardized device events that exceed the timing output boundary or whose message sequences are repeated, rolled back, or have gaps are isolated.

4. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 1, characterized in that, S2 includes: Based on the product identifier, device identifier, and event time corresponding to the standardized device event, a candidate version group consisting of the object model version, parsing template version, rule set version, and action definition version is determined from the version dependency index. Extract event field signatures, parse template output field signatures, rule set input field signatures, and action parameter signatures of action definitions. Determine whether the event field signature matches the output field signature, whether the output field signature covers the input field signature, and whether the action parameters generated by the rule set match the action parameter signature.

5. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 4, characterized in that, S2 further includes: When the compatibility check passes, the rule set version is compiled into a rule matching network containing condition nodes, shared matching nodes, and action nodes; The candidate version group, version dependency relationship, field mapping relationship, rule matching network and action parameter structure are serialized in a preset order. The serialization result is digested to generate a snapshot identifier, forming an immutable processing snapshot. The snapshot identifier is then atomically associated with the standardized device event.

6. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 1, characterized in that, S3 includes: The device identifier, device startup cycle identifier, message unique identifier, and message payload in the standardized device event are sorted by field and data type unified to generate a payload summary. The source event idempotent key is generated based on the device identifier, device startup cycle identifier, message unique identifier, and payload summary. A processing instance key is generated based on the source event idempotent key, snapshot identifier, matching rule identifier, and rule matching branch identifier. The rule matching branch identifier is generated based on the sequence of condition nodes traversed by the standardized device event.

7. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 6, characterized in that, S3 further includes: The action target, action type and action parameters to be executed are sorted by field, data types are standardized, units of measurement are converted and numerical precision is normalized. The semantic action idempotency key is generated based on the source event idempotency key, the normalized action target, the action type, the action parameter summary, and the action valid range, so that actions to be executed with the same above items have the same semantic action idempotency key; when the semantic action idempotency keys are the same but the data lengths of the normalized action parameters are different, the complete normalized action parameters are compared to determine whether the actions to be executed are the same.

8. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 1, characterized in that, S4 includes: The semantic action idempotent key is used as the unique index for the action execution record; when no corresponding action execution record exists, an action execution record containing the processing instance key, snapshot identifier, action to be executed, action parameter summary, action execution status, and status version number is written through an atomic transaction; when a corresponding action execution record already exists, the current processing instance key is associated with the existing action execution record. When the action execution status is pending execution or the original execution lease expires, the action execution node updates the action execution status, node identifier, lease expiration time and status version number with the current status version number as the comparison condition to obtain the execution lease, and generates an incremental execution token bound to the action execution node according to the number of lease allocations.

9. The IoT platform rule engine parsing, data forwarding, and device linkage control method according to claim 1, characterized in that, S5 includes: After the node identifier, execution lease and execution token are verified, the action execution node sends the semantic action idempotent key, execution token and action parameter digest along with the action to be executed to the target end, which is a device gateway, message queue consumer or Hypertext Transfer Protocol server. When the target terminal does not have a corresponding historical execution record and the execution token is not less than the maximum execution token of its idempotent key record for the semantic action, it executes the action to be executed and returns an action execution receipt containing a summary of actual execution parameters, target state version and execution result. If no action execution receipt is received, the action execution status is marked as execution result unknown, and the execution result is verified according to the target's historical execution record or target status version. If it is confirmed that the action has not been executed, it is resent using the same semantic action idempotent key. If it is confirmed that the action has been executed, an action execution receipt is added, and action execution requests with a smaller execution token than the current execution token in the action execution record are rejected.

10. A system applied to the IoT platform rule engine parsing, data forwarding, and device linkage control method according to any one of claims 1-9, characterized in that, include: The message processing module is used to receive raw device messages reported by IoT devices, parse and standardize the raw device messages, generate standardized device events, and perform partitioning, caching, and timing processing according to device identifiers; The snapshot and rule matching module is used to obtain the object model version, parsing template version, rule set version, and action definition version. When the output field set of the parsing template covers the input field set of the rule set and the action parameters generated by the rule set match the parameter signature of the action definition, an immutable processing snapshot and snapshot identifier containing the versions, version dependencies, and rule matching network are generated. The module then performs rule matching on the standardized device events to obtain the matching rule identifier and the action to be executed. An idempotent key generation module is used to generate a source event idempotent key that does not contain the snapshot identifier, generate a processing instance key based on the source event idempotent key, the snapshot identifier, and the matching rule identifier, and generate a semantic action idempotent key that does not contain the snapshot identifier based on the source event idempotent key and the normalized action to be executed. The action scheduling module is used to atomically write the action execution record with the semantic action idempotent key as a unique constraint, and to allocate an execution lease and an incrementing execution token to the action execution node that successfully occupies the action execution record; The action execution module is used to execute the action to be executed after the execution lease and execution token verification are passed, confirm the execution result according to the action execution receipt returned by the target end, and re-execute the action to be executed using the same semantic action idempotent key when it is confirmed that the action to be executed has not been executed.

Images