基于阿里云IoT平台的物联网解决方案

去年差不多也是这个时候，我写过一篇《阿里云IoT应用案例》，重点提到了我们对于阿里云IoT SDK的封装并实现自主注册、消息队列规则转发、双向通讯、远程升级和远程控制等功能的设计思路。

又经过一年的持续优化、打磨，我们也落地了一整套物联网解决方案，包括物联网中间件和物联网平台，实现从仪器研发人员快速接入，到运维人员扫码装机注册，到仪器自动数据回传，到运维人员远程升级，再到管理人员物联网卡充值续费，最后到面向经营决策人员的大数据分析应用，拉通了整个业务闭环。

1. 背景

再一次提到背景，在上一篇文章中，简单概述了我们的物联网项目背景和需求，是为了解决在不同操作系统、不同开发语言的仪器，不同通讯协议、不同运营商的平台服务的环境下做一站式解决方案。但这只是技术背景和技术需求，放大来说，促使我们做这件事的原因还是产业数字化升级转型的趋势。一方面通过物联网和大数据等新技术对现有产品的升级、改造、赋能，让机器活起来，让数据流动起来，起到降本增效，辅助决策的作用，这是短期价值；另一方面，通过新技术的结合，面向新的场景探索，完成产品和业务的重塑，实现业务模式的转型，这是长期价值。

引用三个大佬的话来说这件事：

“大数据的本质是在线，而且是双向在线。所有东西都能在线这件事，远比‘大‘更能反映本质 ”

“千万不要想着利用数据去改进一个现有业务，那不是大数据应该做的事情，而是应该去做以前做不了的事情”

​ —— 《在线》王坚，阿里云创始人

“实现智能商业的第一步，就是让你的产品和服务核心流程在线化。在线化之后，真正的考验是你能否通过各种方式完成与客户的互动”

​ —— 《智能商业》曾鸣，阿里巴巴集团前总参谋长

“在亚马逊，数据的收集和分析是实时的。如果有需要，我们可以看到每天、每小时、每分、每秒的数据。如果出现异动，系统会自动提示相关人员”

​ —— 《贝佐斯的商业帝国》

2. 物联网技术

开始正式内容前，还是需要简单回顾下物联网技术。广义上来讲，能把物体自身的信息数据通过某种渠道方式传输到物体外部都可以叫物联网。常见的，物联网=

WLAN物联网（WiFi、蓝牙、Zigbee…）+ 蜂窝物联网（2/3/4/5G、NB、LoRa、eMTC、Sigfox…）

目前应用最广的外网物联网技术主要是NB-IoT/eMTC和3/4G，下图分别是这两种技术简单的横向对比和全球覆盖情况。

其中重点提一下，电信的NB-IoT是锁IP的，也就是只能回传到电信自己的平台（华为开发），不是很方便集中管理。我曾与与电信内部人员沟通，如果是大客户可以走特批渠道解除定向IP。而其他两家运营商的NB-IoT以及所有的4G，都是可以通过云或者自建CoAP、MQTT服务器实现统一接入管理。

此外，对比中很明显的几个点。一个是资费，虽然现在4G的资费已经下降了很多，流量费用基本和NB-IoT持平，但芯片还是很高的一笔费用。另一个是覆盖率，NB-IoT的覆盖目前还是不足。最后就是特点和场景，基本上NB-IoT只能满足一些状态信息和少量数据的收集。有更高数据传输要求的还是得往4G方向走。

提到物联网，少不了5G。我们都知道5G是一定是下一代IoT的标准，但目前还是处于发展期，基础设施覆盖不全、因用户少难以承受功耗压力众多5G基站选择关闭、缺少应用等情况是当下正在发生的情况，但也不妨碍我们去学习和了解他。大多数情况下，我们讨论的都是5G的高速和低延时，其实5G不单单只有这两个方面，具体来说，5G解决三大块问题：

· eMBB：上网更快，数据吞吐量更大；

· URLLC：通讯时延更低，最低可达1ms；

· mMTC：大连接标准，解决NB-IOT和eMTC正在解决的问题

可以看到5G解决了NB-IoT、4G的痛点问题，并把优势做整合，确实是值得期待的下一代技术。但作为消费者和用户，关心的还是还基础设施建设、覆盖率、国际化标准以及最主要的资费问题。所以对于5G，保持关注，让子弹飞一会。

3. 现状分析与需求清单

一般来说，物联网平台分成设备管理平台和数据管理平台，两个平台聚焦的方向和内容不同。设备管理平台关注设备监控，数据通讯。而数据管理平台关注的是设备管理平台回传的数据的存储和分析。

上两章是从大的背景和技术角度做了分析。结合上文关于物联网平台的定义，简单概括下我们做物联网解决方案的主要目的和需求：

设备管理平台：

• 业务需求
  • 设备 -> 云：
    • 状态信息回传
    • 错误异常信息回传
  • 云 -> 设备：
    • 设备远程升级
    • 配置文件远程下发
• 技术需求
  • 成本
    • 提供统一、通用的方式实现IoT接入
    • 可快速移植复用到其他类型仪器
  • 性能
    • IoT模块相对独立，不影响仪器核心稳定运行
    • 减少数据在传输中丢失
    • 支持多运营商，IoT信号需稳定良好

数据管理平台：

• 业务需求
  • 可视化与分析预测
    • 设备分布
    • 设备监控
    • 设备的区域渗透率
    • 耗材用量统计与预测
    • 故障告警与预测性维护
    • 多维度检索、分析
  • 数据质量与合规性
    • 数据的准确性、完整性、及时性、合规性
    • 数据的标准化、统一化
• 技术需求
  • 数据权限
    • 负责不同片区的人员只能看到该片区的数据
  • 业务权限
    • 不同角色职能的人员具有不同的权限

4. 功能实现与注意事项

根据上述需求，我们设计了一整套解决方案，打通端网云到数据应用。

从整体方案设计上来说：

• 开发物联网中间件，以SideCar的形式对设备提供快速、统一的接入方案。

• 设备管理平台与中间件进行双向数据交互，汇总所有设备通过中间件回传的数据，并作为数据源向数据管理平台提供原始数据。

• 数据管理平台对数据源进行处理，并结合内外部数据，如内部CRM系统的客户机构信息、WMS的耗材出入库信息等，外部的GIS、行政区域信息、客户企业公开信息等，以可视化的方式进行展示，动态分析和预测。

从业务流程和技术细节上来说：

• 设备接入

  • 物联网中间件的设计开发思路在《阿里云IoT应用案例》已经讲过，本质上就是基于阿里云IoT SDK的二次封装，为了同时兼容阿里云IoT和其他IoT平台像NB-IoT的电信以及AWS等。本例中描述的都是4G + MQTT方案。

  • 物联网中间件提供标准接口，并要求传输的数据内容格式是约定好的内容，比如Json或者其他自定义的格式。考虑性能问题，中间件不做数据的解析，只将数据转发到云或者其他IoT平台，由云端服务再做解析。

  • 由于中间件不做解析，只做转发。简单起见，我们的自定义Topic只有两个，一个是下行数据（回传到云）的Topic，一个是上行数据（从云端接收）的Topic，将不同业务的数据内容按照type和data字段加入到Topic中。title和data要作为物模型定义。

    

  • 由于物模型Text字段长度不能超过10240字节（19年是2k，后面增加到10k），所以中间件虽然不解析数据，但如果设备端传输的单个字段数据超过10k，需要拆分成数组array传输。

    

  • 为了方便开发测试、跨部门联调以及生产环境使用，需要区分不同的环境，我们在阿里云IoT平台用三个不同的产品来进行区分。设备注册时使用对应的ProductKey即可建立关联关系。

    

  • 此外，阿里云IoT平台限制消息发送的频率，如下图。所以中间件还需考虑高并发数据回传。可以使用消息聚合，多条消息合并发送，降低并发率。也可以使用队列的方式缓存，但要根据情况选择缓存到磁盘还是内存，不要因为中间件的使用导致设备上位机异常崩溃。

    

• 现场装机

  • 我们的设备是面向B端，需要运维人员去客户现场完成装机培训。所以我们把物联网注册也放到装机这个阶段。所谓装机就是登记设备的一些信息，包括装机地址、时间、装机人、客户机构信息等。

  • 我们开发了企业微信的应用，运维人员可以通过应用扫描设备的二维码序列号，并在手机上完成装机信息填写，数据会上报到我们自建的设备管理平台。当然大部分信息都实现了自动填写，如地址、时间、装机人等。这些信息为设备管理平台的设备管理、权限隔离，以及为数据管理平台的仪器分布、多维查询等功能提供基础数据。

  • 装机信息上报到设备管理平台后，后台服务会根据扫描二维码得到唯一的设备序列号，向阿里云IoT平台注册以获取三元组。需要注意，获取三元组的注册接口，也就是相当于在阿里云平台添加一个物联网设备，他的DeviceName是唯一的，且长度不超过32个字符，所以我们用设备的序列号来作为DeviceName进行注册。但实际情况是我们的设备序列号可能会超过32位，考虑截取序列号会出现重复情况，最终选择了以设备序列号的MD5作为DeviceName进行注册，并把设备序列号作为备注名称填写。当然备注名称也是有长度限制的，但无需唯一，所以这里截取就不会有问题。

    

  • 设备开机后，会调用中间件的初始化接口。中间件会通过HTTPS访问设备管理系统的后台服务，使用设备序列号请求获取三元组。这时候如果已经完成装机，后台服务就会返回三元组给到中间件，并由中间件完成阿里云IoT设备的后续注册。如果没有完成装机，后台服务没有申请到三元组，中间件就不会完成注册，自然数据通路就不会建立，设备状态就显示离线。

  • 如果设备由于故障返厂，也需要运维人员到用户现场，使用企业微信扫码，进行停机申报。这个请求也会到设备管理平台，后台服务再与阿里云IoT平台通讯，删除设备，注销三元组。此时该设备将无法再进行数据的传输。

• 数据回传

  • 中间件和后台服务的订阅发送依赖于规则引擎。从本质来讲，中间件通过某个Topic进行数据的发送，走MQTT协议，而MQTT需要Proxy Server进行中转，一般常见的像mosquitto，而阿里云IoT自己封装了这个Server，那我们的后台服务就需要去接这个封装的服务，这个就是规则引擎。

  • 可以通过规则引擎的“服务端订阅”直接使用AMQP与后台服务进行通讯。也可以通过云产品流转，把设备回传的信息直接流转到像阿里云RocketMQ、RDS、OSS等等。

  • 19年阿里云IoT的规则引擎还不是很完善，我们只能通过RocketMQ实现数据的中转，但RocketMQ SDK对于Golang的支持太差，不走SDK就只能通过HTTP协议通讯，轮询导致性能更差。直到后续上线了AMQP，我们才重新设置了转发规则，利用阿里云AMQP（RabbitMQ）进行物联网信息的订阅发送。

    

• 远程升级

  • 阿里云IoT平台提供了整套OTA方案，按用量付费，实现了版本判断、重试等机制。但有一些限制，像包的大小、数量、格式等。个人感觉在C端场景可能比较适用。

    

  • 我们的场景在B端，一般来说需要操作人员手动发起，甚至可以选择版本和进行回退。所以我们基于OSS重新实现了一套远程升级。将软件包上传功能放在设备管理平台，使用OSS存储，使用CDN进行下载。远程升级提供两种方式，PUSH和PULL。

    • 前者是从设备管理平台上传软件包后，主动推送到设备端，中间件获取到推送信息后根据地址下载，放在指定目录，并以回调方式通知设备上位机。而整个软件升级以及异常恢复功能都需要上位机自己实现。
    • 后者是从设备端由操作人员发起，通过设备管理平台获取指定数量、指定时间的软件包版本、内容和下载地址清单，人工选择具体的版本，随后完成升级。

  • 最后，我们也实现了升级日志，用于记录升级过程中的行为和异常信息。

    

• 物联网卡管理

  • 上文也说到，我们的物联网解决方案不仅仅使用阿里云，还要兼容运营商自己的平台。物联网卡的开停机、告警、续费等管理就是一个很大的麻烦。 为此我们也把物联网卡管理功能加入到设备管理平台，实现流量月不足预警和叠加包的快速续费。

    

  • 阿里云物联网无线服务虽然提供了物联网卡的下单、续费等管理功能，但毕竟与业务系统割裂。所以我们一般使用阿里云的物联网无线服务进行物联网卡的采购和每年一次的批量续费。而把叠加包的续费下沉到业务系统，也就是设备管理平台。阿里云也提供了相应的接口，只不过目前还十分简陋。比如只支持Java和PHP的SDK，所以我们只能使用功能不完善的API来实现这个功能。

  • 需要提醒的是，DoIotRecharge接口需要OfferID，文档上说这个ID需要咨询阿里云的业务人员，然而我们对接完发现业务人员也不知道这个东西，而且不同的运营商、不同的流量套餐，这个OfferID都是不同的。所以最后我们只能通过QueryIotCardOfferDtl接口查询不同运营商、不同套餐的物联网卡，找到对应的OfferID，写死在我们的设别管理平台中，用于续费。虽然是个很蠢的方案，但也没有更好的办法，希望阿里云也尽快完善这部分的功能。

    

• 数据管理平台相关功能

  • 有了设备管理平台的相关数据，并结合内外部数据，就可以通过可视化的方式进行展示。当然阿里云IoT平台的数据是可以使用云上其他产品进行快速应用的，包括数字孪生、数据分析，以及使用阿里云QuickBI DataV等产品进行可视化。这块内容涉及更多的是数据的治理和具体业务需求的实现，直接使用PaaS、SaaS产品还是自建产品，具体情况具体分析，就不再展开了。

5. 数据合规

数据合规性是物联网行业不得不慎重考虑的地方。数据是把双刃剑，它的价值很大，相应的风险也很高。关于数据合规，展开能讲的东西太多，不同的行业不同的场景也有不同。我不是法律和相关专业从业人员，所以仅就工业物联网中，设备的数据传输，提几个小点。

跨境数据：

不论是否含有个人隐私信息，从境外输入到中国，或者从中国输出到境外，都为数据出入境场景。凡是涉及数据出入境，都需要在符合关键环节条件的情况下，走政府申报。跨境数据可以说是个巨坑，因为跨境数据的风险远远不止数据一个维度，甚至涉及当地习俗、宗教等多种因素影响。互联网巨头们用专业法律团队武装到牙齿，仍然在跨境数据上吃苦头。所以在这方面务必慎重。

环节	合规要求	要求描述
数据产生/输出	满足本地合规限制即源头合规	指遵循数据输出国的法律对于数据收集和存储的要求，如数据本地化存储、数据主体同意、政府申报、任命数据保护官（DPO）等
数据传输	满足传输目的限制	指企业（数据控制者或处理者）将数据从本地转移到另一个国家，需要合适的理由与个人数据的出境目的
数据接收	满足接收国水平限制	指接收国的数据保护水平需要符合数据输出国要求，一般会要求接收国的数据保护水平要达到充分水平，至少二者水平要相当，并需要经过数据输出国认可

主要国家地区法规约束：

• 中国
  • 《个人信息和重要数据出境安全评估办法（征求意见稿）》
  • 《个人信息出境安全评估办法（征求意见稿）》
  • 《数据出境安全评估指南 （征求意见稿）》
• 欧盟
  • GDPR
• 俄罗斯
  • 《俄罗斯联邦个人数据法》
  • 《关于信息、信息技术和信息保护法》
  • 《关于“进一步明确互联网个人数据处理规范”对俄罗斯联邦系列法律的修正案》[第242号令]
• 日本
  • 《个人信息保护法 》(APPI)
  • 《个人信息保护管理体系要求事项》JIS Q 15001
• 北美
  • Health Information Portability and Accountability Act (HIPAA)
• 非洲
  • 《个人数据保护补充法案》
  • 《数据保护示范法》
  • 《网络安全和个人数据保护公约》

个人隐私数据：

几乎所有主要国家地区的法律法规都强调注意规避个人隐私数据的采集。下面针对通用行业、场景，举一些例子，帮助识别个人隐私数据、脱敏，使其合规化

• 国内

  

• GDPR禁止以下数据处理行为

  • 处理个人数据，揭露出其种族、民族、政治观点、宗教和哲学信仰，或工会成员身份；
  • 处理基因数据、生物识别数据，以识别出特定个人；
  • 处理与健康相关的数据，或与自然人性取向或性经历有关的数据；
  • 以及能够用来推断出上述信息的所有有关数据。
  

• 脱敏

  属性	去标识化建议
  姓名	删除或者置空
  联系方式（电话、住址、邮箱等）	删除或者置空 或隐藏部分信息，如手机号139****2345
  日期	时间偏移法： 通过日期时间+或-随机偏移量，进行数据扰动，实现去标识化且保证计算逻辑正确
  年龄	数据泛化： 以区间代替具体值，如年龄20-25
  号码（邮编、身份证）	删除或者置空 如有利用ID唯一性进行逻辑分析，如分析关联同一身份证的多个信息，可用其他唯一标识替代身份证

虽然目前物联网在基础设施上、产业上发展上、数据合规上，还是存在很多不完善、不确定的灰色地带。但随着国家政策的推进和技术的升级，伴随相关法律法规的完善，标准的建立，以及众多企业和物联网通讯从业人员的不懈努力。相信不久的将来，我们就会全面进入万物互联时代。