杜龙少(sdvdxl)

使用 IoTOS 搭配 tio 接入存量物联网设备

字数统计: 1.6k阅读时长: 5 min
2020/02/28 Share

概述

目前包括 BAT、华为等主流物联网云服务都内置自己的标准数据格式,均面临存量物联网设备接入的难题。氦氪 IoTOS 作为一款对标各大品牌的物联网数据中台私有化产品,也面临同样的问题。

tio(点击访问) 国内著名的网络开发框架。

本文将基于氦氪长期的实践经验,来讲述 IoTOS 搭配 tio 解决存量设备接入的具体思路和方法。

注:通过边缘网关接入的情况不属于本次讨论范畴,若关注这方面的内容,可翻看之前的博客文章《网关采集 ModBus 温度传感器数据传输到 IoTOS 实例》。本次讨论的部分只限于如下图红框处:

为什么存量设备接入是难题?

协议栈复杂

首先,“协议”这个词个人认为现在已经被使用地过于泛滥,好像所有协议都处于同一个层面,而实际上并非如此。参考下图,大家能看出来物联网协议栈其实非常复杂。

从下到上依次为:

  • 通信方式:Wi-Fi、GPRS、5G等
  • 网络协议:IPV4、IPV6等
  • 传输协议:TCP、UDP
  • 应用协议:MQTT、CoAP、LwM2M、HTTP等
  • 数据格式:ALink(阿里云)、HLink(华为)、KLink(氦氪)、私有 JSON、私有 HEX、私有 XML、……

相对来说,通信方式和网络协议好处理,因为物联网平台本来就对网络透明。当然有个别特殊情况,比如 Wi-Fi涉及到设备发现这个环节,略微复杂,但设备发现成功之后设备跟平台的交互处理几乎是一致的。

真正比较难处理的是传输协议数据格式这两层。

传输协议

相信大家都清楚,在 MQTT 成为当下主流物联网协议之前,大部分传统设备生产厂家几乎都使用 TCP 或 UDP 来直接包装业务数据,比如宏电协议等。熟悉网络编程的朋友们知道,TCP 存在半包、粘包问题,因此必须使用特殊字符(如 \n、\r\n 等)或者特殊格式(如 head+len+data+checksum)等方式来告诉 Server 端如何拆包(也可以叫做解码),把 data 正确取出。

包括 Netty 在内的若干网络框架,都很难实现免编译、动态插件化地解码,而且即使实现也可能影响处理性能、提高学习使用门槛(关于这点,可以参考 JMeter。即使 JMeter 的插件化能力已经非常强了,但依然不能实现热加载)。

数据格式

这里的数据格式就是上面提到的 data。对不同产品的 data,我们的理想当然也是免编译对接。好在目前有不少开发语言都能充当胶合的角色,比如 Python、JavaScript、Groovy、Lua。

难点在于:

  • 平台开发语言和动态语言的集成,双方是否可共享上下文 Context?
  • 执行效率。动态语言难免在性能上有所损失,因此也要看实际项目场景。
  • 编写门槛。好在像 Python、JavaScript 开发群体众多,门槛较低。
  • ……

存量设备的信息缺失

信息缺失并非是设备厂家主观行为故意导致,而是存量设备在设计时可能还没有类似所谓的通用物联网平台。

比如,像 BAT 的 IoT 平台、华为 OC、氦氪 IoTOS,要连接每一个设备,都得预先在平台上先创建产品,平台会自动给产品分配productKey,否则设备接上来,平台就不知道它到底是什么品类(对应物模型)、什么型号(对应协议栈里的各层信息),后续任何交互也无从谈起。而且更要注意到,这个问题跟上一个问题实际上是耦合的。

但存量设备里很少预存类似 productKey,怎么办?

设备认证

目前主流平台均使用三元组来实现设备认证。实话讲,确实比仅仅单纯靠 IMEI 或者 ID 匹配安全太多。但存量设备有三元组吗?😭😭😭

解决办法

先确定标准接入流程

如下图是氦氪 IoTOS标准接入流程

基于标准流程,不仅可以解决新增设备的接入,也能部分解决存量设备的接入,即创建产品时选择自定义模式,开启数据解析插件功能。

IoTOS 对 MQTT、CoAP、LwM2M、NB(运营商转发)接入的产品均支持数据解析插件功能,对不统一的数据格式提供了一种统一的解决办法。

基于 tio 定制连接通道

tio 是国内著名的网络开发框架,特点是极轻量化、性能强悍、简单易用、门槛低,开发者可以很快上手。正因为如此,tio 很适合作为 IoTOS 定制通道的开发组件。

tio 定制通道和 IoTOS 的协作关系如下图:

tio 负责对私有协议的编解码,其他功能(如:设备认证、规则引擎、数据存储和聚合分析等)由 IoTOS 实现,相得益彰!

注:考虑到 IoTOS 是私有化产品,因此暂时直接开放消息队列接口。基于超轻量的考虑,IoTOS 使用了 Redis 5.x 的新特性 Stream 作为消息队列。

TCP 通道定制

目前,IoTOS 基于 tio 已经完成部分特殊 TCP 通道 ,包括:

  • KLink-TCP
  • \n 作为分割符的私有协议
  • \r\n 作为分隔符的私有协议
  • 其他在计划中 ……

UDP 通道定制

  • KLink-UDP
  • 其他在计划中 ……

工作量评估

若熟悉 tio 的代码结构,我们评估开发一个定制通道的时间基本按小时计算。是不是很香?😆

总结

坦率地说,IoTOS 并不能解决所有存量物联网设备的接入,这也并非是我们在开发 IoTOS 之初的设想。

解决大部分环节的标准化,把定制化的部分尽量压缩在一个很小的范围内,由轻量级的组件或者合作伙伴来配合完成,可能才是正确的选择!

来源

原文作者:杜龙少(sdvdxl)

原文链接:https://todu.top/posts/7be8/

发表日期:2020-02-28 14:25:32

更新日期:2020-03-01 12:39:47

版权声明:本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

CATALOG
  1. 1. 概述
  2. 2. 为什么存量设备接入是难题?
    1. 2.1. 协议栈复杂
    2. 2.2. 存量设备的信息缺失
    3. 2.3. 设备认证
  3. 3. 解决办法
    1. 3.1. 先确定标准接入流程
    2. 3.2. 基于 tio 定制连接通道
      1. 3.2.1. TCP 通道定制
      2. 3.2.2. UDP 通道定制
      3. 3.2.3. 工作量评估
  4. 4. 总结