XOS-EdgeX(XOS)

作者:mnq10_0@126.com
发布时间: 2019-12-28 08:39:06 (4年前)
关键词: XOS EdgeX
摘要:

                              
                                     EdgeX Foundry 的原始代码主要来自 Dell 的 Fuse 项目，以 Apache 2.0 许可证发布。主要编程语言是Java，整体框架采用 Spring Boot、Spring Framework、Docker、Consul 等微服务注册和配置中心等技术构成。

EdgeX Foundry 的原始代码主要来自 Dell 的 Fuse 项目，以 Apache 2.0 许可证发布。主要编程语言是Java，整体框架采用 Spring Boot、Spring Framework、Docker、Consul 等微服务注册和配置中心等技术构成。 其中核心微服务有 8 个： 分别是 core-data、 command、 metadata、 consul、mongodb、 edgex-files、log、 notification 服务， 这是启动 EdgeX Foundry 工程的最小依赖。 下图是 EdgeX Foundry 的整体架构，可大略分为东、南、西、北、中几个部分： [图片]![](/user/files/msH1uYMHT7H8yJC9QQ30LBW59gHX0IRY-e6jvqPHFv4.png) ● 南侧为设备微服务 (device service) ，用于连接物理设备，如传感器、摄像头等，每个设备微服务都有自己与特定设备连接的驱动代码，需要用户针对自己的设备数据传输协议编写数据驱动代码，EdgeX Foundry 提供 SDK-tool 工具用于快速生成设备微服务整体结构中的通用代码部分，开发者只需根据 EdgeX Foundry 指定的task标志完成指定位置的代码编写即可。具体参见 <a href="https://wiki.edgexfoundry.org/">https://wiki.edgexfoundry.org/</a>　 ● 北侧为导出微服务 (export service)，用于企业用户远程读取设备数据，开发者需要针对自己的业务需求，可以调用 Export 微服务的相关 API，读取针对某个特定设备的数据。 ● 中心为核心微服务，主要用于存储设备元数据，解析传递命令，存储设备数据等。 整体框架的大致流程如下： ● 设备微服务读取 device.profile 文件存储到 metadata 微服务，profile 文件中存储了特定设备的元数据信息，包括该设备的数据 key，能够执行的命令等。 ● 向设备发送命令，必须经过comand微服务，调用 comand 微服务的 API，可以得到设备的所有命令信息，该服务经过调用 metadata 微服务存储的设备元数据信息后，发送到设备微服务，设备微服务在通过特定的协议（通常需要针对您的设备开发）发送到真实物理设备。 ● 北侧端的导出服务，有特定的 API，开发人员开发的微服务需要注册到北侧导出微服务后才能得到设备数据，注册的微服务可以是本地和远程，本地可用于边缘计算后上传到企业中心，远程是企业用户中心直接读取走设备数据。 EdgeX Foundry 已经开发的规则引擎微服务就是一种注册到北侧端的本地服务，用于实时分析设备数据后执行特定的规则，触发相应的命令发送给设备。目前北侧端的导出微服务，支持 Http 和 zeromq 协议注册。 在我们前一阶段针对 Edgex Foundry 项目的探索工作中，已经完成了如下目标： ● 基于Docker Swarm的跨主机网络实现全域名访问，并基于此扩展了EdgeX Foundry 的混合开发环境； ● 移植 EdgeX Foundry 到虚拟化网关中，并连接真实物理设备、读取传感器数据； ● 针对EdgeX Foundry在单物理机（网关）上运行的宕机风险，提出了部署集群化网关的方案。 ,
EdgeX Foundry 的原始代码主要来自 Dell 的 Fuse 项目，以 Apache 2.0 许可证发布。主要编程语言是Java，整体框架采用 Spring Boot、Spring Framework、Docker、Consul 等微服务注册和配置中心等技术构成。 其中核心微服务有 8 个： 分别是 core-data、 command、 metadata、 consul、mongodb、 edgex-files、log、 notification 服务， 这是启动 EdgeX Foundry 工程的最小依赖。 下图是 EdgeX Foundry 的整体架构，可大略分为东、南、西、北、中几个部分： <img src="/user/files/siUtaPsFi5t9_y2M88G1t2cF3OfDH0vUxkGmnVoipmM.jpeg" alt=""> ● 南侧为设备微服务 (device service) ，用于连接物理设备，如传感器、摄像头等，每个设备微服务都有自己与特定设备连接的驱动代码，需要用户针对自己的设备数据传输协议编写数据驱动代码，EdgeX Foundry 提供 SDK-tool 工具用于快速生成设备微服务整体结构中的通用代码部分，开发者只需根据 EdgeX Foundry 指定的task标志完成指定位置的代码编写即可。具体参见 <a href="https://wiki.edgexfoundry.org/">https://wiki.edgexfoundry.org/</a>　 ● 北侧为导出微服务 (export service)，用于企业用户远程读取设备数据，开发者需要针对自己的业务需求，可以调用 Export 微服务的相关 API，读取针对某个特定设备的数据。 ● 中心为核心微服务，主要用于存储设备元数据，解析传递命令，存储设备数据等。 整体框架的大致流程如下： ● 设备微服务读取 device.profile 文件存储到 metadata 微服务，profile 文件中存储了特定设备的元数据信息，包括该设备的数据 key，能够执行的命令等。 ● 向设备发送命令，必须经过comand微服务，调用 comand 微服务的 API，可以得到设备的所有命令信息，该服务经过调用 metadata 微服务存储的设备元数据信息后，发送到设备微服务，设备微服务在通过特定的协议（通常需要针对您的设备开发）发送到真实物理设备。 ● 北侧端的导出服务，有特定的 API，开发人员开发的微服务需要注册到北侧导出微服务后才能得到设备数据，注册的微服务可以是本地和远程，本地可用于边缘计算后上传到企业中心，远程是企业用户中心直接读取走设备数据。 EdgeX Foundry 已经开发的规则引擎微服务就是一种注册到北侧端的本地服务，用于实时分析设备数据后执行特定的规则，触发相应的命令发送给设备。目前北侧端的导出微服务，支持 Http 和 zeromq 协议注册。 在我们前一阶段针对 Edgex Foundry 项目的探索工作中，已经完成了如下目标： ● 基于Docker Swarm的跨主机网络实现全域名访问，并基于此扩展了EdgeX Foundry 的混合开发环境； ● 移植 EdgeX Foundry 到虚拟化网关中，并连接真实物理设备、读取传感器数据； ● 针对EdgeX Foundry在单物理机（网关）上运行的宕机风险，提出了部署集群化网关的方案。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论