A device automatic registration and data communication method for a thing internet station

Abstract

The application relates to a device automatic registration and data communication protocol for an Internet of Things data center. After the device is started, an automatic registration request is sent to the data center. The data center checks the authentication information of the device and, after verification, registers the device information, then allocates an access endpoint to the device, and feeds back the endpoint information to the device. After the device accesses the endpoint, the device sends login, time synchronization and topology messages to the data center in sequence, and then reports real-time state of the device or second-level monitoring data to the data center at fixed time intervals. When an alarm or an event is triggered, the device can report to the data center according to actual conditions, and a user can also send instructions to the device through the data center to operate or remotely debug and upgrade the device. The application standardizes device communication and realizes decoupling between business modules of the Internet of Things data center, thereby reducing development and operation and maintenance costs of the data center and the device.

Description

Technical Field

[0001] This invention relates to the field of power Internet of Things (IoT) technology, and in particular to an automatic device registration and data communication protocol for an IoT middleware platform. Background Technology

[0002] The goal of an IoT data platform is to build a complete software and hardware ecosystem based on data, providing a unified device access method at the lower level and the ability to agilely build scenario, industry, and regional solutions based on data and services at the upper level. When connecting a large number of devices, the IoT data platform urgently needs an automatically initiated registration process by the devices to reduce the cost of device access. At the same time, it needs to abstract and classify the communication scenarios between devices and the data platform to form a standard communication protocol, reducing the development difficulty of the data platform and devices. In high-concurrency scenarios with a large number of devices connected, it should ensure the security and reliability of low-frequency data, avoid data loss, and support high-frequency data uploads. Summary of the Invention

[0003] The purpose of this invention is to overcome the above-mentioned shortcomings and provide an automatic device registration and data communication protocol for an IoT data platform. This protocol standardizes device communication, decouples the business modules of the IoT data platform, and reduces the development and maintenance costs of the data platform and devices.

[0004] The objective of this invention is achieved as follows: An automatic device registration and data communication protocol for an IoT data platform includes an automatic registration process when a device connects to the IoT data platform and a data communication protocol between the data platform and the device. The automatic registration process includes the following: When a new device model needs to connect to the IoT data platform, the device model must first be created in the data platform. The data platform will generate a unique product code and authentication key for this model. During device production, the product code, authentication key, and unique serial number of the device are written into each device. After the device starts up, it automatically sends a registration request to the designated service of the data platform. The data platform verifies whether the product number and authentication key exist. If they exist, the data platform registers the serial number of this device in the data platform and assigns an endpoint to access the data platform for this device according to the load balancing strategy. Then, the endpoint information is fed back to the device, enabling it to connect to the data platform and continue the subsequent data reporting process. The endpoint information includes the device's IP address, port, and authorization authentication information for connecting to the data platform. Otherwise, a failure message is fed back to the device, and the device is prohibited from connecting. The data communication protocol includes the following: After the device starts up, it first sends an automatic registration request to the data platform. After authentication, the device connects to the endpoint of the data platform and sends login, time synchronization, and topology messages in sequence. Then, the device begins to periodically report real-time data or second-level monitoring data to the data platform. When the device triggers an alarm or event, it needs to report the corresponding message to the data platform. At the same time, the device needs to receive operation instructions or debugging and upgrade messages from the data platform, process them, and feed the results back to the data platform. The data platform will also determine whether the device is offline based on the device's communication status. When a device is determined to be offline, the data platform will send an offline message to notify each business module that the device is offline.

[0005] Furthermore, the data communication protocol includes general functions such as login, time synchronization, and topology reporting. The device login process is as follows: After the device connects to the data platform, it sends a login message to the platform, which includes the device's firmware version, network connection method, encryption / compression status, and related algorithms. Upon receiving the message, the data platform updates the information in its database and sends a confirmation reply to the device. The device time synchronization process is as follows: The device sends a time synchronization message to the data platform. Upon receiving the message, the data platform generates a reply, attaching the device's time zone information, and sends it back to the device. After receiving the reply, the device calculates the current precise time and writes the precise time and time zone information into its database. The device topology reporting process is as follows: The device sends a topology message to the data platform, which includes information such as the model, unique identifier, grouping details, and cascading structure of its subordinate sub-devices. Upon receiving the topology message, the data platform updates the information of each sub-device in its database and sends a confirmation reply to the device.

[0006] Furthermore, the data communication protocol includes a real-time data reporting process. After the device login, time synchronization, and topology processes are completed, real-time data is reported at fixed intervals. The real-time data includes the status of the device itself and the status of each sub-device. If the size of the data packet exceeds the limit of the network transmission module, packet uploading can be used. When splitting the packet, the packet number, the number of packets, and the sequence number should be marked in each packet to facilitate the data platform to merge the packets. If network jitter or failure occurs during transmission, causing the message to fail to be sent, the message needs to be cached in the device and re-uploaded as historical data after the network is restored. When re-uploading, the historical data needs to be reported first, and then the real-time data needs to be reported to ensure the orderliness of the message.

[0007] Furthermore, the data communication protocol includes a device-reported event alarm process. When an alarm or event occurs on the device, it can upload an alarm or event message containing an alarm code or event code and related data information. After receiving the alarm message, the data platform generates a corresponding alarm or event record based on the alarm code / event code and sends a confirmation reply to the device.

[0008] Furthermore, the data communication protocol includes a process for sending operation commands. When a user wants to send an operation command to a device through the data platform, the data platform first caches the command, then sends a message to the device. After receiving the message, the device executes the command and replies with the result to the data platform. After the data platform receives the reply message, it displays the execution result to the user.

[0009] Furthermore, during device operation, if a user needs to remotely debug or upgrade the firmware of the device through the data platform, they can send a debugging or upgrade message to the device. The device can also actively request an upgrade from the platform. Debugging and upgrading include the following message types: push device upgrade, device actively requests upgrade, obtain device firmware version information, restart device, read / modify device setting parameters, port listening, read device topology information, read real-time data / historical data, and synchronize configuration files.

[0010] Furthermore, the data communication protocol includes a second-level monitoring data flow. When users need to monitor the device status with high precision, they can configure a high-frequency data upload mode on the device side. After receiving the message, the data platform parses it and determines that it is a second-level monitoring message. Then, it does not reply with a confirmation message to the device, but only receives, parses, and stores the data.

[0011] Furthermore, the data communication protocol includes an offline message generation process. When a device is connected to the data platform, the data platform will periodically determine whether the device is offline. When the data platform determines that the device is offline, it will send an offline message on behalf of the device to notify each business module that the device is offline. This will trigger the device status change cached by the data platform and forward it to the application platform to trigger offline alarms and other business processes.

[0012] Furthermore, there are two ways to determine whether a device is offline: For short-connection devices, such as HTTP: The data platform periodically checks whether the time since the last received device message exceeds two reporting cycles; if it does, the device is considered offline. For long-connection devices, such as TCP, MQTT, and AMQP: The data platform periodically sends heartbeat packets to the device. If the device fails to respond to the heartbeat packet twice consecutively, the data platform will actively disconnect the long connection and determine that the device is offline.

[0013] Furthermore, when a device is limited by network conditions and cannot directly connect to the data platform, an M2M communication proxy can be set up between the device and the data platform. The M2M communication proxy is set up on a cloud server or bastion host and is responsible for simultaneously connecting the device and the data platform, forwarding the messages sent by the data platform or device to the receiver, and then forwarding the receiver's reply to the sender.

[0014] Compared with the prior art, the beneficial effects of the present invention are: This invention provides an automatic device registration and data communication protocol for an IoT middleware platform. Upon startup, a device sends an automatic registration request to the middleware platform. After verifying the device's authentication information and passing the verification, the middleware platform registers the device information, assigns an access endpoint to the device, and feeds back the endpoint information to the device. Once connected to the endpoint, the device sequentially sends login, time synchronization, and topology messages to the middleware platform. It then reports its real-time status or second-level monitoring data to the middleware platform at fixed time intervals. When an alarm or event is triggered, the device can report to the middleware platform according to the actual situation. Users can also issue commands to the device through the middleware platform for operation, or remotely debug and upgrade the device. When the middleware platform periodically determines that a device is offline according to a certain method, it will send an offline message to notify each business module. When the device and the middleware platform cannot connect directly due to network environment limitations, an M2M communication proxy can be established to connect both the device and the middleware platform and forward messages between them, enabling indirect communication between the device and the middleware platform.

[0015] This invention provides a complete solution for device access to an IoT data platform, enabling device development to follow a unified communication protocol, improving the efficiency and reliability of communication between devices and the data platform. Automatic device registration also reduces maintenance costs when devices connect to the platform. This invention streamlines and abstracts the business processes of the data platform, reducing its development difficulty and yielding significant economic and social benefits. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the automatic device registration process for the IoT data platform of the present invention.

[0017] Figure 2 This is a schematic diagram illustrating the process of data communication between the IoT data platform and devices according to the present invention.

[0018] Figure 3 This is a schematic diagram of the device login process of the present invention.

[0019] Figure 4 This is a schematic diagram of the time synchronization process of the device according to the present invention.

[0020] Figure 5 This is a schematic diagram of the device reporting topology process of the present invention.

[0021] Figure 6 This is a schematic diagram of the real-time data reporting process of the device according to the present invention.

[0022] Figure 7 This is a schematic diagram of the device reporting event alarm process of the present invention.

[0023] Figure 8 This is a schematic diagram of the data platform sending operation instructions according to the present invention.

[0024] Figure 9 This is a schematic diagram of the data platform push device upgrade process of the present invention.

[0025] Figure 10 This is a schematic diagram of the device actively requesting an upgrade process according to the present invention.

[0026] Figure 11 This is a schematic diagram of the process by which the data platform of the present invention obtains device firmware information.

[0027] Figure 12 This is a schematic diagram of the data platform restart process of the present invention.

[0028] Figure 13 This is a schematic diagram of the data platform reading / modifying device parameter settings process of the present invention.

[0029] Figure 14 This is a schematic diagram illustrating the process of opening the device port monitoring function in the data platform of the present invention.

[0030] Figure 15 This is a schematic diagram of the process of reading device topology information by the data platform of the present invention.

[0031] Figure 16 This is a schematic diagram of the real-time / historical data reading process of the data platform reading device of the present invention.

[0032] Figure 17 This is a schematic diagram of the data platform and device synchronization configuration file process of the present invention.

[0033] Figure 18 This is a schematic diagram of the device reporting second-level monitoring data flow according to the present invention.

[0034] Figure 19 This is a schematic diagram illustrating the offline message generation process of the data platform in this invention.

[0035] Figure 20 This is a schematic diagram of the M2M communication agent operation process of the present invention. Implementation

[0036] To better understand the technical solution of the present invention, a detailed description will be provided below in conjunction with relevant illustrations. It should be understood that the specific embodiments described below are not intended to limit the specific implementation of the technical solution of the present invention, but are merely possible implementations of the technical solution of the present invention. It should be noted that the descriptions of the positional relationships of the components herein, such as component A being located above component B, are based on the relative positions of the components in the illustrations and are not intended to limit the actual positional relationships of the components. Example 1

[0037] See Figure 1-20 , Figure 1A schematic diagram of the automatic device registration process for the IoT data platform of the present invention is shown. As illustrated, the present invention relates to an automatic device registration and data communication protocol for an IoT platform, including an automatic device registration process and a device data communication protocol. The automatic device registration process includes the following: When a new device model needs to be connected to the IoT data platform, the device model and the basic communication protocol used for connection must first be registered in the data platform. The basic communication protocol includes, but is not limited to, common protocols such as TCP, HTTP, MQTT, and AMQP. The data platform has multiple access endpoints, each using a different IP address, port number, or domain name. Each access endpoint corresponds to only one protocol, but the same basic communication protocol can have multiple access endpoints. The data platform will generate a unique product code and authentication key for the model. Hardware R&D personnel will write the product code and authentication key into the device firmware, and the device serial number will be written into each device during production.

[0038] Upon each startup, the device first sends a registration request to the data platform. The request includes three pieces of authentication information: product code, authentication key, and device serial number. After receiving the request, the data platform verifies the product code and authentication key to determine whether the device model is allowed to access the data platform. If the verification is successful, the data platform assigns an access endpoint to the device based on the basic communication protocol of the model registered in the data platform and a certain load balancing strategy, and feeds back the endpoint information to the device. The endpoint information includes the IP address, port or domain name of the platform receiving messages, as well as authentication information such as account password or token. If the verification fails, the device authentication fails.

[0039] After receiving the endpoint information, the device stores the authentication information in the device and then connects to the endpoint to report data.

[0040] See Figure 2 , Figure 2 A schematic diagram illustrating the data communication process between the IoT data platform and devices according to the present invention is provided. As shown in the figure, the data communication protocol is an abstraction of business scenarios. The data communication protocol of the present invention includes eight scenarios: general functions, real-time data, operation instructions, event alarms, offline messages, second-level monitoring, debugging and upgrades, and M2M communication proxy. Most data communication between the device and the data platform adopts a question-and-answer method. After each message is sent, the receiver must reply with an acknowledgment message. The process is only considered complete when the sender receives the acknowledgment message. If the sender does not receive a reply within a certain period of time (e.g., 30 seconds), it means that the message may have been lost and needs to be resent until the other party confirms. This is to avoid message loss due to network jitter, link failure, etc.

[0041] The general functions of data communication protocols include device login, time synchronization, and topology procedures. See Figure 3 , Figure 3 This is a schematic diagram of the device login process of the present invention. As shown in the figure, the device login process includes the following: After the device connects to the endpoint of the data platform, it first sends a login message to the data platform, which includes the device's firmware version, network connection method, whether it is encrypted, compressed, and related algorithms. After receiving the message, the data platform updates the device information in the database and sends a confirmation message back to the device.

[0042] See Figure 4 , Figure 4 This is a schematic diagram of the device time synchronization process of the present invention. As shown in the figure, the device time synchronization process includes the following: After receiving the confirmation, the device sends a communication message to the data platform, which includes the device's sending timestamp DeviceSend. Upon receiving the message, the data platform adds the server's received timestamp ServerRecv, the server's reply timestamp ServerSend, and the device's time zone information to the message sent by the device. Then, it replies to the device. When the device receives the reply, it obtains the local timestamp DeviceRecv, calculates the precise timestamp, parses the time zone information in the reply, calculates the local time of the device's time zone, and writes it into the device's clock chip.

[0043] The formula for calculating an accurate timestamp is as follows, which can minimize time errors caused by network latency between the device and the server: Precise timestamp = (Server received + Server replied + Device received replied - Device sent) / 2; During equipment operation, it needs to synchronize with the data platform every 24 hours to avoid the problem of clock errors gradually increasing as the equipment runs longer.

[0044] See Figure 5 , Figure 5 This is a schematic diagram of the device topology reporting process according to the present invention. As shown in the figure, the device topology reporting process includes the following: The device sends a topology message to the data platform. The message includes information such as the model and unique identification number of the sub-devices under the device, as well as the cascading structure. After receiving the topology message, the data platform automatically stores the sub-device information and topology structure of the device into the database, and then replies with a confirmation message to the device. At this point, the login process after the device connects to the data platform endpoint ends.

[0045] See Figure 6 , Figure 6 This is a schematic diagram of the real-time data reporting process of the device according to the present invention. The real-time data reporting process of the device includes the following: After device login, time synchronization, and topology procedures are completed, real-time data is reported to the data platform at fixed intervals. Real-time data includes the latest status information of the device itself and each sub-device. The sub-device information needs to be distinguished according to the unique identifier reported in its topology. Upon receiving the data, the data platform replies with a confirmation message to the device and distributes the message to the data cleaning module for cleaning. Then, it distributes the message to various business modules for processing, such as: caching the latest device status, streaming computing, predictive analysis, historical curve recording, log storage, alarm driver, and data subscription.

[0046] If the device experiences network jitter or failure during transmission and cannot send messages, all messages after the network failure should be cached in chronological order and uploaded as historical messages after the network is restored. When re-uploading, the historical messages should be reported first, and then the real-time messages should be reported to ensure the orderliness of the messages.

[0047] If a device has many subordinate devices or each sub-device uploads many attributes, causing the data packet size to exceed the device's network transmission module limit when uploading all attributes of all sub-devices at once, a packet-splitting upload method can be used. The logic of packet splitting is to divide the data according to sub-devices, or to split the attributes of the same sub-device into multiple packets for reporting, and to label each packet with a message number, the number of packets, and the packet sequence number. This means splitting occurs during packet assembly, rather than directly assembling all data into one packet and then truncating the packet by length. This facilitates packet merging by the data platform and avoids the loss or corruption of any packet, which could render the entire message unusable. The message number represents the unique identifier of this message, and the message numbers of all packets after splitting must remain consistent. The number of packets indicates how many packets this message is divided into for uploading. The packet sequence number indicates which packet is currently being transmitted. When the data platform receives the split data, it merges the packets according to the following logic: Packet sequence number 1 indicates the first packet, which is cached in the data middleware and awaits subsequent packets. When the packet sequence number is greater than 1, it is necessary to try to retrieve the previous message from the cache and merge it into a new message. At this time, if the packet sequence number is the same as the number of packets, it means that it is the last packet, and the packet merging should be ended and the message should be sent to each business module for processing. If it is not the last packet, it should continue to be cached and wait for subsequent messages.

[0048] While the protocol design can prevent packet loss due to network failures, it cannot guarantee against packet loss caused by other failures such as power outages or restarts. Therefore, before executing the above logic, it is necessary to check the packet number in the cache. Only if it matches the currently received packet will the packets be merged. If they do not match, the cached packet needs to be distributed to the business module as data from the previous round before processing the current round of packets. Although this approach cannot guarantee the integrity of all packets, it can minimize the loss caused by packet loss, ensuring that the entire round of data cannot be parsed due to the loss of a single packet.

[0049] See Figure 7 , Figure 7 This is a schematic diagram of the device event reporting alarm process of the present invention. As shown in the figure, the device event reporting alarm process includes the following: When an alarm or event occurs on the device and needs to be reported, the device can report it through an alarm or event message. The message contains the alarm code or event code, as well as related data information. After receiving an alarm message, the data platform replies with a confirmation message to the device and queries relevant information based on the alarm code to determine whether to simply generate an alarm record or to set the device status to alarm. If the device status is set to alarm, the device needs to report an alarm recovery message for recovery, or the user can manually clear the alarm status in the data platform.

[0050] After receiving the event message, the data platform replies with a confirmation message to the device and distributes the event message to the corresponding business module according to the event processing rules, triggering its business processing flow.

[0051] See Figure 8 , Figure 8 This is a schematic diagram illustrating the process of sending operation instructions to the data platform of the present invention. As shown in the figure, the operation instruction process includes the following: When a user sends an operation command to a device through the data platform, the data platform first caches the command, then sends a message to the device. After receiving the message, the device executes the command and sends the result back to the data platform. Once the data platform receives the reply message, it displays the execution result to the user.

[0052] See Figures 9-17 To facilitate the debugging and upgrade process, during device operation, if a user needs to remotely debug or upgrade the firmware of the device through the data platform, they can send a debugging or upgrade message to the device. The device can also proactively request an upgrade from the platform. Debugging and upgrades include the following message types: push device upgrade, device proactively request upgrade, obtain device firmware version information, restart device, read / modify device settings parameters, port listening, read device topology information, read real-time data / historical data, and synchronize configuration files.

[0053] See Figure 9 , Figure 9 This is a schematic diagram of the data platform push device upgrade process of the present invention. As shown in the figure, the push device upgrade process includes the following: Users send upgrade messages through the data platform. The message contains the download address, size, MD5 verification code, and version number of the firmware package. If it is an upgrade of a sub-device under the device, the identification number of the sub-device is also required. After receiving the message, the device replies with confirmation, downloads the firmware, verifies the firmware, and performs the upgrade.

[0054] See Figure 10 , Figure 10 This is a schematic diagram of the device proactively requesting an upgrade process according to the present invention. As shown in the figure, the device proactively requesting an upgrade process includes the following: The device sends an upgrade request message to the data platform. The message contains the device's current firmware version. After receiving the message, the data platform compares it with the available versions in the firmware library. If there is a newer firmware, the data platform sends the latest firmware information to the device. The device then downloads the firmware and performs the upgrade.

[0055] See Figure 11 , Figure 11 This is a schematic diagram illustrating the process of obtaining device firmware information using the data platform of the present invention. As shown in the figure, the process of obtaining device firmware information includes the following: When a user needs to read the device's firmware information, they can send a message through the data platform. After receiving the message, the device will reply with the firmware information to the data platform.

[0056] See Figure 12 , Figure 12 This is a schematic diagram of the device restart process for the data platform of the present invention. As shown in the figure, the device restart process includes the following: Users send a restart message to the device through the data platform. The device first replies with a confirmation message and then restarts.

[0057] See Figure 13 , Figure 13 This is a schematic diagram of the data platform's process for reading / modifying device parameter settings according to the present invention. As shown in the figure, the process for reading / modifying device parameter settings includes the following: When a user needs to read / modify the device's parameter settings, they can send a read / write message and related parameters to the device through the data platform. After receiving the message, the device will reply with the parameter value to be read or the result of the parameter to be written.

[0058] See Figure 14 , Figure 14 This is a schematic diagram illustrating the process of enabling device port monitoring in the data platform of this invention. As shown in the figure, the port monitoring process includes the following: Users send messages through the data platform, including the port number to be listened to and the listening duration, thus enabling the device's port listening function for a period of time. The default listening duration is 15 minutes, with a maximum of 1 hour. During the listening period, the device will continuously report data from that port to the data platform, which users can view to troubleshoot issues. The device automatically disables this function after the listening time limit has expired to prevent traffic loss or security issues caused by forgetting to disable it.

[0059] See Figure 15 , Figure 15 This is a schematic diagram illustrating the process of reading device topology information using the data platform of the present invention. As shown in the figure, the process of reading device topology information includes the following: Users can send requests to devices through the data platform to read device topology information. After receiving the request message, the device will reply with the topology information to the data platform.

[0060] See Figure 16 , Figure 16 This is a schematic diagram illustrating the process of reading real-time / historical data from the data platform of the present invention. As shown in the figure, the process of reading real-time / historical data from the device includes the following: Users send messages to devices through the data platform to query the current status of the devices or the historical status within a certain period of time. The devices reply with the corresponding data to the data platform. When reading historical data, the time range needs to be passed to the devices as a parameter. The range of data that can be queried depends on the amount of historical data cached by the devices.

[0061] See Figure 17 , Figure 17 This is a schematic diagram illustrating the process of synchronizing configuration files between the data platform and devices according to the present invention. As shown in the figure, there are four ways to synchronize configuration files between the data platform and devices: (1) The data platform sends a request to the device to read the file list. After receiving the request, the device replies with the file list to the data platform. (2) The data platform requests the device to upload files to the server. After receiving the request, the device first replies with confirmation, and then uploads the files to the server in sequence. The data platform saves the received files to the configuration file space of the device, overwriting the files with the same name. (3) The data platform requests to synchronize files to the device. The message needs to include the download address of each file. After receiving the request, the device downloads each file to the device in sequence and overwrites the file with the same name on the device. (4) The data platform requests the deletion of files on the device. The message must include the file name to be deleted. After receiving the request, the device deletes each file in turn and then replies with the deletion result to the data platform.

[0062] See Figure 18 , Figure 18 This is a schematic diagram of the device reporting second-level monitoring data flow according to the present invention. As shown in the figure, the second-level monitoring flow includes the following: Second-level monitoring is used when high accuracy is required for device status monitoring. It uses a high-frequency data upload method. The format of second-level monitoring messages is basically the same as that of real-time data messages. The difference is that an attribute is added to the message to mark that the data belongs to the second-level monitoring message.

[0063] Because second-level monitoring has relatively low requirements for data reliability—only a certain level of reliability is needed, without the need for 100% delivery to the data platform—second-level monitoring messages are transmitted unidirectionally from the device to the data platform. Upon receiving a second-level monitoring message, the data platform does not need to reply with confirmation; it only needs to store or display it. The device also does not need to wait for a reply from the data platform to upload the next message, thus ensuring high-frequency data uploads.

[0064] See Figure 19 , Figure 19 This diagram illustrates the offline message generation process for the data platform of this invention. As shown, the offline message process includes the following: When a device goes offline or experiences a network failure for a certain period of time, the data platform detects the disconnection and sends an offline message on behalf of the device to notify all business modules that the device is offline. This triggers the device status change cached in the data platform and forwards the message to the application platform to trigger offline alarms and other business processes.

[0065] Because the data platform supports various basic communication protocols, the methods for determining offline status are not entirely the same. If it is a short-connection communication protocol such as HTTP, the device reporting cycle interval needs to be maintained in the data platform. The data platform periodically polls the last reporting time of such devices. If no data is received for more than 2 cycles, the data platform will send an offline message.

[0066] For devices using long-connection communication protocols such as TCP, MQTT, and AMQP, the endpoints of the data platform periodically send heartbeat packets to each connected device. The device needs to reply to indicate that it is online. If the data platform finds that a device has not replied to two consecutive heartbeat packets, it will actively disconnect the long connection with the device and send an offline message.

[0067] See Figure 20 , Figure 20 This is a schematic diagram of the M2M communication agent operation process of the present invention. As shown in the figure, the M2M communication agent operation process includes the following: In some cases, devices may not be able to connect directly to the data platform, including but not limited to the following: (1) The device uses ISP operator cellular network communication, but the data middleware server does not lease a fixed IP, so the device cannot be configured with a fixed IP for connection; (2) For network security reasons, the data middleware server and equipment are deployed in different network environments and need to communicate through a bastion host.

[0068] M2M communication proxy is a cloud-based communication solution that connects both devices and a data platform, enabling indirect communication between them. Since most data packets between the device and the data platform require a one-to-one response, long-connection communication protocols such as TCP, MQTT, and AMQP are recommended for M2M communication. However, short-connection communication protocols such as HTTP can be used when the network link between the device, M2M proxy, and data platform is stable and fast.

[0069] The M2M agent provides an access endpoint on the device side, allowing devices to directly connect to the M2M agent. Simultaneously, it provides an access endpoint for the data platform on the data platform side. When the M2M agent receives a message reported by the device or issued by the data platform, it needs to forward the message to the corresponding recipient, wait for the recipient's reply, and then forward the reply message to the sender to complete the data communication.

[0070] This invention discloses an automatic device registration and data communication protocol for an IoT data platform. Upon startup, a device sends an automatic registration request to the data platform. After verifying the device's authentication information and passing the verification, the data platform registers the device information, assigns an access endpoint to the device, and feeds back the endpoint information to the device. After connecting to the endpoint, the device sequentially sends login, time synchronization, and topology messages to the data platform. It then reports its real-time status or second-level monitoring data to the data platform at fixed time intervals. When an alarm or event is triggered, the device can report to the data platform according to the actual situation. Users can also issue commands to the device through the data platform for operation, or remotely debug and upgrade the device. When the data platform periodically determines that a device is offline according to a certain method, it will send an offline message to notify each business module. When the device and the data platform cannot connect directly due to network environment limitations, an M2M communication proxy can be established to connect the device and the data platform simultaneously and forward messages between them, enabling indirect communication between the device and the data platform.

[0071] The above are merely specific application examples of the present invention and do not constitute any limitation on the scope of protection of the present invention. All technical solutions formed by equivalent transformations or substitutions fall within the scope of protection of the present invention.

Claims

1. A method for automatic device registration and data communication in an IoT middleware platform, characterized in that: This includes the automatic registration process when devices connect to the IoT data platform, as well as the data communication protocol between the data platform and the devices. The automatic registration process includes the following: When a new device model needs to connect to the IoT data platform, the device model must first be created in the data platform. The data platform will generate a unique product code and authentication key for this model. Hardware R&D personnel write the product code and authentication key into the device firmware, and write the device serial number into each device during production. After the device starts up, it automatically sends a registration request to the designated service of the data platform. The data platform verifies whether the product number and authentication key exist. If they exist, the data platform registers the serial number of this device in the data platform and assigns an endpoint to the device to access the data platform according to the load balancing strategy. Then, the endpoint information is fed back to the device, enabling it to connect to the data platform and continue the subsequent data reporting process. The endpoint information includes the device's IP address, port, and authorization authentication information for connecting to the data platform. Otherwise, a failure message is fed back to the device, and the device is prohibited from connecting. The data communication protocol includes the following: After the device starts up, it first sends an automatic registration request to the data platform. After authentication, the device connects to the endpoint of the data platform and sends login, time synchronization, and topology messages in sequence. Then, the device begins to periodically report real-time data or second-level monitoring data to the data platform. When the device triggers an alarm or event, it needs to report the corresponding message to the data platform. At the same time, the device needs to receive operation instructions or debugging and upgrade messages from the data platform, process them, and feed the results back to the data platform. The data platform will also determine whether the device is offline based on the device's communication status. When a device is determined to be offline, the data platform will send an offline message to notify each business module that the device is offline. The data communication protocol includes general functions such as login, time synchronization, and topology reporting. Device login process: After connecting to the data platform, the device sends a login message to the platform, which includes the device's firmware version, network connection method, whether encryption is enabled, whether compression is enabled, the encryption algorithm, and the compression algorithm. Upon receiving the message, the data platform updates the information in its database and sends a confirmation reply to the device. Device time synchronization process: The device sends a time synchronization message to the data platform. Upon receiving the message, the data platform generates a reply, attaching the device's time zone information, and sends it back to the device. Upon receiving the reply, the device calculates the current precise time and writes the precise time and time zone information into the device. Device topology reporting process: The device sends a topology message to the data platform. The message includes information about its subordinate sub-devices, including their models, unique identifiers, grouping details, and cascading structure. Upon receiving the topology message, the data platform updates the information of each sub-device in its database and sends a confirmation reply to the device.

2. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: The data communication protocol includes a real-time data reporting process. After the device login, time synchronization, and topology processes are completed, real-time data is reported at fixed intervals. The real-time data includes the status of the device itself and the status of each sub-device. If the size of the data packet exceeds the limit of the network transmission module, a packet-splitting upload method should be adopted. When splitting the packet, the packet number, the number of packets, and the sequence number should be marked in each packet to facilitate the data platform to merge the packets. If network jitter or failure occurs during transmission, causing the message to fail to be sent, the message needs to be cached in the device and re-uploaded as historical data after the network is restored. When re-uploading, the historical data needs to be reported first, and then the real-time data needs to be reported to ensure the orderliness of the message.

3. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: The data communication protocol includes a device reporting event alarm process. When an alarm or event occurs on the device, it uploads an alarm or event message containing an alarm code or event code and related data information. After receiving the alarm message, the data platform generates a corresponding alarm or event record based on the alarm code / event code and sends a confirmation reply to the device.

4. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: The data communication protocol includes the process of sending operation commands. When a user wants to send an operation command to the device through the data platform, the data platform first caches the command, then sends a message to the device. After receiving the message, the device executes the command and replies with the result to the data platform. After the data platform receives the reply message, it displays the execution result to the user.

5. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: During device operation, if a user needs to remotely debug or upgrade the firmware of the device through the data platform, they can send a debugging or upgrade message to the device. The device will also actively request an upgrade from the platform. Debugging and upgrading include the following message types: push device upgrade, device actively requests upgrade, obtain device firmware version information, restart device, read / modify device settings parameters, port listening, read device topology information, read real-time data / historical data, and synchronize configuration files.

6. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: The data communication protocol includes a second-level monitoring data flow. When users need to perform high-precision monitoring of device status, they configure a high-frequency data upload mode on the device side. After receiving the message, the data platform parses it and determines that it is a second-level monitoring message. Then, it does not reply with an acknowledgment message to the device, but only receives, parses, and stores the data.

7. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: The data communication protocol includes an offline message generation process. When a device is connected to the data platform, the data platform will periodically determine whether the device is offline. When the data platform determines that the device is offline, it will send an offline message on behalf of the device to notify each business module that the device is offline. This will trigger the device status change cached by the data platform and forward the message to the application platform to trigger the offline alarm business process.

8. The method for automatic device registration and data communication for an IoT middleware platform according to claim 7, characterized in that: There are two ways to determine if a device is offline: For short-connection devices using HTTP: The data platform periodically checks whether the time since the last received device message exceeds two reporting cycles; if it does, the device is considered offline. For long-connection devices using TCP, MQTT, or AMQP: The data platform periodically sends heartbeat packets to the device. If the device fails to respond to the heartbeat packets twice consecutively, the data platform actively disconnects the long connection and determines the device to be offline.

9. The method for automatic device registration and data communication for an IoT middleware platform according to claim 1, characterized in that: When a device is limited by network conditions and cannot connect directly to the data platform, an M2M communication proxy is set up between the device and the data platform. The M2M communication proxy is set up on a cloud server or bastion host and is responsible for connecting the device and the data platform at the same time. It forwards the messages sent by the data platform or device to the receiver and then forwards the receiver's reply to the sender.

Images