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下发登陆地址(可选);
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342

推荐阅读更多精彩内容