阅读说明：本技术 一种基于KubeEdge和EdgeOS的物联网设备控制架构和方法 (KubeEdge and edgeOS-based Internet of things equipment control architecture and method ) 是由 郁善金 王晓江 高丰 郑欢欢 杨涛 汤志航 于 2021-07-13 设计创作，主要内容包括：本发明涉及一种基于KubeEdge和EdgeOS的物联网设备控制架构和方法,该架构具体为：所述KubeEdge包含云侧模块和边缘侧模块,所述云侧模块部署有云端节点,边缘侧模块部署有边缘节点,所述云侧模块管理边缘节点和发布边缘端应用,边缘侧模块执行边缘端应用部署和数据同步至云侧模块,所述边缘节点部署Device Mapper和MQTT Broker,所述EdgeOS配置有Gateway网关并通过该网关与端侧设备进行数据通信,所述Device Mapper以HTTP消息形式与Gateway网关交互,发布、订阅MQTT消息至MQTT Broker。本发明降低了KubeEdge侧设备管理开发的复杂度。(The invention relates to an Internet of things equipment control framework and a method based on KubeEdge and EdgeOS, wherein the framework specifically comprises the following steps: the KubeEdge comprises a cloud side module and an edge side module, the cloud side module is deployed with a cloud end node, the edge side module is deployed with an edge node, the cloud side module manages the edge node and issues edge end application, the edge side module executes edge end application deployment and data synchronization to the cloud side module, the edge node is deployed with a Device Mapper and an MQTT Broker, the EdgeOS is configured with a Gateway and carries out data communication with end side equipment through the Gateway, and the Device Mapper interacts with the Gateway in the form of HTTP messages and issues and subscribes MQTT messages to the MQTT Broker. The invention reduces the complexity of KubeEdge side equipment management development.)

1. The Internet of things equipment control architecture based on the KubeEdge and the EdgeOS is characterized in that the KubeEdge comprises a cloud side module and an edge side module, namely a cloud end and an edge end, the cloud side module is provided with a cloud end node, the edge side module is provided with an edge node, the cloud side module manages the edge node and issues edge end application, the edge side module executes edge end application deployment and data synchronization to the cloud side module, the edge node is provided with a Device Mapper and an MQTT Broker, the EdgeOS is provided with a Gateway and carries out data communication with end side equipment through the Gateway, and the Device Mapper interacts with the Gateway in the form of HTTP messages and issues and subscribes QTMT messages to the MQTT Broker.

2. The KubeEdge and edgeOS-based Internet of things device control architecture of claim 1, wherein the cloud node comprises: a native kubernets module and a CloudCore module, the native kubernets module comprising: the kube-apiserver is used for receiving a client request; a kube-scheduler that schedules cloud application deployment; kube-controller-manager, which manages the various microcontrollers of the system.

3. The KubeEdge and edgeOS-based Internet of things device control architecture of claim 2, wherein the CloudCore component comprises: the EdgeController is used for synchronizing the information of the edge side module and the API-server and managing the metadata of the edge nodes and the Pods; a DeviceController for synchronizing the CRD information and API-Server information of the edge side module; the CloudHub is connected and communicated with the edge terminal based on a websocket or quic protocol, monitors the change of a cloud terminal, caches and sends a message to the edge side module, and achieves cloud-side communication.

4. The Kubeedge and edgeOS-based Internet of things device control architecture of claim 1, wherein the edge node is further deployed with an Edgecore component, and the Edgecore component comprises:

EdgeHub: the cloud service interaction with the edge computing is carried out, information is received from the cloud hub of the cloud and forwarded to the edge side module, meanwhile, the information of the edge side module is sent to the cloud side module through the tunnel, and the cloud service interaction comprises the steps of synchronous cloud resource updating and reporting of the state change of an edge host and equipment to the cloud side;

edge: the system comprises a cloud end, a storage node, a container application program, a storage node and a storage node, wherein the container application program is used for managing the container application program, ensuring that a cloud end issues a pod and various configurations and storages can run in the edge node, and automatically detecting and recovering faults after the abnormality occurs;

EventBus: the MQTT client interacts with an MQTT server mosquitto provide subscription and publishing functions for other components and is used as a message interface for sending/receiving related MQTT topics;

service bus: the HTTP client running at the edge receives a request from a cloud and interacts with an HTTP server running at the edge;

DeviceTwin: the system is in charge of storing the state of the Internet of things equipment, synchronizing the state of the equipment to the cloud end and providing a query interface for an application program;

MetaManager: the message processor is positioned between the Edged and the Edgehub, and the back end corresponds to a local lightweight database SQLite which is responsible for storing/retrieving metadata to the lightweight database SQLite.

5. The KubeEdge and EdgeOS-based Internet of things device control architecture of claim 1, wherein the Gateway is provided with a device acquisition service and a device data export service, the acquisition service is responsible for data communication between the Gateway and end-side devices, acquires device data, and processes the acquired device data uniformly; and the data export service is responsible for data communication between the gateway and the cloud.

6. A Kubeedge and edgeOS-based Internet of things equipment control method is characterized by comprising the following steps:

the method comprises the following steps: pre-building a Kubernets cluster, deploying a cloud core module Cloudcore at a cloud node, and deploying an edge core module EdgeCore and an equipment data communication module MQTT Broker at an edge node;

step two: creating a device model/device instance at the cloud, wherein the CRD resource comprises a description of the function of the device and a description of the attribute of the device;

step three: a Device Mapper is developed and deployed to run on the edge node to communicate with the Gateway of the edgeOS via http.

7. The internet of things Device control method based on kubeeedge and EdgeOS of claim 6, wherein the Device Mapper is used for conversion between http messages and MQTT messages, and specifically comprises: publish, subscribe MQTT messages to MQTT Broker and interact with Gateway in http messages.

Technical Field

The invention relates to the field of edge computing, in particular to an Internet of things equipment control framework and method based on KubeEdge and EdgeOS.

Background

With the continuous promotion and development of the internet of things and the 5G technology, the gradual increase of cloud computing application and the rapid increase of intelligent equipment data, and the requirements for equipment access and data acquisition are inevitably high. In 2010-2018, the number of global Internet of things devices is increased at a high speed, the composite growth rate reaches 20.9%, and in 2018, the number of global Internet of things devices connected reaches 91 hundred million. It is predicted that the number of global internet of things devices (including cellular and non-cellular) networking devices will reach 252 billion in 2025. The traditional real-time monitoring and data acquisition using technology of the equipment cannot meet the requirements of low delay and high bandwidth. On the other hand, functional modules such as the equipment terminal, the bottom layer system, the equipment access protocol conversion and the like are developed in a single mode, and functions such as data collection, processing, export, equipment control and the like are realized. The system design and implementation mode has operation and maintenance difficulty and non-reusable functional modules. In later development, the system adaptability is very poor, and the system data sharing is inconvenient.

KubeEdge is an open source system, and the design is performed at the beginning, so that the cloud edge cooperation and the edge autonomy are focused, and the management capacity of the equipment at the opposite end side is fully considered. The device management capability of the device can reach the end-side device through the side module and penetrate through the cloud-side-end. However, since the types of protocols supported by the end-side device are numerous and difficult to unify, KubeEdge only provides a specification framework and requires developers to develop the protocols according to different protocols, which is very difficult for developers who do not know the protocols.

The EdgeOS is an internet of things operating system developed based on OpenWrt, has core functions of industrial protocol analysis, data filtering and distribution and the like, and has the advantages of cross-platform performance, easiness in use, secondary development and the like. The method has extensible north-south access capability, but the capability mainly focuses on the access management of south-direction equipment, and the cloud edge coordination capability based on a cloud native architecture like KubeEdge is lacked.

In summary, there is a need for a method that can simplify the complexity of management and development of a KubeEdge device, effectively shield the difference of devices on the end side, and access a device with a rich protocol type on the end side.

Disclosure of Invention

In order to solve the technical problems in the prior art, the invention provides an internet of things equipment control architecture and method based on KubeEdge and EdgeOS, which conform to a cloud edge-side architecture, can effectively shield the difference of bottom equipment, and aggregate the advantages of different systems, thereby improving the expandability of an internet of things platform and the management capability of edge equipment, and the specific technical scheme is as follows:

the KubeEdge and the EdgeOS-based Internet of things Device control architecture comprises a cloud side module and an edge side module, namely a cloud end and an edge end, wherein the cloud side module is provided with a cloud end node, the edge side module is provided with an edge node, the cloud side module manages the edge node and releases an edge end application, the edge side module executes edge end application deployment and data synchronization to the cloud side module, the edge node is provided with a Device Mapper and an MQTT Broker, the EdgeOS is provided with a Gateway and carries out data communication with end side devices through the Gateway, and the Device Mapper interacts with the Gateway in an HTTP message mode and releases, subscribes and transmits MQTT messages to the MQTT Broker.

Further, the cloud node includes: a native kubernets module and a CloudCore module, the native kubernets module comprising: the kube-apiserver is used for receiving a client request; a kube-scheduler that schedules cloud application deployment; kube-controller-manager, which manages the various microcontrollers of the system.

Further, the CloudCore component includes: the EdgeController is used for synchronizing the information of the edge side module and the API-server and managing the metadata of the edge nodes and the Pods; a DeviceController for synchronizing the CRD information and API-Server information of the edge side module; the CloudHub is connected and communicated with the edge terminal based on a websocket or quic protocol, monitors the change of a cloud terminal, caches and sends a message to the edge side module, and achieves cloud-side communication.

Further, the edge node is also deployed with an Edgecore component, where the Edgecore component includes:

EdgeHub: the cloud service interaction with the edge computing is carried out, information is received from the cloud hub of the cloud and forwarded to the edge side module, meanwhile, the information of the edge side module is sent to the cloud side module through the tunnel, and the cloud service interaction comprises the steps of synchronous cloud resource updating and reporting of the state change of an edge host and equipment to the cloud side;

edge: the system comprises a cloud end, a storage node, a container application program, a storage node and a storage node, wherein the container application program is used for managing the container application program, ensuring that a cloud end issues a pod and various configurations and storages can run in the edge node, and automatically detecting and recovering faults after the abnormality occurs;

EventBus: the MQTT client interacts with an MQTT server mosquitto provide subscription and publishing functions for other components and is used as a message interface for sending/receiving related MQTT topics;

service bus: the HTTP client running at the edge receives a request from a cloud and interacts with an HTTP server running at the edge;

DeviceTwin: the system is in charge of storing the state of the Internet of things equipment, synchronizing the state of the equipment to the cloud end and providing a query interface for an application program;

MetaManager: the message processor is positioned between the Edged and the Edgehub, and the back end corresponds to a local lightweight database SQLite which is responsible for storing/retrieving metadata to the lightweight database SQLite.

Furthermore, the Gateway is provided with an equipment acquisition service and an equipment data export service, wherein the acquisition service is responsible for data communication between the Gateway and the end-side equipment, acquires the equipment data and uniformly processes the acquired equipment data; and the data export service is responsible for data communication between the gateway and the cloud.

A Kubeedge and edgeOS-based Internet of things equipment control method comprises the following steps:

the method comprises the following steps: pre-building a Kubernets cluster, deploying a cloud core module Cloudcore at a cloud node, and deploying an edge core module EdgeCore and an equipment data communication module MQTT Broker at an edge node;

step two: creating a device model/device instance at the cloud, wherein the CRD resource comprises a description of the function of the device and a description of the attribute of the device;

step three: a Device Mapper is developed and deployed to run on the edge node to communicate with the Hekr Gateway204 Gateway of EdgeOS via http.

Further, the Device Mapper is configured to convert an http message and an MQTT message, and specifically includes: publish, subscribe MQTT messages to MQTT Broker and interact with the Hekr Gateway204 Gateway in http messages.

The invention has the beneficial effects that:

the invention integrates the advantages of KubeEdge and EdgeOS, gets through the cloud edge, simplifies the complexity of the KubeEdge side for equipment management development, effectively shields the development of Device mappers with different protocol types, simultaneously exerts the core capabilities of the EdgeOS such as industrial protocol analysis, data filtering and distribution, solves the high-efficiency management and intelligent analysis of the Internet of things equipment in the scenes such as industrial Internet, intelligent traffic, new retail and the like, and realizes the cooperation of equipment management at the cloud end and the edge end.

Drawings

FIG. 1 is a device management interaction diagram based on Kubeedge and edgeOS according to the present invention;

fig. 2 is a KubeEdge framework diagram.

Detailed Description

In order to make the objects, technical solutions and technical effects of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings.

As shown in fig. 1, an internet of things device control architecture based on KubeEdge and EdgeOS of the present invention specifically includes the following contents:

the cloud Edge coordination, the Edge autonomy and the equipment management are realized based on the KubeEdge, and the KubeEdge is an open source system and is used for expanding the containerization application program arranging function to a host of the Edge, so that the control management of the end-side equipment can be realized.

As shown in fig. 2, the KubeEdge is constructed based on kubernets, and provides infrastructure support, deployment between a cloud side and an edge side, and metadata synchronization for a network application program, the KubeEdge includes a cloud side module and an edge side module, that is, a cloud end and an edge end, the cloud side module is deployed with a cloud end node, the edge side module is deployed with an edge node, the cloud side module manages the edge node and issues an edge end application, the edge side module executes edge end application deployment and data synchronization to the cloud end, and it provides two-way capabilities: on one hand, the edge end load application, namely the service running in the pod form, is managed, and on the other hand, the end side Device control and the data synchronization thereof are carried out through the Device controller/Device twin/Device mapper.

The cloud side module is deployed with a cloud end node, namely a kubernets master control node, and the kubernets master control node comprises: native kubernets module and CloudCore module. The native kubernets component comprises: the kube-apiserver is used for receiving a client request; a kube-scheduler that schedules cloud application deployment; kube-controller-manager, which manages the various microcontrollers of the system.

The CloudCore component includes:

the EdgeController is an extended Kubernets controller and is used for synchronizing the information of an edge side module and API-servers, managing the metadata of edge nodes and Pods and ensuring that data can be transmitted to the designated edge nodes;

the DeviceController is an extended Kubernets controller, and is used for synchronizing CRD information and API-Server information of edge side equipment, managing the edge equipment and ensuring cloud side synchronization of equipment information and equipment state.

The CloudHub is a Web Socket server, is connected and communicated with the edge terminal based on a websocket or a quic protocol, is responsible for monitoring the change of the cloud terminal, caches and sends a message to the EdgeHub of the edge side module, and realizes cloud-side communication.

The edge side module is provided with an edge node, and controls the equipment by means of Kubernets CRDs and Device mapper corresponding to the used equipment, wherein the edge node comprises: edgecore component and MQTT Broker component.

The Edgecore component comprises:

EdgeHub: the system comprises a Web Socket client, an edge side module and a client side, wherein the Web Socket client is responsible for interacting with cloud services of edge computing, receiving information from a cloud end and forwarding the information to the edge side module, and sending the information of the edge side module to the cloud end through a tunnel, and specifically comprises the functions of synchronizing cloud end resource updating, reporting the state change of an edge host and equipment to the cloud end and the like;

edge: the agent is an agent running on an edge node and used for managing a containerized application program, ensuring that a cloud-side issuing pod and various configurations and storages can run on the edge node, and providing capabilities of automatic detection, fault recovery and the like after abnormity;

EventBus: the MQTT client interacts with an MQTT server mosquitto provide subscription and publishing functions for other components and serves as a message interface for sending/receiving related MQTT topics;

service bus: the HTTP client side runs on the edge, receives a request from a service on the cloud, interacts with the HTTP server running on the edge, and provides the capability of the service on the cloud to access the HTTP server on the edge through an HTTP protocol;

DeviceTwin: the system is in charge of storing the state of the Internet of things equipment, synchronizing the state of the equipment to the cloud end and providing a query interface for an application program;

MetaManager: the message processor is located between the edge and the edge hub, the rear end of the message processor corresponds to a local lightweight database SQLite, all contents of other modules needing to be communicated with the cloud end are stored in the local DB, and when data needs to be inquired, if the data exists in the local DB, the contents can be acquired from the local DB, so that frequent network interaction with the cloud end is avoided. Meanwhile, under the condition of network interruption, the locally cached data can also ensure the stable operation of the intelligent automobile, for example, the intelligent automobile enters a tunnel without wireless signals, and after communication is recovered, the data is resynchronized, and the data is responsible for storing/retrieving metadata to the lightweight database SQLite.

And managing the equipment of the cloud end through the Device controller and the Device twin, and synchronizing the equipment update between the edge node and the cloud end. Under the assistance of MQTT Broker and Device mapper, the control and data exchange of edge nodes and end-side equipment are realized, so that the cloud-edge-end capability is communicated.

The edge Gateway system of the EdgeOS internet of things realizes the functions of data acquisition, protocol analysis, data distribution and the like of a Gateway on the sub-equipment of the internet of things by configuring an industrial Gateway Hekr Gateway204 of the EdgeOS internet of things, wherein the industrial Gateway Hekr Gateway204 is provided with equipment acquisition service and equipment data export service, and the acquisition service is responsible for data communication between the Gateway and the sub-equipment, acquires the data of the sub-equipment and uniformly processes the acquired data of the sub-equipment; and the data export service is responsible for data communication between the gateway and the north cloud service platform.

The Internet of things sub-device supports multiple communication protocol types of devices, such as ModBus, Zigbee, Bluetooth and the like.

The Hekr Gateway204 Gateway is a core part of the EdgeOS system, and has the main functions of:

the protocol analysis supports various communication protocols, carries out data communication with the sub-equipment and collects the data of the sub-equipment;

data filtering, namely uniformly processing the acquired data of the sub-equipment;

and data distribution, namely, according to the requirement, the data distribution is in data communication with the cloud service platform, and the equipment data is distributed to different platforms.

The EdgeOS internet of things edge gateway system is a lightweight internet of things operating system developed based on OpenWrt and specially configured for adapting to edge-side resource-constrained devices, has core functions such as industrial protocol analysis, data filtering and distribution, has the advantages of being cross-platform, easy to use, secondary developed and the like, and specifically comprises:

extensible southbound access capability, support multiple data interfaces: ethernet, RS232, RS485, CAN support the analysis of multiple industry protocols, and the protocol includes: KNX, BACnet, ModBus TCP, ModBus RTU, DL/T645, OPC, etc.;

the extensible northbound access capability supports various cloud service platforms including EdgeX, Http, IoTOS and the like;

data automation, namely performing operations such as data filtering, calculation, forwarding and the like according to conditions, expressions and the like;

data visualization, namely performing visual display on the acquired data;

abundant network access capability, support GPRS, 4G (long term evolution), Wi-Fi and Ethernet access modes;

different architectures are supported across multiple hardware platforms: ARM, x86, x86-64, MIPS and the like, and various hardware gateway devices with different costs and different performances;

the background management interface can be connected to a management background by using a browser as a client to perform function configuration, and the configuration supports import and export and can be rapidly deployed on site;

the memory resource occupation is low, the EdgeOS program only occupies less than 128MB of running memory, and acquisition and cloud service interaction tasks running different protocols have extremely low memory occupation performance;

the EdgeOS system is designed to be an extensible structure, and can support more data acquisition protocols or more types of sub-devices by writing a program to be a module, and can also send data to a self-defined format to a self server.

Based on the above framework, the internet of things equipment control method based on KubeEdge and EdgeOS in the invention comprises the following steps:

the method comprises the following steps: pre-building a Kubernets cluster, deploying a cloud core module Cloudcore at a cloud node, and deploying an edge core module EdgeCore and an equipment data communication module MQTT Broker at an edge node;

step two: creating a device model/device instance at the cloud, wherein the CRD resource comprises a description of the function of the device and a description of the attribute of the device;

step three: a Device Mapper is developed and deployed to run on the edge node to communicate with the Hekr Gateway204 Gateway of EdgeOS via http.

The Device Mapper is used for converting http messages and MQTT messages, publishing and subscribing the MQTT messages to MQTT Broker upwards, and interacting with the Hekr Gateway204 Gateway downwards through http messages.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention in any way. Although the foregoing has described the practice of the present invention in detail, it will be apparent to those skilled in the art that modifications may be made to the practice of the invention as described in the foregoing examples, or that certain features may be substituted in the practice of the invention. All changes, equivalents and modifications which come within the spirit and scope of the invention are desired to be protected.