0%

使用氦氪 IoTOS 搭配开源 tio 接入存量物联网设备

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

概述

目前包括 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 之初的设想。

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