An internet of things edge computing gateway system and method with extensible architecture

Abstract

The application provides an Internet of Things edge computing gateway system and method with an extensible architecture, and belongs to the technical field of Internet of Things applications. The gateway system comprises a hardware system and a software system. The hardware system supports multiple types of protocols and device access in physical connection. The software system adopts a micro-service architecture based on containers, and comprises a network access layer, a device abstraction layer, a custom logic layer and a cloud connection layer, four-layer systems, to provide multiple functional components such as device connection services, configuration management services, edge computing services and data uploading services. The gateway has wide applicability and can be applied to various application scenarios such as intelligent factories, smart homes and smart agriculture. The gateway has strong extensibility in terms of software and hardware functions, meets the flexible customization requirements of edge computing applications, has high reliability and security, and provides a user-friendly configuration management interface.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) application technology, and in particular to an IoT edge computing gateway system and method with a scalable architecture. Background Technology

[0002] The Internet of Things (IoT) refers to the connection of various physical devices, sensors, actuators, and smart terminals (hereinafter referred to as terminal devices) through the Internet, wireless communication networks, and other means to achieve information exchange, sharing, and intelligent management. Currently, IoT technology has been widely applied in industries such as manufacturing, agriculture, logistics, and consumer goods. The National 14th Five-Year Plan outlines the promotion of the comprehensive development of IoT, incorporating it into the seven key digital economy industries, and making arrangements for IoT access capabilities and key application areas. According to the GSMA (Global System for Mobile Communications Association) report, "The Mobile Economy 2020," the number of terminal devices connected to the IoT globally reached 12 billion in 2019, and is projected to reach 24.6 billion by 2025, representing a compound annual growth rate of 13%.

[0003] However, not all terminal devices have network connectivity. For those that cannot access the network, an IoT gateway with network capabilities is needed as an intermediary. The IoT gateway acts as a bridge, receiving data according to the terminal device's own communication protocol, converting the protocol, and then uploading it to the cloud platform or server according to the access protocol of the cloud platform or remote server. Alternatively, it may receive instructions from the cloud platform, parse them, and send them to the terminal device. In practical applications, IoT gateways face challenges such as the diversity of terminal devices, the diversity of processor architectures and board resources used by the gateways, the diversity of IoT cloud platforms, and the diversity of edge computing business logic.

[0004] Microservice architecture and container technology have been widely adopted in cloud computing and also show promising application prospects in IoT edge computing scenarios. Microservice architecture breaks down previously monolithic applications into a series of independent services or modules. Each service represents a relatively independent business unit, and services communicate and exchange data with each other through predefined rules. In microservice architecture, each software module can be developed, built, tested, and deployed independently, with loose coupling between modules. Containers are lightweight virtualization tools that can package applications and their dependent resources together. Containers have system resource spaces isolated from other applications on the host machine. Compared to traditional virtual machines, containers are more lightweight, consume fewer resources, and are deployed quickly.

[0005] Currently, IoT gateways on the market can only support specific types of devices in terms of hardware, and in terms of software, they typically function as converters for specific protocols, developed for specific data protocols, and can only upload data to a single cloud platform. Their applicable scenarios are limited, and they do not support dynamic deployment of business logic. If the terminal devices, protocols, or business scenarios change, the gateway hardware, communication interfaces, and gateway programs need to be redeveloped and redeployed, resulting in long development cycles, high difficulty, and high costs. Summary of the Invention

[0006] To address the problems of poor scalability, tight hardware-software coupling, and inconvenient configuration and deployment in current IoT gateways, this invention proposes a gateway system and method with a scalable architecture.

[0007] The present invention discloses an IoT edge computing gateway system with a scalable architecture, comprising a gateway software system and a gateway hardware system; the gateway hardware system includes a SoC chip and several communication interfaces connected to the SoC chip; the gateway software system runs on the SoC chip, and terminal devices are connected to the communication interfaces;

[0008] The gateway software system includes a network access layer, a device abstraction layer, a custom logic layer, a cloud connection layer, a message bus, and a database.

[0009] The network access layer encapsulates the application programming interface (API) that interacts with the hardware driver or communication protocol stack in the communication interface; the device abstraction layer implements connection and read / write operations with the terminal device by calling the API of the network access layer.

[0010] The device abstraction layer, custom logic layer, and cloud connection layer are all composed of several different containers. Different containers in the device abstraction layer correspond to different terminal devices. Different containers in the custom logic layer are pre-configured with different edge computing logic. Different containers in the cloud connection layer correspond to different cloud platforms, private servers, or ports.

[0011] The container of the device abstraction layer is used to send information generated by the corresponding terminal device to the message bus. The information generated by the terminal device is one or more of the terminal device's attributes, events, and actions. The container of the custom logic layer is used to complete the edge computing processing of the messages in the message bus according to the set edge computing logic. The container of the cloud connection layer is used to upload the data processed by the custom logic layer to the corresponding cloud platform, private server, or port. It is also used to receive commands or requests issued by the corresponding cloud platform, private server, or port and further issue them. The further issued commands or requests are processed in the containers of the device abstraction layer or the custom logic layer.

[0012] The message bus is used to enable communication between containers in different layers, and the database is used to store the processed data of the custom logic layer.

[0013] Preferably, the communication interface includes an RS485 interface, a CAN interface, an Ethernet interface, a USB slot, and a UART slot; the specific connection method for the terminal device to the communication interface is as follows: terminal devices using wired communication are connected to the RS485 interface, CAN interface, or Ethernet interface, and terminal devices using wireless communication protocols are connected to the USB slot or UART slot through a wireless communication adapter.

[0014] Preferably, all messages on the message bus have an MQTT topic. The MQTT topic is uniformly composed of five fields in sequence: container name, channel name, device name, function description, and function identifier. The channel name indicates the communication protocol used by the device. The function description indicates that the current message is an attribute, event, or action of the terminal device. If the current message is an attribute of the terminal device, the function identifier indicates that the current message is a reporting or setting of the attribute. If the current message is an event or action of the terminal device, the function identifier indicates the name of the event or action.

[0015] Preferably, all containers in the gateway software system are created using images. During creation, the containers are bound to configuration files, allowing containers created from the same image to have different operating parameters. The configuration files are created using configuration file templates. Each terminal device connected to the gateway corresponds to a configuration file. Terminal devices using the same communication protocol use a common configuration file template. The configuration file template includes configuration items for communication protocol parameters, as well as configuration items for sets of attribute, event, or action variables. The set of attribute, event, or action variables is a set of variables that stores the attribute, event, or action data of the terminal device. By modifying the specific values ​​of the configuration items in the configuration file template, configuration files for different devices can be created.

[0016] Based on the aforementioned IoT edge computing gateway system with a scalable architecture, this invention further proposes a communication method, including:

[0017] The terminal device is connected to the communication interface; the container of the device abstraction layer obtains the terminal device information through the application programming interface of the network access layer and sends it to the message bus; the container of the custom logic layer obtains the required terminal device information from the message bus according to the pre-set edge computing logic and performs edge computing processing; the processed data is stored in the database; the container of the cloud connection layer retrieves the processed data from the database and uploads it to the corresponding cloud platform, private server or port; at the same time, the container of the cloud connection layer also receives commands or requests issued by the corresponding cloud platform, private server or port and sends them to the message bus; the container of the device abstraction layer or the custom logic layer receives and processes messages in the message bus regarding commands or requests issued by the cloud platform, private server or port.

[0018] Compared with the prior art, the technical advantages of this invention are as follows:

[0019] 1. The gateway of this invention has wide applicability, capable of connecting devices with various communication protocols and uploading data to different cloud platforms. It can be applied to various application scenarios such as smart factories, smart homes, and smart agriculture, realizing end-to-end capabilities from data collection to processing to uploading.

[0020] 2. The gateway of this invention is scalable. When connecting terminal devices, the gateway can flexibly and dynamically configure the number of channels, adapting to different terminal devices and connecting to different cloud platforms or remote servers without modifying the gateway program. By using container technology and a microservice architecture, the gateway software can be partially added, deleted, and upgraded. Unlike traditional monolithic applications, where functional modules are heavily coupled and the calling logic between modules is fixed from the beginning of program writing, adding a new module requires shutting down the entire system, deploying a completely new system program with the added functionality, and restarting it to complete a functional expansion, the microservice architecture eliminates the traditional function call method for module calls. Instead, it uses lightweight communication protocols to request services, making the calling logic between modules flexible. When adding a new service module to the system, only the new service module needs to support the communication protocol of the internal modules, and then the module can be deployed to the system without restarting the system.

[0021] 3. The containers described in the gateway software system of this invention can be reused in many different application scenarios. After the developer builds the application image, multiple users can create containers with different running parameters on this image. This achieves "build once, deliver multiple times," thereby improving implementation efficiency and reducing development workload. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the hardware system design according to an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram of the microservice software architecture of the present invention;

[0024] Figure 3 This is a schematic diagram of an embodiment of the present invention. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention and therefore showing only the components relevant to the invention. The one or more embodiments of the invention described below are merely one or more specific ways to implement the technical solution of the invention, and are not exhaustive. It should be understood that other ways belonging to a general inventive concept can be used to implement the technical solution of the invention, and should not be limited to the embodiments described exemplary. All other embodiments obtained by those skilled in the art based on one or more embodiments of the invention without creative effort should fall within the scope of protection of the present invention.

[0026] To address the problems of poor scalability, tight hardware-software coupling, and inconvenient configuration and deployment in current IoT gateways, this invention proposes a gateway system and method with a scalable architecture, specifically including three technical solutions: a hardware system solution, a software system solution, and a configuration management system solution. The hardware system solution provides a design concept for the gateway's core circuit board. The software system solution includes a microservice software architecture solution and an inter-service communication solution. The configuration management system solution allows users to configure and manage the parameters of the microservices running on the gateway.

[0027] (1) Gateway hardware system solution

[0028] Gateway hardware system solutions can provide a unified access environment for various IoT devices. The gateway hardware design consists of three main parts: the main control processor minimum system, the communication interface, and auxiliary components.

[0029] The minimum system of the main control processor consists of a SoC chip (hereinafter referred to as the main control chip) capable of running a Linux system, along with necessary storage modules and power supply modules. Currently, commonly used communication protocols in the market are divided into two main categories: wired and wireless. Wired communication mainly includes various fieldbus protocols and industrial Ethernet protocols, while wireless communication is diverse. To address the issue of diverse communication methods for terminal devices, the following solution is adopted:

[0030] For devices using wired communication, corresponding electrical interfaces are reserved on the gateway core board. Investigations have shown that RS485, CAN, and Ethernet interfaces can support most mainstream wired communication protocols on the market at the physical layer. For example, devices using protocols such as Modbus RTU (industrial), Profibus DP (industrial), BACnet MS / TP (construction), and DALI (lighting) can be connected to the RS485 bus; devices using protocols such as CAN (automotive) and DeviceNet (industrial) can be connected to the CAN bus; and Ethernet can serve as the underlying technology for communication protocols such as EtherNet / IP, Profinet, OPC UA, and Modbus TCP.

[0031] For devices using wireless communication, the gateway hardware does not contain specific wireless communication modules; instead, it provides a unified slot. Research shows that most wireless communication modules can be adapted to the host computer via UART or USB interfaces. Therefore, multiple serial port slots and USB slots are provided on the gateway core board. The main control chip connects to the corresponding wireless communication adapter via the serial port or USB interface, and then connects to devices using the wireless communication protocol through the adapter. This allows users to select and insert different types of communication adapters as needed, thus flexibly building a communication network. It also avoids the problem of mutual interference caused by numerous wireless communication modules existing simultaneously on the core board.

[0032] The auxiliary components mainly consist of serial port expansion chips, USB expansion chips, and Ethernet switching chips. These chips can increase the number of serial ports, USB ports, and Ethernet ports, allowing multiple devices to connect simultaneously.

[0033] In summary, the gateway's hardware design uses a unified interface and optional communication adapters to address the connectivity issues of terminal devices with different communication protocols.

[0034] (2) Software system design scheme

[0035] The software system adopts a microservices design philosophy, using container technology to manage and deploy applications. The microservices software architecture employs a layered design, dividing gateway functions such as data acquisition, data processing, data storage, and data uploading into different microservices, each implemented using a container.

[0036] The gateway software architecture is based on the Linux operating system and a container engine running on it at its lowest level. Functionally, it is divided into a network access layer, a device abstraction layer, a custom logic layer, and a cloud connectivity layer. In addition to these four layers, the gateway software architecture also includes a message bus and a database, such as... Figure 2As shown in the diagram, the message bus and database are each implemented using a container. The network access layer encapsulates the interface for interacting with hardware drivers or the underlying protocol stack, i.e., the API (Application Programming Interface), for upper-layer applications to call. The device abstraction layer calls the API provided by the network access layer to implement operations such as connection, read and write to terminal devices. Each terminal device has a corresponding container at this layer. The functionality of a device can be described using three types of information: attributes, events, and actions, as shown in Table 1 below. Each container encapsulates one or more of the device's attributes, events, and actions, and can convert the information into MQTT messages and publish them to the MQTT message bus. An MQTT message contains only one of the attributes, events, and actions.

[0037] Table 1: Meaning of Attributes, Events, and Actions

[0038]

[0039] In the custom logic layer, users can receive messages from the device abstraction layer and process terminal device attributes, events, and actions, such as data analysis, rule engines, data storage, and data visualization. The raw data processed by the custom business logic can also be published to the message bus according to the specifications of attributes, events, and actions, allowing other services to receive and process it, thus forming a data processing flow. Each service corresponds to a container, ensuring isolation and independence between services, and allowing for dynamic addition or deletion of business logic.

[0040] The cloud connectivity layer is responsible for uploading the final data processed by the custom logic layer to a specific port on the cloud platform or remote server, according to the cloud platform's access protocol, and for receiving commands and requests from the cloud platform. Different cloud platform access protocols are contained within corresponding pre-developed containers.

[0041] Communication between microservices uses an MQTT message bus independent of all applications. Messages on the MQTT message bus have MQTT topics. A microservice only needs to publish and subscribe to topics of interest, and other microservices subscribed to the same topics can receive the messages. In the scheme described in this paper, the MQTT topics are designed with a unified namespace within the gateway. This unified namespace is a common naming hierarchy for MQTT topics; every MQTT message sent to the message bus uses this structure, enabling communication between devices and application services without considering their original names, locations, or protocols. This provides a consistent and standardized way to access data across multiple applications. The general naming hierarchy of MQTT topics is explained in Table 2 below, including five fields: container name, channel name, device name, function description, and function identifier. These fields are separated by " / ", for example, Device1 / ModBus / HumiditySensor / property / post. Here, Device1 is the container name, indicating the message originates from the container Device1; ModBus indicates the device uses the ModBus protocol; HumiditySensor is the device name; property indicates the message represents a device attribute; and post indicates the message is for the device to report its attribute. The container name identifies a unique container, the channel name and device name identify a unique terminal device, and the function description and function identifier identify a specific function of that device.

[0042] Table 2: Explanation of the Common Naming Hierarchy of MQTT Topics

[0043]

[0044] Following this hierarchical structure, users can create microservices for data acquisition, data processing, and data uploading. Each microservice consists of a container, and the flexible combination of numerous microservices enables gateway protocol conversion and edge computing functions. When new requirements arise, simply add the corresponding microservices and mount them to the message bus according to communication specifications.

[0045] The gateway of this invention has enhanced software reliability, with applications isolated from each other and not interfering with one another. This isolation improves the security and stability of applications, preventing problems in one application from affecting others.

[0046] This software system is not dependent on a specific language. For example, C is a high-performance language that can be used to develop data acquisition modules with high real-time requirements. Machine learning data analysis functions can be developed using Java, Python, or other languages. Each application runs in its own independent space and only needs to communicate with each other through a unified interface.

[0047] The gateway's software and hardware are loosely coupled, and the gateway software is portable, easily portable to any processor running Linux systems and Docker container engines. This saves developers from repetitive development work across different processor architectures.

[0048] (3) Configuration Management System Design Scheme

[0049] The configuration management system is responsible for configuring and managing the microservices running within the gateway. This can be divided into two aspects.

[0050] Firstly, it performs operations such as creating, starting, stopping, and updating microservices, and monitors their operational status. This invention uses the Portainer container orchestration tool. Portainer consists of two parts: a master and slave. The slave is installed on the gateway, while the master can be installed in the cloud. Portainer provides a web management interface for convenient container management.

[0051] Secondly, there's the configuration of microservice runtime parameters. Microservices are implemented as containers, and containers are created from images. The same image can create containers with different runtime parameters. For example, for ModBusRTU protocol integration, developers only need to build one image. The image doesn't specify parameters such as serial port baud rate, device address, or data type; instead, different runtime parameters are implemented by binding configuration files when creating the container. For already running microservices, the configuration files can also be modified to change the program's functionality.

[0052] Taking a smart home scenario as an example, the above solution is implemented as follows.

[0053] Based on the hardware system architecture described above, select a suitable chip to design the hardware system, such as... Figure 1 As shown in the diagram. The main control chip is the STM32MP157, which features a 32-bit dual-core ARM Cortex-A7 and a single-core Cortex-M4, with a main frequency of up to 800MHz. It integrates a CAN controller and an Ethernet MAC layer. The serial port expansion chip is the VK3224, which connects to the main control chip via an SPI interface, expanding one SPI port into four serial ports. The USB expansion chip is the FE2.1, which can expand one USB interface into seven. The Ethernet switching chip is the LAN9303, which connects to the STM32MP157 MAC layer via an RMII interface, expanding to two Ethernet interfaces. The RS485 level converter is the SP3485, which connects directly to the main control chip via a serial port. The CAN transceiver chip is the TJA1042, which connects to the CAN controller interface of the main control chip. The schematic diagram is shown below. Figure 1 As shown.

[0054] The Linux Debian operating system was ported to the main control chip, and Docker was downloaded and installed. Then, Docker container images were pulled from the Docker remote repository. Taking a smart home scenario as an example, assuming the terminal devices are a humidity sensor and a humidifier, connected to the gateway via ModBus and Bluetooth Low Energy (BLE) respectively. The humidity sensor continuously collects ambient humidity information and uploads it to the cloud platform; the humidifier should be turned on when the humidity value is below 20%. The following container images need to be pulled:

[0055] (1) Modbus device docking image, with a JSON type configuration file.

[0056] (2) The BLE device interface image has a .json type configuration file.

[0057] (3) The Alibaba Cloud platform interface image has a .txt type and a .json type configuration file.

[0058] (4) eKuiper rule engine official mirror.

[0059] (5) Influxdb time series database official mirror.

[0060] (6) Eclipse-mossquitto official image, which is based on the MQTT bus.

[0061] (7) Potainer official image, used for container management and monitoring.

[0062] For terminal device connection, connect the Modbus humidity sensor to the RS485 interface on the gateway using a wire. Next, plug in any USB WiFi adapter and USB Bluetooth adapter that support Linux via the USB interface. Connect the WiFi adapter to the router, which provides network connectivity for the gateway. Establish Bluetooth pairing and connection between the humidifier and the router via the Bluetooth adapter.

[0063] After the hardware system is connected, the software system is created. First, a configuration management system is created using the official Potainer image. Then, containers for the MQTT bus and time-series database are created on the management page.

[0064] Next, a container for the device abstraction layer is created using the image, with two containers corresponding to two terminal devices. Taking a humidity sensor as an example, it is created by connecting a Modbus device to the image, and a configuration file is bound during creation. The configuration file is modified from the Modbus protocol's configuration file template, and all configuration items in the configuration file are described in Table 3 below.

[0065] Table 3: Configuration file description for the humidity sensor and its corresponding container

[0066]

[0067]

[0068] The created container is named "Device1". Running the container will allow you to collect the humidity value from the sensor every 5 seconds and publish the humidity value to the MQTT message bus.

[0069] Next, a custom logic layer container is created, including a rule engine. This is created using the official eKuiper image and named RuleEngine. A rule is created in the rule engine to subscribe to the topic published by the container corresponding to the humidity sensor, retrieve the humidity value information, upload the humidity value to the time-series database, and determine if the humidity value is less than 20%. If so, a message is published to the MQTT bus.

[0070] Finally, a container for the cloud connection layer is created. This container, named `cloud`, is created using an Alibaba Cloud platform interface image. It retrieves data from the time-series database and uploads it to the Alibaba Cloud platform. This container has two configuration files: a text file responsible for retrieving data from the database according to rules, and a JSON file responsible for providing the parameters for connecting to the cloud platform.

[0071] After creating and configuring the above containers, the gateway can fulfill the requirements of the smart home scenario. A schematic diagram of the software system in this embodiment is shown below. Figure 3 As shown.

[0072] The above-described embodiments are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. Those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. An IoT edge computing gateway system with a scalable architecture, characterized in that, The gateway system is used to enable end-to-end communication between terminal devices and cloud platforms, private servers, or ports. The gateway system includes a gateway software system and a gateway hardware system. The gateway hardware system includes a SoC chip, several communication interfaces connected to the SoC chip, and auxiliary components. The auxiliary components are used to expand the communication interfaces, increasing the number of communication interfaces. The gateway software system runs on the SoC chip, and the terminal device connects to the communication interfaces. The gateway software system includes a network access layer, a device abstraction layer, a custom logic layer, a cloud connection layer, a message bus, and a database. The network access layer encapsulates the application programming interface (API) that interacts with the hardware driver or communication protocol stack in the communication interface; the device abstraction layer implements connection and read / write operations with the terminal device by calling the API of the network access layer. The device abstraction layer, custom logic layer, and cloud connection layer are all composed of several different containers. Different containers in the device abstraction layer correspond to different terminal devices. Different containers in the custom logic layer are pre-configured with different edge computing logic. Different containers in the cloud connection layer correspond to different cloud platforms, private servers, or ports. The container of the device abstraction layer is used to send information generated by the corresponding terminal device to the message bus. The information generated by the terminal device is one or more of the terminal device's attributes, events, and actions. The container of the custom logic layer is used to complete the edge computing processing of the messages in the message bus according to the set edge computing logic. The container of the cloud connection layer is used to upload the data processed by the custom logic layer to the corresponding cloud platform, private server, or port. It is also used to receive commands or requests issued by the cloud platform, private server, or port and further issue them. The further issued commands or requests are processed in the containers of the device abstraction layer or the custom logic layer. The message bus is used to enable communication between containers at different layers, using the MQTT protocol. Messages on the message bus have MQTT topics, which consist of five fields in sequence: container name, channel name, device name, function description, and function identifier. The channel name indicates the communication protocol used by the device. The function description indicates that the current message is an attribute, event, or action of the terminal device. If the current message is an attribute of the terminal device, the function identifier indicates that the current message is a report or setting of the attribute. If the current message is an event or action of the terminal device, the function identifier indicates the name of the event or action. The database is used to store the data processed by the custom logic layer; The step of sending the information generated by the corresponding terminal device to the message bus specifically involves converting one or more of the terminal device's attributes, events, and actions into messages with MQTT topics and sending them to the message bus. The containers in the gateway software system are all created from images. During creation, the containers are bound to configuration files, allowing containers created from the same image to have different running parameters. The configuration files are created using configuration file templates. Each terminal device connected to the gateway corresponds to a configuration file. Terminal devices using the same communication protocol use a common configuration file template. The configuration file template contains configuration items for communication protocol parameters, as well as configuration items for sets of attribute, event, or action variables. The set of attribute, event, or action variables is a set of variables that stores the attribute, event, or action data of the terminal device. By modifying the specific values ​​of the configuration items in the configuration file template, configuration files for different devices can be created.

2. The IoT edge computing gateway system with a scalable architecture according to claim 1, characterized in that, The SoC chip is a SoC chip capable of running the Linux system.

3. The IoT edge computing gateway system with a scalable architecture according to claim 1, characterized in that, The communication interfaces include an RS485 interface, a CAN interface, an Ethernet interface, a USB slot, and a UART slot. The specific connection methods for the terminal devices to the communication interfaces are as follows: terminal devices using wired communication are connected to the RS485 interface, CAN interface, or Ethernet interface; terminal devices using wireless communication protocols are connected to the USB slot or UART slot through a wireless communication adapter.

4. The IoT edge computing gateway system with a scalable architecture according to claim 1, characterized in that, The attributes of the terminal device are the operating status and collected data of the terminal device; the events of the terminal device are the information that the terminal device needs to be perceived and processed by the outside; and the actions of the terminal device are the instructions of the terminal device for external invocation.

5. The IoT edge computing gateway system with a scalable architecture according to claim 1, characterized in that, The containers in the cloud connection layer adopt the access protocol of the corresponding cloud platform, private server, or port.

Images