Dynamic expansion management method for protocol coding and decoding adapters of Internet of Things equipment

Abstract

The invention discloses a dynamic expansion management method for a protocol coding and decoding adapter of Internet of Things equipment, which comprises the following steps of: 1, carrying out standardized configuration on access of Internet of Things platform equipment, and carrying out component registration and dual-mode interface management; step 2, configuring a standardized reporting and distributing mechanism of Internet of Things platform equipment data, and performing message queue configuration, message analysis and storage and dual-mode data output; 3, configuring a data issuing mechanism of the Internet of Things platform, and carrying out protocol adaptation and data issuing; and 4, on the basis of the configuration, carrying out full-life-cycle dynamic management and control, including safe recovery and dynamic change, on the adapter of the Internet of Things platform, the method can carry out dynamic registration, logout and addition on the adapter, and does not cause the change of the whole service architecture and the processing flow when a protocol is changed, thereby shortening the development cycle of the Internet of Things equipment, and improving the development efficiency of the Internet of Things equipment. The maintenance complexity is reduced, and the problem that a software system is unstable is solved.

Description

Technical Field

[0001] The present invention relates to the field of Internet of Things, and in particular to a method for dynamically expanding and managing protocol codec adapters for Internet of Things devices. Background Art

[0002] The development of the Internet of Things (IoT) has evolved from conception to technological maturity. Initially based on RFID and sensor networks, it has gradually expanded to areas such as smart homes, the Industrial Internet, and smart cities. With the development of Industry 3.0 and the advocacy and policy support of the "Internet of Everything" concept, the number of connected devices in the IoT industry has grown exponentially. The integration of technologies such as 5G, edge computing, and artificial intelligence has further enriched its application scenarios and enhanced its intelligence level.

[0003] In the current digitization of IoT devices, different manufacturers have customized distinct communication protocols for the same device, leading to complex protocol processing challenges when connecting these devices to a unified platform. Each manufacturer's protocol exhibits significant differences in data format, transmission method, and instruction set, requiring the platform to perform customized parsing and adaptation for each protocol. Current IoT platforms employ a "stovetop" development model for multi-protocol and multi-access devices. Each device protocol integration requires a series of steps, including device integration maintenance, protocol parsing, data conversion, data storage, data application development, and upgrades. Each development step requires changes and upgrades to accommodate new devices, increasing the development cost of IoT device integration and the complexity of the IoT platform. The platform is unable to horizontally scale across device types and faces pressure from the increasing number of devices of the same type.

[0004] To achieve unified device management and data interaction, the platform must convert these heterogeneous protocols into unified definitions and descriptions. This process involves extensive protocol mapping, data conversion, and semantic alignment, which is challenging and prone to compatibility issues. Conventional technology makes protocol standardization and the promotion of universal interfaces difficult. Furthermore, insufficient standardization and interoperability of device data pose challenges to data integration and analysis, hindering the overall efficiency and value creation of IoT systems. Summary of the Invention

[0005] In response to the above-mentioned technical deficiencies, the purpose of the present invention is to provide a dynamic expansion management method for protocol codec adapters of Internet of Things devices, aiming to solve the problem that devices using different communication protocols face complex protocol processing when accessing a unified platform, the conversion of heterogeneous protocols is difficult and easily introduces compatibility issues, and it is difficult to achieve protocol standardization and universal interface promotion under the existing technology, which restricts the overall efficiency of the Internet of Things system.

[0006] In view of the above problems, the present application provides a method for dynamic expansion management of protocol codec adapters of IoT devices.

[0007] The first aspect disclosed in the present application provides a method for dynamically expanding and managing a protocol codec adapter of an Internet of Things device, the method comprising: Step 1: Standardize the configuration of IoT platform device access, register components, and manage dual-mode interfaces. Step 2: Configure the standardized reporting and distribution mechanism for IoT platform device data, including message queue configuration, message parsing and storage, and dual-mode data output. Step 3: Configure the data delivery mechanism of the IoT platform to perform protocol adaptation and data delivery; Step 4: Based on the above configuration, dynamically manage the entire life cycle of the IoT platform adapter, including secure recycling and dynamic changes.

[0008] Preferably, the step 1 specifically includes the following steps: Step 1.1: Define the adapter parameters to register the adapter and generate the command ID to call the adapter. The adapter parameters include the adapter name, adapter URL, and corresponding protocol type. Step 1.2: Register the interface. If the existing interface meets the requirements, reuse the existing interface. If the existing interface does not meet the requirements, define interface parameters for interface registration and add the interface to the unified API. The interface parameters include the adapter name, adapter document, and interface name corresponding to the interface. Step 1.3: Define device parameters for device registration. The device parameters include the device identification code, device type, and corresponding protocol type. The device description information is expanded to the object type and object ID description fields that can be automatically matched or automatically created. At the same time, the device registration information will be transparently transmitted to the access point. Step 1.4: Register the unified API and divide it into message queue asynchronous calls and restful API remote calls based on whether the data requires timeliness. At the same time, register the message queue of the message queue asynchronous call and the command ID of the restful API remote call to the data standardization module.

[0009] Preferably, the step 2 specifically includes the following steps: Step 2.1: The message queue receives the data and puts it into a queue, where the data waits to be consumed by the adapter. Step 2.2: The adapter listens to the message queue and prepares to consume data; Step 2.3: The adapter identifies the data and consumes the data if the protocol type corresponding to the adapter is consistent with the protocol type used by the data. Step 2.4: Parse the parameter key-value pairs in the reported data according to the protocol encoding and decoding rules, and store the parsing results in the device identification code of the device that matches the data; Step 2.5: The data normalization module outputs the data.

[0010] Preferably, the step 2.5 specifically includes the following steps: Step 2.5.1: If the third-party service has registered a message queue, after receiving the device data, the data standardization module obtains the third-party message channel address and account corresponding to the device type from the database and forwards the data to the other party's message queue; Step 2.5.2: If the device identification code or device type of the device is newly added, update the device type in the database; Step 2.5.3: If the third-party service is remotely called through the RESTful API, the data standardization module finds the interface name based on the command ID of the RESTful API remote call and matches the device type based on the device identification code to obtain the device data.

[0011] Preferably, the step 3 specifically includes the following steps: Step 3.1: The third-party business calls the unified API and submits an application for review; Step 3.2: The data standardization module obtains the object ID based on the object type; Step 3.3: Get the corresponding command ID according to the object ID. Step 3.4: Determine whether the API is a general capability or an adapter capability based on the command ID; Step 3.5: If it is a general capability command ID, obtain the object type based on the device type. If it is an adapter capability command ID, find the command document and interface URL based on the command ID. Step 3.6: Send data with the device identification code and device type parameters to the device access point corresponding to the object type; Step 3.7: The device access point sends data to the device based on the device identification code.

[0012] Preferably, step 4 specifically includes the following steps: Step 4.1: If and only if there is no device record in the device type corresponding to the adapter applying for deregistration, execute the adapter deregistration process; Step 4.2: When the protocol type corresponding to the device parsed by the adapter changes, resulting in changes in the existing interface parameters of the adapter or new additions, the adapter interface is changed.

[0013] Preferably, the step 4.1 specifically includes the following steps: Step 4.1.1: Delete the adapter registration record; Step 4.1.2: Delete the device type record registered in the adapter; Step 4.1.3: Delete the adapter record corresponding to the object type; Step 4.1.4: The adapter service is offline; Step 4.1.5: Delete the database corresponding to the adapter.

[0014] Preferably, the step 4.2 specifically includes the following steps: Step 4.2.1: Add an interface to the adapter; Step 4.2.2: The adapter initiates an API registration request to the data standardization module. After the data standardization module reviews and approves the request, it generates a new command ID.

[0015] The second aspect disclosed in the present application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps of a method for dynamically expanding and managing a protocol codec adapter of an Internet of Things device.

[0016] The beneficial effects of the present invention are: (1) Decouple device access management and protocol processing processes. An adapter encodes and decodes a device communication protocol and can be dynamically registered and deregistered. The adapter provides a data interface after protocol encoding and decoding, and registers the interface to the unified API of this type of device to generate a unique interface call encoding id and path to facilitate the unified API calling process to identify the specific adapter.

[0017] (2) Compared with the traditional standardized management method of heterogeneous protocols for IoT devices, this method does not cause changes in the entire business architecture and processing flow when adding or changing protocols, shortening the IoT device development cycle, reducing maintenance complexity, and alleviating software system instability. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0019] Figure 1 This is an overall flow chart of a dynamic expansion management method for protocol codec adapters of IoT devices.

[0020] Figure 2This is an overall structural diagram of a dynamic expansion management method for protocol codec adapters of IoT devices. DETAILED DESCRIPTION

[0021] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0022] Example 1: like Figure 1 and Figure 2 As shown, an embodiment of the present application provides a method for dynamically expanding and managing a protocol codec adapter for an Internet of Things device, the method comprising: Step 1: Standardize the configuration of IoT platform device access, register components, and manage dual-mode interfaces.

[0023] Step 1 specifically includes the following steps: Step 1.1: Define the adapter parameters to register the adapter and generate the command ID to call the adapter. The adapter parameters include the adapter name, adapter URL, and corresponding protocol type. Step 1.2: Register the interface. If the existing interface meets the requirements, reuse the existing interface. If the existing interface does not meet the requirements, define interface parameters for interface registration and add the interface to the unified API. The interface parameters include the adapter name, adapter document, and interface name corresponding to the interface. Step 1.3: Define device parameters for device registration. The device parameters include the device identification code, device type, and corresponding protocol type. The device description information is expanded to the object type and object ID description fields that can be automatically matched or automatically created. At the same time, the device registration information will be transparently transmitted to the access point. Specifically, the thing type, thing_type, is defined as the same item in the IoT platform if it has the same characteristic attributes, purpose, or usage scenario. The thing id, thing_id, is a unique symbolic identifier automatically generated in the IoT platform when defining an item and can be used for program recognition. Step 1.4: Register the unified API and divide it into message queue asynchronous calls and restful API remote calls based on whether the data requires timeliness. At the same time, register the message queue of the message queue asynchronous call and the command ID of the restful API remote call to the data standardization module.

[0024] Step 2: Configure the standardized reporting and distribution mechanism for IoT platform device data, and perform message queue configuration, message parsing and storage, and dual-mode data output.

[0025] Step 2 specifically includes the following steps: Step 2.1: The message queue receives the data and puts it into a queue, where the data waits to be consumed by the adapter. Step 2.2: The adapter listens to the message queue and prepares to consume data; Step 2.3: The adapter identifies the data and consumes the data if the protocol type corresponding to the adapter is consistent with the protocol type used by the data. Step 2.4: Parse the parameter key-value pairs in the reported data according to the protocol encoding and decoding rules, and store the parsing results in the device identification code of the device that matches the data; Step 2.5: The data normalization module outputs the data.

[0026] Step 2.5 specifically includes the following steps: Step 2.5.1: If the third-party service has registered a message queue, after receiving the device data, the data standardization module obtains the third-party message channel address and account corresponding to the device type from the database and forwards the data to the other party's message queue; Step 2.5.2: If the device identification code or device type of the device is newly added, update the device type in the database; Step 2.5.3: If the third-party service is remotely called through the RESTful API, the data standardization module finds the interface name based on the command ID of the RESTful API remote call and matches the device type based on the device identification code to obtain the device data.

[0027] Step 3: Configure the data delivery mechanism of the IoT platform to perform protocol adaptation and data delivery.

[0028] Step 3 specifically includes the following steps: Step 3.1: The third-party business calls the unified API and submits an application for review; Step 3.2: The data standardization module obtains the object ID based on the object type; Step 3.3: Get the corresponding command ID according to the object ID. Step 3.4: Determine whether the API is a general capability or an adapter capability based on the command ID; Step 3.5: If it is a general capability command ID, obtain the object type based on the device type. If it is an adapter capability command ID, find the command document and interface URL based on the command ID. Step 3.6: Send data with the device identification code and device type parameters to the device access point corresponding to the object type; Step 3.7: The device access point sends data to the device based on the device identification code.

[0029] Step 4: Based on the above configuration, dynamically manage the entire life cycle of the IoT platform adapter, including secure recycling and dynamic changes.

[0030] Step 4 specifically includes the following steps: Step 4.1: If and only if there is no device record in the device type corresponding to the adapter applying for deregistration, execute the adapter deregistration process; Step 4.2: When the protocol type corresponding to the device parsed by the adapter changes, resulting in changes in the existing interface parameters of the adapter or new additions, the adapter interface is changed.

[0031] Step 4.1 specifically includes the following steps: Step 4.1.1: Delete the adapter registration record; Step 4.1.2: Delete the device type record registered in the adapter; Step 4.1.3: Delete the adapter record corresponding to the object type; Step 4.1.4: The adapter service is offline; Step 4.1.5: Delete the database corresponding to the adapter.

[0032] Step 4.2 specifically includes the following steps: Step 4.2.1: Add an interface to the adapter; Step 4.2.2: The adapter initiates an API registration request to the data standardization module. After the data standardization module reviews and approves the request, it generates a new command ID.

[0033] Example 2: In a second embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the steps of the above-mentioned method for dynamic expansion management of an IoT device protocol codec adapter are implemented.

[0034] In summary, the method for dynamic expansion management of an IoT device protocol codec adapter provided by the embodiments of the present application has the following technical effects: (1) Decouple device access management and protocol processing processes. An adapter encodes and decodes a device communication protocol and can be dynamically registered and deregistered. The adapter provides a data interface after protocol encoding and decoding, and registers the interface to the unified API of this type of device to generate a unique interface call encoding id and path to facilitate the unified API calling process to identify the specific adapter.

[0035] (2) Compared with the traditional standardized management method of heterogeneous protocols for IoT devices, this method does not cause changes in the entire business architecture and processing flow when adding or changing protocols, shortening the IoT device development cycle, reducing maintenance complexity, and alleviating software system instability.

[0036] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0037] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for dynamic expansion management of an Internet of Things device protocol codec adapter, characterized in that: The method comprises: Step 1: Standardize the configuration of IoT platform device access, register components, and manage dual-mode interfaces. Step 2: Configure the standardized reporting and distribution mechanism for IoT platform device data, including message queue configuration, message parsing and storage, and dual-mode data output. Step 3: Configure the data delivery mechanism of the IoT platform to perform protocol adaptation and data delivery; Step 4: Based on the above configuration, dynamically manage the entire life cycle of the IoT platform adapter, including secure recycling and dynamic changes.

2. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 1, characterized in that: The step 1 specifically includes the following steps: Step 1.1: Define the adapter parameters to register the adapter and generate the command ID to call the adapter. The adapter parameters include the adapter name, adapter URL, and corresponding protocol type. Step 1.2: Register the interface. If the existing interface meets the requirements, reuse the existing interface. If the existing interface does not meet the requirements, define interface parameters for interface registration and add the interface to the unified API. The interface parameters include the adapter name, adapter document, and interface name corresponding to the interface. Step 1.3: Define device parameters for device registration. The device parameters include the device identification code, device type, and corresponding protocol type. The device description information is expanded to the object type and object ID description fields that can be automatically matched or automatically created. At the same time, the device registration information will be transparently transmitted to the access point. Step 1.4: Register the unified API and divide it into message queue asynchronous calls and RESTful API remote calls based on whether the data requires timeliness. At the same time, register the message queue of the message queue asynchronous call and the command ID of the RESTful API remote call to the data standardization module.

3. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 2, characterized in that: The step 2 specifically includes the following steps: Step 2.1: The message queue receives the data and puts it into a queue, where the data waits to be consumed by the adapter. Step 2.2: The adapter listens to the message queue and prepares to consume data; Step 2.3: The adapter identifies the data and consumes the data if the protocol type corresponding to the adapter is consistent with the protocol type used by the data. Step 2.4: Parse the parameter key-value pairs in the reported data according to the protocol encoding and decoding rules, and store the parsing results in the device identification code of the device that matches the data; Step 2.5: The data normalization module outputs the data.

4. A method for dynamically expanding and managing an Internet of Things device protocol codec adapter according to claim 3, characterized in that: The step 2.5 specifically includes the following steps: Step 2.5.1: If the third-party service has registered a message queue, after receiving the device data, the data standardization module obtains the third-party message channel address and account corresponding to the device type from the database and forwards the data to the other party's message queue; Step 2.5.2: If the device identification code or device type of the device is newly added, update the device type in the database; Step 2.5.3: If the third-party service is remotely called through the RESTful API, the data standardization module finds the interface name based on the command ID of the RESTful API remote call and matches the device type based on the device identification code to obtain the device data.

5. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 4, characterized in that: The step 3 specifically includes the following steps: Step 3.1: The third-party business calls the unified API and submits an application for review; Step 3.2: The data standardization module obtains the object ID based on the object type; Step 3.3: Get the corresponding command ID according to the object ID. Step 3.4: Determine whether the API is a general capability or an adapter capability based on the command ID; Step 3.5: If it is a general capability command ID, obtain the object type based on the device type. If it is an adapter capability command ID, find the command document and interface URL based on the command ID. Step 3.6: Send data with the device identification code and device type parameters to the device access point corresponding to the object type; Step 3.7: The device access point sends data to the device based on the device identification code.

6. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 5, characterized in that: The step 4 specifically includes the following steps: Step 4.1: If and only if there is no device record in the device type corresponding to the adapter applying for deregistration, execute the adapter deregistration process; Step 4.2: When the protocol type corresponding to the device parsed by the adapter changes, resulting in changes in the existing interface parameters of the adapter or new additions, the adapter interface is changed.

7. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 6, characterized in that: The step 4.1 specifically includes the following steps: Step 4.1.1: Delete the adapter registration record; Step 4.1.2: Delete the device type record registered in the adapter; Step 4.1.3: Delete the adapter record corresponding to the object type; Step 4.1.4: The adapter service is offline; Step 4.1.5: Delete the database corresponding to the adapter.

8. A method for dynamic expansion management of an Internet of Things device protocol codec adapter according to claim 7, characterized in that: The step 4.2 specifically includes the following steps: Step 4.2.1: Add an interface to the adapter; Step 4.2.2: The adapter initiates an API registration request to the data standardization module. After the data standardization module reviews and approves the request, it generates a new command ID.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the processor implements the steps of a method for dynamically expanding and managing a protocol codec adapter for an Internet of Things device according to any one of claims 1 to 8.

Images