工业物联网关-整体框架

概述

网关设备主要用来解决数据采集以及上送到云端的问题。本来这些属于传统行业的技术，在物联网迅速发展的背景下，产生了许多变化。例如原来网关只需要实现Modbus或DLT-645协议，采集一些仪表和PLC设备的数据，通过私有协议上送上位机。随着终端设备的各类和数量增加，近距离无线通信技术的发展，网关设备如何做到灵活适配是个挑战；物联网和大数据的需求下，上送云端的协议和标准也增加了不少，从传统TCP/HTTP到MQTT/CoAP/LwM2M等；原来都是私有平台，现在阿里，腾讯，涂鸦平台逐渐成为标配，开放的平台也很多，比较出名的有Thingsboard。

目前并没有形成大一统的物联网标准，所以当前网关项目的定位以满足母公司应用为基础，同时兼容一些通用功能，也为日后定制化和新需求预留空间。例如采集端支持串口和以太网口，协议是Modbus-RTU，Modbus-TCP,DLT-645-07，基本兼容大多数传统设备。如果有新型的例如无线设备，应当做个无线适配器中转，不会直接做到网关来。云端的平台和协议复杂多变，上送软件走定制化灵活适配的方向。

硬件主要包括核心板，采集模块，网络模块。相对于第一代，采集模块和网络接口基本兼容，核心板和网络模块都选用了更低成本的方案，而且核心板的CPU，内存，flash规格都有一定的下降，对软件有一定的压力。第一代网关的定位是自用，通用性和扩展性不好，第二代网关的软件会大范围重构，软件的工作量会比较大。

硬件方案

第一代网关采用RK3288的方案，整体核心规格比较高比较贵，有点大炮打蚊子的感觉，所以第二代选了sigmastar的SSD202D方案，规格有一定程度的下降，特别是ram从原来的2G降到了128M。原来用4G模块现在使用Cat.1模块，同样是4G，价格降了不少。整体方案图如下：

如上图所示，CPU核心板包括了RAM和flash，组成基本小系统，并提供网络口，USB，串口，GPIO等接口，省略了一些业务关系不大的模块，例如RTC。
一路USB连Cat.1模块(4G)，USB 2.0 理论带宽480Mbps，4G理论带宽最高100Mbps，理论上足够，而且从产品业务看数据量不会特别大。另一路USB连6路RS485，我们RS485接口最高支持 115200bps 波特率, 115200 x 6 < 1Mbps 所以也是足够的。网络接入方面，方案提供了双百兆以太网，一个WIFI，一个4G，基本能满足市场需求，如果想要低成本方案，WIFI和4G可以裁剪。
数据采集方面，方案最多支持8路RS485，每路最多支持128个终端设备（RS485芯片能力限定，软件上每路最多支持256个终端设备），即整个网关最多支持8 * 128 = 1024 个终端设备。

软件框架

模块组成，数据逻辑说明，系统模块划分与架构
底层软件包括BSP及驱动部分，需要实现的功能包括bsp及应用层编译环境搭建，uboot及内核的系统移植，驱动开发，文件系统的裁剪，硬件测试配套软件开发，生产烧录，软件升级等。应用层包括业务数据处理，业务配置，设备管理，数据区。设备最重要的功能是实现终端数据采集，处理后缓存，上传云端。上传功能要支持多种协议多种平台，因此最好能做到相互独立，下面有一个比较直观的数据业务逻辑分层图：

从上图可见，最底层是外部终端设备，大部分通过RS485连接，通过Modbus-RTU协议通讯，如果要支持无线设备，则需要外挂无线适配器。小部分场景会用到局域网内通过Modbus-TCP协议采集数据功能，软件上也会支持。采集协议之上是独立的数据区，是使用redis软件在内存上缓存的，缓存数据会有过期时间，而且没有持久化到flash的功能，所以如果因为网络原因导致数据长时间不能上传，会丢数据，预计会预留几十M内存给redis，最长缓存时间由设备数据的数量决定。因为要支持的平台有可能是多个，协议也有多种，数据上传应用会有多个，每个处理一种业务或平台，互不干扰。各应用软件可能使用不同的语言开发，所以很有必要使用redis软件把数据区和变量区独立出来。层次划分清楚后就比较容易得出逻辑和数据的流程图：

从上图可以看到，数据物理通道有两种，RS485和以太网，采集协议和方式其实有好几种，RS485有Modbus-RTU，DLT645-07，以太网口支持Modbus-TCP。另外，两种物理通道都支持透传方式。
从上面的图知道，数据区其实包括数据区和变量区，数据区就是通过采集协议采集到的原始数据，以byte数组形式缓存，要注意的是redis只存字符形式数据，所以数据经过十六进制到字符串的转换。变量就是以"key = value"形式缓存的数据，变量支持integer, float, string, boolean，公式这几种数据类型。以下是一个变量的描述：

{
    "code": "current_A",
    "name": "A相电流",
    "attr_type": "telemetry",
    "unit": "mA",
    "area_code": "da_01",
    "area_offset": 0,
    "value_type": "float",
    "value_size": 4,
    "byte_order": "4321",
    "value_base": 0.5,
    "value_ratio": 100.2
}

可知，变量有唯一标识，名字，单位，与数据区的对应关系，数据类型，比率等。

进程划分

根据整体框架和业务逻辑划分出几个业务软件进程，如下图：

从上面可见，把采集都统一由1个进程实现，主要是考虑采集的业务后面不会有太大的改变，顶多只有通道数量等改变，不会大范围修改。使用c语言实现是因为本人对c语言熟而且涉及到操作硬件，而且对效率也有要求。云端适配层的应用可以根据需求再修改，上图只是给出大致方向。采集程序与云端适配器程序之间使用redis和消息队列做隔离。
另外，网关还提供一个web server，方便用户配置设备及业务，web server后端用boa实现，基本分层及逻辑如下图：

后端boa实现的主要功能包括：

• 设备与数据web端展示
• 保存各种用户配置，大部分是json格式
• 命令处理，例如恢复出厂设置，设备重启

模块间通信

系统划分多个模块，应用软件之间的通信方式需要提前规划，如下图：

如上图所示，web server的实现结果就是保存配置文件和调用shell脚本文件，配置文件会被采集程序及上层适配器程序读取；调用的shell脚本文件主要用于实现各种指定功能，例如重启。需要注意的是，有些程序在启动的时候读取配置文件并初始化，如果用户在运行过程中修改了配置文件并保存，想要配置生效的话，boa web server在保存了配置文件后，调用"killer.sh"脚本kill掉指定的进程，这时后台有个"keeper.sh"的脚本会自动把退出的进程重新启动，这样就重新读取配置并初始化了。要注意的是"killer.sh"脚本尽量采用通过给进程发送消息的方式使进程安全退出。

end