物联网平台如何支持设备的多样化接入

简介： 我们常说，物联网平台的使命就是将物理世界映射到数字世界，而对于具体的一个物联网设备而言，要完成数字化的前提，首先是必须要能够通过某种方式直接或者间接的“接入”到云端。从“接入”这个视角去看，传统的互联网场景下，往往以 app、web 接入为主，app 和浏览器在接入上的实现一般都是比较标准的，相应的提供接入服务的云端实现也就比较标准。而在物联网世界中，情况就大不相同了，千奇百怪的设备，特点各异的应用场景，组合出非常多样化的接入需求，因而对于物联网的接入层的实现也就提出了多样化的挑战。

一、物联网设备的接入特点

我们常说，物联网平台的使命就是将物理世界映射到数字世界，而对于具体的一个物联网设备而言，要完成数字化的前提，首先是必须要能够通过某种方式直接或者间接的“接入”到云端。

从“接入”这个视角去看，传统的互联网场景下，往往以 app、web 接入为主，app 和浏览器在接入上的实现一般都是比较标准的，相应的提供接入服务的云端实现也就比较标准。而在物联网世界中，情况就大不相同了，千奇百怪的设备，特点各异的应用场景，组合出非常多样化的接入需求，因而对于物联网的接入层的实现也就提出了多样化的挑战。

终端碎片化

物联网设备碎片化严重，这种碎片化体现在很多维度。比如说，有的边缘网关是超高配置的物理机服务器，而有的传感设备则计算、存储和网络流量资源都极其受限。有的设备没有访问公网的能力，必须要借助网关才能连接云端。有的设备对功耗的要求极高，发一条消息就要休眠下，有的工业场景的传感器设备则一天 24 小时极其高频的大量上报点位信息，等等。这些不同的形态特点，所带来的需求和挑战也是不同的。

场景多样化

对于典型的边缘网络的场景，既需要边缘网关对设备进行本地控制（本地有拓扑结构，子设备数据通过网关通道上云），又需要设备能够在云端进行独立的数字建模。具体到拓扑结构上，既有树状的结构，也有 mesh 网状的结构，典型的如蓝牙 mesh 网络等。

协议多样化

物联网平台支持设备通过 MQTT、CoAP 和 HTTP 等标准协议，直接和云端通信，其他类型协议，如消防协议 GB/T 26875.3-2011、Modbus、JT808 等则暂不支持，事实上，平台侧也不可能将市面上所有的物联网协议都支持全了，只能优先支持广泛使用的标准协议。对于这些必须要私有协议和外部通信的设备，也需要有一套标准的适配方案。

升级困难或者周期长

有很多客户想将已有的设备接入体系迁移到物联网平台，但是他们的原有体系下，设备没有 OTA 的能力，不能进行固件升级，或者说虽然能够进行 OTA，但是成功率低或者升级周期很长。

二、要解决什么问题？

场景一：子设备如何上云建模

举个例子，比如一个园区中的传感器，传感器本身只采集数据，没有连云的能力，它就必须要通过一个边缘的数据网关将采集到的数据上报到云端。

要借助网关的通道将数据上传，一个直观的做法是，用户可以自己定义一套协议，把子设备的数据作为网关上报的报文的 payload 发送到云端，同时用户通过服务端订阅去接收数据。

image

这种做法本身是可以行的通的，但是这样做有两个问题。第一，这个方案下，只能仅仅将物联网平台作为一个传输通道，无法为子设备进行独立的数字建模。这样子设备就无法利用物联网平台的能力，而对于用户来说接入物联网平台的价值就大大降低。第二，用户的业务系统需要感知网关和子设备的拓扑，并且设备侧和业务侧需要 follow 同一套业务协议。

举个例子，如果用户想从云端对这个子设备进行控制（典型的比如通过 APP 调用云端接口进行设备控制），消息下发也必须通过网关的通道，那么用户就需要将发给子设备的下行指令，封装在网关的物理通道中，然后网关侧再对报文进行解析。这样操作会比较复杂。而且实际上，IoT 的整个生产流程往往是需要多环节协作的，边缘网关可能是 A 厂商的，施工是 B 厂商的、传感器是 C 厂商的、C 端用户使用的 APP 又是 D 厂商的，因此要求设备侧和业务侧去 follow 同一套私有协议是比较难的。

这个问题归结为，边缘拓扑下的子设备，如何既能复用网关的物理通道，又能以独立身份映射到云端进行数字建模和控制？

场景二：非标准协议设备如何迁移上云

很多客户在接入物联网平台之前，往往自己的设备已经有了一套数据采集的基础设施，比如智能抄水电表的系统；而且这些设备往往使用的是某种特定的行业协议，比如消防协议等等。这样的客户，既想使用物联网平台的赋予设备的数字化建模分析能力，但又不希望对已有设备程序和网络设施有深度的侵入性改动。

换句话说，已有自建基础设施的客户存量设备，或者非标准协议的设备，如何低成本平滑的迁移上云？

场景三：存量设备如何能力升级

物联网平台的诞生已经有 3 年多了，平台所提供的能力是在不断演进和发展的，早期的物联网套件时期，主要是提供的基础的接入和消息流转的能力，后来才逐步有了物模型建模的能力，有了数据分析能力等等。如果早期的客户，他的设备只是使用平台的基础能力，后面又希望使用平台的物模型等能力，但是前面我们已经提到过，物联网设备的特点就是 OTA 升级的难度往往比较大，甚至是没有 OTA 能力。

也就是说，原来使用自定义数据格式的客户，怎么能够不对设备进行 OTA 的情况下，升级使用平台的新能力？

场景四：超大数据量上报支持

在某些场景下，边缘侧要采集的数据量非常的大，典型的比如智能工业场景，工厂里每条产线上都有很多数据采集点位，这些点位每时每刻都在大量的上报数据，用于高精度的实时控制作业。一般来说工厂是通过边缘网关将数据上云的，那么这个边缘网关上报的数据量是非常大的，带宽和 qps 都会有瓶颈，而且单个 tcp 通道也很难支撑。

那么，对于边缘超大数据量上报的场景，怎么支持？

三、如何解决上述问题

连接方式与业务解耦

前面我们提到了由于物联网接入场景的多样性和产业链的复杂性，端侧往往需要通过多种协议或者网关形态接入，而云侧业务未必能和端侧保持同样的私有协议，因此阿里云物联网平台将连接方式与业务解耦，无论设备是通过何种方式接入上来的，都转换为统一的身份模型提供给业务层，对于业务层而言，只需要对直接对具体设备进行建模和控制即可，不需要理解其接入方式。

image

具体到技术实现上，一方面通过协议与流转分离屏蔽协议差异，另一方面在接入层通过拓扑映射和身份转换，将网关子设备的拓扑打平为统一的流转身份，从而实现业务系统和端侧接入方式的完全解耦。

泛化接入适配体系

对于存量设备或者第三方协议的接入适配，物联网平台提供了两种方式，一种是在用户侧适配，在用户侧搭建泛化桥接服务器，物联网平台提供泛化 sdk，包含了与云端之间的上下行协议，用户只需要编写自定义协议的转换逻辑，并调用泛化 sdk 的相应接口，就可以完成第三方协议的上云适配。不过这种方式，桥接服务器部署在用户侧，用户需要自行完成相关的资源部署和运维工作。

另外一种方式是在云端适配，这种方式也称为云网关。具体说来，就是在云端通过配置的方式直接生成标准资源，在云端进行托管部署，省去用户的资源配置和部署运维工作。云网关目前支持电信 NBIoT 接入方式，后续会继续完善其他三方协议，并支持动态协议插件等更灵活的形式。

image

脚本解析

随着平台能力的演进和用户业务的发展，用户的存量设备不可避免有能力升级的需求，最典型的就是从自定义业务协议升级到标准的物模型格式。此外还有一种场景是设备资源受限，只能用原始二进制格式上传，但是又想使用平台提供的物模型或者规则分析的能力等。

针对这种场景需求，物联网平台在接入层提供脚本解析的能力，用户可以针对某个产品配置相应的自定义脚本，当设备数据上报上来的时候，经过某种规则匹配到自定义脚本，通过脚本的执行将原始数据转换成物模型数据或者其他 json 格式的数据，然后消息就可以以转换后的格式进一步流转。

通过脚本解析的方式，用户就可以实现在不对设备进行 OTA 改造的前提下，无缝迁移使用平台的物模型等高阶能力。

image

报文聚合与通道压缩

image

对于工业这种超大数据量上报的场景，普通的传输方式带宽和 qps 都会出现瓶颈，物联网平台针对大数据量上报的场景，提供了以下解决方案。

报文聚合：就是将多个设备的数据，聚合在一个报文里，这样一方面可以减少报文的公共开销，提高传输效率，更重要的是简化了边缘侧的处理流程，边缘侧在单位时间内采集了多个不同点位的数据信息，可以不拆分为不同设备的数据，直接将数据聚合上报，大大提高了处理效率。

通道压缩：就是对于传输报文在边缘侧进行压缩，然后到云端再对应进行解压缩，这样可以大大提高报文的传输效率，减少边缘侧的带宽压力。

此外对于这种场景，还可以结合物联网平台的连接型实例，让网关连接独享接入资源，从而可以保障传输资源的稳定性。

通过以上方案组合使用，可以大大提高传输效率，减少带宽占用和传输 qps，稳定支撑大数据量场景的数据传输。

五、总结

本文列举了物联网接入的特点和挑战，以及几个典型场景的问题，介绍了阿里云物联网平台是解决这些物联网场景下的典型痛点问题的。在平台标准接入方式的基础上，通过身份解耦、泛化接入、脚本解析、压缩解压等多种能力的组合，让广泛的各种存量设备、受限设备、复杂拓扑场景下的设备都能具备连云的能力，并针对存量设备的迁移与能力升级、大数据量上报等典型场景提供了针对性的解决方案，让不同场景、不同特性的设备都能接入到物联网平台，享受数字世界带来的便利。