Internet-of-things equipment state synchronization system based on event driving and two-state verification

Abstract

The invention provides an Internet of Things equipment state synchronization system based on event driving and two-state verification, and relates to the technical field of Internet of Things, and the system comprises an Internet of Things system side which is used for recording the state of corresponding Internet of Things equipment as a current expected state according to an equipment state change event monitored in real time, generating a state difference message when the current expected state is inconsistent with the actual state of the equipment acquired last time; the Internet of Things equipment side is used for generating a response difference message containing a current actual state when the current expected state contained in the state difference message is inconsistent with the current actual state of the Internet of Things equipment side; and the system side of the Internet of Things adjusts the actual state of the equipment into the current actual state according to the response difference message, and then executes dual-state consistency verification to synchronize the current expected state into the current actual state. The method has the beneficial effects of breaking a state isolation barrier, remarkably reducing the synchronization cost, eliminating the time sequence deviation problem, reducing the cloud computing pressure and being compatible with different deployment architectures.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an IoT device state synchronization system based on event-driven and dual-state verification. Background Technology

[0002] With the deep penetration of IoT technology into fields such as smart homes, industrial control, and smart healthcare, the scale of devices connected to IoT systems has jumped from hundreds of thousands to millions or even tens of millions. The system architecture is also gradually evolving towards a distributed, cloud-edge collaborative approach. To achieve flexible deployment, independent maintenance, and elastic expansion of each functional module, the industry generally adopts a layered and decoupled architecture, separating the device connection layer from the business system. The device connection layer often exists independently in the form of public cloud services (such as AWS IoT Core, Alibaba Cloud IoT), private cloud solutions, open source frameworks (such as Eclipse Mosquitto), or self-developed platforms, while the business system focuses on business logic processing and user interaction.

[0003] However, in actual operation, the existing IoT system architecture has gradually revealed the following key technical pain points, which seriously restrict the reliability and operating efficiency of the system: 1. Data isolation issues arising from system decoupling The mainstream device connection layer is generally deployed as an independent subsystem. The real-time status data of the devices stored in it cannot be directly accessed by the business system. Data interaction between the two must be completed indirectly through a preset interface. This indirect synchronization method not only increases the length of the data transmission link, but is also prone to data synchronization delays due to problems such as interface call delays and abnormal interface interruptions.

[0004] 2. The problem of excessively high costs for synchronizing massive amounts of equipment. Typical IoT systems require access to millions of devices. Existing technologies generally use timed full data synchronization to maintain strong consistency between the device connectivity layer and the business system. This method requires synchronizing the status data of all devices from the device connectivity layer to the business system at fixed intervals, resulting in huge consumption of network bandwidth and computing resources. Meanwhile, after receiving the full data, the business system needs to compare, update, and store the status data of each device, leading to a significant increase in server CPU utilization and strained computing resources. This not only increases hardware deployment and maintenance costs but may also cause a decrease in the processing capacity of the business system due to insufficient resources, affecting the overall service quality.

[0005] 3. Timing issues in distributed architectures Business systems commonly employ distributed architectures to handle high-concurrency scenarios. However, the characteristics of distributed architectures lead to timing inconsistencies in device status messages during transmission and processing, resulting in discrepancies between the device connectivity layer and the business layer. Because distributed nodes are deployed in different physical locations, the network latency for transmitting device status messages from the device connectivity layer to each distributed node varies, potentially causing multiple status change messages for the same device to be received in reverse order on different nodes. Furthermore, differences in message processing speed among distributed nodes also exacerbate timing irregularities.

[0006] The aforementioned technical pain points directly lead to serious risks in the business system's determination of device status, specifically manifested as follows: 1. Failure to issue device operation commands: The business system issues control commands based on inaccurate or outdated device status. For example, if the device is actually online, but the business system considers the device to be offline due to data synchronization lag, the issued control commands will not be received by the device, resulting in operation failure; or the device is offline, but the business system does not update the status in time and continues to issue commands, resulting in invalid command transmission.

[0007] 2. Business logic errors caused by status misjudgment: The business system misjudges the operating status of devices due to discrepancies in status data, thereby triggering incorrect business logic. For example, a device that is normally online may be misjudged as offline, causing the system to automatically stop pushing service data to that device, affecting normal business operations; or an offline device may be mistakenly judged as online, continuously allocating task resources to it, resulting in resource waste.

[0008] 3. Decreased reliability of equipment management functions: Inaccurate and inconsistent equipment status data prevents the equipment management functions of the business system from functioning properly. For example, when calculating equipment online rate, errors in the status data of some equipment lead to distorted statistical results, affecting operation and maintenance decisions; when locating faulty equipment, the lag in status data makes it impossible to detect and handle equipment faults in a timely manner, prolonging the impact time of the fault; when controlling equipment in batches, inconsistencies in the status data of each node cause some equipment to fail to execute control commands, resulting in control effects that do not meet expectations.

[0009] These problems seriously affect the stability, reliability, and operational efficiency of IoT systems, and restrict the further promotion and application of IoT technology. Therefore, there is an urgent need for an IoT device status synchronization technology solution that can solve the above pain points. Summary of the Invention

[0010] To address the problems existing in the prior art, this invention provides an IoT device state synchronization system based on event-driven and dual-state verification, comprising: On the IoT system side, it is used to record the status of the corresponding IoT device as the current expected status based on the real-time monitored device status change events, and then generate a status difference message when the current expected status is inconsistent with the previously obtained actual device status. On the IoT device side, it is used to obtain the state difference message when establishing a communication connection with the IoT system side, and generate a response difference message containing the current actual state when the current expected state contained in the state difference message is inconsistent with its own current actual state. The IoT system side is also used to adjust the actual state of the device to the current actual state according to the response difference message, and then perform a dual-state consistency check to synchronize the current expected state to the current actual state.

[0011] Preferably, the IoT system side includes a device connection layer and a status synchronization module. The device connection layer is used to monitor the device status change events in real time and push them to the status synchronization module. The state synchronization module is used to record the state of the corresponding IoT device as the current desired state based on the device state change event.

[0012] Preferably, the status synchronization module is deployed in the device connection layer.

[0013] Preferably, the status synchronization module is deployed in a business system that is communicatively connected to the device connection layer; The device connection layer pushes the device status change events it monitors in real time to the business system, and then pushes them to the status synchronization module through the business system.

[0014] Preferably, the status difference message includes the device number of the corresponding IoT device, the current expected status, and the actual status of the device; The IoT device generates the response difference message when it confirms that the current expected state contained in the state difference message is inconsistent with the actual state of the device and that the current expected state is inconsistent with its own current actual state.

[0015] Preferably, the IoT system side also includes a state synchronization engine, and the state synchronization module is further used to adjust the actual state of the device to the current actual state according to the response difference message, and then generate a consistency verification signal; The state synchronization engine is used to perform a bi-state consistency check between the current expected state and the actual state of the device based on the consistency check signal, so as to synchronize the current expected state with the current actual state.

[0016] Preferably, the state synchronization module includes a state confirmation unit, which is used to generate a synchronization request containing the current desired state and send it to the IoT device side when the device state change event is an offline event, and the current desired state is offline; The IoT device side also includes a status repair unit, which generates a difference repair message and reports it to the IoT system side when the synchronization request is received. The difference repair message contains its own real-time device status, and the real-time device status is online; The state synchronization module is also used to adjust the current desired state to the real-time device state according to the difference repair message.

[0017] Preferably, the IoT device side further includes a retransmission control unit, which is used to initiate a retransmission at an initial time interval when the difference repair message fails to be reported, and to increment the initial time interval by twice after each failure as the retransmission time interval until the retransmission is successful or the retransmission time interval reaches a preset maximum time interval.

[0018] Preferably, the state synchronization module further includes a collaborative verification unit, configured to wait to receive the response difference message after sending the state difference message, and resend the state difference message if the waiting time exceeds a preset time, until the response difference message is received or the number of times the state difference message is resent reaches a preset number. And if the response difference message is not received after the preset number of resend attempts, both the current expected state and the actual state of the device are set to offline.

[0019] Preferably, the IoT device side and the IoT system side transmit messages through a QoS enhanced transmission channel.

[0020] The above technical solution has the following advantages or beneficial effects: 1) Breaking down state isolation barriers: The IoT system generates state difference messages by listening to device state change events in real time. After establishing a connection, the device actively obtains the messages and responds with the difference messages, forming a two-way data channel where the system sends out and the device responds. This allows the business system to quickly obtain the real state of the device through the system, completely breaking down the data isolation between the device connection layer and the business layer, and realizing direct linkage of state information. 2) Significantly reduce synchronization costs: Difference messages are generated only when the current expected state is inconsistent with the previous actual state. An event-driven mode is used to replace the traditional timed full synchronization. Compared with full synchronization, which requires periodic transmission of all device status data, this invention only transmits the difference information of state changes, effectively reducing network bandwidth consumption and reducing the system-side computing resource occupation, thus significantly reducing resource costs in the synchronization process. 3) Eliminate timing deviation problems: The IoT system ensures state consistency under the distributed architecture by adjusting the closed-loop process of actual state, dual-state consistency verification, and synchronization of expected state. Even if there is a message transmission delay, the dual-state verification process will force the synchronization of expected and actual states to avoid the same device state from diverging on different nodes, thus completely solving the timing deviation problem caused by the distributed architecture. 4) The state comparison calculation is moved to the device side, and the system side is only responsible for bi-state verification and synchronization, which effectively reduces the computing pressure on the cloud; 5) It can be compatible with different deployment architectures (cross-cloud platforms, self-built platforms), improving system applicability. Attached Figure Description

[0021] Figure 1 A schematic diagram of the structure of an IoT device state synchronization system based on event-driven and dual-state verification, which is a preferred embodiment of the present invention; Figure 2 In a preferred embodiment of the present invention, a schematic diagram of the state synchronization process when the state synchronization module is deployed in the device connection layer is provided. Figure 3 In a preferred embodiment of the present invention, a schematic diagram of the state synchronization process is shown when the state synchronization module is deployed in a business system that is communicatively connected to the device connection layer. Figure 4 In a preferred embodiment of the present invention, a schematic diagram of the state repair process when the device connection layer considers the current device to be online is provided. Figure 5 In a preferred embodiment of the present invention, a schematic diagram of the state repair process when the current device is in an offline state is provided. Detailed Implementation

[0022] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0023] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, an IoT device state synchronization system based on event-driven and dual-state verification is provided, such as... Figure 1 As shown, it includes: IoT system side 1 is used to record the state of the corresponding IoT device as the current expected state based on the device state change event monitored in real time, and then generate a state difference message when the current expected state is inconsistent with the actual state of the device obtained last time. IoT device side 2 is used to obtain state difference messages when establishing a communication connection with IoT system side 1, and generate a response difference message containing the current actual state when the current expected state contained in the state difference message is inconsistent with its own current actual state. The IoT system side 1 is also used to adjust the actual state of the device to the current actual state based on the response difference message, and then perform a dual-state consistency check to synchronize the current expected state to the current actual state.

[0024] Specifically, conventional IoT devices only maintain their own state and do not maintain their mapped state within the IoT system. In this case, the IoT system needs to determine the state of all devices by detecting heartbeat packets from all devices. Due to resource overhead, this heartbeat is typically designed to occur every 1 to 3 minutes, meaning that when the business system operates on a single device, there is theoretically a 1 to 3 minute delay. Similarly, when the business system needs to obtain statistical information or perform batch operations on all devices in their offline state, the delay can lead to data errors and operational failures. Furthermore, for the business system, both event-based (asynchronous, one-time, with the possibility of data loss) and query-based (synchronous, polling, with huge resource overhead) state synchronization methods between the IoT system and the business system have certain limitations. Therefore, this invention shifts the calculation of maintaining device state to the device side. In addition to knowing its own state, the device must also know its state within the IoT system. When a difference occurs (IoT system: offline, device: online), a difference message can be directly reported for modification. This allows IoT systems to quickly detect changes, and business systems do not need to maintain a separate set of state data. When needed, they can directly obtain the state from the IoT system to maintain low-latency, low-consumption state synchronization services.

[0025] More specifically, in this embodiment, the IoT system side 1 senses device state changes in real time and generates difference instructions, breaking down the data isolation barriers of traditional systems. The IoT system side 1 replaces timed full synchronization with an event-driven model, triggering subsequent processes only when the device state changes, significantly reducing network bandwidth and computing resource consumption. When the IoT system side 1 records the current desired state based on the monitored state change events and finds that it is inconsistent with the previous actual device state, it generates a state difference message containing key difference information, ensuring accurate difference positioning and avoiding misjudgments of state due to timing chaos.

[0026] The IoT device-side 2, acting as a terminal for state awareness and proactive repair, overcomes the limitation of traditional devices that only know their own state and cannot perceive the system state. When establishing a communication connection, the IoT device-side 2 proactively acquires the difference messages sent by the IoT system-side 1. Through local dual-state comparison—comparing the system's current expected state with the device's actual state—it accurately identifies state conflicts and generates response difference messages. This device-side proactive verification design shifts state maintenance calculations to the device, reducing the computational burden on the IoT system-side 1, while achieving second-level response to differences and keeping state repair latency within 3 seconds.

[0027] After receiving a response difference message from IoT device 2, IoT system 1 first updates the actual device state to the current true value, and then synchronizes the expected state through a two-state consistency check to ensure that the expected state is completely consistent with the actual state. This closed-loop process completely solves the timing inconsistency problem in distributed architecture, makes the system-side state view unified and accurate, and significantly reduces the device state misjudgment rate.

[0028] Furthermore, the present invention can be adapted to various deployment scenarios, specifically including: 1. Cross-platform deployment: Status difference messages and response difference messages adopt a standardized format, supporting interface adaptation of mainstream cloud platforms such as AWS IoTCore, Azure IoT Central, and Alibaba Cloud IoT, allowing for quick access without modifying core logic; 2. Self-built platform deployment: The interaction logic between the system side and the device side does not depend on a specific underlying architecture and can be directly deployed on the enterprise's self-built MQTT cluster or private cloud environment. Only the transmission channel parameters need to be adjusted for adaptation. 3. Hybrid deployment scenarios: Supports the deployment of some modules on the system side (such as the state synchronization unit) in the cloud and some on local edge nodes, while maintaining a unified response logic on the device side, flexibly responding to the deployment needs of different scenarios.

[0029] This high degree of compatibility allows the system to be integrated into existing IoT architectures without reconstruction, significantly reducing transformation costs and enhancing the feasibility and promotional value of the technical solution.

[0030] The aforementioned expected state refers to the device and its status maintained by the business system, reflecting the business system's expectations for the device's status. The aforementioned actual state refers to the real operating status actively reported by the device, reflecting the actual operating condition of the device. By comparing the two states in real time, state deviations can be directly located, avoiding reliance on indirect judgments based on heartbeat packets.

[0031] In a preferred embodiment of the present invention, the IoT system side 1 includes a device connection layer 11 and a status synchronization module 12. The device connection layer 11 is used to monitor device status change events in real time and push them to the status synchronization module 12. The state synchronization module 12 is used to record the state of the corresponding IoT device as the current desired state based on the device state change event.

[0032] Specifically, in this embodiment, the aforementioned device status change event can be either a change in the IoT device's state from online to offline, or a change in its state from offline to online. Taking a change in device status from online to offline as an example, the corresponding device status change event includes, but is not limited to, any of the following: 1) The device actively sends a disconnection request; 2) An I / O error or network failure occurred during device connection; 3) Device Keep-Alive heartbeat timeout (timeout threshold is configurable); 4) The device connection layer actively closes the device connection.

[0033] Once the event acquisition module in the device connection layer 11 captures any of the above events, it immediately pushes the offline event to the status synchronization module 12.

[0034] Among them, based on the flexibility of the device connection layer, two deployment methods are provided: Deployment Method 1: The status synchronization module 12 is deployed on the device connection layer 11.

[0035] This deployment method is suitable when the device connection layer is self-developed or provides a relatively flexible integration method. Only one state synchronization service needs to be developed to complete the overall system adaptation.

[0036] Deployment Method 2: The status synchronization module 12 is deployed in the business system 13, which is connected to the device connection layer 12. The device connection layer 12 pushes the device status change events monitored in real time to the business system 13, and then pushes them to the status synchronization module 12 through the business system 13.

[0037] This deployment method is suitable for situations where the integration of certain device connection services is not very flexible and cannot provide a separate integration path for the state synchronization service. In such cases, the state synchronization service can be used as a basic sub-service of the business system, and the entire link can be completed through data forwarding and hopping of communication channel information between the business system and the device connection layer.

[0038] Based on different deployment methods, the IoT system side 1 provides two implementation schemes for synchronizing the current desired state in response to device state change events: Implementation Method 1 (Recommended): Applicable to deployment method one, such as Figure 2 As shown, the specific state synchronization process is as follows: 1) The device connection layer publishes a device state change event (such as an offline event) and calls the update_device_state("offline") method to push the device state change event to the state synchronization module 12; 2) The state synchronization module 12 marks the current desired state of the IoT device as offline.

[0039] Implementation Method Two (Compatible Solution): Applicable to deployment method two, such as Figure 3 As shown, the specific state synchronization process is as follows: 1) The device connection layer cannot communicate directly with the status synchronization module 12, and can only send device offline notifications to the business system; 2) After receiving the notification, the business system forwards the device offline command to the status synchronization module 12; 3) The status synchronization module 12 updates the device's expected status to offline.

[0040] After updating the current expected state, the difference processing stage begins. Specifically, the state synchronization module 12 performs a dual-state comparison and generates a state difference message when the current expected state is inconsistent with the previously obtained actual device state.

[0041] In a preferred embodiment of the present invention, the status difference message includes the device number of the corresponding IoT device, the current expected status, and the actual status of the device, as shown in the following example format: JSON { deviceId, expectedState, lastActualState}; This status difference message can be sent in any of the following ways: a) Active push notification when the device comes online (Topic: / device / {id} / state / update); b) Broadcast of the cloud status channel subscribed to by the device.

[0042] After receiving the state difference message, the IoT device side 2 performs the state repair phase through the state synchronization engine 14. In a preferred embodiment of the present invention, the IoT system side 1 also includes the state synchronization engine 14. The state synchronization module 12 is also used to adjust the actual state of the device to the current actual state according to the response difference message, and then generate a consistency verification signal. The state synchronization engine 14 is used to perform a bi-state consistency check between the current expected state and the actual state of the device based on the consistency check signal, so as to synchronize the current expected state with the current actual state.

[0043] Specifically, in this embodiment, there are two repair methods for different states of IoT device 2: Repair Method 1: This applies when the device connection layer considers the device to be online, but the last message received from the device indicates it is offline. In such cases, if... Figure 4 As shown, the device connection layer can immediately generate a status difference message and send it to the device. In this case, if the device is actually offline, it will not receive the message and cannot complete the data repair. The status synchronization module can perform a timeout repair and update the status to offline. If the device is actually online, it can report its actual status in seconds. The status synchronization module updates the device's actual status to online, and then triggers a consistency check. The status synchronization engine 14 performs a consistency check between the expected state and the actual state to ensure that the expected state and the actual state are completely consistent, avoiding status distortion caused by a single link failure.

[0044] Repair Method Two: This applies when the device connectivity layer perceives the device as offline. In this case, the device connectivity layer pushes an offline message to the state synchronization service. The state synchronization service then sends the current difference (state synchronization service: current state is offline; device state record in the state service: current state is online) to the device. If the device's actual state is offline, it will not receive this message. If the device's actual state is online, it will immediately detect the error in the state service and report the message, completing state repair within seconds. Furthermore, even if the device is currently offline, when the device comes back online, if... Figure 5 As shown, the device will immediately and proactively synchronize its current status with the cloud. If it finds that the current status in the status synchronization service is offline, it will immediately perform repairs.

[0045] Since the status difference message includes the current expected state and the actual state of the corresponding IoT device, the IoT device can quickly locate the source of the difference based on the actual state: if the system's current expected state (offline) is inconsistent with the historical actual state (online), and its current actual state is still online, it can be clearly determined that the system mistakenly changed the expected state, rather than the device's state fluctuating, thus accurately triggering proactive repair. This effectively avoids the situation where the status difference message only contains the current expected state, causing the device to not know why the system changed the expected state to offline, whether it was a system misjudgment (such as heartbeat loss) or whether the device's last reported actual state was indeed offline (such as the device briefly losing network connection).

[0046] Furthermore, the state difference message only needs to simply compare the current state of the current device in the state synchronization service and the state of the device itself, and perform data repair or difference message generation as needed. For example, the state synchronization service thinks the device is offline {"desired":{"online":false}}, and the device finds that it is currently online and the state synchronization service thinks it is offline: {"report":{"online":True}}), which reduces the time complexity of the difference message generation algorithm to O(1).

[0047] Based on this, IoT device 2 generates a response difference message when the current expected state contained in the confirmation state difference message is inconsistent with the actual state of the device and the current expected state is inconsistent with its own current actual state.

[0048] In a preferred embodiment of the present invention, the state synchronization module 12 includes a state confirmation unit 121, which is used to generate a synchronization request containing the current desired state and send it to the IoT device side 2 when the device state change event is an offline event, and the current desired state is offline. The IoT device side 2 also includes a status repair unit 21, which generates a difference repair message and reports it to the IoT system side 1 when a synchronization request is received; The difference repair message includes its own real-time device status, and the real-time device status is online; The state synchronization module 12 is also used to adjust the current desired state to the real-time device state based on the difference repair message.

[0049] Specifically, in this embodiment, when the device connection layer detects an offline event, the status confirmation unit of the status synchronization module sends a synchronization request containing the desired offline status. If the device is actually online (e.g., due to a misjudgment caused by a weak network), the device-side status repair unit immediately generates a difference repair message containing the real-time online status and reports it. Upon receiving this message, the system quickly adjusts the desired status to online, achieving self-healing from misjudgment. This mechanism effectively solves the problem of offline misjudgment caused by heartbeat loss in a weak network environment and effectively improves the accuracy of device online status identification.

[0050] In a preferred embodiment of the present invention, the IoT device side 2 further includes a retransmission control unit 22, which is used to initiate a retransmission at an initial time interval when the difference repair message fails to be reported, and to use the retransmission time interval as a doubling of the initial time interval after each failure, until the retransmission is successful or the retransmission time interval reaches a preset maximum time interval.

[0051] Specifically, in this embodiment, the initial time interval is preferably 1 second, and the interval increases by 2 times after each failure until the maximum time interval, such as 60 seconds. This strategy ensures that differential repair messages are not lost in weak network environments, avoids network congestion caused by frequent retransmissions, balances transmission reliability and resource consumption, and effectively improves the retransmission success rate.

[0052] In a preferred embodiment of the present invention, the state synchronization module 12 further includes a collaborative verification unit 122, configured to wait for receiving a response difference message after sending a state difference message, and resend the state difference message if the waiting time exceeds a preset time, until a response difference message is received or the number of times the state difference message is resent reaches a preset number. And if no response difference message is received after the preset number of resends, both the current expected state and the actual state of the device will be set to offline.

[0053] Specifically, in this embodiment, after the collaborative verification unit 122 of the IoT system side 1 sends a difference message, it expects the IoT device side 2 to respond to the difference message within a valid time to make the two states consistent. If no response is received after a preset time, the message will be resent until a preset number of attempts are reached. For example, when desired:online:True, report:online:False, it is preferable to attempt to repair three time segments. If the device-reported data still cannot be obtained after three attempts, the following setting is applied: desired:online:False,report:online:Fals; When `desired:online:False` and `report:online:True`, attempt to repair three time segments. If there is still no response, default to the device being offline, setting both the desired and actual states to offline. desired:online:False, report:online:False.

[0054] This mechanism avoids resource consumption caused by infinite waiting on the system side, while ensuring the accuracy of offline status judgment, reducing invalid command issuance, and improving system resource utilization.

[0055] In a preferred embodiment of the present invention, message transmission is performed between the IoT device side 2 and the IoT system side 1 through a QoS enhanced transmission channel.

[0056] Specifically, in this embodiment, IoT device 2 and IoT system 1 transmit messages through a QoS-enhanced transmission channel, employing differentiated QoS levels for different message types: differentiated messages (including status-different messages and response-different messages) use QoS level 1 (at least one transmission) to ensure that critical status data is not lost; non-core data such as heartbeat packets use QoS level 0 (best-effort transmission) to save transmission resources. Simultaneously, the channel supports a TCP retransmission mechanism, further improving message transmission reliability and significantly reducing the loss rate of critical messages.

[0057] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. An IoT device state synchronization system based on event-driven and dual-state verification, characterized in that, include: On the IoT system side, it is used to record the status of the corresponding IoT device as the current expected status based on the real-time monitored device status change events, and then generate a status difference message when the current expected status is inconsistent with the previously obtained actual device status. On the IoT device side, it is used to obtain the state difference message when establishing a communication connection with the IoT system side, and generate a response difference message containing the current actual state when the current expected state contained in the state difference message is inconsistent with its own current actual state. The IoT system side is also used to adjust the actual state of the device to the current actual state according to the response difference message, and then perform a dual-state consistency check to synchronize the current expected state to the current actual state.

2. The IoT device status synchronization system according to claim 1, characterized in that, The IoT system side includes a device connection layer and a status synchronization module. The device connection layer is used to monitor the device status change events in real time and push them to the status synchronization module. The state synchronization module is used to record the state of the corresponding IoT device as the current desired state based on the device state change event.

3. The IoT device status synchronization system according to claim 2, characterized in that, The state synchronization module is deployed in the device connection layer.

4. The IoT device status synchronization system according to claim 2, characterized in that, The state synchronization module is deployed in a business system that communicates with the device connection layer. The device connection layer pushes the device status change events it monitors in real time to the business system, and then pushes them to the status synchronization module through the business system.

5. The IoT device status synchronization system according to claim 1, characterized in that, The status difference message includes the device number of the corresponding IoT device, the current expected status, and the actual status of the device. The IoT device generates the response difference message when it confirms that the current expected state contained in the state difference message is inconsistent with the actual state of the device and that the current expected state is inconsistent with its own current actual state.

6. The IoT device status synchronization system according to claim 2, characterized in that, The IoT system side also includes a state synchronization engine. The state synchronization module is also used to adjust the actual state of the device to the current actual state according to the response difference message, and then generate a consistency verification signal. The state synchronization engine is used to perform a bi-state consistency check between the current expected state and the actual state of the device based on the consistency check signal, so as to synchronize the current expected state with the current actual state.

7. The IoT device status synchronization system according to claim 2, characterized in that, The state synchronization module includes a state confirmation unit, which is used to generate a synchronization request containing the current desired state and send it to the IoT device side when the device state change event is an offline event, and the current desired state is offline; The IoT device side also includes a status repair unit, which generates a difference repair message and reports it to the IoT system side when the synchronization request is received. The difference repair message contains its own real-time device status, and the real-time device status is online; The state synchronization module is also used to adjust the current desired state to the real-time device state according to the difference repair message.

8. The IoT device status synchronization system according to claim 7, characterized in that, The IoT device side also includes a retransmission control unit, which is used to initiate a retransmission at an initial time interval when the difference repair message fails to be reported, and to use the initial time interval as the retransmission time interval by doubling after each failure, until the retransmission is successful or the retransmission time interval reaches a preset maximum time interval.

9. The IoT device status synchronization system according to claim 6, characterized in that, The state synchronization module further includes a collaborative verification unit, which, after sending the state difference message, waits to receive the response difference message, and if the waiting time exceeds a preset time, resends the state difference message until the response difference message is received or the number of times the state difference message is resent reaches a preset number. And if the response difference message is not received after the preset number of resend attempts, both the current expected state and the actual state of the device are set to offline.

10. The IoT device status synchronization system according to claim 1, characterized in that, The IoT device side and the IoT system side transmit messages through a QoS-enhanced transmission channel.

Images