Iot device access system based on model context protocol

Abstract

The application relates to the technical field of Internet of Things, and discloses an Internet of Things device access system based on a model context protocol, which comprises a protocol drive management module, a product analysis management module and a device management module. The protocol drive management module is used for acquiring a target protocol drive program corresponding to a target device protocol and instantiating the target protocol drive program into a target protocol drive instance, wherein the target device protocol is a newly-added protocol type. The product analysis management module is used for acquiring a target product analysis program corresponding to the target device protocol. The device management module is used for acquiring device identification information of a target device in response to an access instruction of the target device, wherein the target device communicates with an edge gateway based on the target device protocol; and an association relationship among the device identification information, the target protocol drive instance and the target product analysis program is established to complete functional access of the target device. In the foregoing manner, the dynamic expansion capability of the edge gateway for heterogeneous device protocols is improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, specifically to an IoT device access system based on a model context protocol. Background Technology

[0002] The booming development of the Internet of Things (IoT) has made edge gateways increasingly important as hubs connecting the physical and digital worlds. One of the core tasks of edge gateways is to enable access and data collection from massive amounts of heterogeneous industrial devices (such as sensors and smart meters). However, traditional edge gateways have revealed significant limitations when faced with the demands of diverse device protocols and rapid iteration.

[0003] Currently, there are several solutions in the industry aimed at improving gateway flexibility. For example, Chinese patent publication number "CN120499237A" discloses a secondary development system and method based on industrial IoT gateways. It enhances the gateway's secondary development capabilities by introducing an object model, an MQTT server (Broker), and a Python SDK module. The aim is to build a communication framework based on a publish / subscribe mechanism at the gateway level, abstract device data into an object model, and provide secondary development interfaces for upper-layer applications through the Python SDK. This provides a unified data model and a convenient application development environment for device data already connected to the gateway, thereby reducing the difficulty of developing business logic.

[0004] However, such solutions assume that the edge gateway already possesses the ability to interact with the target device using low-level communication protocols. They typically rely on protocol driver libraries pre-installed in the gateway firmware. When a new device using a completely new or proprietary protocol needs to be connected, even with a convenient upper-layer development environment, a complete firmware upgrade from the gateway manufacturer is often required, sometimes even necessitating hardware returns for updates. This process is time-consuming and costly, failing to meet the urgent needs of industrial sites for rapid device access and flexible expansion.

[0005] Therefore, improving the dynamic expansion capability of edge gateways for heterogeneous device protocols has become an urgent technical problem to be solved. Summary of the Invention

[0006] In view of the above problems, this application provides an IoT device access system based on the Model Context Protocol to solve the problem that the edge gateway's ability to extend heterogeneous device protocols needs to be improved in the prior art.

[0007] According to one aspect of the embodiments of this application, an IoT device access system based on a Model Context Protocol is provided. The system includes: a protocol driver management module, located on an edge gateway, for obtaining a target protocol driver corresponding to a target device protocol and instantiating the target protocol driver into a target protocol driver instance, wherein the target device protocol is a newly added protocol type; a product parsing management module, located on the edge gateway, for obtaining a target product parsing program corresponding to the target device protocol; and a device management module, located on the edge gateway, for: responding to an access command from the target device, obtaining device identification information of the target device, wherein the target device and the edge gateway communicate based on the target device protocol; and establishing an association between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device.

[0008] Preferably, the system further includes: an interface management module, located on the edge gateway, used for: receiving an interface configuration file for a target physical communication interface, wherein the interface configuration file includes parameter configurations for the target physical communication interface and a target protocol identifier to be bound; initializing the target physical communication interface in the edge gateway according to the parameter configuration; binding the initialized target physical communication interface to a target protocol driver instance according to the target protocol identifier to be bound, so as to realize data interaction between the target device and the edge gateway based on the target physical communication interface; and a data management module, located on the edge gateway, used for interacting with external program sources in a standardized data format.

[0009] Preferably, the product parsing management module is also used to obtain the object model file associated with the target product parsing program, wherein the object model file is used to define the data structure and business rules followed by the target product parsing program when performing data processing.

[0010] Preferably, the device identification information includes the device physical address, device protocol attributes, and device product type attributes. Establishing the association between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device includes: based on the device protocol attributes, determining the target protocol driver instance corresponding to the target device from multiple protocol driver instances in the protocol driver management module, and assigning a driver port identifier to the target protocol driver instance; based on the device product type attributes, determining the target product parsing program corresponding to the target device from multiple product parsing programs in the product parsing management module, and assigning a product port identifier to the target product parsing program; and establishing the association between the device physical address, driver port identifier, and product port identifier to complete the functional access of the target device.

[0011] Preferably, the system is used to perform uplink processing on communication data sent by a target device based on an association relationship. The uplink processing includes: an interface management module receiving raw communication data from the target device through a target physical communication interface bound to a target protocol driver instance, and sending the raw communication data to a protocol driver management module; and a protocol driver management module receiving the raw communication data, parsing the device physical address from the raw communication data, determining the target protocol driver instance corresponding to the device physical address based on the association relationship, driving the target protocol driver instance to perform protocol parsing on the raw communication data to obtain protocol data, and sending the protocol data to a product parsing management module. The system consists of a device management module and a product parsing management module. The product parsing management module, based on the association relationship, determines the target product parsing program and object model file corresponding to the device's physical address. It then drives the target product parsing program to perform product semantic parsing on the protocol data according to the object model file, obtaining device data with clear business meaning. This device data and its corresponding physical address are then sent to the device management module. The device management module, after associating the device data with its physical address, sends the resulting data to the data management module. Finally, the data management module standardizes and encapsulates the received data, forming a reporting data message, which is then sent to an external program source, completing the data reporting for the target device.

[0012] Preferably, the system is used to perform downlink processing on downlink messages sent by an external program source based on association relationships. The downlink processing includes: a data management module receiving downlink messages from an external program source and decapsulating them to obtain the target device's physical address and control parameters; a device management module querying the target association relationships formed by the target device's physical address, determining the target product port identifier and target driver port identifier based on these relationships, and sending these identifiers and control parameters to a product parsing management module; a product parsing management module calling the target product parsing program corresponding to the target product port identifier, converting the control parameters into protocol instructions based on the object model file associated with the parsing program, and sending the protocol instructions and target driver port identifier to a protocol driver management module; a protocol driver management module calling the target protocol driver instance corresponding to the target driver port identifier, encoding the protocol instructions into a raw control byte stream, and sending the raw control byte stream to an interface management module; and an interface management module sending the raw control byte stream to the target device through the physical communication interface bound to the target protocol driver instance, completing the data transmission to the target device.

[0013] Preferably, the system is further configured to remove the target device protocol, wherein the removal process includes: a device management module, which, in response to a removal command for the target device, deletes the association corresponding to the device's physical address; a product parsing management module, which, when it detects that all associations corresponding to the target product parsing program have been deleted, uninstalls the target product parsing program and its associated object model files; and a protocol driver management module, which, when it detects that all product parsing programs depended on by the target protocol driver instance have been uninstalled, uninstalls the target protocol driver instance.

[0014] Preferably, the system further includes a remote service module and an external program source with a communication connection, the external program source being an IoT cloud platform; the remote service module, located at the edge gateway, is used to communicate with the IoT cloud platform based on a pre-configured model context protocol, receive interface configuration files, target protocol drivers, target product parsing programs and their associated object model files, and access instructions issued by the IoT cloud platform, and distribute the interface configuration files to the interface management module, the target protocol drivers to the protocol driver management module, the target product parsing programs and their associated object model files to the product parsing management module, and the access instructions to the device management module.

[0015] Preferably, the IoT cloud platform includes: a product and driver repository for storing various protocol drivers, various product parsing programs, and multiple object model files associated with each product parsing program; and a device configuration service module for providing a user configuration interface, receiving device access information input by the user based on the user configuration interface, and generating access instructions based on the device access information. The device access information includes interface configuration parameters and device identification information. The interface configuration parameters include the interface type corresponding to the target device protocol. The interface configuration parameters are used to configure the communication environment of the physical communication interface of the edge gateway.

[0016] Preferably, the product and driver repository includes an AI-assisted generation module, which is used to: receive target device protocol description information input by the user; parse the target device protocol description information based on a preset protocol driver template to generate a target protocol driver; and / or, receive product function definition information input by the user; parse the product function definition information based on a preset object model template to generate a target product parsing program and a target object model file.

[0017] This application embodiment dynamically acquires and instantiates the driver program corresponding to the target device protocol through the protocol driver management module, directly replacing the traditional approach of relying on pre-built protocol drivers in firmware. This allows the edge gateway to support new or proprietary protocols without manufacturer intervention or firmware upgrades. The product parsing management module synchronously acquires the target product parsing program that matches the protocol, ensuring that the raw data of newly connected devices can be parsed into standardized information in real time and accurately. The device management module automatically associates the device identifier, protocol driver instance, and product parsing program when a device is connected, enabling plug-and-play functional access for new devices. This transforms the device access process from traditional firmware iteration dependency to dynamic configuration, greatly improving the edge gateway's adaptability and rapid expansion capabilities for heterogeneous device protocols.

[0018] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This illustration shows a schematic diagram of the structure of an IoT device access system based on a model context protocol, as provided in an embodiment of this application. Figure 2 This illustration shows a schematic diagram of another IoT device access system based on the Model Context Protocol provided in an embodiment of this application; Figure 3 A flowchart illustrating the uplink processing procedure provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating the downlink processing procedure provided in an embodiment of this application is shown; Figure 5 A flowchart illustrating the removal process provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the structure of the Internet of Things cloud platform provided in an embodiment of this application is shown.

[0020] The reference numerals in the detailed embodiments are as follows: 1. IoT device access system based on Model Context Protocol; 11. Edge Gateway; 111. Interface Management Module; 112. Protocol Driver Management Module; 113. Product Resolution Management Module; 114. Device Management Module; 115. Data Management Module; 116. Remote Service Module; 12. External program source; 13. IoT cloud platform; 131. Product and driver repository; 1311. Artificial intelligence-assisted generation module; 132. Device configuration service module. Detailed Implementation

[0021] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0022] Currently, mainstream edge gateways typically come pre-installed with gateway functionality for several protocols. Before deployment, users must confirm whether the selected gateway supports the specific protocols they require. For example, consider a scenario requiring OPC protocol sensor access: if a gateway only has pre-installed gateway functionality for DLT645-2007, CJ-T188-2004, and Modbus-RTU protocols, then this gateway will not meet the OPC protocol access requirements. In this case, the user must return the device to the manufacturer for a new gateway firmware version that supports the OPC protocol.

[0023] In this traditional model, the developer's workflow is as follows: first, develop new firmware that integrates OPC protocol support; then, based on this firmware, edit the product definition corresponding to the OPC protocol; after successful integration testing, return the updated gateway to the field. Correspondingly, the user's workflow is: select a gateway model that supports the OPC protocol, choose the corresponding product definition in the configuration interface, and enter information such as the device address to complete the device connection.

[0024] The fundamental problem with this model lies in its highly coupled architecture. Traditional edge gateways tightly integrate protocol drivers, product definition parsing, and product-specific parsing programs within the application layer. Once the gateway application is developed and solidified into firmware, the types of protocols, products, and parsing capabilities it can support are permanently limited, making on-demand dynamic installation and loading impossible.

[0025] Furthermore, the accompanying IoT cloud platforms typically only provide a basic device management interface and lack the ability to dynamically load product parsing programs and product definition files. Users can only learn about which protocols and products the gateway supports by default through documentation, and their access scope is strictly limited to a pre-adapted, finite set. This means that adding any device to the IoT cloud platform requires that the corresponding protocol driver, product definition, and dedicated parser program have all been pre-developed in the gateway firmware. For a completely new type of device, it is necessary to go through three complete steps: protocol driver development, product definition creation, and dedicated parser program development, and integrate them all into the new firmware before the user can successfully add the device in the management interface.

[0026] In summary, the core flaw of traditional solutions lies in the deep coupling between the edge gateway's southbound protocol driver, product-specific parser, and product definitions and the gateway's main program. Any requirement for a new protocol inevitably necessitates the complete redevelopment, testing, and re-release of the gateway's main program.

[0027] Based on this, the inventors of this application have discovered that the functions of multiple threads related to new protocols in an edge gateway can be decoupled to improve the edge gateway's ability to extend to heterogeneous device protocols. Specifically, Figure 1 This illustration shows a schematic diagram of the structure of an IoT device access system 1 based on a model context protocol, as provided in an embodiment of this application. Figure 1 The IoT device access system based on the Model Context Protocol (hereinafter referred to as "System") 1 shown includes: a protocol driver management module 112 located on the edge gateway 11, used to obtain the target protocol driver corresponding to the target device protocol and instantiate the target protocol driver into a target protocol driver instance, wherein the target device protocol is a newly added protocol type; a product parsing management module 113 located on the edge gateway 11, used to obtain the target product parsing program corresponding to the target device protocol; and a device management module 114 located on the edge gateway 11, used to: respond to the access command of the target device, obtain the device identification information of the target device, wherein the target device and the edge gateway 11 communicate based on the target device protocol; and establish the association relationship between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device.

[0028] The protocol driver management module 112, as the core control hub of the southbound interface of the edge gateway 11, is used to deeply decouple the originally coupled heterogeneous protocol processing threads, thereby giving the edge gateway 11 the ability to dynamically extend heterogeneous device protocols. For example, if the edge gateway 11 only has gateway functions for three protocols—DLT645-2007, CJ-T188-2004, and Modbus-RTU—it will not be able to meet the access requirements of the OPC protocol. Since the OPC protocol is a new protocol type, the edge gateway 11 needs to be further endowed with the ability to extend the OPC protocol. The protocol driver management module 112 is not only responsible for the overall management of the loading, unloading, starting, and stopping of the protocol stack and various communication protocols, but also completely abandons the dependence on traditional firmware pre-installation, and has the ability to dynamically obtain and load external drivers through specific communication channels.

[0029] Optionally, the external program source 12 is an IoT cloud platform. The protocol driver management module 112 establishes a connection with the IoT cloud platform's MCP Server C through the RemoteService C application deployed inside the edge gateway 11, based on the Model Context Protocol (MCP). The RemoteService C application acts as the MCP server. When a developer uploads a file through MCP Server A, the IoT cloud platform uses the MCP protocol based on JSON-RPC 2.0 format to distribute the file stream, thus achieving the process of accurately receiving the target protocol driver from the external program source 12. The target protocol driver referred to here is the carrier for data communication between the edge gateway 11 and the target device. It encapsulates the complete underlying logic required for a specific communication protocol (such as serial communication or TCP / IP communication), covering key functions such as timing control, checksum calculation, and message assembly and disassembly.

[0030] Upon receiving the target protocol driver file (such as a .so dynamic library file or a .py script file, including files for handling protocols such as Modbus RTU, OPC UA, DLT645, and CJ-T188), the protocol driver management module 112 immediately instantiates it. This process utilizes the dynamic link library loading interface provided by the operating system (such as the dlopen function under Linux) to load the static driver file into memory, assign it an internal port number (e.g., port number 001), and initialize runtime data such as callback function tables and buffers, thereby forming an independent target protocol driver instance that can be called by the system. Each instance is assigned a unique identifier to distinguish it from other protocol driver instances. This generation of the runtime object enables the edge gateway 11 to acquire the ability to handle new protocol types without restarting the main program, achieving hot-plugging of protocol drivers.

[0031] At the semantic layer of the data link, the product parsing management module 113 undertakes the core functions of device business logic deconstruction and data semantic interpretation. The product parsing management module 113 manages the object model, which is a digital abstraction of the physical entities in the digital twin. Based on the object model, the device's attributes, services, and events can be rigorously defined. This definition is specifically described through the object model file, which defines the data structure and business rules followed by the target product parsing program when processing data, ensuring accurate and consistent data interaction within the digital twin. While acquiring and loading the object model file, the product parsing management module 113 also receives the corresponding target product parsing program. The target product parsing program is the key logical entity that interprets the specific business meaning of the target device data. Based on the object model definition, it is responsible for further translating the structured data (such as function codes, register addresses, and values) parsed from the target protocol driver instance into a standardized data format (such as key-value pairs {key name: key value}) that upper-layer applications can understand. For example, it converts the hexadecimal data of register 40001 into a floating-point value of "current temperature" with business meaning.

[0032] The object model file typically uses a structured data format, which details the functional points of the device and specifies the data type, value range, unit, and read / write permissions for each functional point, forming a dictionary for the edge gateway 11 to understand the meaning of the device data.

[0033] As the scheduling center of the entire system, the device management module 114 is responsible for maintaining the device list, handling device registration and deregistration, and managing data routing, thereby establishing the binding relationship between the underlying physical devices and the upper-layer software logic. When the device management module 114 responds to control commands (such as MQTT messages or WebSocket commands) from the IoT cloud platform or local operation interface, it is activated to execute subsequent operations. Specifically, when a message containing an add device command and specifying the target device parameters is detected, the device management module 114 begins to obtain the device identification information of the target device. This information can be designed as a composite format (such as "HalAddr_pid_drvId"), containing the device physical address, the product parser port number, and the protocol driver port number. Subsequently, the device management module 114 creates a new entry in the device list in memory, records the device physical address (such as address 08), and fills in the associated target protocol driver instance port number (such as 001) and target product parser port number (such as 002). This data binding operation based on a hash table or tree structure tightly associates the device identification information, the target protocol driver instance, and the target product parser. At this point, the system has completed the functional access of the target device, marking that the edge gateway 11 has established a complete link from obtaining the raw data stream from the physical interface, through protocol-driven parsing and product parsing translation, until standardized data is uploaded to the cloud platform. The IoT platform now has the function of remote monitoring and control of the target device.

[0034] The following explanation uses a new type of thermostat X1 that uses a proprietary protocol as an example. Initially, the edge gateway 11 does not have built-in support for this protocol. First, the developer uses an Artificial Intelligence (AI) tool or IDE to generate the target protocol driver for the thermostat X1 (e.g., "Drv_X1.so") and the target product parser program (e.g., "X1_Parser.so" and "PX1config.json"), which define the attributes "temperature" and "setpoint," and uploads them to the external program source 12 via the MCP channel. Next, the protocol driver management module 112 obtains and instantiates the driver file through RemoteService C, loads it into memory, allocates port number 001, and generates a target protocol driver instance; simultaneously, the product parsing management module 113 obtains the parser program and configuration file, loads the logic, and allocates port number 002. Subsequently, when the device management module 114 responds to the addition command for the thermostat X1 issued by the external program source 12, it obtains its device identification information (such as address 08), establishes an association, and generates a unique device ID (such as "08_002_001") containing the device address, product parsing port, and protocol driver port. Finally, when the thermostat X1 reports data, the data stream is accurately routed to the corresponding protocol driver instance for parsing based on the device ID, and then translated into business data by the product parsing instance for uploading, thus verifying the effectiveness of the dynamic expansion mechanism.

[0035] Through dynamic acquisition and instantiation mechanisms, the access cycle for new devices can be shortened from weeks to minutes; the deep decoupling of protocol drivers and product parsing programs from the main application not only reduces the risk of system crashes but also greatly improves the maintainability and reusability of the software; and the on-demand loading feature significantly saves the memory and storage resources of the edge gateway, improving system performance; relying on the combination of the MCP protocol and AI-assisted tools, the threshold for driver development is greatly reduced, effectively supporting the rapid access needs of massive and heterogeneous devices in the Industrial Internet of Things.

[0036] Specifically, the external program source 12 can be deployed on a private server or local management platform within the same internal network as the edge gateway 11, or it can be located on the public internet, such as... Figure 6 The IoT cloud platform 13 shown is an example of an alternative remote server. Optionally, such as... Figure 2 As shown, external program source 12 can be set inside the system to form system 1, or, as... Figure 1 As shown, external program source 12 is set outside the system.

[0037] Optionally, such as Figure 1As shown, System 1 may only include the decoupled functional modules of the interface management module 111 to the remote service module 116 in the edge gateway 11, without including other applications and firmware layers unrelated to the core functions to be implemented in this application, such as the basic operating system and hardware drivers. Alternatively, it may include, for example... Figure 2 As shown, System 1 includes the entire physical entity and all software functions of Edge Gateway 11.

[0038] To further optimize the architecture of the IoT device access system 1 based on the Model Context Protocol (MTP), an interface management module 111 and a data management module 115 can be introduced to construct a complete chain from the underlying physical interface configuration to the upper-layer cloud data interaction. Preferably, the system 1 further includes: an interface management module 111 located on the edge gateway 11, used to: receive an interface configuration file for a target physical communication interface, wherein the interface configuration file includes the parameter configuration of the target physical communication interface and the identifier of the target protocol to be bound; initialize the target physical communication interface in the edge gateway 11 according to the parameter configuration; bind the initialized target physical communication interface to the target protocol driver instance according to the identifier of the target protocol to be bound, so as to realize the data interaction between the target device and the edge gateway 11 based on the target physical communication interface; and a data management module 115 located on the edge gateway 11, used to interact with the external program source 12 in a standardized data format.

[0039] The interface management module 111 is located within the edge gateway 11, serving as a bridge connecting the underlying hardware and the upper-layer protocol driver management. It manages the physical communication interfaces of the edge gateway 11, ensuring that target devices can access the gateway with the correct hardware parameters and accurately transmit data to the corresponding protocol driver instance. The interface management module 111 manages the target physical communication interfaces, i.e., the hardware interfaces on the edge gateway 11 used to connect to external physical devices, covering common interfaces in industrial IoT scenarios such as RS485 serial interfaces, Ethernet interfaces (ETH_RJ45), and CAN bus interfaces. In this application, these interfaces abandon the traditional hard-coded firmware model and instead adopt a dynamically configurable architecture.

[0040] The workflow of the interface management module 111 begins with the execution of a receiving action, namely obtaining the interface configuration file from the external program source 12. This process is based on the MCP connection established between the RemoteService C application deployed inside the edge gateway 11 and the MCP Server C in the IoT cloud platform 13. After the user completes the configuration in the cloud, the interface configuration file, which contains parameter configurations and binding relationships, is sent to the edge side. The interface configuration file specifically includes the parameter configurations required to initialize the target physical communication interface, such as baud rate, data bits, parity bits, stop bits, or IP address values, as well as the identifier of the target protocol to be bound, indicating the direction of data flow.

[0041] After obtaining the interface configuration file, the interface management module 111 performs initialization actions according to the parameters configured in the file. It calls the driver interface of the underlying operating system (such as Linux), such as system calls like ioctl or open, to write parameters such as the baud rate into the gateway's hardware registers or configure the serial port chip, thereby activating the interface and putting it in a ready state, capable of sending and receiving physical electrical signals. Next, the interface management module 111 performs binding actions according to the target protocol identifier in the interface configuration file. The target protocol identifier uniquely identifies the target protocol driver instance, typically corresponding to the port number (e.g., 001) after the protocol driver is instantiated. Connecting the target physical communication interface to a specific target protocol driver instance, the interface management module 111 maintains a mapping table in memory, associating the interface's device file handle (e.g., / dev / ttyUSB0) with the port number or memory address of the target protocol driver instance. This ensures that when the interface reads raw byte data, it can directly look up the table and accurately deliver it to the corresponding protocol driver instance.

[0042] Continuing with the example of thermostat X1 connecting to edge gateway 11, assuming the protocol driver management module 112 has already acquired and instantiated the thermostat X1 driver (port number 001), the user selects to connect to serial port 1 on the IoT cloud platform 13 (external program source 12) and sets the baud rate to 9600 and the station number to 8. The IoT cloud platform 13 generates and distributes an interface configuration file containing parameter configurations and the target protocol identifier 001 to be bound. After receiving the file, the interface management module 111 parses the parameter configuration, calls the operating system interface to initialize serial port 1 to 9600 baud rate mode and opens listening. Subsequently, the interface management module 111 reads the target protocol identifier 001 to be bound and establishes a binding record between serial port 1 and protocol driver instance 001 in the internal mapping table. When thermostat X1 reports raw data through the serial port, the interface management module 111 reads the data and directly delivers it to the protocol driver instance 001 for parsing according to the binding relationship; conversely, control commands can also be sent to thermostat X1 via serial port 1 through the reverse path.

[0043] At the top layer of the data link, this application sets up a data management module 115, which serves as the final exit and entry point for data exchange between the edge gateway 11 and the external program source 12. The data management module 115 is responsible for data format standardization, data aggregation, and cloud communication connection management. The external program source 12 typically refers to an IoT cloud platform located outside the edge gateway 11, providing device management, data storage, and visualization services. The data management module 115 and the external program source 12 conduct bidirectional data communication through interactive actions. This interaction is based on a message queue telemetry transmission protocol and specifically covers both uplink and downlink data processes.

[0044] During data uplink, the data management module 115 obtains parsed business data from the device management module 114 and encapsulates it into a standardized data format. This format aims to shield underlying protocol differences and typically employs a key-value pair structure containing device identifiers and business data, such as JSON. The data management module 115 connects to the MQTT Broker of the external program source 12 via its built-in MQTT client, publishing the encapsulated data to the corresponding topic to achieve data reporting. During data downlink, the data management module 115 subscribes to control topics sent from the cloud, receives control commands from the external program source 12, parses the standardized data format to extract the device ID and control value, and then passes them to the device management module 114, thereby triggering a reverse control flow from device management to interface management.

[0045] Continuing with the example of thermostat X1, after its temperature data is processed by the preceding modules and converted into business-meaning data, the data management module 115 confirms the device's unique identifier as 08_002_001 and encapsulates the data into a standardized data format (such as a message containing deviceId 08_002_001 and temperature 17.0). This data is then published to the cloud platform's telemetry topic via the MQTT protocol, enabling remote monitoring of the temperature data. When the user adjusts the thermostat X1's set temperature to 25℃ in the cloud, the IoT cloud platform 13 generates a standardized message containing this instruction and publishes it to the control entity. The edge gateway 11's data management module 115 receives and parses the instruction, identifies the target device as 08_002_001 and the operation value as 25.0, and then passes the instruction to the device management module 114. The instruction is then sequentially converted into a register value by the product parsing instance, encapsulated by the protocol driver instance, and sent to the physical device by the interface management module 111, ultimately completing the temperature parameter setting for thermostat X1.

[0046] By introducing the interface management module 111 and the data management module 115, together with the aforementioned protocol driver management module 112, product parsing management module 113, and device management module 114, a fully functional IoT device access system 1 is formed. This architecture achieves complete decoupling and dynamic adaptation of software and hardware interfaces, so that the physical layer interface configuration is no longer coupled with the upper layer protocol. The same physical interface can be bound to different protocol driver instances at different times, which greatly improves the utilization of hardware resources. At the same time, the standardized cloud interaction channel established by the data management module 115 shields the complexity of the underlying industrial protocols, so that the external program source 12 only needs to process a unified standardized data format to access a large number of heterogeneous devices, which significantly reduces the complexity of system integration. Combined with remote configuration distribution and standardized data reporting, this application supports a highly automated operation and maintenance process, which can complete device access and configuration without on-site personnel intervention, effectively reducing the operation and maintenance costs and manpower requirements in the industrial IoT environment.

[0047] Preferably, the product analysis management module 113 is also used to obtain the object model file associated with the target product analysis program.

[0048] In addition to loading and managing the target product parsing program, the product parsing management module 113 is also used to obtain the object model file closely associated with the target product parsing program. As the core descriptive carrier of device digitization, the object model file defines the data structure and business rules followed by data processing, enabling the edge gateway 11 to transform the underlying byte stream into business information with actual physical meaning, thereby establishing a precise semantic mapping relationship between protocol data and upper-layer business applications.

[0049] The product parsing management module 113, as the management unit within the edge gateway 11 responsible for loading, maintaining, and interpreting device business logic and data semantics, acts as a bridge connecting the underlying protocol data and the upper-layer business applications. It not only manages executable parsing program code but can also receive structured object model files from external program sources 12 (such as IoT cloud platforms). This receiving process is also based on the model context protocol. After the developer completes the product definition and uploads the object model file and parsing program in the cloud, the edge gateway 11 receives the data stream through its built-in communication service, identifies the file type, and transmits it to the product parsing management module 113.

[0050] To achieve accurate conversion of data from bitstreams to business information, the object model file clearly defines the data structure and business rules. The data structure defines the logical organization of data storage and transmission; for example, defining the data format of a specific register as floating-point, guiding the parser to interpret hexadecimal data as 17.0 instead of two integers. Business rules define the logical constraints or operational rules for data processing and conversion; for example, stipulating that the raw value read from a register must be divided by 10 to obtain the actual physical value, or setting a temperature alarm threshold. These rules guide the target product parser to perform corresponding calculations or judgments when processing data, ensuring that the output data conforms to the standardized specifications of business requirements.

[0051] After acquiring the object model file, the product parsing management module 113 logically binds the object model file to the target product parsing program. When loading the target product parsing program to generate an instance, the product parsing management module 113 passes the path or content handle of the object model file as an initialization parameter to the parsing program instance. This association mechanism ensures that the parsing program can read the definitions in the object model file in real time during runtime. For example, when the parsing program needs to parse a certain data point, it will query the associated object model file to obtain the data type and conversion formula of that data point, thus decoupling the parsing program from the specific device parameter definitions. The same parsing program can adapt to the same type of device model with slightly different parameters by loading different object model files, thereby improving the system's compatibility and flexibility.

[0052] Continuing with the example of accessing the thermostat X1, the developer generates a physical model file containing attribute temperature and setpoint definitions, scaling factors, and business rules based on the product manual, and uploads it along with the parsing program to the IoT cloud platform 13. Upon receiving the add request, the IoT cloud platform 13 distributes the file to the edge gateway 11 via the model context protocol. The product parsing management module 113 receives and loads the parsing program instance, and simultaneously performs an association action, registering the path of the physical model file to that instance. When the thermostat X1 reports data, the protocol driver instance parses the raw data into protocol data with a value of 170 in register 40001, and then sends the data to the target product parsing program instance. At this point, the parsing program processes the data based on the associated physical model file: first, it checks the data structure definition to confirm the attribute and data type corresponding to register 40001; then, it checks the business rules to find that the scaling factor is 0.1; finally, it calculates 170 multiplied by 0.1, generating the final device data of 17.0℃. Without the guidance of the physical model file, the parsing program can only output the raw value 170, failing to accurately express the Celsius unit and its actual physical meaning.

[0053] By acquiring and associating object model files through the product parsing management module 113, standardization of data semantics and deep decoupling of business logic are achieved. The edge gateway 11 no longer hardcodes data processing logic for specific devices; when faced with different device models under the same protocol, only the corresponding object model file needs to be replaced without recompiling the program. Simultaneously, the object model file, stored as a text-formatted configuration item, supports hot updates in the cloud, significantly reducing maintenance costs after device access. Furthermore, as a mandatory specification, the object model file ensures that data processing strictly adheres to the defined data structure and business rules, avoiding type mismatches or unit confusion that may result from manual coding. This provides a high-quality, accurate, and consistent data foundation for external program sources 12, strongly supporting agile operation and maintenance and intelligent decision-making in the industrial IoT environment.

[0054] To further illustrate the process of constructing logical connections in the device management module 114, preferably, the device identification information includes the device physical address, device protocol attributes, and device product type attributes. Establishing the association between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device includes: based on the device protocol attributes, determining the target protocol driver instance corresponding to the target device from multiple protocol driver instances in the protocol driver management module 112, and assigning a driver port identifier to the target protocol driver instance; based on the device product type attributes, determining the target product parsing program corresponding to the target device from multiple product parsing programs in the product parsing management module 113, and assigning a product port identifier to the target product parsing program; and establishing the association between the device physical address, driver port identifier, and product port identifier to complete the functional access of the target device.

[0055] In this application, device identification information is defined as a composite set of information used in System 1 to uniquely identify and locate target devices. This set includes not only single location information but also communication and product model characteristics, specifically including the device physical address, device protocol attributes, and device product type attributes. The device physical address refers to the specific location identifier of the target device on the physical communication link, such as the station number of an RS485 bus, the IP address and port number of a TCP / IP network, or the node ID of a CAN bus. It is the primary basis for the edge gateway 11 to establish a physical connection with the target device. The device protocol attribute refers to the specific identifier of the communication protocol used by the target device, such as Modbus RTU, DLT645, or a specific proprietary protocol, used to distinguish different communication mechanisms. The device product type attribute refers to the product category or model identifier of the target device, such as thermostat X1, which determines the specific business semantics after data parsing.

[0056] To enable functional access, the device management module 114 executes a process to establish associations, specifically encompassing a series of logical actions such as instance determination, port identifier allocation, and final binding. First, based on the device protocol attributes, the device management module 114 determines the target protocol driver instance corresponding to the target device from multiple protocol driver instances managed by the protocol driver management module 112. During this process, module 114 parses the protocol attributes in the access command and queries the list of loaded drivers in the protocol driver management module 112. The protocol driver management module 112 assigns a unique driver port identifier to the driver when loading it; this identifier is the identity ID of the protocol driver instance running within the edge gateway 11. By matching the device protocol attributes with the driver port identifier, the device management module 114 locks the target protocol driver instance, ensuring that device data is parsed and processed by the correct protocol driver.

[0057] Subsequently, based on the device product type attribute, the device management module 114 determines the target product parsing program corresponding to the target device from multiple product parsing programs managed by the product parsing management module 113. Module 114 parses the product type attribute in the access command and queries the list of parsing programs already loaded in the product parsing management module 113. The product parsing management module 113 also assigns a unique product port identifier when loading a parsing program. Module 114 matches the device product type attribute with the product port identifier to determine the target product parsing program, ensuring that the data can be translated into correct business semantics.

[0058] After completing the above steps, the device management module 114 performs the final action of establishing the association relationship, that is, constructing a mapping between the device physical address, driver port identifier, and product port identifier. The device management module 114 generates a composite device ID in memory, logically stitching the physical address, product port identifier, and driver port identifier together. For example, the generated ID may contain a sequence of physical address, product port identifier, and driver port identifier. Module 114 stores this ID in a maintained device list. When subsequent data transmission occurs, the system can instantly determine the physical interface of the data source, the protocol driver instance to be invoked, and the business parsing program to be used by parsing this ID. This three-in-one association design is the key mechanism for achieving flexible access for multiple devices, multiple protocols, and multiple products in this application.

[0059] Continuing with the example of thermostat X1, assuming the protocol driver management module 112 has assigned driver port identifier 001 to the thermostat X1's driver, and the product parsing management module 113 has assigned product port identifier 002 to its parsing program, the user inputs the device physical address 08, selects the device protocol attribute as X1 private protocol, and the device product type attribute as thermostat X1 on the IoT cloud platform 13. After responding to the command, the device management module 114 locks the instance corresponding to driver port identifier 001 according to the protocol attribute, locks the instance corresponding to product port identifier 002 according to the product type attribute, and establishes a device ID association including address 08, port 002, and port 001. From this point on, the edge gateway 11 establishes the complete path for the data flow of physical address 08, which must be parsed by driver 001 and then translated by parsing 002.

[0060] Through the refined parsing and association of device identification information by the device management module 114, the device ID adopts a composite structure combining physical address, product port, and driver port. This enables the edge gateway 11 to support high-density heterogeneous device hybrid access. Even if a large number of different models of devices are connected to the same interface, the system can accurately distinguish them through a unique ID. Simultaneously, based on the mapping relationship between driver port identifiers and product port identifiers, compared to traditional name matching, the routing method based on numeric IDs significantly improves the efficiency and accuracy of data processing, effectively avoiding routing errors. Furthermore, this attribute-based dynamic binding mechanism eliminates the need for the device management module 114 to rely on hard-coded address mapping tables. When device attributes need to be adjusted or new device types need to be added, no modification to the core code is required; only the port identifier mapping relationship needs to be updated, thus ensuring the long-term scalability and maintainability of the system.

[0061] To further illustrate the uplink processing of data from the target device to the external program source 12 in System 1, Figure 3 A flowchart illustrating the uplink processing procedure provided in an embodiment of this application is shown, as follows: Figure 3 As shown, preferably, the system is used to perform uplink processing on communication data sent by the target device based on the association relationship, wherein the uplink processing includes S211~S215: S211, the interface management module 111 receives raw communication data from the target device through the target physical communication interface bound to the target protocol driver instance, and sends the raw communication data to the protocol driver management module 112.

[0062] In the initial stage of uplink processing, the interface management module 111 performs a receiving action through the target physical communication interface bound to the target protocol driver instance. At this time, the target device sends raw communication data, i.e., an unprocessed signal bit stream or byte sequence, such as a string of hexadecimal code, containing only physical layer electrical signal information. The interface management module 111 uses system calls at the operating system level to read this data from the interface buffer and transmits it to the protocol driver management module 112 through inter-process communication mechanisms, completing the data transfer from the hardware layer to the software protocol layer.

[0063] S212, the protocol driver management module 112 receives the original communication data, parses the device physical address from the original communication data, determines the target protocol driver instance corresponding to the device physical address based on the association relationship, drives the target protocol driver instance to perform protocol parsing on the original communication data, obtains protocol data, and sends the protocol data to the product parsing management module 113.

[0064] The protocol driver management module 112 receives the raw communication data and initiates the parsing process. First, the protocol driver management module 112 extracts the device physical address from the data frame, such as the station number under the Modbus protocol, and determines the target protocol driver instance corresponding to that physical address based on the previously established association. Subsequently, the protocol driver management module 112 drives this instance to execute specific protocol parsing logic, unpacking, verifying, and converting the raw byte stream into protocol data. At this point, the protocol data has a basic protocol structure, including function codes, register addresses, and raw values. For example, function code 03 represents reading a register, with an address of 40001 and a value of 0x4110, but it still lacks a specific physical meaning.

[0065] S213, the product parsing management module 113 determines the target product parsing program and object model file corresponding to the device physical address based on the association relationship, drives the target product parsing program, performs product semantic parsing on the protocol data according to the object model file, obtains device data with clear business meaning, and sends the device data and the corresponding device physical address to the device management module 114.

[0066] The product parsing management module 113 receives protocol data and performs deep semantic processing. Based on association relationships, the product parsing management module 113 determines the corresponding target product parsing program and its associated object model file. By driving the target product parsing program, the system 1 performs product semantic parsing on the protocol data according to the data structure and business rules defined in the object model file. This process uses the object model definition to map abstract register addresses and values ​​to specific business attributes. For example, the value of register 40001 is converted to a temperature value according to the IEEE 754 floating-point standard and scaling factor, ultimately generating device data with clear business meaning, such as a key-value pair format containing the temperature value 17.0.

[0067] S214, the device management module 114 sends the data formed by associating device data with device physical address to the data management module 115.

[0068] The device management module 114 receives the aforementioned device data. To ensure data traceability, the device management module 114 performs an association action, binding the device data with the device's physical address or complete device ID to add an identity tag to the data, ensuring that subsequent processing steps can accurately identify the data source and transform the device data into a complete information package with device identification.

[0069] S215, the data management module 115 standardizes and encapsulates the received data to form a reporting data message, and sends the reporting data message to the external program source 12 to complete the data reporting to the target device.

[0070] The data management module 115 performs standardized encapsulation. The data management module 115 serializes the device data carrying the device identity according to the standard format agreed upon by the external program source 12, converting it into text formats such as JSON or XML, and adding metadata such as timestamps and message type identifiers to form a reporting data message. This message is sent to the external program source 12 via communication protocols such as MQTT, completing the full reporting of data from the edge to the cloud.

[0071] Taking the data reporting of thermostat X1 as an example, its original hexadecimal data stream is captured and transmitted by the interface management module 111 in stage S211; in stage S212, the protocol driver management module 112 locks the driver instance 001 by parsing the station number and parses the byte stream into protocol data containing address 40001 and value 0x4110; in stage S213, the product parsing management module 113, based on the object model file, uses parsing program 002 to convert the value 0x4110 into business temperature data of 17.0; in stage S214, the device management module 114 associates the temperature data with the device ID; in stage S215, the data management module 115 encapsulates it into a standard JSON message and sends it to the cloud. The entire uplink processing flow, through clear stage division, realizes the pipelined data processing, which not only improves the overall throughput of the system, but also shields the underlying protocol differences through a standardized encapsulation mechanism, ensuring high data accuracy and traceability, and significantly reducing the development complexity of cloud applications.

[0072] To further illustrate the downlink processing flow of System 1 in a remote control scenario, Figure 4 A flowchart illustrating the downlink processing procedure provided in an embodiment of this application is shown, as follows: Figure 4 As shown, preferably, the system is used to perform downlink processing on downlink messages sent by external program source 12 based on association relationships, wherein the downlink processing includes S221~S225: S221, the data management module 115 receives downlink packets from the external program source 12 and performs decapsulation processing on the downlink packets to obtain the target device physical address and control parameters.

[0073] The downlink processing begins when the data management module 115 receives a downlink message from the external program source 12. This message is a network data packet intended to change the operating state of the target device, typically a payload based on the MQTT protocol. The data management module 115 then performs decapsulation processing, removing the transport layer packet and performing deserialization to parse the core control parameters and the target device's physical address from the standard format message. At this stage, the control parameters represent the specific values ​​or states that the user expects the device to perform, such as a set temperature value, representing the operational intent at the business layer, but not yet converted into register values ​​at the device's underlying level.

[0074] S222, the device management module 114 queries the target association relationship formed by the target device physical address based on the target device physical address, determines the target product port identifier and the target driver port identifier based on the target association relationship, and sends the target product port identifier, the target driver port identifier and the control parameters to the product parsing management module 113.

[0075] Subsequently, the device management module 114 retrieves the device list in memory to query the target association relationship based on the extracted target device physical address. This association relationship is a data structure describing the mapping relationship between the target device and each software module. Through the query, the device management module 114 determines the target product port identifier and target driver port identifier corresponding to the device, and sends the target product port identifier, target driver port identifier, and control parameters to the product parsing management module 113. This process completes the accurate mapping from business objects to software processing objects.

[0076] S223, the product parsing management module 113 calls the target product parsing program corresponding to the target product port identifier, and converts the control parameters into protocol instructions based on the object model file associated with the target product parsing program, and sends the protocol instructions and the target driver port identifier to the protocol driver management module 112.

[0077] In the product parsing management module 113, System 1 calls the corresponding target product parsing program based on the target product port identifier and executes conversion logic according to the object model file associated with the program. This process converts the control parameters at the business layer into protocol instructions that conform to specific industrial protocol specifications. For example, based on the data type and scaling factor defined in the object model, the temperature setpoint 25.0 is converted into a register write value of 250. The generated protocol instructions, as application layer data units, are transmitted to the protocol driver management module 112 along with the target driver port identifier.

[0078] S224, the protocol driver management module 112 calls the target protocol driver instance corresponding to the target driver port identifier, encodes the protocol instructions into a raw control byte stream, and sends the raw control byte stream to the interface management module 111.

[0079] After receiving the protocol instruction, the protocol driver management module 112 calls the target protocol driver instance corresponding to the target driver port identifier to perform the encoding action. The driver instance assembles the protocol instruction into a complete data frame containing address code, function code, data field, and checksum, according to the protocol specification, generating a raw control byte stream that the target device hardware can directly recognize. This bit sequence encapsulates all the underlying communication details.

[0080] S225, the interface management module 111 sends the raw control byte stream to the target device through the physical communication interface bound to the target protocol driver instance, thus completing the data transmission to the target device.

[0081] Finally, the interface management module 111 executes the data transmission action, writing the raw control byte stream to the physical communication interface bound to the target protocol driver instance via a system call. Electrical signals are transmitted to the target device through physical lines. The device hardware parses the frame structure and executes the instructions, thus completing the data transmission and ensuring that control commands can penetrate complex network and protocol layers to accurately act on the physical entity.

[0082] Taking the remote temperature setting of thermostat X1 as an example, the user inputs a setting value of 25℃ in the cloud, generating a downlink message containing the device ID and control parameters. After the data management module 115 parses the message and extracts the information, the device management module 114 locks the associated product port 002 and driver port 001 based on the device ID. The product parsing management module 113 converts 25.0 into a register value of 250 based on the object model and generates a write register instruction. The protocol driver management module 112 encodes this instruction into a raw byte stream containing station number 08, function code, and data. The interface management module 111 sends this byte stream to the thermostat X1 via the serial port. After receiving the stream, the device adjusts the temperature setting value to 25.0.

[0083] Through a strictly defined downlink processing flow, precise conversion and verification of control commands are achieved. The introduction of object model files ensures accurate mapping from business values ​​to hardware values, avoiding errors from manual conversion; strict protocol-driven coding guarantees the legality of commands and accurate verification. Simultaneously, the standardized downlink message interface shields the differences in underlying protocols, allowing external program sources 12 to control heterogeneous devices simply by sending commands in a unified format, greatly reducing the development difficulty of upper-layer applications and achieving true remote operation and maintenance and automated control.

[0084] To automatically clean up unnecessary software resources when the target device is removed, Figure 5 A flowchart illustrating the removal process provided in an embodiment of this application is shown, as follows: Figure 5 As shown, preferably, the system is also used to remove the target device protocol, wherein the removal process includes S231~S233: S231, in response to the removal command for the target device, the device management module 114 deletes the association relationship corresponding to the physical address of the device.

[0085] When a user or system 1 issues a removal command, i.e., a control command requesting the removal of the target device from the management list of the edge gateway 11, the device management module 114 will respond to the command by removing the association corresponding to the device's physical address from the device list maintained by the device management module 114. This association was originally a mapping record that bound the device's physical address to specific software processing logic, representing the device's context information in the system. Deleting this association logically severs the connection between the device and software resources, signifying that the device has been deregistered from the management list, but the related software resources have not yet been immediately cleared.

[0086] S232, when the product parsing management module 113 detects that all the associations corresponding to the target product parsing program have been deleted, it uninstalls the target product parsing program and its associated object model files.

[0087] The association relationship corresponding to the target product parser is essentially a reference count or usage list, used to count the set of all devices currently using that specific product parser. The product parsing management module 113 is responsible for performing a detection action, namely, determining whether the set is empty. When it is detected that the association relationship has been completely deleted, i.e., the reference count is zero, indicating that no device is using the parser, the product parsing management module 113 will remove the target product parser and its associated object model file from the running memory of the edge gateway 11 by calling the operating system-level dynamic library unloading interface, and at the same time release the system resources such as memory, port number, and handle occupied by it.

[0088] S233, when the protocol driver management module 112 detects that all product parsing programs on which the target protocol driver instance depends have been uninstalled, the target protocol driver instance is uninstalled.

[0089] A dependency exists between the protocol driver instance and the product parser; that is, the product parser needs to call the interfaces provided by the protocol driver instance during runtime, thus the product parser depends on the protocol driver instance. The protocol driver management module 112 is responsible for determining whether this dependency still exists. When it is detected that all product parsers depended on by the target protocol driver instance have been uninstalled, it indicates that the driver instance has no upper-level callers, and the protocol driver management module 112 then releases the system resources occupied by the protocol driver instance. This dependency chain-based judgment mechanism prevents other devices sharing the same protocol from becoming unreachable due to the accidental deletion of a device.

[0090] Specifically, the removal process comprises three key steps. First, in step S231, the device management module 114 receives the removal instruction and removes the target device's entry from the device list, severing its logical connection with the software module. Next, in step S232, the product parsing management module 113 checks whether the affected parser still has other device dependencies. If all associations have been deleted, i.e., the reference count is zero, the corresponding parser and object model file are automatically uninstalled. Finally, in step S233, the protocol driver management module 112 further evaluates the necessity of the protocol driver instance. Only after confirming that all product parsers dependent on the protocol driver instance have been uninstalled will the protocol driver instance be uninstalled, ensuring that the release of underlying resources does not affect other running business logic.

[0091] Taking the removal of thermostat X1 as an example, assume that three devices are connected to edge gateway 11: thermostats X1 with addresses 08 and 09 share product port 002, thermostat X2 with address 10 shares product port 003, and all three devices depend on driver port 001. When the user deletes device 08 in the cloud, device management module 114 deletes its association. Product resolution management module 113 detects that product port 002 is still used by device 09, so it does not perform uninstallation. When the user continues to delete device 09, product resolution management module 113 detects that product port 002 has no device dependency, and then uninstalls the resolution program and notifies protocol driver management module 112. At this time, driver port 001 is still used by product port 003 (thermostat X2), so it is not uninstalled. Until the user deletes device 10, causing product port 003 to be uninstalled, protocol driver management module 112 detects that driver port 001 has no dependency, and finally uninstalls the protocol driver instance, completing the reclamation of all related resources.

[0092] This cascading removal process endows the system with automated resource reclamation capabilities. This not only effectively prevents memory leaks and resource exhaustion caused by frequent device replacements, ensuring the stability of the Edge Gateway 11 in long-term unattended industrial environments, but also significantly improves hardware resource utilization efficiency through dynamic resource reallocation, supporting higher-density device access tasks. Simultaneously, this intelligent background cleanup mechanism is completely transparent to users; users only need to perform simple deletion operations, requiring no professional maintenance knowledge, greatly simplifying the complexity of device lifecycle management.

[0093] The communication connection between the external program source 12 and the edge gateway 11 is further described. Preferably, the system also includes a remote service module 116 with which a communication connection has been established with the external program source 12 (IoT cloud platform 13); the remote service module 116 is located on the edge gateway 11 and is used to communicate with the IoT cloud platform 13 based on a pre-configured model context protocol, receive the interface configuration file, target protocol driver, target product parsing program and its associated object model file, and access command issued by the IoT cloud platform 13, and distribute the interface configuration file to the interface management module 111, the target protocol driver to the protocol driver management module 112, the target product parsing program and its associated object model file to the product parsing management module 113, and the access command to the device management module 114.

[0094] The remote service module 116 acts as an edge proxy or communication middleware in the system, responsible for listening to network requests, managing communication connections, and distributing received data. When communicating with the IoT cloud platform 13, the remote service module 116 follows the Model Context Protocol specification, establishes connections using Ethernet, supports HTTP / HTTPS protocols, and maintains long-lived connections using SSE technology to ensure that commands can be issued in real time. The communication content is encapsulated in JSON-RPC 2.0 format messages. The remote service module 116 distinguishes different operation types, such as uploading files or issuing commands, by parsing the fields in the messages, in order to build a standardized cloud-edge transmission channel, enabling the IoT cloud platform 13 to securely and efficiently transmit files to the edge gateway 11.

[0095] During the receiving phase, the remote service module 116 reads and parses the data stream from the IoT cloud platform 13 through the network interface. Based on the TCP / IP protocol stack, the remote service module 116 listens on a predetermined port. When the IoT cloud platform 13 completes file upload or command generation, it sends the data stream through the model context protocol. The remote service module 116 receives the byte stream, parses the header, and extracts the payload. If the payload is file data, such as interface configuration files, target protocol drivers, target product parsing programs, and their associated object model files, the module temporarily stores it in a local cache. If the payload is a text command, such as an access command, the remote service module 116 parses it into an internally executable data structure.

[0096] The remote service module 116 accurately forwards data to the corresponding internal processing module via inter-process communication mechanism based on the content category or message identifier, completing data distribution. Specifically, for interface configuration files containing physical interface parameters of the edge gateway 11, the remote service module 116 sends them to the interface management module 111, ensuring that interface configuration updates are accurately delivered to the underlying units. For target protocol drivers, the remote service module 116 forwards them to the protocol driver management module 112, realizing automatic transmission of protocol drivers from the cloud to the edge without manual intervention. For target product parsing programs containing business logic and device definitions, along with their associated object model files, the remote service module 116 packages or forwards them sequentially to the product parsing management module 113, completing the remote deployment of business logic and device definitions. Finally, for access commands instructing the edge gateway 11 to perform device access operations, the remote service module 116 directly forwards them to the device management module 114, triggering specific device registration logic, thereby establishing a closed-loop command from cloud operation to edge execution.

[0097] Taking the complete integration of thermostat X1 as an example, after the developer completes the configuration and file upload on the IoT cloud platform 13, a message containing the interface configuration file, target protocol driver, parser, object model file, and access command is generated in the cloud. The remote service module 116 receives and parses the message and temporarily stores the file. Subsequently, the remote service module 116 identifies and distributes the interface configuration file to the interface management module 111 to configure serial port parameters, distributes the driver to the protocol driver management module 112 for loading and port allocation, distributes the parser and object model to the product parsing management module 113 for deployment, and distributes the access command to the device management module 114 to generate a device ID and establish an association. Thus, through the relay of the remote service module 116, the remote zero-contact deployment of thermostat X1 is realized.

[0098] By introducing a remote service module 116 and a communication mechanism based on the Model Context Protocol (MTP), a standardized cloud-edge transmission channel is constructed. Regardless of the hardware vendor of the edge gateway 11 or the service provider of the IoT cloud platform 13, as long as the MTP-based communication protocol is supported, seamless integration can be achieved, breaking the limitations of traditional deep integration and greatly improving system compatibility and ecosystem openness. Simultaneously, the remote service module 116, as a unified communication entry point, allows maintenance personnel to configure interfaces, update drivers, and add devices without being physically present on-site, significantly reducing on-site maintenance costs. Furthermore, the centralized single-channel architecture significantly reduces the network attack surface, and coupled with a mechanism for verifying the integrity of transmitted files, it ensures that only legitimate protocol drivers and parsing programs can be loaded, effectively improving system security and manageability.

[0099] To illustrate the internal structure of the IoT cloud platform 13, Figure 6 This application provides a schematic diagram of the structure of an IoT cloud platform, as shown in the embodiment. Figure 6 As shown, preferably, the IoT cloud platform 13 includes: a product and driver repository 131 for storing various protocol drivers, various product parsing programs, and multiple object model files associated with each product parsing program; and a device configuration service module 132 for providing a user configuration interface, receiving device access information input by the user based on the user configuration interface, and generating access instructions based on the device access information. The device access information includes interface configuration parameters and device identification information. The interface configuration parameters include the interface type corresponding to the target device protocol. The interface configuration parameters are used to configure the communication environment of the physical communication interface of the edge gateway 11.

[0100] The IoT cloud platform 13 includes a product and driver repository 131 and a device configuration service module 132. The product and driver repository 131, as a software artifact repository, features version control and traceability, and is used to uniformly store drivers for various protocols, product parsers, and object model files associated with each product parser. Optionally, this repository is a code version control system optimized for IoT scenarios, providing standard application programming interfaces (APIs) that allow other modules to retrieve and download corresponding software components based on protocol IDs or product IDs, thereby ensuring version consistency and stability during driver and parser distribution.

[0101] The device configuration service module 132 is responsible for the core functions of human-computer interaction and command conversion. It provides a graphical user interface for receiving device access information input by the user. This information includes interface configuration parameters and device identification information. The interface configuration parameters include the interface type corresponding to the target device protocol, used to configure the communication environment of the edge gateway 11's physical communication interface. Upon receiving the input, the device configuration service module 132 generates standardized access commands based on the device access information. These commands not only include the operation type and device physical address but also associate the corresponding target product port identifier and target driver port identifier from the repository 131. These commands are then precisely sent to the edge gateway 11 via the MCP channel, ensuring that the configuration takes effect in real time.

[0102] Preferably, the product and driver repository 131 includes an artificial intelligence-assisted generation module 1311, which is used to: receive target device protocol description information input by the user; parse the target device protocol description information based on a preset protocol driver template, and generate a target protocol driver program.

[0103] Preferably, the AI-assisted generation module 1311 is further configured to: receive product function definition information input by the user; parse the product function definition information based on a preset object model template, and generate a target product parsing program and a target object model file.

[0104] To further lower the development threshold, the product and driver repository 131 integrates an AI-assisted generation module 1311. Leveraging the natural language understanding capabilities of a large language model, the AI-assisted generation module 1311 automates the process from requirement description to code generation. In protocol-driven development, the AI-assisted generation module 1311 receives user-inputted target device protocol description information and parses it based on a pre-set protocol driver template. By extracting key parameters such as baud rate, parity, and frame format, and instantiating them into a generic code skeleton, it automatically generates the target protocol driver. In business logic development, the AI-assisted generation module 1311 receives user-inputted product function definition information and parses it based on a pre-set object model template. Based on defined device attributes, data types, and conversion rules, it automatically generates the target product parser and the target object model file, reducing the adaptation work that would have required several days for professional programmers to minutes, significantly improving the agility of device integration.

[0105] Taking the cloud-based intelligent generation of the X1 thermostat as an example, developers only need to input a protocol description containing parameters such as the private serial protocol, baud rate 9600, and frame header 0xAA into the platform. The AI-assisted generation module 1311 can then call the general serial port driver template, automatically fill in the parameters, compile and generate the target protocol driver, and store it in the repository. Subsequently, after inputting the product function definition containing temperature attributes, register addresses, and scaling factors, the AI-assisted generation module 1311 automatically generates the target product parsing program and the corresponding object model file. During the deployment phase, the user enters the device address 08 through the interface of the device configuration service module 132, selects the generated driver and parsing program, and the module 132 then generates an access command containing the device ID and software version information. The command and the required files are then sent to the edge gateway 11 via the MCP protocol to complete the remote automated deployment of the device.

[0106] By introducing an AI-assisted generation module 1311 and a standardized product and driver repository 131, a cloud-driven, out-of-the-box ecosystem can be built. This low-code generation method transforms complex industrial protocol programming into natural language interaction, reducing reliance on professional developers and enabling business personnel to participate in the device access process. At the same time, the centralized management mechanism of the repository enables the accumulation and reuse of software assets. Combined with the cloud-edge collaborative MCP communication mechanism, it ensures the consistency of software across the entire network of devices, effectively solving the pain points of version dispersion and management difficulties in traditional development, and providing strong technical support for large-scale device access in the Industrial Internet of Things.

[0107] This application embodiment dynamically acquires and instantiates the driver corresponding to the target device protocol through the protocol driver management module 112, directly replacing the traditional method of relying on firmware pre-built protocol drivers. This allows the edge gateway 11 to support new or private protocols without manufacturer intervention or firmware upgrades. The product parsing management module 113 synchronously acquires the target product parsing program that matches the protocol, ensuring that the raw data of newly connected devices can be parsed into standardized information in real time and accurately. The device management module 114 automatically associates the device identifier, protocol driver instance, and product parsing program when the device is connected, enabling plug-and-play functional access for new devices. This transforms the device access process from traditional firmware iteration dependence to dynamic configuration, greatly improving the edge gateway 11's adaptability and rapid expansion capability for heterogeneous device protocols.

[0108] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0110] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0111] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An IoT device access system based on a model context protocol, characterized in that, The system includes: The protocol driver management module, located at the edge gateway, is used to obtain the target protocol driver corresponding to the target device protocol and instantiate the target protocol driver into a target protocol driver instance, wherein the target device protocol is a newly added protocol type; The product parsing management module is located on the edge gateway and is used to obtain the target product parsing program corresponding to the target device protocol; The device management module, located in the edge gateway, is used for: In response to an access command from a target device, the device identification information of the target device is obtained, wherein the target device and the edge gateway communicate based on the target device protocol; Establish the association between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device.

2. The system according to claim 1, characterized in that, The system also includes: The interface management module, located in the edge gateway, is used for: Receive an interface configuration file for a target physical communication interface, wherein the interface configuration file includes the parameter configuration of the target physical communication interface and the identifier of the target protocol to be bound; The target physical communication interface in the edge gateway is initialized according to the parameter configuration. Based on the target protocol identifier to be bound, the initialized target physical communication interface is bound to the target protocol driver instance to realize data interaction between the target device and the edge gateway based on the target physical communication interface; The data management module, located at the edge gateway, is used to interact with external program sources in a standardized data format.

3. The system according to claim 2, characterized in that, The product parsing management module is also used to obtain the object model file associated with the target product parsing program, wherein the object model file is used to define the data structure and business rules followed by the target product parsing program when performing data processing.

4. The system according to claim 1, characterized in that, The device identification information includes the device physical address, device protocol attributes, and device product type attributes; Establishing the association between the device identification information, the target protocol driver instance, and the target product parsing program to complete the functional access of the target device includes: Based on the device protocol attributes, the target protocol driver instance corresponding to the target device is determined from multiple protocol driver instances of the protocol driver management module, and a driver port identifier is assigned to the target protocol driver instance; Based on the device product type attribute, the target product parsing program corresponding to the target device is determined from multiple product parsing programs in the product parsing management module, and a product port identifier is assigned to the target product parsing program; Establish the association between the device physical address, the driver port identifier, and the product port identifier to complete the functional access of the target device.

5. The system according to claim 3, characterized in that, The system is used to perform uplink processing on communication data sent by the target device based on the association relationship, wherein the uplink processing includes: The interface management module receives raw communication data from the target device through the target physical communication interface bound to the target protocol driver instance, and sends the raw communication data to the protocol driver management module. The protocol driver management module receives the original communication data, parses the device physical address from the original communication data, determines the target protocol driver instance corresponding to the device physical address based on the association relationship, drives the target protocol driver instance to perform protocol parsing on the original communication data to obtain protocol data, and sends the protocol data to the product parsing management module. The product parsing management module, based on the association relationship, determines the target product parsing program and the object model file corresponding to the device physical address, drives the target product parsing program to perform product semantic parsing on the protocol data according to the object model file, obtains device data with clear business meaning, and sends the device data and the corresponding device physical address to the device management module. The device management module sends the data formed by associating the device data with the device physical address to the data management module; The data management module standardizes and encapsulates the received data to form a reporting data message, and sends the reporting data message to the external program source to complete the data reporting to the target device.

6. The system according to claim 3, characterized in that, The system is used to perform downlink processing on downlink messages sent by the external program source based on the association relationship, wherein the downlink processing includes: The data management module receives downlink packets from the external program source and decapsulates the downlink packets to obtain the target device's physical address and control parameters. The device management module queries the target association relationship formed by the target device's physical address based on the target device's physical address, determines the target product port identifier and the target driver port identifier based on the target association relationship, and sends the target product port identifier, the target driver port identifier, and the control parameters to the product parsing management module. The product parsing management module calls the target product parsing program corresponding to the target product port identifier, and converts the control parameters into protocol instructions based on the object model file associated with the target product parsing program, and sends the protocol instructions and the target driver port identifier to the protocol driver management module. The protocol driver management module calls the target protocol driver instance corresponding to the target driver port identifier, encodes the protocol instruction into a raw control byte stream, and sends the raw control byte stream to the interface management module; The interface management module sends the original control byte stream to the target device through the physical communication interface bound to the target protocol driver instance, thereby completing the data transmission to the target device.

7. The system according to claim 3, characterized in that, The system is also used to remove the target device protocol, wherein the removal process includes: The device management module, in response to a removal command for the target device, deletes the association relationship corresponding to the physical address of the device; When the product analysis management module detects that all the associations corresponding to the target product analysis program have been deleted, it uninstalls the target product analysis program and its associated object model files. When the protocol driver management module detects that all product parsing programs on which the target protocol driver instance depends have been uninstalled, it uninstalls the target protocol driver instance.

8. The system according to claim 3, characterized in that, The system also includes a remote service module with a communication connection and the external program source, wherein the external program source is an Internet of Things cloud platform; The remote service module, located at the edge gateway, is used to communicate with the IoT cloud platform based on a pre-configured model context protocol. It receives the interface configuration file, the target protocol driver, the target product parsing program and its associated object model file, and the access command issued by the IoT cloud platform. The module then distributes the interface configuration file to the interface management module, the target protocol driver to the protocol driver management module, the target product parsing program and its associated object model file to the product parsing management module, and the access command to the device management module.

9. The system according to claim 8, characterized in that, The IoT cloud platform includes: The product and driver repository is used to store various protocol drivers, various product parsers, and multiple object model files that are associated with each product parser. The device configuration service module is used to provide a user configuration interface, receive device access information input by the user based on the user configuration interface, and generate the access command according to the device access information. The device access information includes interface configuration parameters and device identification information. The interface configuration parameters include the interface type corresponding to the target device protocol. The interface configuration parameters are used to configure the communication environment of the physical communication interface of the edge gateway.

10. The system according to claim 9, characterized in that, The product and driver repository includes an AI-assisted generation module, which is used for: Receive target device protocol description information input by the user; The target device protocol description information is parsed based on a pre-set protocol driver template to generate the target protocol driver program; And / or, Receive product function definition information input by the user; The product function definition information is parsed based on a pre-set object model template to generate the target product parsing program and the target object model file.

Images