IOT设备动态化解决方案在工厂数据上云的应用

文末福利：开发者藏经阁

一、背景

工业互联网是近年工业领域的热门话题，不只是它被列入国家层面的战略计划，更是工业制造转型的必要需求。工厂数字化是未来工业的价值所在，工业互联网则是数字化转型实现的形式和必经之路。

工厂的数字化方案极为关键的一部分是将各类工厂线下数据标准化接入上云，其中工厂数据包含货品、原料、库存、生产计划、生产进度、订单、大盘等各式各样的数据信息，如何将这些纷乱的数据以标准格式低成本、快速地接入到云平台，是当下面临最关键的问题，本文将介绍一套搭载动态化脚本引擎的数据设备网关软硬一体化方案，帮助工厂数据低成本快速上云。

二、痛点

如上文所描述，我们的目标是将各个工厂纷乱复杂的工厂数据借助设备网关以标准化格式接入到云端数据平台，其中我们就遇到来如下3个问题。

问题现状

1）数据源接口种类繁多：不同工厂规模化与信息化程度不同，有些大厂拥有自己的ERP系统，我们的设备可以通过TCP/HTTP等网络协议与其对接，而很多依靠人工管理的小厂只有几台机床，我们只能通过Modbus/UART/CAN等硬件总线与机床设备对接，采集生产数据。

2）厂家私有协议泛滥：部分具有信息化管理能力的工厂，在ERP系统通过私有协议对生产过程进行管理，而更多时候我们无法直接从ERP获取详细的生产数据，需要我们从私有协议中提取有效信息。但我们面临的现状是各个工厂私有协议五花八门，没有统一的规律。

3）数据格式标准缺失：在工厂数据采集过程中，我们会面对不同层次的数据，从ERP归类的顶层数据到底层机床输出的字节流源数据，我们需要对这些纷乱的数据过滤清洗、归类整理，封装成标准的数据格式接入到我们的数据平台。

鉴于以上的问题现状，开发人员将直面以下3个难点。

难点

1）开发成本高：IOT设备端搭环境、反复编译烧录费时费力；单进程应用，硬件驱动与数据协议转换逻辑耦合，遇到一种数据源开发一种，存在很多重复劳动。

2）人员要求高：开发人员需要了解行业、厂家协议与数据接入；代码层面需要懂从底层到上层应用全链路嵌入式开发，同时熟悉各类网络及硬件协议。

3）运维成本高：无法线上运维，IOT设备出异常需出差到工厂现场；每种数据源对应一个设备固件，管理工作量大；固件升级、批量操作手工完成，费时费力。

三、技术方案

NO.1

动态化解决方案

如上图所示，本文提出一套以设备端动态化脚本引擎为主、涵盖前端、后端的全链路的设备控制台软硬一体解决方案，其主要包含应用管理、在线调试、状态监控、云端运维等功能，核心在于用脚本语言编写业务逻辑，降低设备端开发与运维的成本。

核心内容

1）建设通信链路：基于云端RPC，建设通信链路，将设备端能力透出到云端页面。

2）抽象设备硬件能力：如外设配置、开启/关闭、数据读/写，并按一定格式JSON协议透出。

3）脚本语言编写业务逻辑：基于已抽象的硬件能力与JSON协议，编写算法/业务逻辑并输出结果。

4）应用容器化：从云端页面下发脚本应用，全程管理应用生命周期，如同手机APP一般管理各个应用。

方案优势

1）降低开发成本：根据设备能力，封装主流硬件总线能力，C/C++主程序固化复用，无需反复修改；工厂源数据转换由脚本应用完成，一种接入一个脚本，代码量少，动态性好，无需反复编译烧录，云端下发管理脚本应用；硬件透明化，开发门槛低，硬件与业务开发分离，懂脚本就能完成协议适配开发。

2）降低运维成本：设备能力前端页面透出，解决非屏类设备交互困难问题；云端控制台，支持异地运维，无需出差现场；支持一键式应用升级、批量管理。

页面展示

上图展示的是设备端在阿里云IOT Pass的基本信息，我们可有看到设备的在线情况、固件版本、激活时间、IP地址等等。

上图展示的是设备端的云端控制窗口，云端控制部分有3个功能，第一个RPC-Shell可以看作是一个简易的终端窗口，我们可以远程执行 shell 命令并返回其结果，当然其执行权限必需安全可控；第二个功能是云端推送mqtt消息至设备端，方便云端mock消息到设备端进行联调；第三个功能是远程ssh，常规ssh只能访问无公网IP的局域网设备，而开启远程后我们可以在任意网络环境，通过密钥保护的ssh链接，开启web-shell远程ssh登陆到该设备，方便了设备的异地运维。

上图展示的是设备端应用管理，包含脚本应用添加下发、应用开关、日志查看、应用更新、代码查看等功能，每个应用信息存储在设备端，在web端以卡片形式展示并提供相应的UI交互，脚本应用持续运行在设备端，将工厂端原始数据清洗过滤后转为标准格式数据，上报到云端。

C/C++主程序封装了各类硬件总线并基于local mqtt以JSON协议透出，脚本应用可通过local mqtt对硬件总线进行配置开启，然后脚本便能从local mqtt获取到硬件总线读取的数据，进行清洗与协议转换后，输出给网关让其转发上云。

上图展示的是设备端的状态监控，目前我们将设备端的网络、进程、网卡、内存与外存信息透到web端，开发与运维的同学可以随时查看当前的设备运行状态。

四、技术思考

我们再来看上面这张图，除了彩色部分的外设与业务逻辑是根据场景而变化，其他灰色的模块都是中性化不带业务属性的，因此这套动态化架构的大部分能力是可复用的，以下是此架构方案的个人思考与实践。

思考与实践：

思考1:其他非工业领域的IOT场景能否复用此架构？

Yes，全场景覆盖！先前云栖大会项目套用此架构，核心的算法业务逻辑代码仅100多行，以上2个是非常典型的IOT场景化应用的例子，分别为持续化算法检测与持续化反馈控制的场景。

思考2:脚本引擎是否有限制？

理论上，只要支持mqtt的轻量化脚本均能适配，如node.js、 python 、 lua 、 php 等。

思考3:此方案最大的难点在哪？

设备端硬件能力抽象与应用全周期管理。

思考4:是否有劣势？

进程间通信的延迟与系统资源的消耗。目前在NXP的imx6ul单核芯片平台上，一个node应用内存消耗10-20M（2%-4%），CPU占用3-4%，进程间通信延迟1-2ms。

思考5:技术架构能否输出？

Yes，根据业务方开发资源的不同，能以设备端、设备端+服务端SDK、设备端+服务端SDK+前端多种形式输出。

五、未来展望

设备交互友好化

安卓系统让带屏的设备交互变得友好，而非屏类设备用云控制台页面代替屏幕进行随时随地交互。

开发过程轻量化

IOT开发需要降低开发成本与入门门槛，我们需要尽可能减少搭建环境、编译打包、串口调试、固件升级等费时费力的操作，让更多新手低成本入手IOT开发，开箱即用。

输出与推广？

目前以快速支持工厂数据标准化接入业务为主，根据需求支持其他线下业务。后续能否考虑打造一款类似天猫精灵、树莓派的小而美的硬件，搭载动态化架构引擎，以社区化形式推广，让更多人体验IOT开发的乐趣，这点值得探讨。

推荐阅读

一种高性能的Tree组件实现方案

VS Code 源码分析 - 多语言实现

揭秘手淘召唤术| 帮助千万级用户直达手淘的黑科技

文末福利