IoT gateways and cloud communication methods that support dynamic protocol configuration

Abstract

This invention discloses an IoT gateway and cloud communication method supporting dynamic protocol configuration, relating to the field of IoT communication technology. The cloud management platform generates protocol configuration tasks based on triggering conditions and distributes these tasks to the corresponding IoT gateways. The IoT gateways receive the protocol configuration tasks, dynamically load and update corresponding protocol plugins, and do not restart the gateway or interrupt data processing of other loaded protocols during the loading process. Based on the loaded protocol plugins, the accessed terminal devices are matched for protocol types, and the successfully matched protocol plugins are parsed to obtain standard object model data. The standard object model data is uploaded to the cloud management platform via cloud communication, where it is uniformly stored and collaboratively processed. This invention supports dynamic loading and updating of protocol plugins, quickly responding to the needs of multiple device accesses, and effectively improving the compatibility, scalability, and operational efficiency of IoT systems.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, specifically to an IoT gateway and cloud communication method that supports dynamic protocol configuration. Background Technology

[0002] In IoT application scenarios, there are hundreds or thousands of different communication protocols. Currently, IoT gateways generally adopt the 'protocol fixed-line' design mode, that is, the set of device communication protocols supported by the gateway is defined once in its factory firmware. In practical applications, faced with a massive number of heterogeneous terminal devices and their complex communication protocols, when it is necessary to access devices outside the predefined set of a gateway, the traditional approach requires technicians to burn new firmware on-site or perform a full remote upgrade. However, on-site upgrades are labor-intensive and difficult to deploy at scale, while full remote upgrades have significant drawbacks such as coarse upgrade granularity, high bandwidth consumption, long service interruption time, and high risk of upgrade failure. In addition, existing technologies lack a fine-grained mechanism that coordinates between the cloud and the gateway and supports dynamic loading or updating of protocol plugins without restarting the gateway, which severely limits the scalability, flexibility, and availability of IoT systems. How to achieve dynamic configuration and updating of IoT gateway protocols is a problem we need to solve. To this end, we now provide an IoT gateway and cloud communication method that support dynamic configuration of protocols. Summary of the Invention

[0003] The purpose of this invention is to provide an IoT gateway and cloud communication method that support dynamic configuration of the support protocol.

[0004] The objective of this invention can be achieved through the following technical solution: an IoT gateway and cloud communication method supporting dynamic protocol configuration, comprising the following steps: Step S1: The cloud management platform generates a protocol configuration task and sends the protocol configuration task to the corresponding IoT gateway; Step S2: The IoT gateway receives the protocol configuration task and dynamically loads and updates the corresponding protocol plugins; Step S3: Based on the loaded protocol plugins, perform protocol type matching on the connected terminal devices, and parse the data of the successfully matched protocol plugins to obtain standard object model data; Step S4: Upload the standard object model data to the cloud management platform, where it will be stored and processed collaboratively.

[0005] Furthermore, the process of generating protocol configuration tasks on the cloud management platform includes: Set the trigger conditions for the protocol configuration task. Based on the trigger conditions, the cloud management platform selects a protocol plugin installation package from the protocol plugin library that matches the central processing unit architecture and operating system version of the target IoT gateway. The system reads the list of currently loaded protocol plugins of the target IoT gateway, determines whether the protocol plugin corresponding to the selected protocol plugin installation package exists and is the latest version, and if it does not exist or exists but is outdated, it generates a protocol configuration task containing the plugin download address, hash check value and digital signature, and sends the protocol configuration task to the corresponding IoT gateway.

[0006] Furthermore, the process of dynamically loading protocol plugins and performing security verification operations according to the protocol configuration task includes: The IoT gateway has a built-in protocol dynamic loader, protocol plugin repository, and performs security verification operations; The protocol plugin is distributed from the cloud management platform in the form of a protocol plugin installation package. The protocol plugin installation package contains a protocol plugin binary file, a configuration file, a digital signature, and a hash verification value. The configuration file records information such as the plugin protocol type and matching rule definition. After receiving the protocol configuration task, the protocol dynamic loader first extracts the plugin download address from the protocol configuration task, obtains the protocol plugin installation package from the plugin download address, and temporarily stores the original binary data of the obtained protocol plugin installation package in memory. Then, the protocol dynamic loader invokes the security verification operation to verify the original binary data of the protocol plugin installation package temporarily stored in memory, as well as the digital signature and hash check value carried in the protocol configuration task.

[0007] Furthermore, the security verification operation includes the following steps: When the IoT gateway leaves the factory, the root certificate public key of the cloud management platform is pre-installed in the secure storage area. First, the digital signature in the protocol configuration task is extracted and the root certificate public key of the cloud management platform is called to decrypt the digital signature and obtain the first digest value. Meanwhile, the original binary data of the obtained protocol plugin installation package is hashed using the same hash algorithm as the cloud management platform to obtain the second digest value; The security verification operation compares the first digest value and the second digest value byte by byte to determine whether the first digest value and the second digest value are completely identical. If they match, the digital signature verification is deemed successful, indicating that the protocol plugin installation package indeed comes from a trusted cloud management platform and has not been tampered with. If they do not match, the digital signature verification is deemed unsuccessful. After the digital signature verification is successful, the security verification operation further compares the hash verification value carried in the protocol configuration task with the obtained second digest value. If they match, the hash verification is completed. When digital signature verification or hash verification fails, the security verification operation immediately refuses to execute the protocol configuration task, generates an error message containing the reason for the failure, reports it to the cloud management platform, and discards the downloaded protocol plugin installation package without performing any subsequent storage or loading operations. After both digital signature verification and hash verification are successful, the security verification operation returns a notification that the verification has passed, allowing the decompression and dynamic loading process to continue. After successful verification, the protocol dynamic loader obtains the protocol plugin installation package from the plugin download address and decompresses and stores it in the protocol plugin repository.

[0008] Furthermore, the process of dynamically loading protocol plugins on an IoT gateway includes: The protocol dynamic loader obtains the protocol plugin type from the configuration file of the protocol plugin installation package, and calls the dynamic link interface of the IoT gateway according to the protocol plugin type to load the protocol plugin into the runtime memory; Once loading is complete, the protocol dynamic loader registers the protocol plugin with the protocol parsing engine; If an error occurs during loading, the protocol dynamic loader will automatically roll back to the state before loading and delete the stored abnormal protocol plugin from the protocol plugin repository.

[0009] Furthermore, the process of dynamically updating and uninstalling protocol plugins includes: When the cloud management platform detects that a new version of the protocol plugin installation package exists for a certain protocol plugin, it generates a protocol configuration task and sends it to the corresponding IoT gateway. After the IoT gateway receives the data, the protocol dynamic loader loads the protocol plugin according to the above process, downloads and verifies the new version of the protocol plugin installation package, and decompresses it to obtain the new version of the protocol plugin. Load the new version of the protocol plugin into memory and mark the original protocol plugin as to be uninstalled; The IoT gateway uses a reference counting mechanism to achieve safe unloading. During unloading, the protocol dynamic loader marks the original protocol plugin as "prohibited from new matching". After the counter drops to zero, the actual unloading and resource release operation is performed. When an IoT gateway no longer needs to support a certain type of protocol plugin, the protocol dynamic loader stops matching the protocol plugin and waits for the current message to be processed before uninstalling the corresponding protocol plugin.

[0010] Furthermore, the process of matching the protocol type of the accessing terminal device based on the loaded protocol plugins includes: The terminal device generates raw data packets according to preset communication triggering conditions, and sends the generated raw data packets to the second network interface of the IoT gateway through a physical connection or wireless connection. After receiving the raw data packet sent by the terminal device, the second network interface of the IoT gateway sends the raw data packet to the protocol parsing engine for processing. The protocol parsing engine first extracts feature information from the raw data packet. The protocol parsing engine traverses the list of currently registered protocol plugins based on the extracted feature information and performs protocol type matching according to the preset matching priority order; If the protocol type fails to match, i.e. it is not in the list of registered protocol plugins, the protocol parsing engine discards the original data packet, records the matching failure log, and can choose to report the unrecognized protocol features to the cloud management platform, triggering the cloud management platform to generate a protocol configuration task and issue the corresponding protocol plugin installation package. If the protocol type matches successfully, the protocol parsing engine calls the parsing function of the protocol plugin whose protocol type matches successfully.

[0011] Furthermore, the process of parsing the data of protocol plugins that successfully match the protocol type to obtain standard object model data includes: The parsing function first performs protocol format verification on the raw data packet; If the protocol format verification fails, the parsing function returns a verification error flag and marks the original data packet as an invalid packet, and no further parsing operations will be performed. If the protocol format verification passes, the parsing function parses the data content in the original data packet field by field according to the frame format definition of the protocol; The parsing function extracts the data of each field from the raw data packet according to the frame format definition, and converts it into the standard data type according to the predefined data type mapping relationship; The converted field data is organized into standard object model data in standard object model format, and the converted standard object model data is returned to the protocol parsing engine as the parsing result. If any error occurs during the parsing process, the parsing function returns an error identifier and an error description. The protocol parsing engine decides whether to discard the original data packet or retry the process based on the error identifier.

[0012] Furthermore, the process of uploading the standard object model data to the cloud management platform, and having the cloud management platform perform unified storage and collaborative processing, includes: The protocol parsing engine processes the standard object model data and sends the processed standard object model data to the data cache queue for temporary storage. According to the pre-configured data reporting strategy, cloud communication is carried out, the standard object model data to be uploaded is read from the data cache queue, and uploaded to the cloud management platform through the first network interface; Before engaging in cloud communication, first determine the current network connection status: If the network connection is normal, the standard object model data can be uploaded directly through the established network connection; If the network connection is interrupted, the standard object model data will be temporarily stored in the data cache queue and the network reconnection mechanism will be initiated. After the network is restored, the temporarily stored data will be uploaded in the order of timestamps to ensure the integrity and timeliness of the standard object model data. During cloud communication, a unique serial number is assigned to each uploaded standard object model data, and a confirmation response is awaited from the cloud management platform. If no confirmation response is received within the preset timeout period, the corresponding standard object model data is re-uploaded. Once the number of retransmissions reaches the preset limit, the corresponding standard object model data is marked as uploaded as a failure, and a failure log is recorded. After receiving the uploaded standard object model data, the cloud management platform sends an acknowledgment response to the IoT gateway. Upon receiving the acknowledgment response, the successfully uploaded standard object model data is deleted from the data cache queue, releasing cache space.

[0013] Compared with the prior art, the beneficial effects of the present invention are: the cloud management platform generates protocol configuration tasks according to triggering conditions and sends the protocol configuration tasks to the corresponding IoT gateways, realizing centralized management and automated distribution of protocol configuration, reducing manual intervention, improving configuration efficiency and accuracy, and supporting remote operation and maintenance and batch management; The IoT gateway receives the protocol configuration task, dynamically loads and updates the corresponding protocol plugins, and does not restart the gateway or interrupt the data processing of other loaded protocols during the loading process. Through the protocol plug-in and dynamic loading mechanism, the IoT gateway does not need to restart the device when adding or updating protocols, and the communication and data reporting services of the terminal devices corresponding to the original protocols are not affected in any way. Based on the loaded protocol plugins, the protocol type of the connected terminal devices is matched, and the data of the successfully matched protocol plugins is parsed to obtain standard object model data. This realizes the automatic identification and standardized conversion of protocols of multiple manufacturers' devices, solves the compatibility problem of heterogeneous device access, reduces the complexity of data processing, and realizes the interconnection and interoperability of devices from multiple manufacturers and with multiple protocols. The standard object model data is uploaded to the cloud management platform via cloud communication, where it is uniformly stored and collaboratively processed. This enables centralized storage and efficient collaboration of IoT data in the cloud. The invention supports dynamic loading and updating of protocol plugins, quickly responds to the access needs of multiple devices, effectively improves the compatibility, scalability and operation and maintenance efficiency of the IoT system, reduces system maintenance costs, shortens the access cycle of new devices, and enhances the market adaptability and technical competitiveness of the IoT platform. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0015] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0016] like Figure 1 As shown, the IoT gateway and cloud communication method that supports dynamic protocol configuration includes the following steps: Step S1: The cloud management platform generates a protocol configuration task and sends the protocol configuration task to the corresponding IoT gateway; Step S2: The IoT gateway receives the protocol configuration task and dynamically loads and updates the corresponding protocol plugins; Step S3: Based on the loaded protocol plugins, perform protocol type matching on the connected terminal devices, and parse the data of the protocol plugins that successfully match the protocol type to obtain standard object model data; Step S4: Upload the standard object model data to the cloud management platform, where it will be stored and processed collaboratively.

[0017] It should be further explained that, in the specific implementation process, the process of the cloud management platform generating protocol configuration tasks includes: The triggering conditions for setting the protocol configuration task include: the user manually adding a protocol type through the cloud interface, the IoT gateway reporting unrecognizable device protocol characteristics, or the cloud protocol plugin library releasing a new version of the protocol plugin installation package; Based on the triggering conditions, the cloud management platform selects a protocol plugin installation package from the protocol plugin library that matches the central processing unit architecture and operating system version of the target IoT gateway; The system reads the list of currently loaded protocol plugins of the target IoT gateway, determines whether the protocol plugin corresponding to the selected protocol plugin installation package exists and is the latest version, and if it does not exist or exists but is outdated, it generates a protocol configuration task containing the plugin download address, hash check value and digital signature, and sends the protocol configuration task to the corresponding IoT gateway.

[0018] It should be further explained that, in the specific implementation process, the process of dynamically loading the protocol plugin and performing security verification operations according to the protocol configuration task includes: The IoT gateway has a built-in protocol dynamic loader, protocol plugin repository, and performs security verification operations; The protocol dynamic loader refers to a software processing procedure in the operation of an IoT gateway, which is responsible for loading protocol plugins from the storage area into memory during the operation of the IoT gateway. The protocol plugin is distributed from the cloud management platform in the form of a protocol plugin installation package. The protocol plugin installation package contains a protocol plugin binary file, a configuration file, a digital signature, and a hash verification value. The configuration file records information such as the plugin protocol type and matching rule definition. The protocol plugin repository is used to persistently store the decompressed protocol plugins and their version information; After receiving the protocol configuration task, the protocol dynamic loader first extracts the plugin download address from the protocol configuration task, obtains the protocol plugin installation package from the plugin download address, and temporarily stores the original binary data of the obtained protocol plugin installation package in memory. Then, the protocol dynamic loader invokes the security verification operation to verify the original binary data of the protocol plugin installation package temporarily stored in memory, as well as the digital signature and hash check value carried in the protocol configuration task.

[0019] It should be further explained that, in the specific implementation process, the security verification operation includes: When the IoT gateway leaves the factory, the root certificate public key of the cloud management platform is pre-installed in the secure storage area. The root certificate public key is used to verify the digital signature of the distributed protocol plugin installation package. Upon receiving the protocol configuration task, a security verification operation is performed based on the digital signature, hash check value, and plugin download address carried in the protocol configuration task. The security verification operation first extracts the digital signature from the protocol configuration task. The digital signature is the ciphertext generated by the cloud management platform after performing asymmetric encryption on the complete contents of the protocol plugin installation package using its private key. The security verification operation calls the root certificate public key of the cloud management platform to decrypt the digital signature and obtain the first digest value; Meanwhile, the original binary data of the obtained protocol plugin installation package is hashed using the same hash algorithm as the cloud management platform to obtain the second digest value; The security verification operation compares the first digest value and the second digest value byte by byte to determine whether the first digest value and the second digest value are completely identical. If they match, the digital signature verification is deemed successful, indicating that the protocol plugin installation package does indeed originate from a trusted cloud management platform and has not been tampered with. If they do not match, the digital signature verification is deemed to have failed. After the digital signature verification is successful, the security verification operation further compares the hash verification value directly carried in the protocol configuration task with the obtained second digest value. If they match, the hash verification is completed. When digital signature verification or hash verification fails, the security verification operation immediately refuses to execute the protocol configuration task, generates an error message containing the reason for the failure, reports it to the cloud management platform, and discards the downloaded protocol plugin installation package without performing any subsequent storage or loading operations. After both digital signature verification and hash verification are successful, the security verification operation returns a notification that the verification has passed, allowing the decompression and dynamic loading process to continue. After successful verification, the protocol dynamic loader obtains the protocol plugin installation package from the plugin download address and decompresses and stores it in the protocol plugin repository.

[0020] It should be further explained that, in the specific implementation process, the process of dynamically loading protocol plugins by the IoT gateway includes: The protocol dynamic loader obtains the protocol plugin type from the configuration file of the protocol plugin installation package, calls the dynamic link interface of the IoT gateway according to the protocol plugin type, loads the protocol plugin into the runtime memory, and calls the predefined registration interface function of the protocol plugin to obtain the protocol type identifier, matching rules and parsing function entry address corresponding to the protocol plugin from the registration interface function. Once loading is complete, the protocol dynamic loader registers the protocol plugin with the protocol parsing engine. The registration information includes protocol characteristics, parsing functions, and priority values. The protocol parsing engine refers to the core part of the IoT gateway responsible for receiving raw data packets, selecting matching protocol plugins, and calling parsing functions. Internally, it maintains a list of registered protocol plugins and a matching rule table. During the entire loading process, the IoT gateway does not perform a restart operation, and the communication and data parsing services of devices corresponding to other loaded protocol plugins are not affected in any way; If an error occurs during loading, the protocol dynamic loader will automatically roll back to the state before loading and delete the stored abnormal protocol plugin from the protocol plugin repository.

[0021] It should be further explained that, in the specific implementation process, the process of dynamically updating and uninstalling the protocol plugin includes: When the cloud management platform detects that a new version of the protocol plugin installation package exists for a certain protocol plugin, it generates a protocol configuration task and sends it to the corresponding IoT gateway. After the IoT gateway receives the data, the protocol dynamic loader loads the protocol plugin according to the above process, downloads and verifies the new version of the protocol plugin installation package, and decompresses it to obtain the new version of the protocol plugin. Load the new version of the protocol plugin into memory and mark the original protocol plugin as to be uninstalled; The IoT gateway uses a reference counting mechanism to achieve secure offloading. The reference counting mechanism refers to maintaining a counter for each loaded protocol plugin to record the number of threads or tasks currently using the protocol plugin to process messages. When a new message arrives, the counter increments by one; after the message is processed, the counter decrements by one. During uninstallation, the protocol dynamic loader marks the existing protocol plugins as "prohibited from new matching". After the counter drops to zero, the actual uninstallation and resource release operations are performed. When an IoT gateway no longer needs to support a certain type of protocol plugin, the protocol dynamic loader stops matching the protocol plugin and waits for the current message to be processed before uninstalling the corresponding protocol plugin.

[0022] It should be further explained that, in the specific implementation process, the process of matching the protocol type of the access terminal device based on the loaded protocol plugin includes: The terminal device generates raw data packets and sends them to the IoT gateway according to preset communication trigger conditions; The preset communication triggering conditions include periodic reporting after the internal timer of the terminal device times out, event reporting after detecting a state change, or responding to a query command actively sent by the IoT gateway. The terminal device refers to various sensors, actuators, smart meters or other IoT devices that are connected to the Internet of Things, which generate raw data packets according to the communication protocol format they support through their built-in communication modules. The raw data packet refers to a data packet encapsulated by a terminal device according to a frame format of a specific communication protocol. The data packet includes fields such as protocol frame header, device address, data content, and checksum. The terminal device sends the generated raw data packets to the second network interface of the IoT gateway via a physical connection or a wireless connection. The second network interface refers to the physical interface or wireless communication module on the IoT gateway used to connect terminal devices; After receiving the raw data packet sent by the terminal device, the second network interface of the IoT gateway sends the raw data packet to the protocol parsing engine for processing. The protocol parsing engine first extracts feature information from the original data packets. The feature information includes key fields such as the packet's frame header identifier, source device address, destination port number, protocol signature, and packet length. The protocol parsing engine traverses the list of currently registered protocol plugins based on the extracted feature information and performs protocol type matching according to the preset matching priority order; The matching priority order refers to sorting according to the priority value set when the protocol plugin is registered. The smaller the priority value, the higher the priority. When the matching rules of multiple protocol plugins are met at the same time, the protocol plugin with the highest priority is selected. If the protocol type fails to match, i.e. it is not in the list of registered protocol plugins, the protocol parsing engine discards the original data packet, records the matching failure log, and can choose to report the unrecognized protocol features to the cloud management platform, triggering the cloud management platform to generate a protocol configuration task and issue the corresponding protocol plugin installation package. If the protocol type matches successfully, the protocol parsing engine calls the parsing function of the protocol plugin whose protocol type matches successfully.

[0023] It should be further explained that, in the specific implementation process, the process of parsing the data of protocol plugins that have successfully matched the protocol type to obtain standard object model data includes: The parsing function refers to the predefined program code in the protocol plugin used to convert raw messages of a specific protocol format into standard data structures; Before calling the parsing function of a protocol plugin, the protocol parsing engine increments the reference count of that protocol plugin by one, indicating that a message is currently being processed by that protocol plugin. After the parsing function is executed, the reference count of that protocol plugin is decremented by one. The parsing function first performs protocol format verification on the original data packet. The protocol format verification refers to verifying the integrity and correctness of the packet according to the communication protocol specifications supported by the protocol plugin. If the protocol format verification fails, the parsing function returns a verification error flag and marks the original data packet as an invalid packet, and no further parsing operations will be performed. If the protocol format verification passes, the parsing function parses the data content in the original data packet field by field according to the frame format definition of the protocol; The frame format definition refers to the metadata pre-configured in the protocol plugin that describes the structure of the protocol message, including the starting position, length, data type, byte order, and other information of each field; The extracted field data is converted into standard data types according to predefined data type mapping relationships; The data type mapping relationship refers to the rule table pre-configured in the protocol plugin that converts protocol-specific data types into general data types; The converted field data is organized into standard object model data in standard object model format, and the converted standard object model data is returned to the protocol parsing engine as the parsing result. The standard object model format refers to a predefined, unified data representation specification that is independent of specific communication protocols, including a device unique identifier field, a protocol type identifier field, a data acquisition timestamp field, and a data content object field. If any error occurs during the parsing process, the parsing function returns an error identifier along with an error description. The protocol parsing engine then determines whether to discard the original data packet or retry the process based on the error identifier. For example: When the terminal device is a temperature sensor, the raw data packet is a hexadecimal byte sequence: 01 03 02 00 17 B8 42 The parsing process of the parsing function for this raw data packet is as follows: Protocol format verification: Calculate the cyclic redundancy check code to verify message integrity; verification passes. Field parsing: Device address field is 01, function code field is 03, data length field is 02, data content field is 00 17, and cyclic redundancy check field is B8 42; Data type conversion: Convert the data content field 00 17 to a standard integer type, with a value of 23; Standard object model format conversion: Organize the analysis results into a standard object model format.

[0024] It should be further explained that, in the specific implementation process, the process of uploading the standard object model data to the cloud management platform, and the unified storage and collaborative processing by the cloud management platform, includes: The protocol parsing engine processes the standard object model data; The data processing refers to the operation process in the IoT gateway responsible for optimizing the standard object model data, which includes data deduplication, data compression, and data encryption. After the standard object model data has been processed, it is sent to the data cache queue for temporary storage. The data cache queue refers to the memory buffer in the IoT gateway used to temporarily store data to be uploaded, and the data is managed using a first-in-first-out queue structure. According to the pre-configured data reporting strategy, cloud communication is carried out, the standard object model data to be uploaded is read from the data cache queue, and uploaded to the cloud management platform through the first network interface; The first network interface is the network interface for communication between the IoT gateway and the cloud management platform; The data reporting strategy includes periodic reporting mode, change reporting mode, and threshold triggering mode; The cloud communication refers to the operation process in the IoT gateway responsible for establishing a network connection with the cloud management platform and transmitting data, which supports multiple communication protocols. Before engaging in cloud communication, first determine the current network connection status: If the network connection is normal, the standard object model data can be uploaded directly through the established network connection; If the network connection is interrupted, the standard object model data will be temporarily stored in the data cache queue and the network reconnection mechanism will be initiated. After the network is restored, the temporarily stored data will be uploaded in the order of timestamps to ensure the integrity and timeliness of the standard object model data. During cloud communication, a unique serial number is assigned to each uploaded standard object model data, and a confirmation response is awaited from the cloud management platform. If no confirmation response is received within the preset timeout period, the corresponding standard object model data is re-uploaded. Once the number of retransmissions reaches the preset limit, the corresponding standard object model data is marked as uploaded as a failure, and a failure log is recorded. After receiving the uploaded standard object model data, the cloud management platform sends an acknowledgment response to the IoT gateway. Upon receiving the acknowledgment response, the successfully uploaded standard object model data is deleted from the data cache queue, releasing cache space.

[0025] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications or equivalent substitutions made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. An IoT gateway and cloud communication method supporting dynamic protocol configuration, characterized in that, Includes the following steps: Step S1: The cloud management platform generates a protocol configuration task and sends the protocol configuration task to the corresponding IoT gateway; Step S2: The IoT gateway receives the protocol configuration task and dynamically loads and updates the corresponding protocol plugins; Step S3: Based on the loaded protocol plugins, perform protocol type matching on the connected terminal devices, and parse the data of the successfully matched protocol plugins to obtain standard object model data; Step S4: Upload the standard object model data to the cloud management platform, where it will be stored and processed collaboratively.

2. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 1, characterized in that, The process of generating protocol configuration tasks on the cloud management platform includes: Set the trigger conditions for the protocol configuration task. Based on the trigger conditions, the cloud management platform selects a protocol plugin installation package from the protocol plugin library that matches the central processing unit architecture and operating system version of the target IoT gateway. The system reads the list of currently loaded protocol plugins of the target IoT gateway, determines whether the protocol plugin corresponding to the selected protocol plugin installation package exists and is the latest version, and if it does not exist or exists but is outdated, it generates a protocol configuration task containing the plugin download address, hash check value and digital signature, and sends the protocol configuration task to the corresponding IoT gateway.

3. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 2, characterized in that, The process of dynamically loading protocol plugins and performing security verification operations according to the protocol configuration task includes: The IoT gateway has a built-in protocol dynamic loader, protocol plugin repository, and performs security verification operations; The protocol plugin is distributed from the cloud management platform in the form of a protocol plugin installation package. The protocol plugin installation package contains a protocol plugin binary file, a configuration file, a digital signature, and a hash verification value. The configuration file records information such as the plugin protocol type and matching rule definition. After receiving the protocol configuration task, the protocol dynamic loader first extracts the plugin download address from the protocol configuration task, obtains the protocol plugin installation package from the plugin download address, and temporarily stores the original binary data of the obtained protocol plugin installation package in memory. Then, the protocol dynamic loader invokes the security verification operation to verify the original binary data of the protocol plugin installation package temporarily stored in memory, as well as the digital signature and hash check value carried in the protocol configuration task.

4. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 3, characterized in that, The security verification process includes: When the IoT gateway leaves the factory, the root certificate public key of the cloud management platform is pre-installed in the secure storage area. First, the digital signature in the protocol configuration task is extracted and the root certificate public key of the cloud management platform is called to decrypt the digital signature and obtain the first digest value. Meanwhile, the original binary data of the obtained protocol plugin installation package is hashed using the same hash algorithm as the cloud management platform to obtain the second digest value; The security verification operation compares the first digest value and the second digest value byte by byte to determine whether the first digest value and the second digest value are completely identical. If they match, the digital signature verification is deemed successful, indicating that the protocol plugin installation package indeed comes from a trusted cloud management platform and has not been tampered with. If they do not match, the digital signature verification is deemed unsuccessful. After the digital signature verification is successful, the security verification operation further compares the hash verification value carried in the protocol configuration task with the obtained second digest value. If they match, the hash verification is completed. When digital signature verification or hash verification fails, the security verification operation immediately refuses to execute the protocol configuration task, generates an error message containing the reason for the failure, reports it to the cloud management platform, and discards the downloaded protocol plugin installation package without performing any subsequent storage or loading operations. After both digital signature verification and hash verification are successful, the security verification operation returns a notification that the verification has passed, allowing the decompression and dynamic loading process to continue. After successful verification, the protocol dynamic loader obtains the protocol plugin installation package from the plugin download address and decompresses and stores it in the protocol plugin repository.

5. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 4, characterized in that, The process of dynamically loading protocol plugins on an IoT gateway includes: The protocol dynamic loader obtains the protocol plugin type from the configuration file of the protocol plugin installation package, and calls the dynamic link interface of the IoT gateway according to the protocol plugin type to load the protocol plugin into the runtime memory; Once loading is complete, the protocol dynamic loader registers the protocol plugin with the protocol parsing engine; If an error occurs during loading, the protocol dynamic loader will automatically roll back to the state before loading and delete the stored abnormal protocol plugin from the protocol plugin repository.

6. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 5, characterized in that, The process of dynamically updating and uninstalling protocol plugins includes: When the cloud management platform detects that a new version of the protocol plugin installation package exists for a certain protocol plugin, it generates a protocol configuration task and sends it to the corresponding IoT gateway. After the IoT gateway receives the data, the protocol dynamic loader loads the protocol plugin according to the above process, downloads and verifies the new version of the protocol plugin installation package, and decompresses it to obtain the new version of the protocol plugin. Load the new version of the protocol plugin into memory and mark the original protocol plugin as to be uninstalled; The IoT gateway uses a reference counting mechanism to achieve safe unloading. During unloading, the protocol dynamic loader marks the original protocol plugin as "prohibited from new matching". After the counter drops to zero, the actual unloading and resource release operations are performed. When an IoT gateway no longer needs to support a certain type of protocol plugin, the protocol dynamic loader stops matching the protocol plugin and waits for the current message to be processed before uninstalling the corresponding protocol plugin.

7. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 6, characterized in that, The process of matching the protocol type of the connected terminal devices based on the loaded protocol plugins includes: The terminal device generates raw data packets according to preset communication triggering conditions, and sends the generated raw data packets to the second network interface of the IoT gateway through a physical connection or wireless connection. After receiving the raw data packet sent by the terminal device, the second network interface of the IoT gateway sends the raw data packet to the protocol parsing engine for processing. The protocol parsing engine first extracts feature information from the raw data packet. The protocol parsing engine traverses the list of currently registered protocol plugins based on the extracted feature information and performs protocol type matching according to the preset matching priority order; If the protocol type fails to match, i.e. it is not in the list of registered protocol plugins, the protocol parsing engine discards the original data packet, records the matching failure log, and can choose to report the unrecognized protocol features to the cloud management platform, triggering the cloud management platform to generate a protocol configuration task and issue the corresponding protocol plugin installation package. If the protocol type matches successfully, the protocol parsing engine calls the parsing function of the protocol plugin whose protocol type matches successfully.

8. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 7, characterized in that, The process of parsing the data of protocol plugins that successfully match the protocol type to obtain standard object model data includes: The parsing function first performs protocol format verification on the raw data packet; If the protocol format verification fails, the parsing function returns a verification error flag and marks the original data packet as an invalid packet, and no further parsing operations will be performed. If the protocol format verification passes, the parsing function parses the data content in the original data packet field by field according to the frame format definition of the protocol; The parsing function extracts the data of each field from the raw data packet according to the frame format definition, and converts it into the standard data type according to the predefined data type mapping relationship; The converted field data is organized into standard object model data in standard object model format, and the converted standard object model data is returned to the protocol parsing engine as the parsing result. If any error occurs during the parsing process, the parsing function returns an error identifier and an error description. The protocol parsing engine decides whether to discard the original data packet or retry the process based on the error identifier.

9. The IoT gateway and cloud communication method supporting dynamic protocol configuration according to claim 8, characterized in that, The process of uploading standard object model data to the cloud management platform, and then having the cloud management platform perform unified storage and collaborative processing, includes: The protocol parsing engine processes the standard object model data and sends the processed standard object model data to the data cache queue for temporary storage. According to the pre-configured data reporting strategy, cloud communication is carried out, the standard object model data to be uploaded is read from the data cache queue, and uploaded to the cloud management platform through the first network interface; Before engaging in cloud communication, first determine the current network connection status: If the network connection is normal, the standard object model data can be uploaded directly through the established network connection; If the network connection is interrupted, the standard object model data will be temporarily stored in the data cache queue and the network reconnection mechanism will be initiated. After the network is restored, the temporarily stored data will be uploaded in the order of timestamps to ensure the integrity and timeliness of the standard object model data. During cloud communication, a unique serial number is assigned to each uploaded standard object model data, and a confirmation response is awaited from the cloud management platform. If no confirmation response is received within the preset timeout period, the corresponding standard object model data is re-uploaded. Once the number of retransmissions reaches the preset limit, the corresponding standard object model data is marked as uploaded as a failure, and a failure log is recorded. After receiving the uploaded standard object model data, the cloud management platform sends an acknowledgment response to the IoT gateway. Upon receiving the acknowledgment response, the successfully uploaded standard object model data is deleted from the data cache queue, releasing cache space.

Images