工业边缘计算机的体系结构
概述
modular-2 Edge 是一台模块化工业边缘计算机，采用的64 位ARM主处理器为核心的主处理器模块，cortex-M 单片机为核心的IO 模块构成多处理器，多模块系统。采用以太网作为背板总线。
主处理器模块采用linux OS 操作系统。使用docker 容器管理应用软件。为了高效率实现IO模块的访问和App 之间的相互通信与协同。modular-2 Edge 设计了一个创新的基础服务层（baseService）。实现基于web socket的远程过程调用（RPC）消息交换。应用App 通过RPC 访问硬件，以及其它App 提供的服务。系统所有的服务通过基础服务层实现。
为App提供了统一的消息平台
工业边缘设备的功能是多样化的，例如要对现场采集的数据进行存储，数据分析，并且连接各种云端平台。这些功能可以通过不同的App提供微服务实现。根据实现功能的不同，App 采用的平台和程序设计语言各有不同。例如web 服务使用Nodejs的javascript，而python更适合数据分析和AI，而C++ 适合实时控制和时间敏感的计算。
最大程度地摆脱对硬件的依赖
不同厂商的Arm 处理器板提供的IO接口是不尽相同的。而且linux 下的驱动也各不相同。另一方面，工业边缘设备对IO接口的需求又是多样化的。如果使用主处理器的外围电路来实现IO接口，一是不够丰富，二是会带来软件兼容性的问题。modular-2 Edge 尽可能减少对主处理器外围电路的依赖，使用廉价的单片机实现丰富多样的IO接口，而且使用以太网作为主处理器和IO模块之间的互联总线。使用Ethernet 作为背板信号。使软件对硬件的依赖减少到了最少。
IO模块开发效率更高
modular-2 Edge IO模块采用cortex-M4/M7 处理器实现，软件采用Arm Mbed OS，使硬件外围电路的控制更加智能，灵活和高效率研发。
硬件结构
modular-2 Edge 是一台多处理器设备，由主处理器模块和多个IO模块构成。主处理器模块采用Arm公司cortex-A 处理器，运行linux 操作系统，IO 模块使用cortex-M 系列单片机实现。软件采用Arm Mbed OS。modular-2 Edge的主处理器和IO 模块之间采用 100 base T 以太网实现数据交换。并且采用独特的以太网交换背板。在modular-2 Edge 的背板上集成了一个8端口 以太网交换机。
产品的结构设计
该产品由一个基座和IO模块组成
软件结构
基于Arm cortex-A 技术的高端处理器层出不穷，但是如何在这样的处理器平台上高效率地开发工业应用软件，是一个富有挑战性的课题。人们习惯于windows时代的软件开发方式-开发一个功能包罗万象的单一应用软件。但是在一个嵌入式linux平台上开发这样的应用软件，对程序员的要求越来越高。目前的发展趋势越来越倾向于微服务，松耦合的App 方式。modular-2 Edge 软件系统在这方面做了探索。
modular-2 Edge 软件系统的特点
- 主处理器使用linux 操作系统，IO模块使用Arm Mbed OS
- docker 容器技术管理App
- websocket RPC实现App之间的消息传输，以及IO模块的访问
- 使用jsonrpc 协议帧格式
- 内置MQTT
- 内置数据库 （influxDB，mySQL，mongoDB ）
- HTML5 的App用户界面
- IO 模块实现大多数 Mbed 驱动
- IO 模块实现modbus等多种工业协议。
modular-2 Edge 在软件方面的最大创新点，是开发了一个小型的消息交换层，它称为基础服务（base Service）。
无论是云端服务，还是边缘计算设备中的服务，都需要有一种或者多种消息交换机制，它们大多是基于消息队列，或远程过程调用RPC 多种方式。
我们可以采纳许多开源的消息交换软件，比如最简单和直接的消息交换方式是MQTT 方式。
但是这些开源消息系统大都是为云端应用而开发，将他们应用到面向工业现场数据采集，控制的边缘设备中，显得过于庞大，和繁复。影响了程序的实时性。而且MQTT的topic 命名空间也十分复杂。base service 是一致面向实时应用的，更高效的消息交换服务。它创造性地开发了数据流远程调用机制。这种方式结合了RPC和MQTT 两种交换方式的优点。
base Service 基于websocket RPC 实现，为了面向多语言App 的应用，RPC格式采纳了rpcjson 格式。 baseService 中实现了数据流远程调用（Streaming RPC），从而更进一步地提高了App 消息传递的效率，。数据流远程调用允许一个PRC 调用的结果是一个数据流（stream），调用方发送启动后，被调用方连续地发送数据给调用方，直到发送停止stop。这种方式在工业App 中比较常见，例如：
- 启动IO外围设备采集数据，IO外围设备按一定周期，源源不断地向应用程序发送原始数据。
- 允许一个事件通知，当事件发生时，产生一个事件结果（event result）。例如，允许按键中断，当按键中断发生时，产生一个事件结果该应用程序。
更进一步地，针对数据流RPC方式，device service 还提供了点对多点数据流传递方式。当一个应用程序调用一个数据流RPC 之后，其它App可以同时读取该数据流。这种方式更进一步提高了工业应用中消息交换的效率。
基础服务层
基础服务层以websocket 服务器的方式运行，每个App开始运行时，将与base service 建立web socket 连接。rpc 是通过websocket 传输jsonrpc 格式帧实现。
每个App 都可以调用基础服务层的方法，或者其它App 提供的rpc 方法（服务），每个App也可以向其它App 提供服务。
从上图可见，baseservice 将App 之间无序的相互调用和消息交换转换称为统一地访问base service，由baseservice 实现各种消息的交换。
jsonrpc 协议
jsonrpc 是一种轻量级远程过程调用协议。讲起来它非常简单，就是使用json 描述RPC 过程的数据格式。它并没有规定传输方式，所以可以在TCP，HTTP，Websocket MQTT 各种传输层实现。
例如：
-> {"jsonrpc":"2.0","id":1,"method":"SUM"，“params”：{“value”:[600,1]}}
<- {"jsonrpc": "2.0", "id": 1, "result":{“value”:601}
base service 对params和result 作了更进一步的规定。
一元模式（Unary RPC）
常规的RPC 是RPC-RESULT 方式，一个RPC 调用对应一个结果。
流模式（streaming RPC）
流式RPC是RPC 的一种扩展，指RPC 调用的结果是一个数据流，直到发出Stop。这种方式在工业控制，数据采集中非常有用。例如启动模数转换（ADC） IO 外设不断地发送采集数据。直到停止（Stop）。
读数据流（readstream）
一旦一个App 启动了一个数据流RPC，会有一个数据流名称，其它App 可以读取这个数据流。这样的机制实现点对多点数据通信机制。点对多点数据通信机制的应用：
假设一个工业设备健康检测程序由三个App 组成。
- 数据分析App 连接上base service 之后，发送register 向baseservice 注册 fftrpc
- 数据分析App 向base service 发送 analogread rpc。
- baseservice 将analog.read 转发给IO 模块，启动ADC 转换。IO模块发送采集数据给baseservice，baseservice将模拟数据转发给数据分析App
- 可视化App 向baseservice 发送 fftprc。baseservice 将fftprc 转发给数据分析App。数据分析App开始发送 fft 数据流。
- 数据存储App 向baseservice 发送read stream rpc。baseservice 开始转发数据流 fft stream 给 数据存储App。
MQTT数据流（MQTTStream）
App 启动一个数据流RPC，并且定义了一个数据流名称。MQTT数据流将该数据流的每个结果通过MQTT 发布出去，发布的主题是该数据流的名称。
启动点对点流模式
rpcjson=
{
"jsonrpc":"2.0",
"method":"analog.start",
"params":{"mode":startStream, "endpoint":“000/001/000”,"value":[val] },
"id": id
}
流式RPC的点对多点方式
流式RPC的点对多点方式同样非常有用，也就是一个数据流发送给多个接收者。例如现场采集的数据既要发送给数据分析的App，又要发送给数据存储App 。
流模式的多点读取
当一个App 调用一个流式RPC时，将会指定流的名称（stream name）。其它App可以同步读取该名称的数据流。
启动点对多点数据流
rpcjson=
{
"jsonrpc":"2.0",
"method":"analog.start",
"params":{"mode":startStream,"streamname":streamName, "endpoint":“000/001/001”,"value":[val] },
"id": id
}
读取数据流
rpcjson=
{
"jsonrpc":"2.0",
"method":"readstream",
"params":{"mode":readStream, "streamname": streamName，“endpoint”：“000/001/010”},
"id": id
}
stopreadStream（stream name）
rpcjson=
{
"jsonrpc":"2.0",
"method":"readstream",
"params":{"mode":1；StopreadStream, "streamname": streamName，“endpoint”：“000/001/002”},
"id": id
}
rpc 调用的流程
App 调用IO 模块的流程
baseservice RPC
register
注册一个RPC 方法
readstream
读取一个数据流
出错代码：
// error_code
#define OK 0
#define ERR_REQ_SYNTAX 1
#define ERR_REQ_SYNTAX1 11
#define ERR_REQ_ID 2
#define ERR_REQ_NO_SUCH_METHODE 3
#define ERR_REQ_NO_METHOD_RESULT 4
#define ERR_REQ_START_NOT_INT 5
#define ERR_REQ_NO_NAME 6
#define ERR_REQ_NO_TYPE 7
#define ERR_REQ_NO_VALUE 8
#define ERR_REQ_NO_PARAMS 9
#define ERR_REQ_NO_PIN 10
#define ERR_REQ_NO_MODE 12
#define ERR_REQ_IL_MODE 13
#define ERR_REQ_NO_STREAM_NAME 14
#define ERR_REQ_STREAM_EXIST 15
#define ERR_REQ_STREAM_NAME_NOT_EXIST 16 末端uri（endpoint uri）
jsonrpc 的参数中，带有一个末端uri（endpoint uri）这个uri 是系统中资源的统一标识符。
endpoint uri=/device/service/resource
其中：
device 为设备标识
service 为服务标识，每一块io 模块，也代表了一种服务
resource 资源标识
每一个App都有一个service 名称，可以为一个数值。
每一个设备都有一个device 名称 可以为一个数值。
如果是本机的RPC 设备名称为local或者000
例如
jsonrpc={
"jsonrpc":"2.0",
method:”analogin.read”
params:{
mode:1
endpoint:”000/03/01”
data:[0]
}
id:1
}
表示读取本机3 号io板的01 个模拟量。
连接云端
大多数边缘计算设备要与云端相连接，所以云端接口是边缘设备软件系统不可或缺的重要部分。
modular-2 Edge 的基础服务（base service） 提供了边缘设备中App和IO 模块，App和App 之间的消息传输和协同操作。
由于云端的架构和服务各有不同，云端接入模块会因不同应用而变。在modular-2 edge 中，云端接入模块采用App 的形式出现。该App 称为“Cloud Agent”
在modular-2 Edge 内部看来，它只是一个普通的App，可以调用IO模块和其它App提供的RPC 过程。同时，它也提供了一些访问云端所需要的RPC 过程。
云端接入的方式有许多种，例如HTTP RestFull API，websocket API，NB-Iot CoAP 协议等等。
显然，根据不同的云端应用，需要有不同的Cloud Agent 与之对应。
base service 应用于云端
如果详细地了解了modular-2 Edge 的基础服务机制，你就不难看出，base service 的机制同样适合于云端部署。如此一来，云端和边缘设备端采纳了相同的软件架构。
这样做看起来越来越好玩了。系统架构变成了下面的方式。
Cloud Agent 可以将边缘设备的部分或者所有的RPC 注册到云端 base Service 上。为了实现边缘和云端RPC 融合，需要扩展一个base service
get_public_rpc:获取所有注册的公开RPC ,这是一个stream RPC ，当有新的RPC 注册的时候，将会通知其它边缘设备。
当然也可以使用MQTT 来通知 RPC 的添加和去除。
显然，当base service 扩展到云端，那么 endpoint uri 就显得非常有用了。
例如：
从云端或者其它边缘设备读取001号边缘设备的第3 号板的01地址的模拟量。
末端uri 为：endpoint:”/001/03/01”
用户界面
大多数App 需要一个用户界面（HMI）, 用于参数设置，人机交互和结果数据的可视化显示。modular-2 Edge 采用HTML5 网页作为App的HMI 界面。
在App 中实现一个内置的web 服务器。在C++ 实现的App 中，web server 由开源的C++ restbed 库实现。
基础服务层同样提供了基于Web的HTML5界面。用于系统参数设置，运行监控和App 的管理。
App 管理
1 .每个App 安装时需要在base service 上注册。App 向base service 提供的信息包括
- App 的名称
- service id
- App 的logo 图标
- 访问端口
2 baseservice 的主页可以跳转到某一个App 的主页。
IO 模块
modular-2 Edge 的IO模块是基于低成本cortex-M 单片机实现的。目前它采用STM32F系列单片机实现。采用IO模块的优点是cortex-M 单片机支持丰富的外围电路接口。可以方便地连接各种工业控制，数据采集设备。
cortex-M处理器除了实现底层接口驱动以外，还可以实现实时性要求高得数据预处理和判别。
为了缩短IO模块软件开发的时间，IO 模块用Arm Mbed OS，该操作系统的应用程序由C/C++ 语言开发。Mbed OS 提供了底层程序库。
bsaeservice 的RPC 名称，参数格式尽量与Mbed 保持一致。实验系统实现了如下命令。
-
DigitalOut
-
PWMOut
-
DigitalIn
-
InterruptIn
-
AnalogIn
-
AnalogOut
-
Serial
-
SPI
-
I2C
-
canbus
- reset
IO 模块复位，数据复位，停止所有的数据流
软件实现的IO模块的功能
- modbus
- NB-iot
- LoRa
baseService 与IO模块的通信协议
IO 模块与主处理器之间的通信协议采用了简单的UDP 协议来实现。避免了cortex-M 处理器分析和产生json 数据格式的复杂费时的处理程序，也能提高系统的实时性能。
结束语
在modular-2 Edge 中引入了 jsonrpc 的消息交换机制。并且扩充了流式RPC和 点对多点流式RPC 的机制。这样一个轻量级的消息系统，简化的工业App的消息交换和协同操作。这是一个有意义的尝试。
工业边缘设备是一个比较新的概念，没有一个固定的模式可以遵循，base service 也是本人脑子一闪念的东西比较。有时候觉得很酷，有时候又觉得没那么酷。需要不断地测试，并且需要大家的评估和意见。