EPIC设备云

之前的物联网大多以项目为导向,结果许多项目被甲方牵制,无法实现一个通用物联网设备云的目标。现在总算抽空开始将之前的项目中性化,转化为一个通用的物联网设备云:EPIC,Extensible Python IoT Cloud。由通用的设备(云)服务器和应用服务器(云)构成。

如果设备能力足够强,使用HTTP/MQTT+TLS方式接入云端,可以采用BAT/GAF + Azure提供的标准化IoT Hub。各类IoT Hub本质上都是一样的:先通过HTTPS获得凭证,然后通过MQTT/TLS接入IoT Hub。IoT Hub可以作为一个透明传输通道,而且解决了在第三方数据流分享的过程,随后附带数据分析、数据存储等服务。这种做法的鼻祖就是Xively。

EPIC设备云存在的意义

所谓设备能力足够强,主要是指计算能力、RAM/ROM存储空间足够满足HTTPS/MQTT+TLS方式,还需要JSON等传统联网编码的需求。这需要MCU具备M3/M4内核,64KB RAM + 512KB ROM左右的配置。虽然最近涌现的ESP8266/ESP32及其IoT竞品的价格组件降低(< CNY10),但是传统架构如M4 + WiFi SoC的BOM价格都不低(> CNY 25)。所以更多的配置是采用低配MCU + SoC的做法。RAM/ROM太少,两者间RAM太少是致命伤。所以低端配置往往不具备采用标准方式联网的条件。这迫使设备云必须提供一定程度的定制。这就是其存在的意义。

定制不意味着放弃最佳实践

在定制协议的时候,不能够放弃行业的最佳实践。以项目为导向的工程中,话语权很容易倒向制造商,但是来自传统行业的设备制造商的开发团队最容易犯的毛病包括:

  1. 把TCP连接等同于串口连接,将串口协议直接平移到TCP协议中;
  2. 把设备云的云计算是为对等的上位机,引入复杂的状态机模型;
  3. 把设备云视为自己系统的一部分,限制设备云的扩展能力;
  4. 忽略安全。

TCP连接与串口连接

串口连接是一种实时的,面向连接的数据流。TCP是一种非实时的,面向连接的数据流。相同点都是面向连接的数据流,差异点在于TCP是一种虚连接,不是电路连接,所以容易产生收发粘连和卡顿。而这在接收端造成了困难,需要依靠通讯协议来切割以及拼接分组报文。所以,串口协议不能够平移到TCP协议上

我接触的客户,凡是有这种冲动的,无法说服的话,我会放弃这家客户。

复杂状态机

实际上,在串口通讯中,上位机(主机)和下位机(设备)之间往往会有不同的状态机:数据采集、设备配置、事件推送、固件下载,甚至和业务本身相关联的状态等。这一点主要和串口的分层模型有关。由于串口只有物理层和应用层,所以设计者的设计思路主要集中在业务状态中。

在物联网中,制造商往往会本能地将此类应用层状态机带入到设备云中。而设备云恰恰只是一个透明通道,不应该涉及到此类状态机设计中。

参考MQTT/CoAP协议,都只是提供一个传输层协议,至于Topic/Message/URI是什么,对于设备云来说完全无感。它仅仅负责传输而已。

所以,在物联网中,更多的状态机管理会移动到设备端一侧。正确的定制方式是分为两层:在TCP之上定义的一层不应涉及业务,而业务应用相关的额外定义。简化的是MQTT/CoAP的定义而已。

对应的方式是采用虚拟寄存器的方式进行交互。

设备与设备云的关系

由于商业的因素,导致话语权失衡。供应商经常将设备云视为自己的资产,会下意识地减少自己在设备测的开发难度。但许多做法会限制自己将来的发展。比如,企图简化所有Id/Key的流程,将产品序列号作为唯一索引。

道理是这样的,即使是同一框架下,凡是进过一个关卡,比如验证对象的Id和Key。而且Id/Key发行权归属于关卡。

所以制造商必须向设备云申请下发Id/Key,烧录在设备中,设备联网向设备云提交Id/Key。而且产品序列号和设备Id/Key的发行方和发行目的完全不同。绝对不能够混用。

忽略安全

物联网安全一直被人反复提及,却又放在最好。主要原因还是成本,因为TLS套件需要不少计算资源。目前我在测试ECDH/ECDSA/SHA/AES的加密套件。目前还没有完全测试,仅仅使用了AES128 CBC模式。

EPIC组成部分和提供的定制服务

  • 支持MQTT/CoAP和自定义协议;
  • 定制自定义协议的Connector,接入EPIC设备云;
  • 针对自定义协议生成mbed/Arduino C++代码;
  • 采用数据缓存/RDBS/TSDB混用方式存储数据,无数据瓶颈;
  • 采用消息队列转发数据;
  • 采用JSON下发配置。
  • 选用HTTPS下发登陆地址(可选);

推荐阅读更多精彩内容