基于SuperEdge和EdgeXFoundry的云边端设备平台控制架构和方法与流程

基于superedge和edgexfoundry的云边端设备平台控制架构和方法
技术领域
1.本发明涉及云计算、边缘计算领域，具体涉及一种基于superedge和edgex foundry的云边端设备平台控制架构和方法。


背景技术：

2.近年来，随着物联网和5g技术不断地推进和发展，云计算应用的逐渐增加以及智能设备数据的急剧增加，企业对设备的管理不断升级。对设备的接入和数据采集需求必然空前高涨。传统的设备实时监控、数据采集使用技术不能满足低延时和高带宽的要求。另一方面设备终端、底层系统、设备接入协议转换等功能模块都以单体模式开发，实现数据收集、处理、导出、设备控制等功能。这种系统设计和实现方式存在运维困难、功能模块不可重用。
3.superedge以零侵入性基于kubernetes实现的边缘应用容器的管理框架，结合近年来火热的边缘计算的特点，将kubernetes强大的容器编排能力下沉到边缘侧，实现了云边协同、边缘自治等特性，很好的打通了云边通信，但是边缘侧应用离不开与终端侧设备的交互，superedge在设计上重点考虑了云边协同能力，对终端侧设备的管理能力存在缺失。
4.edgex foundry是linux基金会下的硬件和操作系统无关的开源中立的边缘计算微服务框架，用于统一工业物联网边缘计算解决方案的生态系统。其微服务众多，服务层级分明，传统的edgex foundry通过docker
‑
compose的部署方式，可以实现在单一边缘节点部署。但是单一边缘节点存在单点故障的风险，一旦边缘节点宕机，必然导致整个管理平台无法使用。
5.综上所述，亟需一种解决边缘设备管理平台的自动化部署以及实现云边协同和边边协同问题的方法，实现边缘设备管理平台部署的自动化、智能化，提高平台的扩展性。


技术实现要素：

6.为了解决现有技术中存在的上述技术问题，本发明提出了一种基于superedge和edgexfoundry的云边端设备平台控制架构和方法，解决边缘设备管理平台自动化部署，实现云端与边缘的协同，提高了物联网平台的可扩展性以及提高边缘设备管理效率，实现云边端一体化，其具体技术方案如下：基于superedge和edgex foundry的云边端设备平台控制架构，由superedge边缘计算管理框架和edgex foundry边缘计算框架组成，所述superedge边缘计算管理框架包括云侧和边缘侧，所述云侧和边缘侧通过云边隧道进行连接，所述云边隧道由tunnel
‑
cloud和tunnel
‑
edge组成；所述云侧部署有云端节点，边缘侧部署有边缘节点，所述边缘侧执行边缘应用部署和数据同步到云端节点，所述云侧用于管理边缘节点和发布边缘应用，所述edgex foundry边缘计算框架通过容器化编排方式部署于边缘节点上，以微服务形式运行。
7.进一步的，所述云端节点，包括：kubernetes原生组件和superedge云端组件，所述
kubernetes原生组件包括：kube
‑
apiserver、kube
‑
scheduler和kube
‑
controller
‑
manager。
8.进一步的，所述superedge云端组件包括：tunnel
‑
cloud：用于维持对接与边缘节点网络隧道tunnel
‑
edge，支持tcp/http/https协议；application
‑
grid controller：服务访问控制servicegroup对应的kubernetes controller，用于引入并管理deploymentgrids以及servicegrids crds，并由这两种cr生成对应的kubernetes deployment以及service，使得服务闭环访问；edge
‑
health admission：用于通过边端分布式健康检查的状态报告判断节点是否健康，并协助kube
‑
controller
‑
manager执行相关处理动作。
9.进一步的，所示云端节点还部署有mqtt broker服务组件。
10.进一步的，所述边缘节点设有superedge边缘侧组件，包括：lite
‑
apiserver：边缘自治的核心组件，是kube
‑
apiserver的代理服务，缓存了边缘节点的组件对kube
‑
apiserver的请求，当遇到请求而且与kube
‑
apiserver网络存在问题的时候会直接返回给client端；edge
‑
health：边端分布式健康检查服务，负责执行具体的监控和探测操作，并进行投票选举判断节点是否健康；tunnel
‑
edge：用于建立与云端边缘集群的网络隧道tunnel
‑
cloud，并接受api请求，转发给边缘节点组件kubelet；application
‑
grid wrapper：与application
‑
grid controller结合完成servicegrid内的闭环服务访问，实现服务拓扑感知。
11.进一步的，所述edgex foundry边缘计算框架，包括：设备服务层、核心服务层、支持服务层和应用服务层；所述设备服务层接入边缘设备，采集设备数据及控制设备功能，处理不同物联网设备协议转换和数据格式标准化，将设备信息转发到核心服务层，以及接受来自核心服务层命令控制服务core
‑
command的指令，并转给物联网设备；所述核心服务层，对设备数据进行存储以及对设备发送控制命令，即：负责服务注册与发现的configuration and registry微服务、采集设备服务层数据并提供数据服务的core data微服务、设备自身能力描述服务的meta data微服务和向设备发送命令的command微服务；所述应用服务层，接收控制命令转发给核心服务层，将收集的设备信息导出到云端或其他第三方应用；所述支持服务层负责日志记录、任务调度、数据清理、规则引擎和告警通知。
12.进一步的，所述应用服务层的微服务包括：提供对设备数据有需求的客户端注册服务；及时通知将设备数据发送到已经注册的客户端；对设备数据的格式进行处理再发送。
13.基于superedge和edgex foundry的云边端设备平台控制方法，包括以下步骤：步骤一：通过superedge部署工具edgeadm，部署边缘kubernetes集群，边缘kubernetes集群包括云端节点和边缘节点；步骤二：通过云端节点的kube
‑
apiserver发送部署edgex foundry微服务部署请求，以容器化方式部署到边缘节点上；步骤三：根据终端侧设备支持的协议类型，在设备服务层开发对应协议的设备服务device service及设备描述device profile，对接设备，并将设备服务device service以pod形式部署到边缘节点上，打通边端通信；
步骤四：基于edgex foundry的应用服务层，将处理后的设备数据进行导出到云侧的云端节点部署的mqtt broker。
14.进一步的，所述步骤三，具体为：所述设备服务，包含对接设备的特定协议驱动；终端侧设备接入边缘节点后，通过设备服务将物联网协议类型数据转换为互联网协议类型的数据，并将数据发送到核心服务层；所述核心服务层，包含：核心数据服务，接收边缘设备的事件信息，并将数据转发到消息队列库zeromq当中供其他微服务订阅使用；元数据服务，管理注册进来的设备数据；设备命令服务，接收外部rest请求，对终端侧设备发送控制指令。
15.本发明的有益效果：本发明可实现edgex foundry设备管理平台的高可用，同时兼顾云端设备数据的存储/分析，解决工业互联网、智能交通、新零售等场景中物联网设备高效管理，实现设备管理在云端和边缘端的协同，提高物联网平台的可扩展性以及提高边缘设备管理效率。
附图说明
16.图1是本发明的基于superedge和edgex foundry集成交互图；图2是superedge架构图；图3是edgex foundry整体架构图。
具体实施方式
17.为了使本发明的目的、技术方案和技术效果更加清楚明白，以下结合说明书附图，对本发明作进一步详细说明。
18.如图1所示，一种基于superedge和edgex foundry的云边端设备平台控制架构，由superedge边缘计算管理框架和edgex foundry边缘计算框架组成，所述superedge边缘计算管理框架包括云侧和边缘侧，所述云侧部署有云端节点，边缘侧部署有边缘节点，所述edgex foundry边缘计算框架通过容器化编排方式部署于边缘节点上，以微服务形式运行。
19.具体的，所述superedge边缘计算管理框架是基于kubernetes实现的边缘应用容器的管理框架，所述云侧：用于管理边缘节点和发布边缘应用；所述边缘侧：执行边缘应用部署和数据同步到云端节点。
20.如图2所示，所述云端节点，包括：kubernetes原生组件和superedge云端组件。
21.所述kubernetes原生组件包括：kube
‑
apiserver、kube
‑
scheduler和kube
‑
controller
‑
manager。
22.所述superedge云端组件包括：tunnel
‑
cloud：用于维持对接与边缘节点网络隧道tunnel
‑
edge，支持tcp/http/https协议；application
‑
grid controller：服务访问控制servicegroup对应的kubernetes controller，用于引入并管理deploymentgrids以及servicegrids crds，并由这两种cr生成对应的kubernetes deployment以及service，同时自研实现服务拓扑感知，使得服务闭环访问；edge
‑
health admission：用于通过边端分布式健康检查的状态报告判断节点是否健康，并协助kube
‑
controller
‑
manager执行相关处理动作。
23.所述边缘节点设有superedge边缘侧组件，包括：lite
‑
apiserver：边缘自治的核心组件，是kube
‑
apiserver的代理服务，缓存了边缘节点的组件对kube
‑
apiserver的请求，当遇到请求而且与kube
‑
apiserver网络存在问题的时候会直接返回给client端；edge
‑
health：边端分布式健康检查服务，负责执行具体的监控和探测操作，并进行投票选举判断节点是否健康；tunnel
‑
edge：用于建立与云端边缘集群的网络隧道tunnel
‑
cloud，并接受api请求，转发给边缘节点组件kubelet；application
‑
grid wrapper：与application
‑
grid controller结合完成servicegrid内的闭环服务访问，实现服务拓扑感知。
24.所示云端节点还部署有mqtt broker服务组件。
25.如图3所示，所述edgex foundry边缘计算框架包含多个微服务，可分为以下四个层次：设备服务层：接入不同的边缘设备，负责采集数据及控制设备功能，具体为：南向主要处理不同物联网设备协议转换和数据格式标准化，北向实现将设备信息转发到核心服务层，以及接受来自命令控制服务core
‑
command的指令，并转给物联网设备。设备服务可能服务一个或者多个物联网设备，例如传感器、执行器等，支持多种物联网协议例如modbus、mqtt、ble、bacnet等。
26.核心服务层：对设备数据进行存储分析和转发数据，以及控制命令下发，具体为：负责服务注册与发现的configuration and registry微服务；负责采集南向设备层数据，并向北向服务提供数据服务的core data微服务；负责设备自身能力描述服务的meta data微服务；负责向南向设备发送命令的command微服务。
27.应用服务层：负责上传数据到云端，以及接收控制命令转发给核心服务，具体为：可以独立于其他系统工作，即使在离线条件下也能对数据进行处理，但在部分场景下平台需要与云平台或其他第三方系统通信，将收集的设备信息导出到云端或其他第三方应用当中去进一步做处理；导出服务层的功能就是实现将边缘物联网平台当中数据通过各种协议导出云平台进行存储和分析，应用服务层包含几个关键的微服务主要功能包括：提供对设备数据有需求的客户端注册服务；及时通知将设备数据发送到已经注册的客户端；对设备数据的格式进行处理再发送。
28.支持服务层：负责日志记录、任务调度、数据清理、规则引擎和告警通知。
29.一种基于superedge和edgex foundry的云边端设备平台控制方法，包括以下步骤：步骤一：通过superedge部署工具edgeadm，部署边缘kubernetes集群，边缘kubernetes集群包括云端节点和边缘节点。
30.步骤二：通过云端节点的kube
‑
apiserver发送部署edgex foundry微服务部署请求，以容器化方式部署到边缘节点上。
31.步骤三：根据终端侧设备支持的协议类型，开发对应协议的设备服务device service及设备描述device profile，对接设备，并将设备服务device service以pod形式部署到边缘节点上，打通边端通信。
32.具体的，所述设备服务，包含对接设备的特定协议驱动；终端侧设备接入边缘节点后，通过设备服务将物联网协议类型数据转换为互联网协议类型的数据，并将数据发送到核心服务。
33.所述核心服务，包含：核心数据服务，接收边缘设备的事件信息，并将数据转发到消息队列库zeromq当中供其他微服务订阅使用；元数据服务，管理注册进来的设备数据，包含设备名称、id、标签等；设备命令服务，接收外部rest请求，对终端侧设备发送控制指令。
34.步骤四： edgex foundry的应用服务层，根据特定需求将处理后的设备数据进行导出到云侧的在云端节点部署的mqtt broker。
35.以上所述，仅为本发明的优选实施案例，并非对本发明做任何形式上的限制。虽然前文对本发明的实施过程进行了详细说明，对于熟悉本领域的人员来说，其依然可以对前述各实例记载的技术方案进行修改，或者对其中部分技术特征进行同等替换。凡在本发明精神和原则之内所做修改、同等替换等，均应包含在本发明的保护范围之内。