物联网系统开发工作涉及哪些方面?
物联网的概念已经被炒了好多年了,奇怪的是:市场中对这个概念的反应总是不温不火。随着5G技术的迅速普及,不知道是否能够再次把这个领域带火起来。目前国内的很多大学已经开设了物联网这个专业。
今天就从开发者的角度,来简单看一下物联网这个领域使用了哪些技术栈、有哪些开发工作。
一、物联网系统架构
这张图从开发者的角度,展示了一个物联网系统中的各种角色,包括它们之间的通信。如果从软件开发岗位的角度来对这几个模块进行划分的话,这个系统中主要包括:
前端、后端开发:负责物联网平台和业务应用的开发;
嵌入式软件:主要是设备端的开发,这部分根据使用的不同技术(或者说硬件模块),又可以分为很多不同的子领域;
移动端开发:Android APP, iOS APP, H5 小程序,还有目前的鸿蒙系统APP。
当前的物联网应用,所要做的就是控制和数据处理。指令,由用户到终端一层一层往下下达,直到硬件端由设备去执行。而数据,便是一层一层往上上报,直至被可视化。
因此,与互联网的架构相比,起点与终点不一样了:指令的终点与数据的起点,变成了硬件层,而非最后的用户层。
数据由客户端 A 发送到服务端,客户端 B 再从服务端获取 A 的数据,如此便算是完成了一个回路。而物联网架构则稍微麻烦了一些,多了一个层级,便多了一个步骤。
硬件层上的微控制器通过直连的方式,采集各式各样的数据,比如温度、湿度等。而受限于微控制器的成本、环境条件等因素,它可能无法直接连接到互联网。因此,需要连接到一些额外的联网设备才能实现。
而这些联网设备,会负责处理来自各个硬件设备的数据,并将其上传至服务器。同时,它会提供一个无线(如蓝牙、红外、ZigBee)接口作为数据的入口。因此,这一层级需要有更好的数据处理能力,并且它应该要可以快速开发。
二、开发技术
物联网设备端开发技术目前有两个比较大的发展方向,一是统一化的物联网操作系统,二是统一化的物联网开发框架。他们共同的目的是形成“软件定义物联网”,与传统从芯片选型开始的,着陆于原厂SDK中完成应用开发,与需求和产品设计汇合的流程完全相反,希望从需求和产品设计入手,通过公开统一的软件构架完成开发,再根据开发使用到的资源去落地芯片和外围设备。这样做的好处主要在于提高开发效率和形成可以复用的应用代码。
三、开发框架
首先解释一下开发框架,开发框架可以小到是一个细节的工具,也可以大到规定开发的全部边界。最典型的例子是Android,纯粹操作系统意义上,Android是Linux的一个分支,但是从App开发角度,除 NDK之外,没有任何与Linux打交道的地方,所以也把Android叫做操作系统。再广泛地看,Android除了面向手机应用的开发框架,还准备了Google play这样的应用分发渠道,这是开发者生态建设。同理,我们看Node.js在后端的种种开发模式,也是将所有后端资源都封装到 JavaScript里,开发时可以随时npm install各种包来require,解决了代码复用问题。
因此,开发框架以及背后的代码复用和开发者生态才是真正的操作系统。目前在物联网领域,正在尝试向生产环境演进的开发框架基本都基于 JavaScript,而在小型实时操作系统上使用的 JavaScript runtime 目前也基本集中到了 JerryScript 上。JerryScript 是三星开发和开源的一个小资源占用的引擎,内存需要 64KB,存储需要 200KB 即可,能够实现完整的事件驱动,符合 ECMAScript 5.1。
四、设备端的开发
这里描述的设备,还是属于比较狭隘的范畴,仅仅包含了具有通信功能的物理硬件实体。如果从广义的物联网来看,任何物品,只要能够接入网络,都可以称之为设备,或者称之为 thing。比如:把一件衣服附上一个电子标签,也是物联网的一个小分子。
我们仍旧以传统意义上的设备来讲解,比如:智慧路灯,智能手表,智能家居里的门磁、报警器等等。
对设备端的开发进行分类的话,从通信方式这个角度来进行划分比较清晰。
一个设备要想接入到网络,肯定需要通信功能,包括:有线通信,无线通信。在一些传统行业,或者对通信质量要求比较高的场景下,部署有线网络还是比较常见的,例如一些工业场景中。对于一些民用领域,大部分还是以无线通信为主。
4.1、不需要网关的设备
这一类设备,利用 2G/3G/4G 基站来进行数据的传输,产品的形态是:
也就是单片机+通信模块的方式。
通信模块包括:GPRS 模块、4Gor5G模块、NB-IoT等等。
在开发这一类产品的时候,单片机负责产品的功能部分;通信模块负责通信部分。单片机与通信模块之间,在硬件上通过 UART 口通信居多,在协议上可以通过 AT 指令,或者其他的一些专有协议。
近几年,在传统的消费类电子产品上,添加一个通信模块,让产品达到连网的功能,还是比较流行的。这一类的产品的软件开发工作,与一般的单片机开发并无两样。无非是增加了一些通过网络来上报数据,或者从网络接收控制指令。只要熟悉所使用的通信协议即可。
上面的这种产品形态,需要对硬件进行重新设计,比较适合从零开始的产品开发。那么对于那些已有的产品,如果想连接到物联网平台上,但是又不想重新设计,又该怎么办呢?
比如:一些扫地机、吸尘器的厂商,由于找不到其他可以创新、突破的点,于是就开始内卷,纷纷加上连网的功能。
他们直接在产品中,添加一个ESP8266或者ESP32模组,就立刻升级成一个智能产品。ESP8266 或者 ESP32 与一般的通信模组有一点不一样:它是一个完整的单片机,只不过它们的主要用途就是专门用来解决通信问题,而不是一般的功能控制。
4.2、需要网关的设备
如果提到智能家居,可能大部分的人会想到一个词语ZigBee,这是一个局域网的无线通信协议,大概在2005年左右就开始在智能家居中崭露头角了。与 ZigBee类似的无线通信协议还有:LoRa、ZWave、RF433、BLE等等。它们的作用都是类似的:都是为了让多个设备能够组网,节点之间以多跳的方式传输数据,达到通信的目的。
这些数据最终会汇总到一个叫做网关的设备,然后与云端的服务器进行通信。
这一类产品的开发,包括:网关开发和设备开发这两种。网关的开发稍微复杂一些。从功能上来说,网关需要实现:
设备的管理(与物联网平台的设备管理不是一个概念);
规则引擎(在断网的状态下实现场景联动等功能);
通信协议转换(把物理网平台的通信协议转成设备私有协议);
有些网关中,还会集成不同的无线通信协议模块,比如:把 ZigBee、BLE、LoRa、红外等功能,集成在一个网关中,这样的话,不同通信方式的设备就可以在一个系统中共存了。
此时,网关就要做更多的工作:
上行链路(连接到云平台):需要做到协议的统一,也就是说云平台才不关系下面到底是什么样的无线通信技术,云平台只会以统一的数据格式来表示每个设备;
下行链路(连接到设备):协议转换,把云平台发来的统一的数据格式,转换成不同的无线通信协议特有的数据格式;
设备的开发工作就相对纯粹一点了,它只需要处理某一种无线协议即可。这一类设备的开发,一般都是使用相应的通信模组,底层的协议栈都是提供好的。开发者需要做的工作主要就是熟悉应用层的通信协议,完成指令的解析和数据上报工作。
4.3、WiFi类设备
这一类产品最常见的就是各种品牌的网络摄像头(IPCamera),比如:小米、360、萤石等等。摄像头如果作为一个单品来使用,只要把家中的 WiFi SSID 和密码配置到摄像头中,就可以使用官方的 APP 来远程查看实时画面了。
如果把摄像头集成在一个智能家居的系统中,就需要二次开发。摄像头厂家一般都会提供 SDK,作为开发者需要做的事情就是:调用 SDK 中的 API 函数,获取实时画面、发送指令控制摄像头云台转动。
这里有一个底层的技术很有意思:P2P 网络穿透。我们买来一个网络摄像机,是不可能有一个独立的 IP 地址的。也就是说:其他设备(手机)是没办法通过 IP:PORT 的编程方式,直接连接到摄像头的。但是为了实时画面的传输质量,为了减轻服务器的转发压力,手机最好可以直接与摄像头建立 TCP 通信。此时,P2P 网络穿透给这种需求提供了可能。
在P2P Master(就是一台服务器)的协助下,实现移动端与摄像头之间的网络穿透,直接建立TCP连接。
五、物联网平台开发
物联网平台,作为连接业务应用和设备的中间层,屏蔽了各种复杂的设备接口,实现设备的快速接入。目前,做的比较大的就是那么几家巨头:亚马逊的 AWS 平台,阿里云、腾讯、华为的物联网平台。
以上这几家的物联网平台,仅仅是他们的云平台中的一个组成部分。它们的目标就是提供一个通用的通信标准和 SDK,快速的接入各种硬件设备,通过设备接入数量、通信数据的流量,以及提供各种业务层的服务来赚钱。
出于不同的原因,诸如保密、安全、可扩展、核心技术等原因,一定规模的公司会采用自主开发的方式。这种开发方式与 Web 应用开发方式并没有太大区别,都是在数据进行 CRUD 操作。并且和前后端分离架构一样,使用 API 作为接口,同时再加上支持不同的传输协议,如 MQTT、CoAP 等。
物联网系统在存储上,采用 NoSQL 作为存储介质会有更大的优势。一般来说,物联网系统的数据都是写入远远多于读取的场景。与此同时,由于设备的种类繁多,不可能为每一类设备创建表;或者考虑到大量设备的特性,来建立一个通用的表,但在未来这样的表可能仍不适用。
因此,对于物联网数据来说,选用诸如 MongoDB 这一类的 NoSQL 数据库,有这么一些优点:
灵活性。采用非结构化的数据模型,可以存储和处理任何结构的数据;
支持水平扩展。NoSQL 数据库的分布式存储架构,带来了优秀的水平扩展性;
实时数据分析。如 MongoDB 可以通过丰富的索引和查询支持,包括二次、地理空间和文本搜索索引,聚合框架和本地 MapReduce,可以针对传感器数据就地运行报告分析。
然而,这样的系统不免存在研发周期长的问题。如果需要快速验证,那么应该考虑使用云服务来完成部分功能。
另外,还有一些下一梯队的公司,开发了自己的、专门针对物联网领域的平台。由于知名度不高,只能以合作开发项目的形式来吸引硬件设备的接入。从开发的角度来看,物联网平台的开发技术栈主要是后台开发。由于这部分技术栈我不太熟悉,就不去深入讨论了。物联网平台最宝贵的就是数据,如何利用这些数据,这就是业务应用的事情了。
六、业务应用开发
所谓的业务应用,简单来说,就是通过调用物联网平台提供的 API,实现设备管理、数据上报、命令下发等业务场景。设备管理是在设备接入基础上,提供了更丰富完备的设备管理能力,简化海量设备管理复杂性,提升管理效率。从物联网平台的设备和数据中,可以衍生出各种不同的业务应用场景,这就要根据实际的系统功能来进行按需开发了。
七、物联网云服务
对于硬件团队来说,直接使用云服务是一种更简单、快速的搭建物联网系统的方法。而使用物联网云服务,就意味着:我们可以直接上硬件层的传感器数据,并在应用层获取、分析这些数据。这一类的服务,比较成熟的有 AWS IoT Things、Azure IoT 等。
AWS IoT Things 参考架构
基于 AWS IoT Things,我们只需要在云端,定义好对应的数据处理规则,便可以在硬件端直接对接服务。不过值得注意的是,单一的云服务无法提供复杂的功能,这个时候就需要一些搭配额外的服务。
7.1、Serverless
Serverless架构是云服务的一种,但是它在可编程与云服务之间做了一个折中。它是一种基于互联网的技术架构理念,应用逻辑并非全部在服务端实现,而是采用 FaaS(Function as a Service)架构,通过功能组合来实现应用程序逻辑。
Serverless 物联网参考架构
从理论上来讲,这些服务提供的是一层 API 封装,它不会限制我们所使用的语言。使用 Serverless 服务,我们可以具备更好的快速开发能力,并且能使用同一种语言(JavaScript)来完成编程。
在这个过程中,开发者要所做的便是:在不同的服务之间传输数据,每一次都只处理下一个服务所需要的数据,类似于 Pipe and Filters 架构模式。如一个典型的物联网应用的数据传输过程中是这样的:
对设备进行鉴权;
转换、存储设备的数据;
广播通知其他监听此设备数据的服务;
后台查询数据;
分析数据(AI);
可视化数据。
只需要少量的编程,我们就可以完成服务端的开发。随后,专注于硬件层的开发,以及应用层的业务功能。