我的系统居然和鸿蒙有点像
我的一个业余项目（我称为自己的宠物项目（pet projects) 是开发一个物联网边缘设备的App 软件环境。跟着感觉走，做出了一个最小可运行系统，目前在测试中。
最近，华为公司发布了一些关于鸿蒙操作系统的消息。成为了网红OS。我惊人地发现，我的项目和鸿蒙有点像。微内核，高效率prc（华为称为IPC）的消息总线，分布式，跨平台。基本元素都类似，同样面向物联网（我不面向手机）
我的项目完全是个人爱好，没有商业目的。完全不是蹭热度，也不是标题党。只是感觉自己的某些思路是正确的。当然也担心鸿蒙的出现，是否会使自己的项目变得毫无意义？毕竟我只是一个人在战斗，不像华为那样财大气粗。
急急忙忙将不成熟的文字铺出来，希望别人给点建议，或者抛砖。
modular-2Edge
-模块化，容器化，微内核架构的工业边缘设备
modular-2 Edge 是一台面向工业物联网应用的边缘计算设备。它采用多处理器的模块化设计。主处理器模块采用Arm公司cortex-A 处理器，IO 模块使用cortex-M 系列单片机实现。
相比于模块化硬件结构之外，软件更加重要。modular-2 Edge 为工业边缘设备构建了一个轻量级的工业App 生态环境。在这一创新的生态环境下。工业应用软件可以更加高效率地研发，部署和运行。
工业App 软件环境
- 容器化管理
- 基于RPC 的软件数据总线
- 微内核理念的基础服务
- 提供面向工业控制，物联网，大数据，人工智能应用的应用服务。例如时间序列数据库（influxDB）。
- C++，python，nodeJS ，nodeRED 等多种程序设计语言的App 框架。
硬件架构
modular-2 Edge的主处理器和IO 模块之间采用 100 base T 以太网实现数据交换，并且采用独特的以太网交换背板。
传统的嵌入式设备的采用并行的数据总线。比如以前的高性能嵌入式计算机大都以Motorola 的68000和powerPC处理器为主，采用是VME并行总线标准，该标准在1982年提出，后来在高性能计算机系统中得到广泛的应用。并成为了ANSI/IEEE 1014-1987的国际标准。
在PC 机发展过程中，出现了ISA和PCI 总线。将PCI总线技术移植到嵌入式计算机中， 1994年PICMG（PCI Industrial Computer Manufacturers Group, PCI工业计算机制造商联盟）提出了Compact PCI（PICMG 2.0）技术，它定义了更加坚固耐用的PCI版本。在电气、逻辑和软件方面，它与PCI标准完全兼容。卡安装在支架上，并使用标准的Eurocard外型。
为了提高更高的传输速率，高性能计算机总线朝着高速，串行化的方向发展。PCI 发展了PCI Express 串行标准。
VMEbus 协会（VITA）于2004年提出了VPX 总线标准（ VITA 46）。2007年成为美国国家标准（ANSI/VITA 46.0-2007）。在工业控制、信号处理和国防领域中得到了广泛应用。
从计算机总线系统的发展趋势看，正朝着串行化总线发展。比如工业控制领域的etherCAT 总线。更进一步地，人们也倾向于直接采用ethernet 作为计算机内部总线。这方面做的比较坚定的是施耐德公司。下图就是施耐德的以太网总线背板。
modular2 Edge 同样采用了以太网作为IO模块的数据总线。其架构如下：
软件架构
在modular-2 Edge中，App，IO模块和云端应用之间的消息交换采纳了微内核,微服务的设计理念。
微内核（Microkernel）的概念是由Richard Rashid在卡内基梅隆(Carnegie-Mellon)大学开发Mach操作系统时提出的，目标是建立一个基于消息传送(message passing)机制的最小内核，以便在此基础上建造对其它操作系统的模拟层来模拟其它操作系统的特性。
微内核的功能被划分为独立的过程，每个过程叫做一个服务器。所有的服务器都保持独立并运行在各自的地址空间。因此，就不可能像单模块内核那样直接调用函数，而是通过消息传递处理微内核通信：系统采用了进程间通信(IPC)机制，因此，各种服务器之间通过IPC机制互通消息，互换“服务”。
微内核设计带来了良好的兼容性、扩充性、灵活性、移植性、可靠性和网络支持。
相比之下，传统的操作系统内核称为单内核（Monolithic kernel）。内核就是把它从整体上作为一个单独的大过程来实现，并同时运行在一个单独的地址空间。因此，这样的内核通常以单个静态二进制文件的形式存放于磁盘。所有内核服务都在这样的一个大内核空间中运行。内核之间的通信是微不足道的，因为大家都运行在内核态，并身处同一地址空间：内核可以直接调用函数，这与用户空间没有什么区别。这种模式的支持者认为单模块具有简单和高性能的特点。大多数Unix系统都设计为单内核。
微内核将功能分为多个服务，服务之间通过RPC 交换信息的模式，与容器化的工业App 的运行机制非常相似。因此我们在设计工业App 运行平台base service 时，采纳了微内核的思想。
modular-2edge的软件架构并没有去开发一个微内核操作系统，而是在标准linux操作系统上开发了一个基础服务层（baseservice）软件，App，IO模块和云端服务通过基础服务层提供的软件总线（software Databus）交换消息。基础服务设计了基于websocket/json 格式的mRPC 协议，App 通过mRPC 协议访问基础服务（BaseService）。
同时,modular-2 Edge的软件采用了docker 容器技术，使工业App能够更加有效，安全地部署和管理。
modular2 edge 的软件架构带来的好处:
-多种接口转变为单一接口。
-复杂，综合功能的应用转变成为多个单一服务。
-App 和微服务相互独立，可以单独部署和更新。
-适合软件敏捷开发。
modular-2 Edge 没有像手机那样的LCD，用户主界面通过浏览器访问baseservice 内置的web服务器。为了尽量让用户具有智能手机LCD 屏的客户体验
仅仅提供基础服务是不够的，modular-2Edge 为工业App 提供的多项常用的服务。例如 MQTT消息交换，InfluxDB时间序列数据库.App 开发者可以在此基础上快速开发出高性能应用程序。
软件数据总线
所谓软件数据总线（software databus）实际上是一个消息交换机制，传统的单内核OS 采样了函数调用的方式来传递数据的，以后发展出了unix 的socket 通信，MQTT消息交换，RPC（远程过程调用）等多种方式，进入云OS 时代更有各种各有的消息系统。例如比较著名的由google的gRPC ，它基于ProtoBuf 协议。这种消息系统能够实现跨平台分布式消息交换。
modular-2edge 设计了自己的RPC 软件总线。为什么要自己设计，而不是采用一种现成的消息交换系统呢？主要是基于下面几个原因：
面向物联网边缘计算的应用场景，我们是为一台基于cortex-A 处理器设计的物联网边缘系统，而不是手机，笔记本这一的终端产品，也不是云端大型分布式系统。物联网边缘设备与他们有所不同：
使用多种程序设计语言来编写应用软件
它们不会像手机App那样，单一地使用一种计算机语言来开发，例如android 搞了一个Davlik虚拟机，使用java来编写App，比如 python 更适合编写数据分析和可视化软件，而nodeJS，nodeRED 适合编写web 服务器程序和人机界面（HMI）。
支持更多的通信协议
工业App将连接更多的物理设备，使用更多的通信协议。比如与传感器通信使用TCP/IP，modbus，canbus fieldbus 等网络和协议。与云端服务器之间可能采取HTTP RestFull API，websocket或者其它一些协议。
更多的协同运行
App 相互之间的协同和消息交换会比手机App 更多。比如一个App 完成数据采集，另外的App 实现数据存储，可视化。
要求更高的实时性
工业App 实时性要求高。
：
促使我们自己开发独特的消息交换机制的另一个原因是现成的消息系统过于庞大，而且与硬件结合的不够紧密。所以效率不高。
modular-2 Edge 的基础服务采用的RPC协议（mRPC）基于websocket 的RPC 协议。并且使用json 格式化描述。使用websocket 协议的优点是适合分布式RPC 的实现，而json 格式适合多语言App的实现。
baseService 中创新地实现了数据流远程调用（Stream RPC）更进一步地提高了App 消息传递的效率，。数据流远程调用允许一个PRC 调用的结果是一个数据流（stream），调用方发送启动后，被调用方连续地发送数据给调用方，直到发送停止stop。这种方式在工业App 中比较常见，例如：
- 启动IO外围设备采集数据，IO外围设备按一定周期，源源不断地向应用程序发送原始数据。
- 允许一个事件通知，当事件发生时，产生一个事件结果（event result）。例如，允许按键中断，当按键中断发生时，产生一个事件结果该应用程序。
更进一步地，base service 点对多点数据流传递方式。当一个应用程序调用一个数据流RPC 之后，其它App可以同时读取该数据流。
基本格式
方法（method）
var rpc_method={
"method": methodName ,
"mode":mode,
"path":path,
"params":{"value":value},
"id": id
}
其中：
methodName 是过程的名称，字符串格式。
mode 为调用模式，共有六种模式。
Normal 1
StartStream 2
StopStream 3
startReadStream 4
stopReadStream 5
MQTTStream 6 6
Normal 是传统的Call/Result模式，其它模式在stream RPC 中进一步说明。
path 是RPC 调用的路径。由三部分组成。目前每一个id 由三位数字组成。
服务/资源/地址
例如访问第二个IO模块上的第路数字输出，路由为“000/002/001”
value 为RPC 的参数，使用二进制数组表示。
id 由一个整型数表示（0 ~5000），每发送一个RPC 调用，id 加一，到5000 翻转到0.
结果（result）
rpc_result={
“path”:path
“result”:{
“status”:status,
“value”:[values]
},
“id”id
}
path 为调用RPC 的路径。
status 为一个字符串。
-OK
-ERR
- 调用RPC 的名称
value 为RPC 的参数，使用二进制数组表示。
id 由一个整型数表示（0 ~5000），每发送一个RPC 调用，id 加一，到5000 翻转到0.
流RPC（Stream RPC）
所谓流RPC是指，RPC 的结果不是单一，而是连续地多个结果，形成一个结果流。直到发送停止stop。
流模式是RPC 的一种扩展，这种方式在工业控制，数据采集中非常有用。例如启动模数转换（ADC） IO 外设不断地发送采集数据。直到停止（Stop）。
读取流（ReadStream）
某一个App 调用了流RPC 后，其它App 也可以通过调用ReadStream 方法，来读取该数据流。数据流由Path 来标识。
一旦一个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。
注册PRC 方法（Register Method）
App 可以提供不同的RPC 方法，供其它App 调用。首先它必需注册这个方法。
rpc_register={
“method“：“register”
“path”:path
params:{
“value”:[methodName]
}
“id”:id
}
value 是一个字符串数组，可以同时注册多个RPC 方法。
基础服务的主要RPC
ping
register.rpc
register.app
get.rpclist
get.applist
read.stream
IO模块的RPC方法
modular-2 的各种IO模块的外设也是通过RPC 方式来访问的。base service通过读取config文件来获得IO模块的RPC 方法。常见的IO 模块RPC 包括
digitalOut_Write
digitalOut_Read
digitalOut_Flipflop
analogIn
interruptin
modular-2 Edge 的IO模块采用了Arm 公司的Mbed OS，所以可以编写各种灵活的IO驱动程序。 用户可以根据需要，编写各种IO模块的RPC方法，比如
modbus.read
modbus.write
canbus.read
canbus.write
具体的方法参见《IO 模块RPC 方法编程指南》
App 调用IO 模块
BaseService 的调用过程
基本方式
每个RPC 都需要注册，IO模块的RPC方式是由baseService 内部注册的。一旦注册之后，别的App 就可以远程调用这个服务了。所有的APP是向base service 调用该服务。base service 实现rpc 的转发。这样做的好处是 App 的服务扩展了base service 的服务。对于App 而言，base service 就是一个能够提供丰富服务的OS。
App 的基本结构
App 是运行在docker 容器中的程序，可以使用多种程序设计语言实现。它建立了一个
web socket 与baseservice 通信。
大多数App 需要一个用户界面（HMI）, 用于参数设置，人机交互和结果数据的可视化显示。尽管modular-2 Edge 提供了一个LCD 的屏幕，但是工业边缘设备不会配置键盘鼠标，所以App的HMI通过web 网页访问更加灵活，modular-2 Edge 中的App内置了一个极简的Web server，用户采用HTML5 网页作为App的HMI 界面。
当浏览器接入modular-2 Edge 后，进入baseservice 主页，由baseservice 主页跳转到各个App 的网页上。
为了实现这一点，每个App 在开始运行时，要在baseservice 注册。
bsseservice 也维护了一个dashboard 可以显示不同App 传来的数据。
IO 模块
modular-2 Edge 的IO模块是基于低成本cortex-M 单片机实现的。目前它采用STM32F系列单片机实现。采用IO模块的优点是cortex-M 单片机支持丰富的外围电路接口。可以方便地连接各种工业控制，数据采集设备。
cortex-M处理器除了实现底层接口驱动以外，还可以实现实时性要求高得数据预处理和判别。
为了缩短IO模块软件开发的时间，IO 模块用Arm Mbed OS，arm mbed OS 是Arm公司为cortex-M 单片机设计的一个物联网操作系统，他的主要特点是编程方便，使程序员摆脱了繁琐的硬件细节。该操作系统的应用程序由C/C++ 语言开发，Mbed OS 提供了底层程序库。
bsaeservice 的RPC 名称，参数格式尽量与Mbed API保持一致。
DigitalOut
PWMOut
DigitalIn
InterruptIn
AnalogIn
AnalogOut
Serial
SPI
I2C
canbus
软件实现的IO模块的功能
modbus
NB-iot
LoRa
GPS
结束语
目前modular-2 的最小可运行系统已经研发了出来，在瑞星微 RK3399 和全志H6 开发平台上运行。初步的测试表明，modular-2 Edge 的软硬件架构是可行的，合理的。