用于云边协同系统的语义模型构建方法与流程

1.本技术涉及天基物联网技术领域，特别是涉及一种用于云边协同系统的语义模型构建方法。


背景技术：

2.物联网是未来网络发展的趋势，是第四次工业革命的核心。但是仅仅依靠地面设备的物联网体系还存在着很大的缺陷，由于极端的地形或通信距离以及成本限制，一些偏远地区还没有网络覆盖，目前地面无线网络的覆盖率仅为48％。卫星广播网的广域覆盖可以解决地面覆盖问题，解决自然灾害造成的通信中断问题。显然，卫星已经成为物联网的重要组成部分。与此同时，卫星是对地面网络和未来5g/6g通信的一种可实现的强大补充。
3.不同于地面网络传输，天基网络通信范围更加广阔，可以实现全球范围性的覆盖，而且在布设传感器时几乎不需要考虑地形和空间的限制。在面对各种自然危害和恶劣天气的情况下，天基网络依然可以正常工作。
4.在传统的天基物联网架构中，卫星更多的是充当一个转发者和中继的角色，数据的处理由地面网络和处理中心负责，并将处理完成后的数据通过移动网或者互联网等各种手段转发给用户。考虑到地面云端和天基边缘节点之间的传输距离远，传输时延长，相对于传统的云计算架构，云边协同架构更适合天基背景。
5.对于天基物联网来说，连接的终端设备底层协议具有标准不统一的情况，因此需要互操作性实现对于设备端的无缝操作，从而充分发挥天基物联网广域连接性的潜力。然而目前底层设备由于各个行业的标准并没有统一，导致数据不容易被人和机器相互理解，这种分散性会增加上层开发人员在使用数据时的时间成本。因此，在天基物联网中，需要考虑到如何提高数据的可理解性，增强数据的互操作，使得无论使用类型的硬件，人和机器之间都能够实现互相连接。


技术实现要素：

6.基于此，有必要针对上述技术问题，提供一种能够增强数据的互操作，使得设备端无论是什么类型的硬件，人和机器、以及机器和机器之间都能够实现互相连接的用于云边协同系统的语义模型构建方法。
7.一种用于云边协同系统的语义模型构建方法，所述语义模型构建方法实施于所述云边协同系统中，其中所述云边协同系统用于构建天基物联网，所述云边协同系统包括云端服务器、作为边缘节点的卫星以及多个设备端，所述云端服务器通过边缘节点接收来自各设备端的上传数据以及向各设备端发送指令，所述方法包括：
8.在每个设备端中，均根据opc ua协议构建与各设备端对应的语义模型，还根据opc ua协议搭建相应的spc ua服务器，并将该语义模型映射到对应设备端中的spc ua服务器地址空间中；
9.在所述云端服务器通过边缘节点向各设备端发送指令时，将所述指令下发给所述
边缘节点，在所述边缘节点中将所述指令发布至mqtt服务器中，再由mapper将来自mqtt协议的指令转换成opc ua协议，并将opc ua协议发送至对应的设备端；
10.在各设备端中通过spc ua服务器中的语义模型对接收到的opc ua协议获取对应的指令，并根据指令进行相应操作。
11.在其中一实施例中，所述方法还包括：
12.各所述设备端向所述云端系统上传数据时，通过各自构建的语义模型将接收的数据转换成相应的opc ua协议，再将opc ua协议发送至所述边缘节点；
13.所述边缘节点将接收到的opc ua协议发布至mqtt服务器中，再由mapper将来自mqtt协议的opc ua协议转换成所述云端服务器可识别格式的上传数据，并将该格式的上传数据发送至所述云端服务器，以供所述云端服务器使用。
14.在其中一实施例中，所述方法还包括：
15.所述云端服务器根据各设备端的语义模型编写对应的yaml文件，再通过各所述yaml文件构建对应的模型元数据，并将各所述模型元数据发送给所述边缘节点；
16.所述边缘节点根据云端服务器下发的各所述模型元数据构建相应的设备孪生，并将各设备孪生存储在边缘节点中。
17.在其中一实施例中，在根据opc ua协议构建与各设备端对应的语义模型时包括：
18.对所述设备端根据其属性以及相关的数据进行定义；
19.在对定义后的设备端根据opc ua协议进行实例化，也就是构建对应的语义模型。
20.在其中一实施例中，根据opc ua协议搭建相应的spc ua服务器时依次包括：服务器初始化、创建服务器、服务器对结构化文件的解析，运行服务器以及删除服务器；
21.并在创建服务器后，将构建好的语义模型映射到spc ua服务器的地址空间中。
22.在其中一实施例中，所述云边协同系统采取基于kubeedge和docker的整体设计。
23.在其中一实施例中，在所述云端服务器和边缘节点之间通过设备插件框架edgecore，以实现将所述边缘节点接收的数据上报至所述云端服务器以及负责所述边缘节点的调度选择。
24.一种用于云边协同系统，所述云边协同系统用于构建天基物联网，所述云边协同系统包括云端服务器、作为边缘节点的卫星以及多个设备端，所述云端服务器通过边缘节点接收来自各设备端的上传数据以及向各设备端发送指令；
25.在每个设备端中，均根据opc ua协议构建与各设备端对应的语义模型，还根据opc ua协议搭建相应的spc ua服务器，并将该语义模型映射到对应设备端中的spc ua服务器地址空间中；
26.在所述云端服务器通过边缘节点向各设备端发送指令时，将所述指令下发给所述边缘节点，在所述边缘节点中将所述指令发布至mqtt服务器中，再由mapper将来自mqtt协议的指令转换成opc ua协议，并将opc ua协议发送至对应的设备端；
27.在各设备端中通过spc ua服务器中的语义模型对接收到的opc ua协议获取对应的指令，并根据指令进行相应操作。
28.上述用于云边协同系统的语义模型构建方法，是实施于由云边协同系统构建的天基物联网中，在该云边协同系统中包括云端服务器、作为边缘节点的卫星以及多个设备端，本方法通过在各个设备端根据opc ua协议构建相应的语义模型以及opc ua服务器，并将构
建好的语义模型映射到opc ua服务器中，以实现设备端的信息进行抽象表示，从而完成云端服务器对各设备端的语义互操作。
附图说明
29.图1为一个实施例中系统总体框架的结构示意图；
30.图2为一个实施例中原始数据映射步骤示意图；
31.图3为一个实施例中sx1302网关建模示意图；
32.图4为一个实施例中opc ua服务器的配置结构体框架示意图；
33.图5为一个实施例中创建服务器流程示意图；
34.图6为一个实施例中服务器运行函数流程示意图；
35.图7为一个实施例中构建mapper镜像流程示意图；
36.图8为一个实施例中云边协同系统的工作流程示意图。
具体实施方式
37.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
38.针对目前的天基物联网中，各低层设备由于各个行业的标准并没有统一，导致数据不容易被人和机器想换理解，这种分散性会增加上层开发人员在使用数据时的时间成本的问题，在本实施例中，提供了一种用于云边协同系统的语义模型构建方法，该语义模型构建方法实施于云边协同系统中，其中云边协同系统用于构建天基物联网，云边协同系统包括云端服务器、作为边缘节点的卫星以及多个设备端，云端服务器通过边缘节点接收来自各设备端的上传数据以及向各设备端发送指令，方法包括：
39.在每个设备端中，均根据opc ua协议构建与各设备端对应的语义模型，还根据opc ua协议搭建相应的spc ua服务器，并将该语义模型映射到对应设备端中的spc ua服务器地址空间中；
40.在云端服务器通过边缘节点向各设备端发送指令时，将指令下发给所述边缘节点，在边缘节点中将所述指令发布至mqtt服务器中，再由mapper将来自mqtt协议的指令转换成opc ua协议，并将opc ua协议发送至对应的设备端；
41.在各设备端中通过spc ua服务器中的语义模型对接收到的opc ua协议获取对应的指令，并根据指令进行相应操作。
42.从本方法中可以看出，本方法实际上是实施在由云边协同系统构建的天基物联网中，可以说本方法与该系统是密不可分的。同时从上文中可以看出本实施例提出的语义模型构建方法不仅仅是一种语义模型构建方法，还包括基于该方法在各设备端进行语义模型构建后如何实现云端服务器对各设备端的语义互操作。
43.通过本方法可实现基于云边协同系统构建的天基物联网满足应用协同、服务协同以及资源协同，其中应用协同是指应用由云端服务器管理，边端节点运行，通过开放的接口标准和平台，建立起应用的开发生态，汇集了丰富的应用。其中服务协同是指建立边缘设备数据采集与上报的标准，使得应用能用以统一的标准从云端或边缘端订阅所需的各类业务
数据，实现应用与数据服务协同。其中资源协同是指通过将管理服务，如监控、编排等，统一放置到云端服务器，极大的减少边缘卫星节点的资源开销，满足卫星场景下，边缘节点轻资源少、低功耗的特点。
44.除此之外。对于语义建模而言，考虑到在物联网领域，传感器设备采集数据，通常各厂商都在做自己的定制方案，无法形成一个统一标准。做数据应用的厂商需要适配各类做设备数据采集的厂商；做传感器数据采集的厂商又需要设配各类平台厂商，造成重复研发，效率低下。为了能够提高效率，必须使用一套既灵活又通用的天基物联网数据采集与应用架构，来尽可能的满足各种类型的传感器数据的采集与各类应用的开发，必须具备以下特点：
45.(1)统一性：支持通过云端统一管理；
46.(2)兼容性：支持适配各类物联网协议，管理各类终端设备、软件；
47.(3)通用性：符合当前主流的容器应用管理、编排规范；
48.(4)标准化：云侧、边缘侧提供标准的接口；
49.(5)大规模：支持百万级设备的接入与管理；
50.(6)低功耗：占用资源低、功耗低。
51.由于本技术中的语义模型构建方法是基于云边协同系统实施，故首先对该系统进行阐述。实际上该云边协同系统为天基物联网，整个系统平台框架如图1所示，包括处于地面的云端服务器(图中为地面云端)，作为边缘节点的卫星，也就是边缘卫星节点，以及多个设备端三个部分组成。在云端服务器中集成了cloudcore用来管理边缘节点，并将边缘卫星节点收集到的数据存储到etcd数据库，在云端统一计算分析。
52.框架采取基于kubeedge和docker的整体设计，结合了轻量化、易管理、开放性等多个特点。docker叠加kubeedge构建了一个可移植的、可扩展的云边协同计算平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
53.该平台与基础设施分离，支持可在ubuntu、rhel、centos等主流的操作系统运行，可以支持zynq-7000、tx2等多样化的硬件部署。因而，平台可以用来实现对于异构边缘硬件的发现、监控和调度。
54.通过插件框架的形式，对边缘硬件的计算、存储、网络等资源进行模型抽象，使得不同的硬件厂家可以为自己的产品提供插件化的定义和描述，提供一个统一资源能力描述、部署、运维管理方式。
55.在本实施例中，对云端服务器和边缘节点之间的硬件环境不做过多要求，能够运行最基本的linux系统即可。云端服务器可以采用包括华为或者dell等厂商的服务器，而边缘节点也支持多种异构设备，例如tx2,zynq-7000系列或者其他硬件厂商的设备。
56.平台在边缘卫星节点通过提供一个设备插件框架edgecore，建立了地面云端和卫星边缘的桥梁。它一方面负责将卫星边缘的信息上报到地面云端，另一方面负责边缘卫星的调度选择。edgecore可通过手动部署或自动部署。
57.同时考虑到天基物联网具有广覆盖的特性，一颗卫星会连接众多感知设备，各种设备的数据形式存在差异，不同的数据拥有不同的语义，在未对数据进行相应的建模之前无法直接进行操作。需要一个统一的信息模型架构来兼容各种模式的数据信息，因此，本方法针对设备端采用语义建模的方式对设备的信息进行抽象化，以完成从云端对设备端的语
义互操作。
58.而语义互操作性影响整个信息生命周期，无论是水平地影响单个设备和系统，还是垂直地影响不同系统。
59.语义模型是一种链接结构，可以将原始数据映射到这些结构上，然后在这些结构之间传播数据以产生新数据。将处理后的数据映射到语义结构之后，这些结构所代表的数据就有了具体的含义。
60.例如，如果将一个浮点数映射到一个表示摄氏温度单位的结构上，那么这个浮点数就表示摄氏温度值，而之前它只是一个浮点值，并不包含任何语义。图2展示了原始数据到语义数据的映射步骤。
61.对数据进行语义建模其本质就是对原始数据添加元数据或者说上下文信息，使得原始数据具有更加清晰和丰富的含义，方便人类或者机器使用。以温度传感器为例，不同厂家生产的温度传感器其数据可能单位不同，可以是摄氏度，也可以是华氏度，而且即使事先知道了单位，想要使用其数据也远远不够，还需要知道整个温度传感器测量的时间、地点以及其他上下文信息，而这就需要对设备进行语义建模。
62.语义建模的挑战是确保交换的信息不仅为信通技术通信渠道两端的人所理解，而且为计算机系统及其相关软件所理解。因此，需要一个统一的标准来规范建模过程，确保不同行业之间的数据能够被彼此理解，互相操作。目前已经构成标准的且确保机器可理解的有iec 61804第3至5部分和iec 62541，并分别衍生出了电子设备描述(edd)和开放平台通信统一架构(opc ua)协议，其中edd包含机器可解释格式的元数据、业务逻辑和用户界面描述；而opc ua包括信息模型，信息模型除了元模型，还提供了标准化的序列化，使得类型和实例描述(节点集)是机器可读的，而信息模型是由个人为连接到opc ua服务器的设备设计的。
63.opc ua作为osi模型里应用层协议，具有跨平台、访问统一性、安全可靠、信息模型统一以及扩展性好等优势。而且使用opc ua协议能够方便的接入本实施例中设计的天基物联网云边协同框架，实现天基开放平台通信统一架构(spc ua)。
64.故在本实施例中，采用opc ua协议对各设备端进行语义建模，其中语义建模包括对设备端根据其属性以及相关的数据进行定义，在对定义后的设备端根据opc ua协议进行实例化，也就是构建对应的语义模型。
65.具体的，spc ua基本建模概念是节点和节点之间的引用。节点可以根据节点类别不同分为类型和实例等，节点之间可以使用引用来连接，每个节点都可能拥有不同属性。nodeid用来唯一标识一个服务器节点，客户端进行地址空间的查询、定位和浏览操作时，服务器会返回nodeid。节点之间的引用可以认为是一个指向其他节点的指针，引用可以是单向，也可以是双向；指针可以引用不存在于服务器上的节点，也可以引用其他服务器上的节点。引用不是节点，没有和节点一样的属性或特性，spc ua使用引用类型来描述引用的语义，在地址空间中，引用类型也被当作节点来使用。
66.进一步的，在对设备端进行语义建模时，数据大致分为两类：一类是感知数据，比如接收数据，一般只需要读取现场数据，而不用上层用户给它们发送控制数据；有的是控制数据，比如功率、模式等，不仅需要读取现场数据，同时上层用户还可以给它们发送控制数据。现场这些数据都可以通过spc ua规范进行描述并信息建模。
67.在定义完设备类型之后，需要对设备类型进行实例化，实例化的设备模型如图3所示。图3中以设备端为sx1302网关为例，标识了设备端各个节点之间的关系，deviceobjecttype继承基础类型(baseojecttype)，同时在deviceobjecttype下面构建了多个基本类型的节点和方法。
68.spc ua支持通过多种结构化文件构建模型，例如rdf,xml,owl，构建完成的结构化文件通过映射到地址空间的方式供用户访问。
69.在根据opc ua协议对各设备端进行语义建模之后，还在各设备端根据opc ua协议构建相应的spc ua服务器，依次包括：服务器初始化、创建服务器、服务器对结构化文件的解析，运行服务器以及删除服务器，并在创建服务器后，将构建好的语义模型映射到spc ua服务器的地址空间中。spc ua服务器的主要功能是实现对设备模型的解析以及与边缘端建立连接。设计开发spc ua服务器，就是使用spc基金会提供的ua栈作为spc ua架构的基础，在此基础上利用opc ua开源项目open62541提供的api接口，按照需求设计开发相对应功能的opc ua服务器。包括例如实现sx1302网关模型以节点的方式在服务器的地址空间映射、实现对节点的读写等功能。下面对spc ua服务器的主要功能实现进行详细叙述。
70.开发spu ua服务器的第一步需要对服务器进行初始化，根据需求设置进行相应的配置，open62541分别提供了registerserver()方法和ua_serverconfig()结构体方法用于服务器的创建以及服务器的具体配置信息，该配置信息包括服务器ip地址，网络端口号，访问控制，证书验证，mdns发现，节点生命周期回调、安全通道的限制、会话限制、操作限制、请求限制、订阅限制、监控项的限制、发布请求的限制以及最后的发现服务等。详细说明如图4所示，将配置完成的结构体传递给ua_serverconfig()函数，实现服务器的初始化，一旦初始化完成将不能在运行期间修改。
71.完成服务器的初始化之后，open62541提供了ua_server_new()用于创建服务器。如图5所示，该函数在创建服务器时会首先检查服务器是否初始化完成，并根据初始化时的配置信息创建新的服务器。根据初始化时的配置信息，该函数会判断所需的资源大小，并为服务器申请相应的内存。完成内存的申请工作后，该函数会返回一个server对象用于后续的使用。
72.在完成spc ua服务器的初始化和创建之后，接下来需要将之前编写的该设备端对应的语义模型映射到spc ua服务器地址空间，也就是服务器对结构化文件的解析，在这里同样以设备端为sx1302网关为例，具体步骤如下：
73.1)配置open62541。
74.2)生成自定义信息模型代码。使用之前生成的结构化文件拷贝到相关目录下，执行生成相关依赖文件。
75.3)把相关依赖文件拷贝到根目录。
76.完成sx1302网关模型的映射之后，即可添加ua_server_run(server,&running)。
77.ua_server_run(server,&running)函数作用为运行spc ua服务器，如图6所示，该函数首先会判断之前创建的服务器状态标志位是否为1，在完成判断之后，该函数会首先启动网络层，并处理网络层所发送过来的各种事件，通过采样服务器的启动时间判断事件的先后顺序。
78.在完成所有的服务器工作之后，最后还需要对创建的服务器进行删除操作，在
open62541中，删除服务器时通过ua_server_delete(server)函数实现的。spc ua服务器的删除会首先删除内部的数据，包括服务器的配置信息以及之前映射到服务器地址空间内部的设备模型，以及释放内存。但删除服务器并不会导致客户端连接的丢失，只有在客户端主动取消对服务器的连接之后服务器才会主动删除。
79.在各个设备端中搭建完spc ua服务器以及将对应的语义模型映射至该服务器后对各设备端在语义互操作的搭建就完成了，而最终需要实现云端服务器对各设备端的语义互操作，也就是在云端对各设备端发送指令以及接受各设备端上传的数据时，还需要边缘节点在其中进行协议转换，在上文中，有提到在云端服务器通过边缘节点向各设备端发送指令时，将指令下发给边缘节点，在边缘节点中将指令发布至mqtt服务器中，再由mapper将来自mqtt协议的指令转换成opc ua协议，并将opc ua协议发送至对应的设备端。在各设备端中通过spc ua服务器中的语义模型对接收到的opc ua协议获取对应的指令，并根据指令进行相应操作。
80.同时，还包括在各设备端向云端上传数据时，通过各自构建的语义模型将接收的数据转换成相应的opc ua协议，再将opc ua协议发送至所述边缘节点；边缘节点将接收到的opc ua协议发布至mqtt服务器中，再由mapper将来自mqtt协议的opc ua协议转换成所述云端服务器可识别格式的上传数据，并将该格式的上传数据发送至所述云端服务器，以供云端服务器使用。
81.在本实施例中，云端服务器根据各设备端的语义模型编写对应的yaml文件，再通过各yaml文件构建对应的模型元数据，并将各模型元数据发送给边缘节点，
82.边缘节点根据云端服务器下发的各模型元数据构建相应的设备孪生，并将各设备孪生存储在边缘节点中。
83.具体的，云边协同系统借助自定义资源描述符(crd)和该设备连接的mapper共同管理设备。通过crd来描述设备元数据/状态，并使用控制器在边缘节点和云端服务器之间同步这些设备更新。因此，想要通过云端管理设备端就需要先定义该设备的crd，crd具有以下功能。
84.1)描述设备端属性：用户可以描述设备属性和访问机制与设备端交互或者控制设备端。
85.2)从云端服务器对设备端执行crud操作：用户可以通过服务器公开的crd api从云端创建、更新和删除设备元数据。可以通过crd api控制设备的所需状态。
86.3)报告设备属性值：在边缘运行的mapper应用程序可以报告设备属性的当前值。
87.而在本实施例中，支持的crd有两种类型，一种是device model crd，另一种是device instance crd。
88.控制设备首先要配置device model crd和device instance crd，框架会根据配置文件生成configmap文件。第一次运行时，mapper会解析configmap文件，并根据解析完成的命令执行相应的操作。在运行时，配置一旦改变，configmap文件会跟着改变，设备孪生会发送改变的消息到mqtt代理，mapper通过订阅主题获取消息。
89.device model描述了设备和访问这些属性的访问者公开的设备属性。设备模型就像一个可重复使用的模板，使用它可以创建和管理许多设备。device model crd里面包含了每一个属性的名字，该属性的描述以及该属性的读写权限节点，还有节点namespace以及
标识符。
90.根据device model创建设备的实例(device instance crd)，device instance crd表示了该device instance crd引用的device model crd，定义了设备具体协议，还定义了opc ua协议地址以及下发的具体边缘节点名字。
91.在实现云端和各设备端进行语义互操作时，还需要对边缘节点也就是卫星构建mapper以实现云端和设备端之间的协议转换。
92.完成设备模型与实例的创建之后，接下来需要构建mapper镜像，并将mapper镜像下发到对应的边缘节点，确保边缘节点能够连接到设备并能够解析opc ua协议，构建mapper镜像流程如图7所示。
93.当mapper镜像上传到中央仓库之后，需要配置deployment文件将mapper以及device model crd和device instance crd生成的configmap文件绑定到对应的边缘节点。
94.而在云边协同系统中，实现各设备端与云端服务器之间的互操作性的工作流程也可如图8所示。
95.上述用于云边协同系统的语义模型构建方法，是实施于由云边协同系统构建的天基物联网中，在该云边协同系统中包括云端服务器、作为边缘节点的卫星以及多个设备端，本方法通过在各个设备端根据opc ua协议构建相应的语义模型以及opc ua服务器，并将构建好的语义模型映射到opc ua服务器中，以实现设备端的信息进行抽象表示，从而完成云端服务器对各设备端的语义互操作。
96.本技术还提供了一种用于云边协同系统，其系统结构可参考图1，云边协同系统用于构建天基物联网，云边协同系统包括云端服务器、作为边缘节点的卫星以及多个设备端，云端服务器通过边缘节点接收来自各设备端的上传数据以及向各设备端发送指令；
97.在每个设备端中，均根据opc ua协议构建与各设备端对应的语义模型，还根据opc ua协议搭建相应的spc ua服务器，并将该语义模型映射到对应设备端中的spc ua服务器地址空间中；
98.在所述云端服务器通过边缘节点向各设备端发送指令时，将所述指令下发给所述边缘节点，在所述边缘节点中将所述指令发布至mqtt服务器中，再由mapper将来自mqtt协议的指令转换成opc ua协议，并将opc ua协议发送至对应的设备端；
99.在各设备端中通过spc ua服务器中的语义模型对接收到的opc ua协议获取对应的指令，并根据指令进行相应操作。
100.在其中一实施例中，所述方法还包括：
101.各所述设备端向所述云端系统上传数据时，通过各自构建的语义模型将接收的数据转换成相应的opc ua协议，再将opc ua协议发送至所述边缘节点；
102.所述边缘节点将接收到的opc ua协议发布至mqtt服务器中，再由mapper将来自mqtt协议的opc ua协议转换成所述云端服务器可识别格式的上传数据，并将该格式的上传数据发送至所述云端服务器，以供所述云端服务器使用。
103.在其中一实施例中，所述方法还包括：
104.所述云端服务器根据各设备端的语义模型编写对应的yaml文件，再通过各所述yaml文件构建对应的模型元数据，并将各所述模型元数据发送给所述边缘节点；
105.所述边缘节点根据云端服务器下发的各所述模型元数据构建相应的设备孪生，并
将各设备孪生存储在边缘节点中。
106.在其中一实施例中，在根据opc ua协议构建与各设备端对应的语义模型时包括：
107.对所述设备端根据其属性以及相关的数据进行定义；
108.在对定义后的设备端根据opc ua协议进行实例化，也就是构建对应的语义模型。
109.在其中一实施例中，根据opc ua协议搭建相应的spc ua服务器时依次包括：服务器初始化、创建服务器、服务器对结构化文件的解析，运行服务器以及删除服务器；
110.并在创建服务器后，将构建好的语义模型映射到spc ua服务器的地址空间中。
111.在其中一实施例中，所述云边协同系统采取基于kubeedge和docker的整体设计。
112.在其中一实施例中，在所述云端服务器和边缘节点之间通过设备插件框架edgecore，以实现将所述边缘节点接收的数据上报至所述云端服务器以及负责所述边缘节点的调度选择。
113.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
114.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
115.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。