查看: 36|回复: 0

物联网接入

发表于 2022-8-19 17:10:25 | 显示全部楼层 |阅读模式
[color=rgba(0, 0, 0, 0.8)]一、物联网设备的接入特点
我们常说,物联网平台的使命就是将物理世界映射到数字世界,而对于具体的一个物联网设备而言,要完成数字化的前提,首先是必须要能够通过某种方式直接或者间接的“接入”到云端。

从“接入”这个视角去看,传统的互联网场景下,往往以app、web接入为主,app和浏览器在接入上的实现一般都是比较标准的,相应的提供接入服务的云端实现也就比较标准。而在物联网世界中,情况就大不相同了,千奇百怪的设备,特点各异的应用场景,组合出非常多样化的接入需求,因而对于物联网的接入层的实现也就提出了多样化的挑战。
[color=rgba(0, 0, 0, 0.8)]
[color=rgba(0, 0, 0, 0.8)]终端碎片化
物联网设备碎片化严重,这种碎片化体现在很多维度。比如说,有的边缘网关是超高配置的物理机服务器,而有的传感设备则计算、存储和网络流量资源都极其受限。有的设备没有访问公网的能力,必须要借助网关才能连接云端。有的设备对功耗的要求极高,发一条消息就要休眠下,有的工业场景的传感器设备则一天24小时极其高频的大量上报点位信息,等等。这些不同的形态特点,所带来的需求和挑战也是不同的。
[color=rgba(0, 0, 0, 0.8)]
[color=rgba(0, 0, 0, 0.8)]场景多样化
对于典型的边缘网络的场景,既需要边缘网关对设备进行本地控制(本地有拓扑结构,子设备数据通过网关通道上云),又需要设备能够在云端进行独立的数字建模。具体到拓扑结构上,既有树状的结构,也有mesh网状的结构,典型的如蓝牙mesh网络等。
[color=rgba(0, 0, 0, 0.8)]
[color=rgba(0, 0, 0, 0.8)]协议多样化
物联网平台支持设备通过MQTT、CoAP和HTTP等标准协议,直接和云端通信,其他类型协议,如消防协议GB/T 26875.3-2011、Modbus、JT808等则暂不支持,事实上,平台侧也不可能将市面上所有的物联网协议都支持全了,只能优先支持广泛使用的标准协议。对于这些必须要私有协议和外部通信的设备,也需要有一套标准适配的方案。
[color=rgba(0, 0, 0, 0.8)]
[color=rgba(0, 0, 0, 0.8)]升级困难或者周期长
有很多客户想将已有的设备接入体系迁移到物联网平台,但是他们的原有体系下,设备没有OTA的能力,不能进行固件升级,或者说虽然能够进行OTA,但是成功率低或者升级周期很长。
[color=rgba(0, 0, 0, 0.8)]二、要解决什么问题?[color=rgba(0, 0, 0, 0.8)]场景一:子设备如何上云建模
举个例子,比如一个园区中的传感器,传感器本身只采集数据,没有连云的能力,它就必须要通过一个边缘的数据网关将采集到的数据上报到云端。
要借助网关的通道将数据上传,一个直观的做法是,用户可以自己定义一套协议,把子设备的数据作为网关上报的报文的payload发送到云端,同时用户通过服务端订阅去接收数据。
这种做法本身是可以行的通的,但是这样做有两个问题。第一,这个方案下,只能仅仅将物联网平台作为一个传输通道,无法为子设备进行独立的数字建模。这样子设备就无法利用物联网平台的能力,而对于用户来说接入物联网平台的价值就大大降低。第二,用户的业务系统需要感知网关和子设备的拓扑,并且设备侧和业务侧需要follow同一套业务协议。

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

发表回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

联系客服 关注微信 下载APP 返回顶部 返回列表