Internet of Things gateway communication method, system and device

Abstract

The invention is suitable for the field of computers, and provides an Internet of Things gateway communication method, system and device, and the method comprises the steps: receiving an original protocol frame sent by a terminal device; matching a target protocol template corresponding to the original protocol frame, and extracting field content according to the original protocol frame and the target protocol template corresponding to the original protocol frame; packaging the field content in a first message structure to obtain first structure data; dynamically binding a key field in the first structure data with a corresponding device command template to obtain the first structure data after business semantic mapping; packaging the first structure data after the business meaning mapping in a second message structure to obtain second structure data; and sending the second structure data to an upper layer Internet of Things control system based on the theme routing mechanism. According to the method, unified analysis and adaptation of multiple different protocol devices are realized, lightweight and extensible operation efficiency is realized, and the Internet of Things gateway has higher compatibility, flexibility and stability.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to an Internet of Things gateway communication method, system and device. Background Technology

[0002] With the rapid development of IoT technology, the increasing number and types of devices have made communication between them increasingly complex. Smart gateways, acting as a bridge between IoT devices and upper-layer systems, face numerous challenges. The communication protocols used by various terminal devices (such as RS485, CAN, Modbus, LoRa, etc.) differ significantly in structure, field organization, address rules, and command semantics, making traditional protocol adaptation methods inefficient in handling emerging devices and protocols.

[0003] Existing technologies often employ a layered architecture of "protocol driver + upper-layer parsing module" for protocol adaptation. However, due to the significant differences between protocols, this approach often requires extensive hard coding, leading to high system complexity and increased maintenance costs. Traditional solutions are prone to issues such as CPU idling and increased memory usage when dealing with parallel processing of multiple protocols, impacting the overall performance and real-time capabilities of the gateway.

[0004] Furthermore, while existing technologies describe device attributes using object models, they mostly focus on data display and business abstraction, and have not yet formed a complete system that connects "protocol parsing—intermediate format—object model mapping—command reverse generation." At the same time, existing technologies lack an effective mechanism for dynamically adjusting protocol processing threads based on the number of devices, data traffic, and system resource status. Summary of the Invention

[0005] This application provides an IoT gateway communication method, system, and apparatus that can solve the above-mentioned problems.

[0006] In a first aspect, embodiments of this application provide an IoT gateway communication method, including: Receive raw protocol frames sent by the terminal device; Match the target protocol template corresponding to the original protocol frame, and extract the field content based on the original protocol frame and the target protocol template corresponding to the original protocol frame; The content of the field is encapsulated in a first message structure to obtain first structure data; Based on the first structural data and the pre-established object model file, the key fields in the first structural data are dynamically bound to the corresponding device command templates to obtain the first structural data after business semantic mapping. The first structure data after mapping the business meaning is encapsulated in a second message structure to obtain the second structure data; The second structured data is sent to the upper-layer IoT control system based on a topic routing mechanism, so that the upper-layer IoT control system can parse the second structured data and perform corresponding operations.

[0007] Secondly, embodiments of this application provide an Internet of Things gateway communication device, comprising: The module includes a driver interface call module, a protocol parsing and port adaptation module, an object model management module, and a communication protocol adaptation module. The driver interface calling module is used to receive the original protocol frames sent by the terminal device; The protocol parsing and port adaptation module is used to match the target protocol template corresponding to the original protocol frame, extract field content based on the original protocol frame and the target protocol template corresponding to the original protocol frame, and encapsulate the field content in a first message structure to obtain first structure data. The object model management module is used to dynamically bind the key fields in the first structure data with the corresponding device command templates based on the first structure data and the pre-established object model file, so as to obtain the first structure data after business semantic mapping. The communication protocol adaptation module is used to encapsulate the first structure data after the business meaning mapping into a second message structure to obtain the second structure data; and to send the second structure data to the upper-layer IoT control system based on the topic routing mechanism, so that the upper-layer IoT control system can parse the second structure data and perform corresponding operations.

[0008] Thirdly, embodiments of this application provide an Internet of Things gateway communication device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0010] Fifthly, embodiments of this application provide an Internet of Things (IoT) gateway communication system, the system including a terminal device, an IoT gateway, and an upper-layer IoT control system; the IoT gateway includes a protocol middleware; the terminal device and the upper-layer IoT control system establish a data connection through the IoT gateway; the protocol middleware is used to execute the method described in the first aspect above.

[0011] In this embodiment, the system receives an original protocol frame sent by a terminal device; matches the target protocol template corresponding to the original protocol frame; extracts field content based on the original protocol frame and the target protocol template; encapsulates the field content using a first message structure to obtain first structure data; dynamically binds key fields in the first structure data to the corresponding device command template based on the first structure data and a pre-established object model file to obtain first structure data after business semantic mapping; encapsulates the first structure data after business semantic mapping using a second message structure to obtain second structure data; and sends the second structure data to the upper-layer IoT control system based on a topic routing mechanism, so that the upper-layer IoT control system can parse the second structure data and perform corresponding operations. This method can quickly process and respond to data from devices, supporting real-time monitoring. The process of matching and dynamically binding protocol templates ensures the accuracy of data parsing and avoids data loss or misunderstanding due to inconsistent formats. The encapsulation of the first and second message structures makes the transmission of data within the system more standardized and structured, facilitating subsequent analysis and processing. Dynamic binding and adaptable message structure design enable the system to flexibly respond to new devices and protocols, supporting future expansion and upgrades. By sending data to the cloud or an upper-level management platform, the system can leverage big data analytics, machine learning, and other technologies to achieve higher-level intelligent decision-making and prediction, improving business efficiency and user experience. Security authentication and encryption mechanisms are incorporated into the data transmission process to ensure data privacy and security, preventing data leakage and tampering during transmission. Attached Figure Description

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

[0013] Figure 1 This is a schematic flowchart of an IoT gateway communication method provided in the first embodiment of this application; Figure 2 This is a schematic flowchart of steps S1021 to S1023 in an IoT gateway communication method provided in the first embodiment of this application; Figure 3 This is a schematic flowchart of steps S1041 to S1043 in an IoT gateway communication method provided in the first embodiment of this application; Figure 4 This is a schematic flowchart of S107~S109 in an IoT gateway communication method provided in the first embodiment of this application; Figure 5 This is a schematic flowchart of S110~S111 in an IoT gateway communication method provided in the first embodiment of this application; Figure 6 This is a schematic diagram of the IoT gateway communication device provided in the second embodiment of this application; Figure 7 This is a schematic diagram of an Internet of Things gateway communication system provided in the third embodiment of this application; Figure 8 This is a schematic diagram of the IoT gateway communication device provided in the fourth embodiment of this application. Detailed Implementation

[0014] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0015] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0016] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0018] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0020] Please see Figure 1 , Figure 1 This is a schematic flowchart illustrating an IoT gateway communication method provided in the first embodiment of this application. In this embodiment, the executing entity of the IoT gateway communication method is a device with IoT gateway communication functionality, such as a desktop computer, server, etc. Figure 1 The IoT gateway communication method shown may include: S101: Receive the raw protocol frame sent by the terminal device.

[0021] In this embodiment, the original protocol frame is a data unit sent by the device according to a specific communication protocol (such as MQTT, CoAP, Modbus, etc.), which may contain information such as device ID, data type, and measurement value.

[0022] IoT gateways or edge computing devices receive raw protocol frames from different terminal devices (such as sensors and actuators) through communication interfaces (such as serial ports, Ethernet interfaces, LoRa modules, etc.). They can monitor the channel asynchronously or synchronously to ensure timely data acquisition.

[0023] In one implementation, S101 may specifically include calling a physical port driver to perform bidirectional interaction with the terminal device and receiving the original protocol frame sent by the terminal device through the corresponding physical port; wherein, several interaction requests from the terminal devices are processed based on a multiplexing mechanism and an asynchronous I / O queue.

[0024] Specifically, a communication channel with the terminal device is opened using a physical port (such as a serial port, USB port, or Ethernet port) by calling the corresponding driver. Initialization commands are sent through this channel to ensure the terminal device is in a communicable state. The physical port is then monitored to receive raw protocol frames sent from the terminal device.

[0025] The system handles interaction requests from several terminal devices based on multiplexing mechanisms and asynchronous I / O queues. Upon program startup, the multiplexing module is initialized, registering all physical ports that need to be listened to (i.e., ports connected to multiple terminal devices) with the multiplexer. An event loop is then entered, using the multiplexing mechanism to wait for input from each terminal device. When data arrives on a port, the multiplexer returns the port's file descriptor, indicating that data is available for reading. Asynchronous I / O operations are used, placing the received data into an asynchronous I / O queue and marking it as pending. These data are processed using callback functions or event-driven methods to avoid blocking reception on other ports.

[0026] S102: Match the target protocol template corresponding to the original protocol frame, and extract field content based on the original protocol frame and the target protocol template corresponding to the original protocol frame.

[0027] A target protocol template is a specification for describing a specific protocol format, defining the protocol's structure, including the position, length, and type of each field. This is typically a structured description, possibly represented in JSON, XML, or other formats.

[0028] The gateway matches the received raw protocol frames against a predefined target protocol template (parsing rules). The target protocol template defines the field structure for parsing the protocol frame. Based on the template matching results, useful information fields are extracted.

[0029] Specifically, the original protocol frame is parsed into a sequence of bytes. Attention must be paid to byte order (big-endian or little-endian) and data type (integer, string, etc.). The corresponding bytes are extracted from the original protocol frame based on the field length. Type conversion is performed based on the field type (e.g., converting the byte stream to an integer or string).

[0030] In one embodiment, S102 may include S1021~S1023, such as Figure 2 As shown, S1021~S1023 are as follows: S1021: Parse the original protocol frame to obtain the terminal device identifier.

[0031] A raw protocol frame is a data packet sent by a device and encoded in a specific format (such as binary, hexadecimal, etc.). It contains information such as the device's identifier, data content, and timestamp.

[0032] Use parsing algorithms (e.g., regular expressions or byte stream processing) to read the contents of the raw protocol frame.

[0033] Extract the terminal device identifier (usually a unique ID of the device, such as a MAC address or UUID) from the protocol frame. Assuming the original protocol frame content is 0xAA01ABCD..., where 0xABCD represents the terminal device identifier, the device ID obtained after parsing is ABCD.

[0034] S1022: Match the target protocol template corresponding to the original protocol frame from the pre-established protocol templates according to the terminal device identifier.

[0035] A protocol template library is pre-built, containing protocol templates for different terminal devices. These templates define the protocol format and field structure for various devices.

[0036] Specifically, in one implementation, if serial port 1 is connected to a Modbus device, then the data coming in from serial port 1 will be parsed using the "Modbus protocol template" by default.

[0037] In one implementation, the first few bytes of the original frame (called the "magic number" or "synchronization header") are examined. If the first two bytes are FFEFeE, the system searches in the signature database and finds that it is "Manufacturer A's proprietary protocol template"; if it starts with 68, it may be "DL / T645 meter protocol template".

[0038] In one implementation, some protocols have fixed values ​​at fixed locations. For example, the HTTP protocol typically includes the string 'GET' or 'POST'; the MQTT protocol includes the string 'MQTT'.

[0039] In one implementation, the parsed terminal device identifier is compared with the device ID in the protocol template library. A target protocol template matching the device ID is found, and its data structure and field meanings are determined. If the device ID is ABCD, the corresponding template Template_A is found in the protocol template library.

[0040] S1023: Determine the frame boundary of the original protocol frame based on the target protocol template corresponding to the original protocol frame, and extract the field content from the original protocol frame based on the frame boundary of the original protocol frame.

[0041] Based on the definition of the target protocol template, the start and end positions of the protocol frames are identified, i.e., the frame boundaries are determined. Typically, frame boundaries may be determined by specific delimiters or length information.

[0042] Based on the defined frame boundaries, extract the content of each field (such as temperature, humidity, etc.) from the original protocol frame and perform formatting.

[0043] Assuming Template_A specifies a 1-byte temperature field and a 1-byte humidity field, and the frame boundary is defined as starting at 0xAA and ending at 0xBB, the extracted content might be: Temperature value: 0x1A (26 degrees Celsius) Humidity value: 0x64 (100%).

[0044] Through the steps described above, the entire IoT time-series data processing method extracts, matches, and parses data from the original protocol frames. This method improves the efficiency and accuracy of data processing, supports standardized access to the IoT for various devices, and facilitates subsequent data analysis, monitoring, and control applications.

[0045] S103: Encapsulate the field content using a first message structure to obtain first structure data.

[0046] The first message structure is a pre-defined, specific data organization format, typically including field names and their values, which can be used for transmission and processing within the system.

[0047] Based on the extracted field content, they are encapsulated according to a predefined first message structure. This encapsulation process may involve converting the field content into a specific data format (such as JSON, XML, etc.) and organizing this data according to a certain structure.

[0048] S104: Based on the first structural data and the pre-established object model file, the key fields in the first structural data are dynamically bound to the corresponding device command templates to obtain the first structural data after business semantic mapping.

[0049] A device model file is created in advance. The device model file is a file that describes the characteristics, functions and interactive behaviors of the device. It is usually used to define the device's attributes, events and commands.

[0050] The first-structure data is analyzed using a predefined object model file. Key fields (such as device ID and status) are dynamically bound to corresponding device command templates to obtain the first-structure data after business semantic mapping. This can be achieved through lookup tables or mapping relationships.

[0051] Specifically, the process begins by loading a predefined object model file, which contains various attributes, commands, and events for the device. For example, an object model for a temperature sensor might include commands such as "get temperature" and "set threshold." Based on key fields in the first structured data (such as "device_id"), the corresponding command templates are located, and a mapping relationship is established between them.

[0052] In one embodiment, S104 may include: encapsulating the field content into the first structured data according to the field content and a preset field matching rule; wherein the first structured data includes at least a field name and a field value.

[0053] Field content refers to the data items extracted from the original protocol frame, which are key information carriers in IoT applications.

[0054] Predefined field matching rules refer to the rules that map extracted field content to specific data structures. These rules usually exist in the form of dictionaries or mapping tables, specifying each field name and its corresponding field value.

[0055] Choose a suitable data format for encapsulation, such as JSON or XML. Align field names and values ​​according to preset field matching rules to form structured data. Use code (such as Python or Java) to populate the field content into the selected data format to obtain the first structured data; wherein the first structured data includes at least field names and field values.

[0056] In this embodiment, the transformation from raw field content to structured data is completed, which improves the standardization and readability of the data, promotes data interaction between various systems, and supports the intelligence and automation of IoT applications.

[0057] In one embodiment, the first structured data includes protocol type, terminal device identifier, and function type, and S104 may include S1041~S1043, such as... Figure 3 As shown, S1041~S1043 are as follows: S1041: Determine the corresponding target object model file based on the protocol type, the terminal device identifier, and the pre-established object model file.

[0058] Protocol type refers to the protocol used for communication (such as MQTT, HTTP, CoAP, etc.), which determines the method and format of data transmission.

[0059] Based on the protocol type and terminal device identifier, the pre-established object model file library is queried to find the object model that matches the device and its protocol, and the corresponding target object model file is determined.

[0060] S1042: Determine the corresponding device command template based on the function type and the target object model file.

[0061] Based on the function type and target object model file, the corresponding command template is located from the preset command template library. Command templates are typically instruction formats that the device can execute, including the structure of parameters and return values.

[0062] S1043: Based on the corresponding device command template, perform business semantic mapping on the key fields in the first structure data to obtain the first structure data after business semantic mapping.

[0063] Based on the parameter structure defined in the device command template, key fields in the first structure data are mapped to the required format in the command template. Necessary transformations and adaptations are performed to ensure the data conforms to business logic and semantic requirements.

[0064] In this embodiment, the conversion from the first structural data to the business semantic mapping data is realized, providing efficient and accurate support for the communication of IoT devices.

[0065] S105: The first structure data after mapping the business meaning is encapsulated in a second message structure to obtain the second structure data.

[0066] A second message structure is pre-configured for the message format transmitted between different systems or modules. It may contain additional context, business logic, or other metadata.

[0067] Based on the dynamically bound data, it is encapsulated according to the second message structure. The second message structure is usually designed to accommodate higher-level systems (such as cloud-based control systems or management platforms) and may include more contextual information and business logic.

[0068] S106: The second structure data is sent to the upper-layer IoT control system based on the topic routing mechanism, so that the upper-layer IoT control system can parse the second structure data and perform corresponding operations.

[0069] The encapsulated second message structure is sent to the upper-layer IoT control system via a suitable communication protocol (such as HTTP, MQTT, CoAP, etc.).

[0070] The upper-level IoT control system parses the second-structure data and executes corresponding operations.

[0071] Through the above continuous communication process, it is ensured that multi-protocol terminal devices can interact with the upper-layer IoT control system in a unified manner. The upper-layer IoT control system does not need to understand the details of the underlying protocol to realize device management, status query and control command issuance, so that the IoT gateway has the end-to-end communication capability from the underlying parsing to the upper-layer interaction.

[0072] In one implementation, S105 includes: encapsulating the first structured data mapped by the business meaning into second structured data containing a topic; wherein the topic includes message source type, message direction, protocol type, and terminal device identifier. Based on this, S106 may include: querying the upper-layer IoT control system that subscribes to the topic, and sending the second structured data to the upper-layer IoT control system.

[0073] Specifically, firstly, the information that needs to be transmitted at the business level is parsed and mapped, and converted into a structured format. For example, if temperature data collected by sensors needs to be sent to the control system, it is converted into structured data containing temperature values ​​and timestamps.

[0074] The first structure data is further encapsulated into a second structure data, and topic information is added. The topic contains four parts: message source type (such as sensor, device, etc.), message direction (such as uplink or downlink), protocol type (such as MQTT, CoAP, etc.), and terminal device identifier (such as device ID).

[0075] The gateway needs to query which upper-layer IoT control systems have subscribed to the topic. This is typically achieved through a registry or subscription management service. For example, suppose there's an upper-layer control system that subscribes to temperature data from all sensors; the gateway needs to confirm the system's existence and obtain its connectivity information (such as IP address and port).

[0076] The encapsulated second-structure data is sent to the confirmed upper-layer IoT control system. The specific sending method depends on the protocol type used.

[0077] If the MQTT protocol is used, the gateway will publish the data to the topic "sensor / temperature" via the MQTT client, ensuring that the upper-level control system can receive the data.

[0078] In this embodiment, there is clear structured and thematic management in the data processing and transmission process, which can effectively improve the efficiency and flexibility of the Internet of Things system.

[0079] In one embodiment, this embodiment may further include S107~S109, such as... Figure 4 As shown, S107~S109 are as follows: S107: Receive the control command issued by the upper-layer Internet of Things control system to the terminal device.

[0080] Control commands refer to the instructions issued by the upper-level IoT control system to the terminal devices, which are used to control the behavior or state of the devices, such as switching on and off, adjusting settings, etc.

[0081] The gateway needs to be configured with a listening mechanism to receive control commands from the upper-layer IoT control system. This can be achieved through specific communication protocols such as MQTT and HTTP.

[0082] After receiving the instruction, the gateway needs to verify its integrity and validity to ensure that the structure of the instruction meets expectations.

[0083] S108: Based on the pre-established object model file, perform reverse business semantic mapping on the control instructions to obtain the original command frame.

[0084] The gateway interprets control commands based on a predefined object model file. The object model file provides the necessary context information for each device. It may define the specific implementation of the "turn_on" command, specifying the required signal format.

[0085] The received control commands are reverse-mapped to their business semantics to generate raw command frames. This process converts higher-level commands into a lower-level command format that the device can parse.

[0086] S109: Send the original command frame to the terminal device so that the terminal device can parse the original command frame and perform the corresponding operation.

[0087] The gateway sends the generated raw command frame to the designated terminal device. This step involves transmitting the command to the device using an appropriate communication protocol (such as serial port, TCP / IP, etc.).

[0088] After receiving the command, the terminal device parses the original command frame and executes the corresponding operation.

[0089] In this embodiment, control commands can be easily modified through reverse business semantic mapping without altering the underlying communication protocol, enhancing system flexibility. The object model file ensures different devices operate according to a unified standard, improving interoperability and adapting to various scenario requirements. By using object model files and standardized control logic, the time and cost required to develop new devices and functions are reduced. Users can quickly and intuitively control devices through high-level commands issued by the upper-level control system, without needing to understand the underlying operational details of the devices.

[0090] In one embodiment, this embodiment may further include S110~S111, such as Figure 5 As shown, S110~S111 are as follows: S110: Monitor the protocol process and obtain protocol performance data in real time; wherein the protocol process is equipped with an independent running space, and the protocol performance data includes at least terminal device activity, port traffic, and CPU utilization.

[0091] Protocol performance data refers to data collected during operation to evaluate the running status and performance of the protocol process, including but not limited to: Terminal device activity: refers to the number of terminal devices communicating with the gateway and their status (online / offline).

[0092] Port traffic: refers to the amount of data transmitted through a network interface within a specific time period, usually measured in bits per second (bps).

[0093] CPU utilization: refers to the percentage of the gateway CPU used by protocol processes, reflecting the system load.

[0094] The protocol process establishes an independent running space within the gateway to ensure its operation is not interfered with by other processes. This can be achieved through virtualization or containerization technologies (such as Docker), allowing them to isolate each other in terms of resource usage.

[0095] Assume the gateway contains multiple protocol processes, each handling different types of communication protocols (such as MQTT, HTTP, etc.). Each protocol process has its own memory and processing resources, and they do not interfere with each other.

[0096] During the protocol process, the following protocol performance data will be continuously monitored: Terminal device activity: The number of currently online devices is counted by periodically querying the list of connected devices.

[0097] Port traffic: Use network traffic monitoring tools to monitor data transmission on specific ports in real time.

[0098] CPU utilization: Use system monitoring tools (such as top, htop, etc.) to obtain the CPU utilization of the protocol process.

[0099] For example, every certain period of time (such as every 5 seconds), the gateway will record that there are currently 10 devices online, the port traffic is 2Mbps, and the CPU utilization is 30%.

[0100] S111: Dynamically allocate system resources and adjust the state of the protocol process based on the protocol performance data.

[0101] Based on real-time acquired protocol performance data, the running status of the protocol process is analyzed to determine whether resource allocation needs to be adjusted.

[0102] For example, if CPU utilization reaches 80% and port traffic continues to increase, resource adjustments may be necessary.

[0103] Based on the analysis results, system resources are dynamically allocated. For example: If a protocol process has excessively high CPU utilization, consider increasing the number of available CPU cores or reducing resource allocation to other low-priority processes.

[0104] If the terminal device has low activity, some protocol processes can be put into a dormant state to free up resources.

[0105] Assuming that during peak hours, the number of active terminal devices increases to 50, the gateway decides to increase the CPU resources for this protocol process while limiting the resource usage of other inactive protocol processes. An adaptive scheduling strategy based on device activity, protocol traffic, and system load dynamically adjusts the process state, allowing the protocol parsing thread to automatically hibernate, reduce its frequency, or resume operation according to the actual workload. This significantly reduces system resource consumption and improves robustness during multi-protocol concurrent processing.

[0106] In this embodiment, real-time monitoring and dynamic resource allocation ensure stable operation of the protocol process under high load, preventing failures due to insufficient resources. The dynamic resource allocation mechanism effectively utilizes system resources, avoids waste, and improves overall system performance and response speed. By ensuring the stability of device connections and responses, users experience better connectivity with IoT devices, reducing latency and malfunctions. The system can flexibly respond to different load conditions based on real-time data, adapting to network traffic fluctuations and enhancing its adaptability and reliability.

[0107] In this embodiment, data from devices can be processed and responded to quickly, supporting real-time monitoring. The process of matching and dynamically binding protocol templates ensures the accuracy of data parsing, avoiding data loss or misunderstanding due to inconsistent formats. Encapsulation of the first and second message structures makes data transmission within the system more standardized and structured, facilitating subsequent analysis and processing. Dynamic binding and adaptable message structure design enable the system to flexibly respond to new devices and protocols, supporting future expansion and upgrades. By sending data to the cloud or upper-level management platform, the system can utilize big data analytics, machine learning, and other technologies to achieve higher-level intelligent decision-making and prediction, improving business efficiency and user experience. Security authentication and encryption mechanisms are incorporated into the data transmission process to ensure data privacy and security, preventing data leakage and tampering during transmission.

[0108] Furthermore, this invention achieves a unified representation of multi-protocol data, improving the processing efficiency of upper-layer systems. It introduces a unified intermediate format, UMF, which encapsulates the parsing results of different protocols according to a unified structure. This enables upper-layer systems to process device data from multiple protocols such as RS485, CAN, LoRa, MBUS, and Modbus with a consistent data model, significantly reducing the complexity of upper-layer business logic.

[0109] Significantly reduces the development costs of device access and protocol adaptation. By dynamically binding commands to UMF fields through the object model management structure, command parsing and instruction generation for devices from different manufacturers can be achieved through configuration files without modifying program code, thus reducing the large amount of hard-coding work in traditional solutions.

[0110] This invention achieves protocol template-based and command semantic standardization, improving system scalability. By separating protocol parsing from command semantics through protocol templates and object model description files, the system can quickly support new device models by adding new template files, achieving high scalability and maintainability.

[0111] This invention reduces system resource consumption through adaptive scheduling of protocol processes. It utilizes an adaptive protocol process operation mechanism to automatically adjust the running state of protocol processes based on device activity, protocol traffic, and system load. This allows idle protocols to automatically hibernate and active protocols to automatically increase their parsing frequency, thereby reducing CPU idling and memory usage.

[0112] This invention enhances the stability and reliability of IoT gateways in complex device scenarios. When an anomaly occurs in the protocol parsing structure or protocol process, the operation management structure of this invention can automatically restart the relevant processes and maintain the continuity of the data channel after recovery, effectively improving the robustness of the system in multi-protocol concurrent scenarios.

[0113] This invention addresses the issue of inconsistent command semantics between heterogeneous devices using multiple protocols. By unifying the definition of protocol fields and business semantics through an object model, it achieves standardization of command semantics at the business level. This allows control commands between different devices to be initiated in a unified manner, significantly improving compatibility issues when devices from different vendors are linked.

[0114] Improve the accuracy and consistency of remote system command issuance. UMF commands issued by the upper-layer system are generated into device native protocol frames through reverse mapping of the object model. This not only improves the accuracy of command generation but also ensures the consistency and controllability of cross-protocol command execution.

[0115] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0116] Please see Figure 6 , Figure 6 This is a schematic diagram of an IoT gateway communication device provided in the second embodiment of this application. The included units are used to perform... Figures 1-5 The steps in the corresponding embodiments. Please refer to the details. Figures 1-5 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 6 The IoT gateway communication device 6 includes: The module includes a driver interface call module 610, a protocol parsing and port adaptation module 620, a device model management module 630, and a communication protocol adaptation module 640. The driver interface calling module is used to receive the original protocol frames sent by the terminal device; The protocol parsing and port adaptation module is used to match the target protocol template corresponding to the original protocol frame, extract field content based on the original protocol frame and the target protocol template corresponding to the original protocol frame, and encapsulate the field content in a first message structure to obtain first structure data. The object model management module is used to dynamically bind the key fields in the first structure data with the corresponding device command templates based on the first structure data and the pre-established object model file, so as to obtain the first structure data after business semantic mapping. The communication protocol adaptation module is used to encapsulate the first structure data after the business meaning mapping into a second message structure to obtain the second structure data; and to send the second structure data to the upper-layer IoT control system based on the topic routing mechanism, so that the upper-layer IoT control system can parse the second structure data and perform corresponding operations.

[0117] Furthermore, the driver interface calling module is specifically used for: The system invokes the physical port driver to perform bidirectional interaction with the terminal device and receives the original protocol frame sent by the terminal device through the corresponding physical port; wherein, based on the multiplexing mechanism and asynchronous I / O queue, it processes the interaction requests of several terminal devices.

[0118] Furthermore, the protocol parsing and port adaptation module is specifically used for: The terminal device identifier is obtained by parsing the original protocol frame; Based on the terminal device identifier, match the target protocol template corresponding to the original protocol frame from the pre-established protocol templates; The frame boundary of the original protocol frame is determined based on the target protocol template corresponding to the original protocol frame, and the field content is extracted from the original protocol frame based on the frame boundary of the original protocol frame.

[0119] Furthermore, the first message structure is the unified message structure in the IoT gateway, and the protocol parsing and port adaptation module is specifically used for: Based on the field content and preset field matching rules, the field content is encapsulated into the first structured data; wherein the first structured data includes at least a field name and a field value.

[0120] Furthermore, the first structured data includes protocol type, terminal device identifier, and function type; the object model management module is specifically used for: Based on the protocol type, the terminal device identifier, and the pre-established object model file, determine the corresponding target object model file; Based on the function type and the target object model file, determine the corresponding device command template; Based on the corresponding device command template, the key fields in the first structure data are mapped using business semantics to obtain the first structure data after business semantic mapping.

[0121] Furthermore, the communication protocol adaptation module is specifically used for: The first structured data after mapping the business meaning is encapsulated into a second structured data containing a topic; wherein, the topic includes message source type, message direction, protocol type and terminal device identifier; Sending the second structured data to the upper-layer IoT control system based on the topic routing mechanism includes the following steps: Query the upper-layer IoT control system that subscribes to the topic, and send the second structure data to the upper-layer IoT control system.

[0122] Furthermore, the IoT gateway communication device further includes a first process running module, which is specifically used for: Receive control commands issued by the upper-layer IoT control system to the terminal device; Based on the pre-established object model file, the control instructions are reverse-mapped to obtain the original command frame. The original command frame is sent to the terminal device so that the terminal device can parse the original command frame and perform the corresponding operation.

[0123] Furthermore, the IoT gateway communication device also includes a second process running module, which is specifically used for: Monitor the protocol process and obtain protocol performance data in real time; wherein the protocol process is equipped with an independent running space, and the protocol performance data includes at least terminal device activity, port traffic, and CPU utilization. The system resources are dynamically allocated and the state of the protocol process is adjusted based on the protocol performance data.

[0124] Figure 7 This is a schematic diagram of an Internet of Things (IoT) gateway communication system provided in the third embodiment of this application. The system includes a terminal device 71, an IoT gateway 72, and an upper-layer IoT control system 73. The IoT gateway includes protocol middleware; The terminal device and the upper-layer IoT control system establish a data connection through the IoT gateway; The protocol middleware is used to execute the IoT gateway communication method as mentioned in the first embodiment.

[0125] Terminal devices connect to IoT gateways via wireless or wired networks, enabling them to send and receive data. For example, a temperature sensor can send data to the gateway, while a lighting controller can receive instructions from the gateway.

[0126] As a core component, the protocol middleware receives data from terminal devices, processes it, and forwards the data to the upper-layer IoT control system as needed. It is also responsible for sending instructions from the upper-layer control system to the corresponding terminal devices using appropriate protocols.

[0127] The upper-level IoT control system receives data from various terminal devices through an IoT gateway, and performs data analysis and storage. At the same time, users can send control commands (such as turning lights on and off, adjusting the temperature, etc.) through this system.

[0128] Terminal devices establish a connection with the IoT gateway through the registration function and send authentication information (such as device ID, key, etc.) to the gateway.

[0129] Once the connection is established, the terminal device can periodically send data (such as temperature values) to the gateway at set time intervals, while the gateway can also send control commands to the terminal device as needed.

[0130] The protocol middleware handles the sending and receiving of data according to the communication protocol used (such as MQTT, CoAP, etc.) to ensure the correct transmission of data.

[0131] For specific details, please refer to the relevant description in the first embodiment, which will not be repeated here.

[0132] The protocol middleware design enables seamless connectivity between devices using different protocols, enhancing system flexibility and scalability. Adding devices becomes easier, supporting more terminal devices and communication protocols. The upper-layer IoT control system centrally manages all terminal devices, simplifying user operations while providing data analysis and monitoring functions, thus improving the system's intelligence level. Through real-time data transmission and processing via the IoT gateway, users can instantly obtain device status and environmental data, quickly responding to system changes and improving system responsiveness. The IoT gateway can implement encryption and authentication during data transmission, ensuring data security and protecting user privacy. Centralized management and automated control reduce the need for manual intervention, lowering operating and maintenance costs and improving system economics.

[0133] Figure 8This is a schematic diagram of the IoT gateway communication device provided in the fourth embodiment of this application. Figure 8 As shown, the IoT gateway communication device 8 of this embodiment includes: a processor 80, a memory 81, and a computer program 82 stored in the memory 81 and executable on the processor 80, such as an IoT gateway communication program. When the processor 80 executes the computer program 82, it implements the steps in the various IoT gateway communication method embodiments described above, for example... Figure 1 Steps 101 to 106 are shown. Alternatively, when the processor 80 executes the computer program 82, it implements the functions of each module in the above-described device embodiments, for example... Figure 6 The functions of modules 610 to 640 are shown.

[0134] For example, the computer program 82 can be divided into one or more modules / units, which are stored in the memory 81 and executed by the processor 80 to complete this application. The one or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 82 in the IoT gateway communication device 8. For example, the computer program 82 can be divided into a driver interface calling module, a protocol parsing and port adaptation module, an object model management module, and a communication protocol adaptation module; The driver interface calling module is used to receive the original protocol frames sent by the terminal device; The protocol parsing and port adaptation module is used to match the target protocol template corresponding to the original protocol frame, extract field content based on the original protocol frame and the target protocol template corresponding to the original protocol frame, and encapsulate the field content in a first message structure to obtain first structure data. The object model management module is used to dynamically bind the key fields in the first structure data with the corresponding device command templates based on the first structure data and the pre-established object model file, so as to obtain the first structure data after business semantic mapping. The communication protocol adaptation module is used to encapsulate the first structure data after the business meaning mapping into a second message structure to obtain the second structure data; and to send the second structure data to the upper-layer IoT control system based on the topic routing mechanism, so that the upper-layer IoT control system can parse the second structure data and perform corresponding operations.

[0135] The IoT gateway communication device may include, but is not limited to, a processor 80 and a memory 81. Those skilled in the art will understand that... Figure 8This is merely an example of the IoT gateway communication device 8 and does not constitute a limitation on the IoT gateway communication device 8. It may include more or fewer components than shown, or combine certain components, or different components. For example, the IoT gateway communication device may also include input / output devices, network access devices, buses, etc.

[0136] The processor 80 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0137] The memory 81 can be an internal storage unit of the IoT gateway communication device 8, such as a hard drive or memory of the IoT gateway communication device 8. The memory 81 can also be an external storage device of the IoT gateway communication device 8, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the IoT gateway communication device 8. Furthermore, the IoT gateway communication device 8 can include both internal storage units and external storage devices. The memory 81 is used to store the computer program and other programs and data required by the IoT gateway communication device. The memory 81 can also be used to temporarily store data that has been output or will be output.

[0138] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0139] This application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0140] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0141] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0142] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0143] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0144] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0146] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method of Internet of Things gateway communication, the method comprising: The method comprises the steps of: receiving an original protocol frame sent by a terminal device; matching a target protocol template corresponding to the original protocol frame, and extracting field content according to the original protocol frame and the target protocol template corresponding to the original protocol frame; encapsulating the field content in a first message structure to obtain first structure data; dynamically binding a key field in the first structure data to a corresponding device command template according to the first structure data and a pre-established physical model file to obtain first structure data after business semantic mapping; encapsulating the first structure data after business semantic mapping in a second message structure to obtain second structure data; sending the second structure data to an upper Internet of Things control system based on a topic routing mechanism, so that the upper Internet of Things control system analyzes the second structure data and performs corresponding operations.

2. The IoT gateway communication method of claim 1, wherein, The method of receiving an original protocol frame sent by a terminal device comprises the steps of: calling a physical port driver to bidirectionally interact with the terminal device, and receiving the original protocol frame sent by the terminal device through a corresponding physical port; wherein the interaction requests of a plurality of terminal devices are processed based on a multiplexing mechanism and an asynchronous I / O queue.

3. The IoT gateway communication method of claim 1, wherein, The method of matching a target protocol template corresponding to the original protocol frame, and extracting field content according to the original protocol frame and the target protocol template corresponding to the original protocol frame comprises the steps of: analyzing the original protocol frame to obtain a terminal device identifier; matching the target protocol template corresponding to the original protocol frame from pre-established protocol templates according to the terminal device identifier; determining a frame boundary of the original protocol frame according to the target protocol template corresponding to the original protocol frame, and extracting the field content from the original protocol frame according to the frame boundary of the original protocol frame.

4. The IoT gateway communication method of claim 1, wherein, The first message structure is a unified message structure in the Internet of Things gateway, and the method of encapsulating the field content in a first message structure to obtain first structure data comprises the steps of: encapsulating the field content into the first structure data according to the field content and a preset field matching rule; wherein the first structure data at least includes a field name and a field value.

5. The IoT gateway communication method according to any one of claims 1 to 4, characterized in that, The first structure data includes a protocol type, a terminal device identifier and a function type, and the method of dynamically binding a key field in the first structure data to a corresponding device command template according to the first structure data and a pre-established physical model file to obtain first structure data after business semantic mapping comprises the steps of: determining a corresponding target physical model file according to the protocol type, the terminal device identifier and the pre-established physical model file; determining the corresponding device command template according to the function type and the target physical model file; performing business semantic mapping on the key field in the first structure data according to the corresponding device command template to obtain first structure data after business semantic mapping.

6. The IoT gateway communication method according to any one of claims 1 to 4, characterized by, The method of encapsulating the first structure data after business semantic mapping in a second message structure to obtain second structure data comprises the steps of: The first structure data after the business meaning mapping is packaged as second structure data containing a topic; wherein, the topic includes a message source type, a message direction, a protocol type and a terminal device identification; The second structure data is sent to an upper Internet of Things control system based on a topic routing mechanism, including the steps of: querying the upper Internet of Things control system subscribing to the topic, and sending the second structure data to the upper Internet of Things control system.

7. The IoT gateway communication method according to any one of claims 1 to 4, characterized by, The method further includes the steps of: receiving a control instruction issued by the upper Internet of Things control system to the terminal device; performing reverse business semantic mapping on the control instruction according to a pre-established thing model file, to obtain an original command frame; sending the original command frame to the terminal device, so that the terminal device parses the original command frame and performs corresponding operations.

8. The IoT gateway communication method according to any one of claims 1 to 4, characterized by, The method further includes the steps of: monitoring a protocol process to obtain protocol performance data in real time; wherein, the protocol process is provided with an independent running space, and the protocol performance data at least includes terminal device activity, port traffic and CPU occupancy rate; dynamically allocating system resources according to the protocol performance data, and adjusting the state of the protocol process.

9. An Internet of Things gateway communication system characterized by, The system includes a terminal device, an Internet of Things gateway and an upper Internet of Things control system; The Internet of Things gateway includes a protocol middleware; The terminal device and the upper Internet of Things control system establish data connection through the Internet of Things gateway; The protocol middleware is used to perform the Internet of Things gateway communication method according to any one of claims 1 to 8.

10. An Internet of Things gateway communication device, characterized by including: a driving interface calling module, a protocol analysis and port adaptation module, a thing model management module and a communication protocol adaptation module; The driving interface calling module is used to receive an original protocol frame sent by a terminal device; The protocol analysis and port adaptation module is used to match a target protocol template corresponding to the original protocol frame, extract field content according to the original protocol frame and the target protocol template corresponding to the original protocol frame; The field content is packaged in a first message structure to obtain first structure data; The thing model management module is used to dynamically bind key fields in the first structure data to corresponding device command templates according to the first structure data and a pre-established thing model file, to obtain first structure data after business meaning mapping; The communication protocol adaptation module is used to package the first structure data after business meaning mapping in a second message structure to obtain second structure data; The second structure data is sent to an upper Internet of Things control system based on a topic routing mechanism, so that the upper Internet of Things control system parses the second structure data and performs corresponding operations.

Images