1. Google Weave框架
在2015年的Google I/O大会上,负责Android业务的桑达.皮查伊(SundarPichai)宣布了Google最新的物联网战略。这包括一个基于Android裁剪过的叫做Brillo的操作系统,以及一个物联网通信框架Weave。对Brillo的分析,我们放在本书的后面部分,这部分对Weave进行解析。需要说明的是,截至目前,Weave有关的正式文档很少,我们只能通过阅读其源代码进行分析。
a) Weave背景及定位
Google把Weave定位为物联网的一个通信层,但本质上,Weave应该属于物联网系统框架的范畴。因为它不依赖于任何底层的通信协议,它可以运行在任何常见的物联网通信协议之上,包括WiFi,BLE,Zigbee等等。
在这之前,Google已经通过多种方式进入物联网领域。最著名的,是收购了Nest,一个专门聚焦智能家居解决方案的技术公司,并对其做了整合。但是Nest的解决方案,只能运行在自有的智能家庭硬件之上,不能运行在非Nest的家庭设备之上,这样就限制了其进一步的应用范围。而且这种封闭的风格,与Google开放共享的风格完全背道而驰。
大概是认识到了Nest解决方案的不足,Google重新审视了物联网的特点,并结合自身优势,推出了Brillo和Weave的组合解决方案。该解决方案的大部分代码都是免费和开源的,因此可供广大物联网设备生产商直接使用。随着应用的广泛,Google会逐渐构筑起一个物联网领域的生态链。这种基于开源代码来构筑生态链的方式,完全符合Google的风格。
因此,Brillo和Weave就担负了构筑物联网生态链的重担。
b) Weave的主要特点
Weave具备如下特点:
首先,它是与操作系统无关的一个物联网系统框架,可以移植到任意操作系统上,只要底层操作系统能够提供Weave需要的最基本函数接口。虽然Google在其I/O发布会上,同时发布Brillo与Weave,而且Brillo缺省会内置Weave,但是Weave却不给Brillo面子,并不与Brillo紧密绑定。同时,Weave也不依赖于任何通信协议,它可以运行在Wi-Fi,BLE,Zigbee等常见的通信协议之上。
其次,针对不同的目标设备,比如资源受限的嵌入式硬件设备,资源充足的硬件设备,智能手机客户端(Android或iOS),云平台等,分别有不同的代码与之对应。这些不同的代码或组件,共同组成了Weave。显然,由于缺乏一个弹性可伸缩的操作系统内核,Weave不得不把所有的“职责”,都揽到自己身上,并通过不同的实现方式来应对。假设Brillo能够做到高度的伸缩性,可以适应几十K内存的资源受限设备,也可以适应数十M内存的复杂设备的话,那么Weave就不用这么费事了,只需要提供一套统一的框架代码即可。
再次,Weave提供了一套标准的设备操作命令(叫做Schema),以及对应的认证机制。Weave对常见的物联网设备,当前主要是智能家居设备,进行了总结和抽象,并形成了一套固定的操作命令集合,内部叫做Schema,并以JSON格式进行描述。Weave这样做的目标,是希望达到不同设备厂商的设备之间,只要使用了Weave,就可以相互操作的目的。同时Weave还引入了一套认证机制,不在标准schema框架内的设备及操作,可以经过Google的认证后,添加到标准schema中。这样就确保了整个schema框架的可扩展性,长此以往,就可以形成一个完整和丰富的生态链。
最后,Weave的大部分代码都是开放的,而且采用了相对宽松的BSD协议。Google仍然认为,以自己在IT行业内的影响力,并充分利用开源模式,来构筑一个完整的生态链,从而奠定在物联网领域的霸主地位,仍然是可行的。同时,面向设备的Weave库,尤其是uWeave,设计了一组简明扼要的接口,成为Provider。Weave的核心功能只依赖于这一组Provider接口,不依赖于任何其它的功能,使得Weave具备高度的可移植性。这从侧面也反映了Weave并没有与Brillo物联网操作系统进行紧密绑定,说明Google内部对Brillo的定位和地位,可能会存在争议。
c) Weave的整体架构
Weave是一个完整的物联网协同框架,它包含了一系列的组件,分别应用于不同的目标对象。下图是Weave的主要组成:
大致来说,Weave包含三个大的功能组件:支撑Weave运行的云端组件WeaveCloud,运行在智能手机(或Pad等其它智能终端)上的智能手机客户端,以及运行在物联网设备上的设备端组件LibWeave和uWeave。其中设备端组件LibWeave和uWeave运行在物联网设备上,比如智能门锁,智能LED灯泡,等等。设备端组件通过Weave Local API与智能手机客户端进行通信,接受智能手机客户端的管理和控制。同时,设备端组件也通过Weave Cloud API,与运行在云端的Weave Cloud进行通信。智能手机客户端也可以通过Weave Cloud API,链接到Weave Cloud上,通过Weave Cloud来控制运行LibWeave和uWeave的物联网设备。
同时,Weave提供了两类API:WeaveCloud API和Weave Local API。Weave Local API是Weave设备端组件与智能手机客户端之间的交互接口,而Weave Cloud API则是Weave Cloud API与其它两个Weave组件之间的通信接口。
下面分别对Weave的三个主要组件,以及两个API接口进行详细介绍。
LibWeave&uWeave
设备端组件又根据不同的目标设备,分成了两个:一个叫做LibWeave,适应于具备复杂计算能力的设备,这类设备支持Linux或者其它功能丰富的操作系统内核,具有数十M以上的内存空间。另外一个叫做uWeave,指的是微小(Micro)的意思。顾名思义,uWeave则是运行在资源受限的嵌入式设备上。
LibWeave是采用C++语言开发的,其代码已正式开发在Internet上。目前来说,LibWeave的主要目标操作系统是Linux,要求目标设备的CPU必须支持MMU(内存管理单元)功能,以实现支撑Linux有效运行的虚拟内存机制。
而uWeave则是面向资源受限的嵌入式领域应用,而专门实现的Weave协议栈。与LibWeave不同,uWeave专门对代码进行了定制和优化,使得整个uWeave的代码非常紧凑和高效。比如,uWeave以标准的C语言(C99)进行开发,这可使得整个代码库尺寸非常小,适应于资源受限的硬件设备。除此之外,uWeave还采用了一些其它的技术,比如采用CBOR编码格式来替代基于纯文本的JSON编码格式,来降低对网络的要求,针对低功耗蓝牙(BLE)进行了特殊的优化,采用更加简化的加密机制等等。
智能手机客户端
Weave开发了针对Android和Apple iOS两种智能手机操作系统的客户端程序库和对应的API,这样智能手机程序员可以直接调用Weave Client的API,来开发客户体验良好的Weave应用程序,来操控基于Weave的物联网设备。比如某个智慧灯泡生产商,在其智能灯泡中嵌入Weave设备端代码(LibWeave或uWeave),然后开发针对智能手机的客户端来操控这些智能灯泡。
同时,Google也开发了缺省的智能手机APP,这个APP可以做基本的Weave设备管理和控制工作。比如,可以通过这个APP,扫描局域网或蓝牙网络上是否有Weave设备。如果有Weave设备,则启动配对程序,把Weave设备纳入APP中进行管理。这时候如果Weave设备是基于Google认证的标准Schema来操作的,那么用户就可以通过Google的APP,来管理和控制Weave设备,而不用关心Weave设备是由哪个厂商生产的。
Weave设备的初