一个IoT网关产品的架构设计

这个产品是职业开始时候做的。当时没有IoT和云计算的概念，所以当时就是叫做透明传输终端，远没有现在的IoT网关这么‘高大上’和‘时髦’。

应用场景

首先介绍use case。用户是做工业系统监控的，产品主要是SCADA的场景。当时参与国家的重大的天然气项目的管道系统监控部分。要监控几十，几百，甚至上千公里长的燃气管道的运行情况，没有网络是做不到的。所以，当时的想法就是沿着管道线路铺设一条电信的数据专线用于数据传输。每隔一段距离把管道的数据收集并且上传到管理中心，并且通过管理中心对相应的管道单元实施远程控制。

在2000年前后，一条64kbps的线路可是不便宜！况且天然气管道往往远离人口密集/经济发达区域，尽量选择偏僻的地段。这样的地方基础设施差，铺设专线的价格更是不菲。

因此，客户当时考虑把作为备用通信通道的无线网络“转正”，也就是利用广域无线网络提供数据通信支持。当时的无线通信网络就是GSM网络的GPRS和CDMA 2000。

用户于是调研并试用了国内的无线传输终端，结果效果很不好。典型的问题就是网络连接的可靠性（reliability）问题，经常是连接建立几十分钟之后就再也收不到数据了，必须把传输终端重启（骑着摩托车开几十公里），之后再能工作几十分钟。这个问题的原因和当时GPRS的网络速度和可靠性都有关系。

所以用户找到我们首先提出来的就是连接的可靠性问题，用户也知道无线网络连接的稳定性不好，因此说可以掉线，但是掉线之后要尽快恢复连接，以保证业务的可用性（availability）。

所以，总结下来就是，以广域无线网络把SCADA系统和远端的控制中心连接起来，实现双向的数据通信。

该网关的下行接口是串口，连接SCADA设备，上行端口是TCP/IP，通过运营商的数据网络连接到控制中心。

所以这就是一个典型的IoT网关加私有云的应用。

具体可参考下图（源自网络）。下图的云服务器在当时的环境里就是用户的管理控制中心，APP远程监控就是运行在服务器上的监控软件。

产品选型

该产品要求具有PPP/TCP/IP的支持，所以一般单片机是不行的。

PPP的拨号功能来自单独的模块，需要外购，它与网关的控制单元之间是通过RS232接口连接，就像当时PC上网一样，串口加一个拨号的modem。

还有一个串口需要接下行的SCADA设备。

另外还需要一个设备管理接口，用于本地管理配置该网关。

概括下来，这个网关的控制单元需要比较多的IO，而且软件要支持PPP/TCP/IP。最后选了一个基于Z80的MCU，其软件栈支持PPP/TCP/IP。

当然，为了支持GPRS和CDMA2000，无线模块的选型也有技巧。那就是选择同一个厂家的模块，可以做到pin-pin兼容，这样的好处是生产和库房只要维护一个BOM就可以了，这样减少了生产和库房的维护成本，降低了出错率。但是软件增加了复杂性，需要自动识别和配置不通的模块和软件。

操作系统不是必需。

架构设计

架构设计上，因为是MCU的系统，512KB FLASH ROM，存放系统软件和配置参数，512KB SRAM作为系统内存。

没有使用操作系统，而是采用状态机（FSM）作为程序运行的主流程。

根据系统运行的阶段，定义不同的状态，根据事件驱动状态的变化。例如，modem配置->PPP拨号->IP软件栈初始化->TCP连接请求->TCP连接建立->数据收发（连接状态检查）。

与远程管理中心的连接使用TCP协议，而不是UDP协议（为什么？)

上行数据和下行数据使用不同环形队列，不同的TCP连接使用不同的上行队列。因为是8bit的MCU嵌入式系统，系统内存最大512KB，因此在预留了一部分内存作为管理功能用以外，其余内存基本都留给了数据缓冲区使用。

网络连接可靠性（reliability），依靠TCP keepalive功能，并根据用户配置设置其间隔（实时性和流量，性能和成本）。

网络连接的可用性（availability），即网络断开之后恢复。从开销最小的层次开始恢复，逐级向下。即从TCP socket重建连接开始，到IP协议栈的reset，最后直到设备reset。就是说如果检测到数据连接丢失，那么会从最高的应用层开始恢复，逐级向下，直到系统级的恢复。

网关设备的管理。支持通过RS232接口的本地管理。如前所述，仅有本地管理是不够的，因为这些设备都是间隔几十公里，而且在人迹罕及的地区，单靠本地配置管理是不行的。

因此通过TCP/IP建立管理连接，实现远程管理功能。

附加功能（与同类产品的差异）是支持系统软件的在线升级。针对这个典型的MCU的嵌入式系统的软件升级有几种方式，第一种是通过TCP的管理连接进行软件下载并升级。第二种是支持通过本地的串口进行升级。这两种是可以做到业务在线的情况下进行升级。第三种方式是在系统软件无法启动（brick了/砖了）的情况下，采用类似JTAG烧写FLASH的模式重新刷写系统软件。这个需要运维人员到现场连接设备特定接口进行升级。

架构对比

与当时市场的其他同类商品对比下来的特点有如下几点。

系统的连接可靠性/可用性（实时性）最好。

系统的应用范围比较广泛，不仅仅适用于天然气一个应用场景。

支持两种运营商网络GPRS或CDMA2000，软件自适应。

设备管理功能丰富，支持本地和远程管理，支持软件在线升级。

支持多个管理控制中心，类似目前云计算的2地三中心，最多支持3个管理控制连接。

系统功能可配置性，提供配置机制给用户，由用户根据自己的应用场景和成本预算达成适合其自身的SLA（网络可靠性/可用性）。

产品亮点

上面说了架构和产品特点。这里说的是亮点。

最大亮点在于在线升级。这是一个8bit的MCU嵌入式系统，通常软件都是运行在FLASH ROM (RIP)，数据存放在RAM当中。但是这个产品采用了全球首创的方式，在没有链接器（linker）来指定image layout的情况，在硬件不支持internal RAM的情况下，巧妙地采用了一种通用的方法实现了把代码和数据都放到RAM当中的实现，大大提高了运行的性能。

比较遗憾，当时没有发专利。

其实方法很简单，但是当时搞了4个星期。有些人得知了设计思路之后会很不屑地一笑然后来一句“哦，原来这么简单”。这是典型的“站着说话不腰疼”，而且暴露了那一丝丝“羡慕嫉妒恨”。

好了扯远了。

另一个亮点是采用了同一家的无线模块，所以做到了pin-pin兼容。看似不重要，其实对于生产部门的料单管理和库房管理非常重要，这大大节省了他们的维护成本和出错概率

第三个亮点是产品的管理维护，包括软件升级的三种方式，都是尽量保证在远距离的可靠性一般的广域网络环境下能方便地管理设备，并且在出现系统软件崩溃的情况下，运维工程师一根线，一个软件工具，一个.rom文件就可以现场恢复，无须返厂维修。这节约了用户的时间，节省了工厂的运维成本。

所以，研发不是只要设计出产品就行，还要考虑生产是否简单高效，是否易于售后维护。要做“系统”工程师，要考虑产品的“全生命期”。

实际运行情况回顾

总体来说运行反馈良好，也拓展了其他领域，例如能源方面。

运行大约4个月，险险出了一个大事故。当年春节，一个在市区外70公里处的燃气阀门故障，导致高压燃气直接威胁下游的几万户居民。运维中心在发现故障之后，立即启动关闭阀门操作，同时疏散当地居民。从发现故障到关闭故障阀门一共不到2分钟，也就是说一个环回的时间不到2分钟。甲方得到了当地政府的隆重表彰，并收到当地政府和相关部门的表扬信。为了感谢我们提供的IoT网关在这次故障处理当中的优异表现，甲方特地表达了对我们的感谢。

写在最后

这个产品是公司里面独一无二的数据通信类产品，而且从谈需求到交付一共用了3个月。参与的人其实就是我一个人，从原理图，到外观布局，到软件，到说明书，都是一个人来。另一个同事帮我做了windows上面的管理软件。参与了整个产品的立项，联调，售前，到售后的全部阶段。

所以，虽然过去了很多年，这里面的很多细节，特别是那些特点仍然记忆犹新。

说到这里，其实还是有一个小小的遗憾。。。。。。

你懂的。