网关诞生的背景
很多物联网终端设备在设计之初就考虑了低功耗、低成本的需求,因此大量的物联网终端设备是靠电池来工作并且需要运行相当长的一段时间,比如油田、农业相关的传感器,且这些终端设备不需要实时与物联网平台通讯,甚至有的终端设备1天、1周、1个月才与物联网平台通讯一次。为了节省功耗,物联网终端设备在通讯协议上也选择的是功耗非常低、对资源消耗非常少的协议,在互联网中常用的TCP/IP协议本身功耗不低且需要用到非常多的资源,故这些终端设备基本上是不会采用TCP/IP协议,那么导致这些设备上传的消息无法进入到互联网中,也就没有办法被远端的软件调用。为解决这个问题,就需要有一个设备能够获取到物联网终端设备上报的数据,并且能把这些数据以TCP/IP(也有基于UDP的)的方式传输到互联网中,为此,网关就诞生了。
鉴于物联网平台中接入的设备种类和数量都非常多,那如何解决万物接入的问题呢?通常的做法是在边缘侧或者平台侧来解决万物连接,边缘侧一般是采用网关,由这个网关负责其它设备的接入,然后将设备的数据以统一的格式上传到物联网平台;平台侧一般会做一个功能模块比如设备接入模块,也可以沿用网关这个概念。边缘侧的做法可以解决那些不能直接接入到互联网设备上传数据的问题,平台侧可以解决联网设备的数据格式统一问题且还可以与其它IoT平台云云对接。
所以在万物互联这一点上,目前并没有特别好的做法。只要有低功耗的物联网终端和电池瓶颈的存在,就注定有很多终端设备无法直接联网,只要有无法联网的设备,那就必然需要网关。且由于没有统一的物联协议,就需要通过网关进行对接否则就是云云对接。
网关介绍
网关的作用
网关是一种协议转换器,将不同的设备协议转换成一种通用的协议,以便应用系统处理。在物联网中,一般是把设备协议转换成基于TCP/IP的协议,这样就可以在以太网中传输。
百度百科
网关(Gateway)又称网间连接器、协议转换器。网关在网络层以上实现网络互连,是复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连,也可以用于局域网互连。 网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言,甚至体系结构完全不同的两种系统之间,网关是一个翻译器。与网桥只是简单地传达信息不同,网关对收到的信息要重新打包,以适应目的系统的需求。同层--应用层。
从物联网网关的定义来看,物联网网关很难以某种相对固定的形态出现。总体说凡是可以起到将感知层采集到的信息通过此终端的协议转换发送到互联网的设备都可以算做物联网网关。形态可以盒子状也可以是平板电脑,可以有显示屏幕的交互式形态,也可以是封闭或半封闭的非交互形态,甚至手机都可以当作是物联网网关(手机可以将蓝牙设备的数据上传至物联网平台)
网关分类
智能家居中的网关按支持的协议来划分可以分成蓝牙网关、Zigbee网关、RS232/485网关、KNX/Modbus、RF射频网关(433)和支持多种协议的多协议网关(一般是zigbee+蓝牙);按照平台来分可以分为嵌入式网关、Linux网关和Android网关。
但是随着智能硬件的普及,网关已经可以逐渐变成一个功能模块嵌入到其它智能硬件中,比如智能音箱、智能电视、智能中控屏、智能家电(净饮机、冰箱等)。当然独立的网关依然存在,依然是构成智能家居系统中不可或缺的一个设备。
ps:智能家居网关和物联网网关大体上功能是一样的,具体设计和应用上略不同。通俗来说,智能家居网关属于家庭物联网,而物联网网关一般是指工业物联网。比如工业物联网要求网关本身的性能足够好,能够应对不同的工作环境;而家庭网关一般属于消费级市场,对网关的性能要求并不高,但是对实时性要求更高一些。
网关架构
无论哪种网关,大体上来说整体架构是相似的,如下图所示。基本分为主控部分、协议转换、供电、网络、存储、其它附属部分。下面是一个独立网关的主要功能结构,如果是非独立的网关,则基本上自需要考虑协议转换部分。
在协议转换层面也有两种做法,一种是基于协议栈的开发,一种是用现成的soc。前者能有更强的自主性,在功耗、成本方面都能自主控制;后者依赖于soc厂商,只能使用soc厂商提供的接口,好处是不需要了解具体的协议栈且可以快速开发,有利于产品的快速上市。至于选择哪种开发方式,取决于当时面临的业务场景、团队成员的技术实力和成本。
以我当初面临的情况来看,网关这个东西非常重要,但是技术实力有限,团队的嵌入式开发人员没有做过Zigbee的开发,且多个项目在并行启动。故最终选择的方案是zigbee部分使用soc,蓝牙部分在电子设计时预留但暂时不做设计和开发,wifi部分也是采用的soc,由安信可提供(基于乐鑫的esp8266)。主控芯片是STM32L151C8T6A (Cortex M3架构),这个是在设计净饮机和wifi门锁时用的主控芯片。嵌入式开发人员对这块芯片玩的很熟,所以上手就更简单一些。且这会儿嵌入式开发人员已经在了解freeRTOS的开发工作(后来他们开始使用阿里云IoT,后来改用阿里云的ali-link方式接入阿里云但是最终没能解决上云的难题,最后硬件团队解散)。
ps:我印象中网关中的wifi soc是安信可公司提供的(esp8266主控),应该是不支持自定义开发就(经查证,是支持二次开发的),所以最终主控就确定是安信可提供的wifi soc。主要是为了控制成本,将bom成本控制在70元以内(刘铮说他能把网关的bom成本控制在50元以内,因为那是海尔,海尔有量,没有量都TM扯淡)
协议转换和协议解析
协议转换和协议解析不是一码事,协议转换是将A协议转换为B协议,转换过程中并不需要关心A协议中的具体内容可以粗暴地打包,比如类似IP封装tcp消息包;协议解析是指解码,将A协议中的载荷(playload)按照一定的规则进行解析,解析的目的是为了让业务系统能够直接处理,比如设备上传的二进制数据是无法被业务系统处理的,需要将设备的二进制数据代表的含义解析后再提供给业务系统。
是否做协议解析还要看网关本身,如果追求极致的成本,那么可以协议解析功能放在物联网平台。比如阿里云IoT就支持开发者自定义脚本来解析设备端上传的数据。如果网关本身筭力足够,那么可以由网关来做协议解析,这样的网关一般还能做额外的事情,比如做本地化的场景(接近边缘网关)
网关的未来
当前网关已经植入到一些能力较强的设备之中,除为了满足性价比需求或者信号覆盖需求外仍需要网关来做补充,否则其实都可以通过其它的一些设备来解决这个问题。前面已经提到了智能音箱基本上都能够充当网关的功能,而且目前通过智能音箱来添加设备是最佳的方式,故智能音箱的作用只会越来越重要,至于网关,独立形态的网关将会越来越少但短期内不会彻底消亡。
未来,多模态传感器的出现或许也会将网关送入历史之中,早先单独的传感器应该功能过于单一处于性价比考虑一般不考虑联网,但是多模态的传感器诞生之后,因为本身功能较之前强大很多,且算力的下沉,可能会诞生超级传感器,那么这会儿传感器本身就能够处理不同的协议,且可以与网络进行通讯。
网关设计
确定网关功能(产品定义)
先看下市面上的智能网关价格,下面分别是华为、绿米、萤石云、京鱼座和小米米家5款。
最便宜的是小米的多模网关,是129元,支持wifi、zigbee3.0和蓝牙mesh,这款设备貌似已经停产。其次是京鱼座和萤石云的网关,价格是149元。最贵的是绿米的网关售价高达219元。
这5个网关的大部分功能都是一样的,除小米米家多模网关具备蓝牙功能外,其它的网关基本上具备语音播报、夜灯(米家网关、萤石云和京鱼座的没有夜灯)、本地场景的功能。除此之外,这些网关并没有大多的区别(支持的设备数量也是有区别,这主要取决于网关的性能,非功能)。
在供电方面,除米家多模网关和京鱼座网关外(microusb供电),都是市电供电,可以直接插在插座上。
那么,对于一个智能家居厂商,究竟要做什么样的网关呢?我当时做出来的决定是做一款价格低廉的网关。对于我们这样没有名气的智能家居厂商(依靠自己地产),采购量并不大,也就很难通过量压低价格(毕竟不是小米,多出蓝牙功能的情况下还能做到最低价格),既然如此,那就把网关的功能聚焦在网关本身,不相关的功能能去就去,以成本为导向。最终我们做出的网关有一下功能:
-
夜灯:老板强烈要求,也可以用于报警灯,于是妥协了(采购RGB led,混色)
-
提示音:采用蜂鸣器的方式
-
microusb供电:不配适配器,只提供microusb线缆。这样成本上能够降低10-20元(不用适配器,能省下10元左右;其实如果自制变压器加稳压芯片,也就多出几块钱)
一切以成本为导向,最终bom成本控制在70元内,10k之后bom成本能够降到60元左右。
事后思考,其实夜灯这个需求是没有必要加的,老板的想法是让用户在买网关时顺便当夜灯使用,但实际上来看,想用这个网关当夜灯,还需要购买额外的传感器(难道是引导消费者购买传感器,捂脸),且由于这个网关体积较大,一般只能插在墙插上(若果插在插排上,估计要占掉3个插座的空间,不合适)而且还要选择好地方,条件确实很苛刻,用在后装市场是一个大问题,装修时谁会留一堆墙插呢?一般都是有桌子地方会预留1-2个,电视柜预留3个左右,床头一边一个插座(也有只留一边的),那么这种情况下要为网关单独留一个插排使,挺浪费的。
关于网关下挂载设备的容量,涂鸦的zigbee网关最多支持挂载50个设备,蓝牙网关支持120个(稳定运行,其实还可以挂载更多的设备,但是不能保证温度运行);小米等网关挂载的zigbee设备不超过32个(绿米网关)。
PS:zigbee网络承载力目前咩有找到相关的解释,能否通过优化提供承载(不确定)
https://support.tuya.com/zh/help/_detail/K8xu0c86wlte1
网关的主要功能有:
-
多协议支持
-
协议转换和协议解析
-
数据传输
-
设备管理
-
其它功能:语音提醒(蜂鸣声或者人声播报);指示灯(用于设备状态或者安防报警)
网关架构
对网关的功能进行抽象和分层之后,可以整理出一个通用的物联网网关的架构,如下图所示。其中协议适配层中的协议解析是非必需的(可以在云端做协议解析),但是协议转换是必须具备的。
网关的电子设计
操作系统
确定网关的功能之后,接下来就需要考虑网关的系统,是实时操作系统(RTOS)、Linux还是Android。由于网关本身的功能较为复杂,裸机开发是无法胜任的,所以裸机系统直接排除了。至于RTOS、Linux还是Android,主要从成本、技术实现两个角度来考虑。
-
从技术实现难度来看:Linux>RTOS>Android
-
从成本来看:RTOS<Linux<Android
如果嵌入式团队中对MCU开发较为熟悉或对成本极为敏感(要求百元以内),那么优选RTOS;如果团队中对linux非常熟悉且网关没有显示屏,那么可以考虑使用linux,并且裁剪系统,降低对处理器和存储的压力;如果没有相关嵌入式的开发工程师但是有熟悉智能硬件Android开发的工程师,那么就考虑Android操作系统,由主板厂商和各模块厂商提供关键的sdk,然后在Android系统上进行开发。
主控芯片
确定操作系统之后,接下来可以选择满足需要的主控芯片。对于RTOS来说,片内的RAM和ROM非常重要,如果确定现有的主控芯片RAM或ROM不满足需要,那么就需要外挂存储芯片比如EEPROM或者NANDFlash等。对于Linux和Android系统而言,主芯片的RAM和ROM肯定是不够用的,需要考虑的反而是芯片的算力和内核。
方案
一旦确定好主芯片、存储和IO后,整个网关的系统组成就确定了。下面是一种基于RTOS电子设计方案,可以根据自己的需求进行修改。比如将主控MCU和wifi或者zigbee或者蓝牙的soc合二为一,这样可以节省一个MCU的成本(别小看这几块钱的成本,一旦批量就是几十万几百万,所以能省则省)。
来自NXP的一个网关方案