标签：
所谓连接，指的是各种各样的终端设备，都能够通过某种网络技术，连接到一个统一的网络上。任何终端之间都可以相互访问。下一代的基础通信网络，包括未来的5G，通信网络架构重构等，为物联网提供泛连接网络是核心目标。目前也已经有很多厂商推出解决方案，比如Google的thread/wave，华为的Hi-Link，以及NB-IoT等。
传统的物联网连接，都是指物联网终端设备与物联网云平台之间的连接，如下图：
在这种模式下，物联网设备通过各种各样的连接技术，比如WiFi，Ethernet，BLE，Zigbee等等技术，连接到位于云端的物联网平台上。需要注意的是，这仅仅是一个逻辑结构，在物理上，物联网设备在接入云平台之前，很可能需要一个物联网网关。因为很多连接技术是无法直接连接到位于Internet上的物联网云平台的，比如Zigbee，BLE，Z-Wave，NFC等等。这些技术的通信范围是一个小的局域网，比如一个家庭，一间办公室等。而连入Internet的技术，则往往是WiFi，Ethernet，2/3/4G等这类网络技术，大部分物联网设备并不能提供这种连接的支持能力。因此，需要有一个物联网网关，来弥补这个GAP，完成不同技术之间的转换。下图示意了物联网网关的功能和网络位置：
物联网网关往往具备相对强大的计算能力，具备丰富的网络接口，同时具备消息或数据的汇聚和分解功能。
在这种连接模式下，物联网云平台是所有物联网终端设备的“大脑”，云平台统一指挥物联网终端的行为，如果这种连接一旦断开，那物联网终端将无所适从，完全失去控制。
更理想的连接，应该是物联网设备之间，也实现本地的直接连接，如下图所示：
物联网设备之间也建立连接，同时保留与云平台的连接。这样的好处就是，一旦云平台的连接中断，物联网终端可以采用本地之间的终端连接，继续提供服务。同时，物联网设备本地之间的交流和通信，直接通过本地连接完成，而不用再上升到云端。
要实现这种“云端连接”加“本地连接”的模型，需要物联网设备支持消息中继功能。即物联网设备可以把另外的物联网设备的消息或数据，转发到云平台，同时把云平台发下来的数据，转接给另外的物联网设备。
协同，则是指接入网络的任何设备之间，能够通过学习，实时的了解自己和对方的能力和状态，能够根据特定的输入条件，或者特定的环境状态，多种设备实现有效互动，协调工作，完成某种单一设备无法完成的工作。协同是物联网的核心和本质。协同表现在下面几个方面：
物联网设备之间的自动发现，尤其是不同功能，不同类别的设备，如何相互发现。比如在智慧交通领域，汽车靠近路灯时，应该可以快速发现路灯，并建立联系。这样路灯就可以根据与自己建立联系的汽车数量，来灵活调度信号灯的闪烁时间；
物联网设备之间的能力交互。设备之间，只有相互了解对方的能力，了解对方能干什么，才能实现有效的交互和协同。类似中国人之间的“找关系”，只有知道对方是干什么的，有哪些能力，才会有目的的去“发起请求”，从而一起协作达到目标；
新增物联网设备或功能的自动传播。比如在一个局域网（智慧家庭）中，新加入了一个新的功能设备，这个新的设备需要尽快的“融入”原有的设备之中。这包括有一种机制，能够广播自己的能力，同时，原有的设备，应该也可以快速的“理解”新加入的设备的功能和角色，这样后续就又达到一种统一的状态。
智能，则是指物联网设备具备“类似于人”的智慧，比如根据特定条件和环境的自我调节能力，能够通过持续的学习，不断优化和改进，更“人性化”的为人类服务。
如果物联网设备只是连接在一起，能够远程控制，被动的听从人们的指挥，那不能算是真正的物联网，只能算是“控制网”。理想的目标是，物联网设备应该具备自我学习能力，能够通过积累过往的经验或数据，能够对未来进行预判，为人们提供更加智能的服务。这种“机器学习”的能力，我们认为应该属于物联网操作系统的一部分，应该能够抽象成一些基本的服务或API，内置到内核中，供应用开发者或者设备开发者调用。
而且，这种机器学习的服务，不仅仅只是位于终端操作系统中的一段代码，还应该有一个庞大的后台进行支撑。大量的计算和预测功能，在后台上执行。而终端上只是做一些简单计算和结果的执行。这样终端加后台软件，就形成一个分布式的计算网格，有效分工，协同计算，有序执行，形成一个支撑物联网的数字神经。
物联网操作系统是支撑物联网大规模发展的最核心软件。根据上面总结的物联网的主要特征，结合操作系统的主要功能和分层结构，我们总结出如下的物联网操作系统整体架构：
总体来说，物联网操作系统是由操作系统内核，外围功能组件，物联网协同框架，通用智能引擎，集成开发环境等几个大的子系统组成。这些子系统之间相互配合，共同组成一个完整的面向各种各样物联网应用场景的软件基础平台。需要说明的是，这些子系统之间有一定的层次依赖关系，比如外围功能组件需要依赖于物联网操作系统内核，物联网协同框架需要依赖于外围功能组件，而公共智能引擎，需要依赖于下层的内核，外围功能组件，甚至是物联网协同框架等。在这个架构图中，也反映了这种层次化的依赖关系。
目前主流的物联网操作系统，比如Google的Brillo，Linux开放基金会的Ostro项目，以及HelloX项目，都遵循这样一种框架。下面对这几个子系统做简要介绍。
内核是任何操作系统都有的核心组件，操作系统的核心功能和核心机制，都是在内核中实现的。比如最核心的线程/任务管理，内存管理，内核安全和同步等机制。虽然从功能上说，大部分操作系统的内核都相差不大，但是在这些具体功能的实现上，面向不同领域的操作系统，其实现目标和实现技术都是不同的。
比如对传统的通用个人计算机操作系统来说，内核更加关注用户交互的响应时间，资源的充分利用，不同应用程序之间的隔离和安全等。这是与其应用场景有关的。而对于面向嵌入式领域的嵌入式操作系统，则更加关注对中断的响应时间，更加关注线程或任务的调度算法，以使得整个系统能够在可预知的时间内，完成对外部事件的响应。
而物联网操作系统的内核，又有不同于其它操作系统的特点。最主要的是其伸缩性。物联网操作系统的内核应该能够适应各种配置的硬件环境，从小到几十K内存的低端嵌入式应用，到高达几十M内存的复杂应用领域，物联网操作系统内核都应该可以适应。同时，物联网操作系统的内核应该足够节能，确保在一些能源受限的应用下，能够持续足够长的时间。比如，内核可以提供硬件休眠机制，包括CPU本身的休眠，以便在物联网设备没有任务处理的时候，能够持续处于休眠状态。在需要处理外部事件时，又能够快速的唤醒。
物联网操作系统的内核也应该具备嵌入式操作系统的一些特征，比如可预知可计算的外部事件响应时间，可预知的中断响应时间，对多种多样的外部硬件的控制和管理机制等。当然，物联网操作系统内核必须足够可靠和安全，以满足物联网对安全性的需求。
从功能上说，与其它操作系统基本类似，主要包括任务管理，内存管理，中断管理，内核同步，安全与权限管理，应用管理等。为了确保内核的正常运行，内核也应提供内核统计与监控功能，即监视内核的运行状态，监视内核对象的数量/状态等，为维护或开发人员提供故障定位的工具。在每一个内核子模块中，都会通过更加具体的机制或者算法，来满足物联网应用的需求。同时确保内核的整体安全性和可靠性。
内核也是直接与物理设备打交道的软件，所有对物理设备的管理，包括物理设备检测，物理设备驱动程序加载和卸载等等功能，也都是在内核中实现的。为了有效的管理物理设备，内核需要定义一套标准的设备管理框架，设备驱动程序需要遵循这一套框架，才能纳入内核的管理。为了访问多种多样的物理设备，内核同时也会定义一套叫做硬件抽象层的软件，这本质上是对一些常用硬件操作的抽象，比如读写设备配置空间，有的CPU是通过I/O接口来访问设备空间的，有的则是把设备配置空间直接映射到内存空间，通过常规内存访问来读取设备配置空间。为了适应这种不同的情况，内核一般会定义一个叫做__device_read和__device_write的宏，根据设备类型的不同，这些宏定义的实现代码会不同，但是对操作系统内核和设备驱动程序来说，只需要调用这两个一致的宏，即可对设备配置空间进行访问。这就是一个典型的硬件抽象层的例子。
除此之外，物联网操作系统的内核还提供面向物联网应用的常用连接功能，比如对蓝牙的支持，对Zigbee的支持，对WiFi的支持，等等。各类领域应用可以直接利用物联网操作系统内核的这些连接功能，实现最基本的通信需求。
下图示意了内核的更进一步的功能结构：
物联网操作系统内核只是提供最基本的操作系统功能，供物联网应用程序调用。但只有物联网操作系统内核是远远不够的，在很多情况下，还需要很多其它功能模块的支持，比如文件系统，TCP/IP网络协议栈，数据库等。我们把这些功能组件从物联网操作系统内核中独立出来，组成一个独立的功能系统，称为“外围功能组件”。
之所以把这些功能组件称为“外围”，是因为在很多情况下，这些功能组件都不是必须的。而且在实际的物联网应用中，这些外围组件也不会全部被用到，大部分情况下用到一到两个就可以满足需求了，其它的功能组件必须裁剪掉。因为在物联网应用中，很多情况下的系统硬件资源非常有限，如果保留没有用到的功能组件，会浪费掉很多资源。同时，保留一些用不到的组件，会对整个系统带来安全隐患。比如，如果物联网应用不需要联网，却保留了TCP/IP协议栈功能，则TCP/IP协议栈的BUG或漏洞，可能会被利用，从而对系统造成安全影响。这些外围功能组件都是针对物联网操作系统进行定制和开发的，与物联网操作系统内核之间的接口非常清晰，具备高度的可裁剪性。
但通用操作系统中，这些外围组件的处理方式却与物联网操作系统不同，这些组件会被统一归类到内核中，随内核一起分发，作为一个整体提供给用户。即使应用程序不用这些组件，也不能把这些组件裁剪掉。之所以这样做，是因为通用操作系统的资源相对丰富，多保留一些功能模块对整体系统的影响并不大。同时，通用操作系统的安全性要求相对较低。
物联网操作系统内核和外围功能组件结合起来，可以解决物联网的“连接”需求。这包括内核提供的基本物联网本地连接（蓝牙，Zigbee，NFC，RFID等），以及外围功能组件中的TCP/IP协议栈等提供的复杂网络连接。
除TCP/IP网络协议栈外，常见的外围组件还包括文件系统，图形用户界面（GUI），安全传输协议，脚本语言执行引擎（比如JavaScript语言的执行引擎等），基于TCP/IP协议的安全传输协议（SSL/SSH等），C运行库，在线更新机制（软件升级/在线更新补丁）等。需要说明的是，TCP/IP协议栈是面向互联网设计的通信协议栈，由于物联网本身特征与互联网有很大差异，TCP/IP协议栈在应用到物联网的时候，面临许多问题和挑战，需要对TCP/IP协议栈做一番优化改造。我们把改造之后的TCP/IP协议栈，称为“面向物联网的TCP/IP协议”，简写为“TCP/IP@IoT”。下图示意了常见的物联网操作系统外围功能组件：
物联网协同框架是实现物联网“协同”功能性需求的关键功能系统。物联网操作系统的内核和外围功能组件，仅仅实现了物联网设备之间的“连接”功能。但是我们知道，仅仅实现物联网设备的连接上网，是远远不够的。物联网的精髓在于，物联网设备之间能够相互交互和协同，使得物联网设备能够“充分合作”，相互协调一致，以达到单一物联网设备无法完成的功能。而物联网协同框架，就是为物联网设备之间的协同提供了技术基础。
一般情况下，物联网协同框架是一组软件的集合，由许多个功能相互独立，但是又相互依赖的软件模块组成。比如，Google的Weave物联网协同框架，是由云平台组件Weave Cloud，面向设备端的LibWeave，以及面向智能手机客户端的Weave Client等组件组成。Weave Cloud是整个框架的“中心管理器”，所有基于Weave的物联网设备，首先都连接到Weave Cloud上，接受Weave Cloud下发的指令，并向Weave Cloud上报相关数据。Weave Client则也需通过Weave Cloud来管理和控制基于Weave的物联网设备，等等。
一般来说，物联网协同框架至少包括如下功能：
物联网设备发现机制。物联网设备一般不提供直接的用户交互界面，需要通过诸如智能手机，电脑等方式，连接到设备上，对设备进行管理和配置。在物联网设备第一次加电并联网之后，智能手机/电脑等如何快速准确的找到这个物联网设备，就是物联网设备发现机制要解决的问题。尤其是在物联网设备数量众多，功能多样的情况下，如何准确快速的发现和连接到物联网设备上，是一个很大的挑战。设备发现机制的另外一个应用场景，是设备与设备之间的直接交互。比如在同一个局域网内的物联网设备，可以相互发现并建立关联，在必要的时候能够直接通信，相互协作，实现物联网设备之间的“协同”；
物联网设备的初始化与配置管理，包括设备在第一次使用时的初始化配置，设备的认证和鉴权，设备的状态管理等等；
物联网设备之间的协同交互。这包括物联网设备之间的直接通信机制。物联网协同框架要能够提供一套标准或规范，使得建立关联关系的物联网设备之间，能够直接通信，不需要经过后台服务器；
云端服务。大部分情况下，物联网服务需要云端（即物联网后台）的支持。物联网设备要连接到云端平台上，进行认证和注册。物联网设备在运行期获取的数据，也需要传送到云端平台上进行存储。如果用户与物联网设备距离很远，无法直接连接，则用户也需要经过云端平台，来简介控制或操作物联网设备，等等。物联网协同框架至少要定义并实现一套标准的协议，来支撑这些操作。
除此之外，物联网协同框架还必须实现一些基本的服务，来支撑上述功能。比如，物联网协同框架需要定义一套标准的物联网设备命名体系，以能够准确唯一的标识每一台物联网设备。物联网设备之间，以及用户与物联网设备之间，在相互操作之前，还必须要完成认证和鉴权，以确保物联网的安全，等等。另外一个基础服务，就是标准的物联网操作模式。比如在智能家电应用中，用户可以通过一个标准的Open命令，来远程打开空调。通过一个Adjust命令，来调节空调的温度。这些标准的命令必须由物联网协同框架进行定义，才能实现不同厂商，不同类型设备之间的互操作。如果没有这些标准的操作模式（操作命令），那么要打开A厂商的空调，是Open命令，要打开B厂商的空调，则可能是Turn On命令，这样就无法实现相互操作了。
上述协同功能和基本服务，都是建立在网络通信基础之上的，协同框架还必须实现或者选择一种合适的网络通信协议。物联网的特征，要求这种通信协议尽可能的低功耗和高效率。一些常用的标准协议，比如CoAP或者MQTT，可以承担这个功能。大部分物联网协同框架，比如IoTivity，就是基于CoAP协议的。
下图示意了物联网协同框架的主要组成：
下面通过一个智慧商场的例子，进一步说明物联网协同框架的作用。智慧商场解决方案中，一般都会包括火警探测器与智慧门禁系统。这两类物联网设备在被安装在商场之前，必须经过安全的初始配置，以确保不会被恶意控制。初始配置完成之后，这两类设备会连接到统一的协同框架云端系统，并实时更新其状态。与此同时，火警探测器也会通过物联网协同框架的设备发现机制，与门禁系统建立联系，并相互知道自己的存在。一旦火警探测器探测到火警发生，则会直接告诉门禁系统打开门禁，以便方便人们尽快逃生。这种情况下，如果没有物联网设备之间的直接通信功能，所有的通信都需要经过后台系统转接，那么不但响应时间会增加，更致命的是，一旦与后台之间的物理网络中断，则终端之间将无法实现自动联动。这种网络故障，在诸如火警等灾难发生时，是最常见的。
为支撑上述机制的有效运行，物联网协同框架还必须提供一致的通信协议和通信技术，物联网设备只要遵循这套协议，就能够相互识别对方的消息。同时，物联网协同框架还必须提供一套唯一的命名规范，确保任何一个物联网终端设备，都能获取到唯一的名字，其它设备能够通过这个唯一的名字与之交互。同时，这套唯一的命名规范，最好能够把物联网终端设备的功能，也体现出来。这样物联网设备之间通过设备名字，就可以确定其提供的功能，从而做出有针对性的动作。比如上述例子，火警探测器可以命名为“Fire alert detector”，而门禁系统可以命名为“Entrance access control”，这样这两者可以通过名字，就知道对方的功能角色。当然，这只是个例子，在实际的命名系统中，还是应该有一套计算机能够识别的编码体系。
目前物联网行业内的一些协同框架，基本都是与物联网操作系统内核独立的，即这些协同框架可以被应用在基于任何操作系统的物联网解决方案中，只要这些操作系统能够提供必要的接口即可。但采取这种方式，显然有其明显的弊端。那就是无法采用一套统一的代码，来适应所有的操作系统。比如Google的Waeve，针对Linux和Android等复杂的操作系统，采用C++语言开发了LibWeave组件。而针对资源受限的嵌入式应用场景，则又采用C语言开发了uWeave。这样对物联网设备的开发者来说，就不得不掌握两套完全迥异的API，了解两套机理完全不同的物联网协同框架，显然无法降低成本。
理想的实现方式是，物联网协同框架能够与物联网操作系统内核紧密绑定，只提供一套API给开发者。通过物联网操作系统内核本身的伸缩机制，来适应不同的应用场景。比如在没有WiFi支持的嵌入式场景，物联网操作系统内核会裁剪掉TCP/IP等组件，而采用低功耗蓝牙技术实现数据通信。而如果目标硬件配置了WiFi或者Ethernet等网络接口设备，则会保留TCP/IP协议栈。不论是哪种形态，物联网操作系统内核都会提供统一的一套API，给物联网协同框架使用，即底层的通信机制，对物联网协同框架是透明的。基于这样的设计原则，类似Google Weave这样的物联网协同框架就无需针对不同的目标硬件设计多套解决方案了，而只需要一套就可解决问题。
通过物联网协同框架，可以使得物联网设备之间建立关联，充分协作，完成单一物联网设备无法完成的功能。但是这种协同的功能，还是局限于事先定义好的逻辑上。比如上述智慧商场中火警探测器和门禁系统的例子，必须在领域应用中编写代码，告诉火警探测器，一旦发生火警，则告诉门禁系统打开门禁。如果没有这样的程序逻辑，火警探测系统是不会通知门禁系统的。
如果希望物联网系统超出预定义的范围，能够达到一种自学习的程度，比如最开始火警探测器并不知道在发生火警时通知门禁系统，而是随着运行时间的增加，逐渐的“学习”到这种能力。这样只有物联网协同框架就无法做到了，必须引入智能引擎的支持。
物联网智能引擎，就是指包含了诸如语音与语义识别，机器学习等等功能模块，以使得物联网能够超出“事先定义好”的活动规则，能够具备像人一样具备“智慧”的能力。在物联网智能引擎内的功能模块，都是基础能力，可以供各种物联网应用所调用。比较典型的例子就是，在物联网设备中加入语音识别功能，人们通过自然语言，与物联网设备直接对话，来达到下达指令的目的。
另外一个公共智能引擎中的重要模块，是DSL语言与其对应的处理引擎。DSL(DomainSpecific Language，领域特定语言)是针对某一种特定的应用领域开发的编程或操作语言，专门应用于一个相对独立的领域。这与计算机编程语言不一样，计算机编程语言大部分都比较通用，可以为多种应用领域编写程序。正是因为它的通用性，无法照顾到某一个具体的领域，因此采用通用计算机语言来实现某一个具体领域的应用时，就非常麻烦，需要专业的程序员，经过复杂的编程工作。而DSL语言，则是针对某一个很细的功能领域开发，专门应用于这个特定的领域。这样就可以针对这个特定的领域建立一些内置对象，定义领域特定的动作，并根据领域的习惯，定义领域特有语法。采用DSL语言来编写领域应用，就非常简单。
现在有很多软件工具，可以用于定义DSL，并提供执行解释引擎。物联网操作系统的公共智能引擎模块中，也应该提供DSL语言开发及解释的功能，以方便物联网特定场景的调用。
集成开发环境是任何一个完备的操作系统所必需提供的功能组件，程序员通过集成开发环境的辅助，完成具体应用的开发，这些应用最终运行在目标操作系统上。比如针对Linux操作系统的GCC开发工具套件，面向Windows操作系统的Microsoft Visual Studio集成开发环境，以及跨平台的Eclipse集成开发环境，等等。
开发环境是丰富壮大操作系统生态圈的最核心组件，同时也是形成“二级开发模式”的基础。所谓二级开发模式，指的是包含操作系统平台本身功能开发的第一级开发，以及基于操作系统平台，进行应用程序开发或操作系统内核定制的二次开发。其中第一级开发，是由操作系统厂商或者开源社区完成。而第二级的二次开发，则是由具体的应用厂商开发完成。这两个层次的开发，所用的工具是不同的。在第一级开发中，一般采用系统级的开发工具，大部分都是命令行模式，采用的开发语言，也是以C/C++，甚至汇编语言为主。而第二级开发的时候，操作系统基础架构已构筑起来，对应的编程开发环境也已经完善，因此大部分是采用图形化的开发环境。相对来说，第二级开发所需要的系统级的开发技能也相对较低。注意，这里说的是“系统级”的开发技能，主要是指对计算机CPU和硬件，操作系统内核等的理解和技能，并不是说面向应用的开发技能。实际上，不论是哪个层级的开发，只要深入进去，真正解决问题了，都不会太简单。
物联网领域也是如此。在物联网操作系统本身的开发中，会采用不同的相对专业的开发工具。在操作系统发布之后，也要提供一套完整的开发工具，方便物联网领域的程序员开发物联网应用。
一般的集成开发环境是由一系列工具组合而成的，即使是Microsoft的Visual Studio集成开发环境，虽然开起来是一个类似Office Word一样的独立应用程序，程序员可以在其中完成程序的编写，编译，调试，运行，发布等等全软件声明周期的所有活动，但是它也是由若干个独立工具组合在一起形成的集成软件工作台，比如编译工具，连接工具，调试工具，软件代码一致性检查工具等等。
面向物联网操作系统的集成开发环境也不例外，它是由一系列相互独立但又相互依赖的独立工具组成的。最基本也是最核心的部分，是开发语言。目前来说，是没有一套专门面向物联网应用开发的语言的，这不利于推动物联网的大发展，因此，必须要选择一种适合物联网特点的开发语言。根据物联网本身的特征，适合物联网应用开发的语言，必须具备下列特征：
开发语言必须是能够跨硬件平台的。跨硬件平台的好处是，针对某一类功能相同或类似的物联网设备编写的应用程序，可以在这一类物联网设备上通用，而不管这类设备是不是同一个厂家的。比如针对智能摄像头而言，A厂商的摄像头个的配置，可能是ARM的CPU，USB接口，分辨率是1024*768等，而B厂商的摄像头可能是基于x86的CPU，SPI接口。基于摄像头编写一个人脸识别程序，如果采用跨平台的编程语言，则针对A厂商设备编写的应用程序，可以直接在B厂家的设备上使用。但是如果编程语言不是跨硬件平台的，比如C/C++语言，则针对A厂家的摄像头编写的应用程序，必须经过重新编译（甚至还需要大量的修改）之后，才能在B厂家的摄像头上运行。物联网设备的碎片化特征，决定了开发语言必须是跨硬件平台的；
开发语言最好是面向对象的开发语言。面向对象编程方法，可以让程序员以更接近实际世界的方式来理解应用场景，建立程序开发模型，同时也可以大大加快开发速度。对于大型的软件，面向对象思想可以简化开发维护过程，降低开发成本。在物联网领域，面向对象编程思想更有价值。因为我们面对的是一个一个的“物”，每个物体都可以抽象为程序开发领域的一个对象，通过不同对象（物）之间的消息交互，可以快速完成复杂应用系统的开发。要支持面向对象的编程思想，面向对象的编程语言是必须的；
开发语言最好能支持完善的“事件驱动”机制。与以人为中心的传统软件开发模式不同，物联网时代的软件，都是受“事件”驱动的。面向物联网的程序，大多数情况下处理的是一个一个的外部事件，根据外部事件做出响应。比如一个火警探测设备，会针对“探测到起火”等异步事件，做出对应的动作。物联网软件开发，很多情况下就是编写一个一个的时间处理程序，并与事先定义好的事件关联在一起。这样一旦外部事件发生，则处理程序就会被调用。这种以“事件”为中心的物联网编程方法，必须配以能够支持完善事件驱动机制的开发语言。
分析目前常见的开发语言，我们认为JavaScript语言是最合适的。更详细的分析过程，在后面部分中会详细描述。
除了编程语言之外，另外一个集成开发环境的核心部件，是“物联网运行库”（物联网Runtime）。任何一种开发语言，都有一个与之对应的运行库，比如针对C语言的libc，针对Java语言的J2SE/J2EE/J2ME等等配套库。这些运行库提供了开发过程中最常用的功能或函数，比如字符串操作，数字操作，I/O，数据库访问，等等。物联网开发领域也一样，必须有一套物联网运行库，来提供最常见的物联网开发功能支持。下列与物联网应用开发相关的功能，应该在物联网运行库中实现：
支持物联网应用开发的最基本操作，比如字符串操作，文件I/O，网络功能，任务管理，内存管理，数据库访问等；
常见传感器的访问接口，比如针对温度，湿度，重力，加速度，光照等等常见传感器设计一套标准的访问接口，然后把这一套访问接口，作为物联网运行库的一部分进行实现。对应用程序来说，只需要调用这些接口即可访问对应的传感器，而不用关心传感器的物理参数（厂商，接口类型，等等）；
支撑物联网软件开发的基本编程机制，比如事件驱动机制的框架，面向对象机制的对象管理，等等。这些基本的机制，也需要在物联网运行库中实现，应用程序直接调用即可；
公共安全服务。比如用户或设备认证，访问鉴权，数据通信加密/解密等。这些基本的安全服务，在几乎每个物联网应用场景中都会涉及到，因此作为公共服务，纳入物联网运行库中进行实现；
物联网协同框架提供的基本服务，也可以纳入到物联网运行库中，暴露给应用程序。比如IoTivity协同框架的API，CoAP协议的API，都可以作为物联网运行库的一部分功能来实现；
其它与具体领域相关的公共服务，比如物联网后台连接服务等，都可以作为领域特定物联网运行库的一部分来实现。
物联网运行库必须与物联网开发语言强相关，且物联网运行库的大部分代码，都是由物联网开发语言实现的。如果以JavaScript作为物联网开发语言，那么与之对应的物联网运行库，大部分会以JavaScript语言实现。物联网运行库有两种存在方式，一种是作为集成开发环境的一部分，在代码编译链接阶段，编译连接器从物联网运行库中选择与应用程序有关的代码片段，与应用程序编译在一起，形成一个可运行的程序包。这种模式下，不需要加载全部物联网运行库，而只需要加载应用程序需要的一部分即可。另外一种存在方式，是在物联网操作系统的内核中。这种情况下，物联网应用程序与物联网运行库是独立存在的，物联网应用程序在运行时，操作系统会根据需要，临时加载物联网运行库（或其中的一部分相关内容），支持物联网应用程序的运行。
除此物联网编程语言和物联网运行库之外，物联网集成开发环境还包括代码编辑工具，编译工具，连接工具，调试工具等等，这是任何一个软件开发环境都需要具备的。需要注意的是，JavaScript语言是解释型语言，即代码可以被语言解释器直接加载并分析运行，不需要事先编译和链接。在这种情况下，就不需要编译链接等工具。但是调试工具是必须的。
物联网应用开发语言，物联网运行库，以及对应的编辑，编译，连接，调试等工具，组成了物联网开发环境的核心部分。除此之外，为了方便开发，分享，交流的目的，一个完善的开发社区，也是必须的。开发者可以在这个社区上共享代码，讨论技术问题等。更重要的是，物联网集成开发环境可以与开发社区紧密结合，可以把成功的代码或有价值的模块，发布到社区中。物联网开发环境可以直接根据程序员的需要，从社区中下载代码，并纳入到项目中。
领域应用是面向不同物联网领域，通过综合利用物联网操作系统的各层功能模块，借助物联网操作系统集成开发环境，开发出来的可以完成一项或多项具体功能的应用程序。应用领域可以根据需要，调用一个或全部物联网操作系统的功能。比如，如果是实现一个提供简单网络连接的实时温度计应用，则只需要利用物联网操作系统的内核和TCP/IP协议栈等外围组件即可。但如果这个温度计应用在智慧农业解决方案中，根据不同的温度，来实时调节通风系统，则必须要集成物联网系统框架，以使得温度计与通风系统能够建立联系并有效协同。更进一步，如果希望温度计具备某些“智慧”的功能，比如能够识别人们的语音指令，能够根据周围环境的温度和湿度等信息，判断出是否下雨，并采取适当动作等，则必须要有公共智能引擎的支持。
总之，领域应用是物联网操作系统的直接服务目标，它利用物联网操作系统这个基础软件平台，并根据具体领域的特征，来完成某项具体的功能。由于领域应用是与特定领域强相关的，不属于公共的平台软件，因此我们不把它作为物联网操作系统的组成部分。但是为了说明领域应用与物联网操作系统的关系，也一起把它体现在了物联网操作系统的架构图中。
综合上面的说明，可以把物联网操作系统的框架做进一步细化，如下图所示：
前面讲到，物联网的三个主要特征分别是连接，协同和智能。物联网的这个整体框架，是与这三个特征分别对应的，如下图所示：
如果物联网应用只希望实现基本的连接功能，那么只要保留物联网操作系统的内核，以及一两个基本的外围组件，比如TCP/IP协议栈，就足够了。
如果物联网应用需要实现协同功能，则必须包含物联网协同框架这个功能模块。通过引入物联网协同框架，可以实现包括物联网应用终端设备之间的交互和协同，物联网设备与物联网运平台之间的交互和协同，甚至包括物联网终端设备与智能手机之间的协同等功能。
如果仅仅提供连接和协同，并不能满足物联网的应用需求，那么物联网的领域应用可以把物联网操作系统的智能引擎利用起来。一个典型的场景就是，用户可以通过语音控制物联网设备，可以与物联网设备进行对话。物联网系统可以通过学习，来理解用户的行为，并对用户的行为进行预测和反馈。
可以看出，物联网操作系统完整的解决了物联网的三个功能性需求。
最后需要说明的是，虽然我们把物联网操作系统分为了内核，外围组件等四个层次，但是这些层次之间，并不是严格的泾渭分明，而是具备一些依赖关系的。比如外围功能组件要依赖物联网操作系统内核机制，而协同框架又依赖于某些外围功能组件。同时，公共智能引擎也需要依赖于内核，外围组件等来作为基础支撑。这些不同的功能层次之间，通过预先定义好的接口，既能够水乳交融的集成在一起，形成完成的解决方案，又可以根据应用场景的需求，只保留其中的一个或几个部分，而仍然可以整齐划一。同时，集成开发环境提供统一的API，使整个系统表现出一致的风格。
下面列举几个比较典型的物联网操作系统，来进一步说明物联网操作系统的功能和架构。首先看一下业界比较有影响力的Brillo操作系统，这是Google发布的专门面向物联网应用的操作系统。Brillo的架构如下：
可见，Brillo与Android一样，仍然使用Linux内核作为其操作系统内核。这样Linux在物联网领域应用的一些弊端，就被完整的继承到了Brillo中。比如，Linux内核对运行内存的要求较高，同时Linux还需要CPU硬件支持MMU(内存管理单元)功能，等等。这样就间接导致Brillo的运行内存要求较高，按照官方说法，要至少32M内存。同时要求CPU支持MMU功能。这样大量的低端CPU或MCU，比如STM32系列，就无法运行Brillo，因为这些CPU的片上内存一般不超过1M，同时一般不提供MMU功能。由于这些原因，大大限制了Brillo的应用范围。
在Linux内核之上，Brillo保留了Android操作系统里面的一个硬件访问层(HAL，Hardware Access Layer)。这个层次的主要功能，就是对底层的硬件进行统一的抽象，以更加友好一致的方式，提供给应用程序访问。从功能上说，这一层软件并无明显的价值，但是其简化了对硬件的操作，给程序开发带来较大的便利。按照一般的软件分层规则，这一层软件应该还是属于操作系统内核的一部分，因为它并没有提供额外的附加功能，在代码量上，与内核相比，也非常少，在某些情况下甚至可以忽略掉。因此，在展示上，应该与操作系统内核放在一起。但是Google为了区分这一层软件是来源于Android系统，而不是Linux，因此把它单独列出来了。
再往上，就是支撑操作系统运行的一些辅助功能组件了。主要有在线更新（OTA Updates），安全相关的一些组件和机制，以及在线数据分析和性能测量等。在线更新机制，可以使运行Brillo操作系统的物联网设备，在运行过程中就可以更新软件，而不用中断运行。这个特性是非常有价值的，Brillo是一个复杂的系统，其版本更迭和补丁发布必定非常频繁。如果不提供在线更新功能，没发布一个新的版本和补丁，都需要现场更新物联网设备，显然是不可操作的。因此Google设计了这个特性来支撑在线实时软件更新功能。只要与Brillo的后台服务器连接上，Brillo会自动检查更新，并安排更新，而不会影响设备的正常运行。而安全机制则提供了设备认证，数据加密等功能，这是任何网络流解决方案必须要提供的机制，在后面部分会详细介绍。而在线性能统计和分析功能，则可以帮助用户实时查看和分析设备状态，性能，消息数量等数据，为设备维护人员提供一个基础的管理平台。开发者可以根据需要，选择启用或关闭这些外围辅助功能。
再上面，就是Weave框架了。Brillo操作系统内嵌了对Weave的支持，把Weave作为支撑物联网应用的主要功能模块。但是具有讽刺意味的是，Weave并没有把Brillo作为唯一的底层操作系统，反而一直强调“跨平台，可移植”等特性。可见，在Google内部，Weave要更强势一些，Brillo的定位或者价值，仍然存疑。
从架构上看，Brillo是完全符合我们前面提到的物联网操作系统参考架构的。比如Linux内核和Android HAL组合到一起，就对应物联网操作系统内核这一层。在线升级，安全机制，性能测量和数据分析等这些辅助功能组件，对应于外围功能组件这一层。Weave则对应于物联网协同框架这一层。如下图所示：
需要说明的是，在Google提供的官方架构图中，Weave模块是与OTAUpdates等外围辅助模块位于同一个层次的。这样无法反映出Weave和Brillo之间的关系。Weave是依赖于Brillo操作系统而运行的，Weave又不属于Brillo操作系统的范畴。因此正确的表示方法应该是把Weave放在Brillo上面，既体现了依赖逻辑，又体现了这两者相互独立的关系。不论哪种处理方式，都不会带来理解上的偏差。
Ostro项目是由Intel主导创建的一个开源物联网操作系统项目，它的目的是开发一个针对物联网应用的专门操作系统，这个操作系统的名字也叫做Ostro。它是基于Linux内核进行裁剪，并针对物联网领域的智能设备进行定制，专门应用于物联网的操作系统。
它可以被安装在USB存储杆或者SD卡上，可以直接启动物联网硬件设备。当然，物联网应用开发者也可以根据自己的需要，对Ostro进行二次裁剪，自定义一个符合自身应用场景的全新内核。这个特征完全符合物联网操作系统的要求。
它所宣称的最主要特征，包括可裁剪，安全，丰富的开发环境，以及面向物联网的丰富组件和服务支持等。主要特点如下：
基于Linux操作系统进行裁剪，专门用于IoT领域；
支持Intel的Quark和Intel Atom处理器；
支持Node.JS，Python，Java和C/C++等语言进行应用程序开发；
程序员可通过RestFUL API，对设备状态进行查询。支持符合OCF标准的设备发现机制；
支持符合OCF标准的JavaScript API；
安全特性，比如可信启动，应用程序内存隔离，权限管理，OS镜像完整性验证等机制；
丰富的通信技术支持，包括Bluetooth*/BLE, WiFi, 6LowPAN, 以及CAN bus等；
支持VirtualBox虚拟机；
可以基于Yocto工具链进行编译开发和裁剪。
下图示意了Ostro物联网操作系统的整体架构：
下面按照从上往下的顺序，对Ostro的各个层次做简要介绍。
IoT应用程序：这个层次包含了所有使用Ostro编程接口所开发的物联网应用程序。当前的Ostro版本并没有开发任何特定的应用程序实例，仅仅提供了如何开发应用程序的指导以及一些简单的代码片段。随着Ostro的发展，或许会有针对特定典型场景的物联网应用程序，比如智慧家庭应用程序，被纳入到这个层次中发布。
编程接口：编程接口是Ostro提供给应用程序开发者使用的，用于开发各种各样的物联网应用程序。当前来说，Ostro提供了多种多样的编程接口供程序员根据自己的喜好和特定应用场景调用。主要有：
Java和Python编程接口，物联网应用程序开发者可以采用Python和Java语言，开发特定的应用程序。Ostro提供了常用的支持类库；
Node.JS编程接口。Ostro提供了Node.JS的运行期支持，以及特定的一些JavaScript API(以Node.JS模块方式提供)。这些Java Script API涵盖了相对广泛的物联网应用场景，比如包含了开放连接基金会（OCF）定义的API接口。这样就非常便于物联网应用程序开发者直接使用这些API，调用IoTivity等协同框架的功能；
Soletta编程接口。Soletta是一个开源的物联网应用程序开发框架，它提供了一些常用的物联网应用开发库，便于程序员方便快速的开发物联网应用程序。Soletta是一种编程框架，可以采用传统的C语言进行应用程序开发，也可以采用一种叫做“基于流的编程语言”（Flow-based Programming）来进行物联网应用的开发。
总之，Ostra提供了相对丰富的变成框架，供应用开发者选择。
物联网协同框架：Ostro内置了对IoTivity的支持。IoTivity 是一个开源的软件框架，用于无缝的支持设备到设备的互联，以及人与设备的简便互联。其主要是为了满足物联网开发的需要，构建物联网的生态系统，使得设备和设备之间可以安全可靠的连接。而
IoTivity 通过提供一系列框架和服务来加速设备的互联应用开发。该项目由 Open Interconnect Consortium (OIC) 组织赞助，相当于是 OIC 标准的一个参考实现。在本书的第二部分中，有详细的描述。
Ostro服务：Ostro服务主要是指系统级的一些进程或线程，这些进程或线程负责管理网络连接，加载必要的支撑服务，以及提供进程间通信（IPC）支持等。在Ostro操作系统中，保留了大部分Linux操作系统所支持的systemd，D-Bus等。
除此之外，在线软件更新也是Ostro提供的基本服务之一。这是专门为物联网应用所提供的一个基本服务，可以快速的完成物联网设备的软件更新，而且只需要最小的软件下载量，只需要重新启动必要的物联网设备即可，而不需要重新启动所有的物联网设备。
在线软件更新是确保物联网可管理可维护的核心机制，通过物联网操作系统与后端云平台的协同，使得物联网设备的软件始终保持在最新和最安全的状态。
Ostro基本库：Ostro基本库包括随Linux内核一起发行的最基本运行库，比如最常用的C运行库等。当然，Ostro可以根据需要，动态的扩展基本库的范围。
Linux内核：Ostro的内核就是通用的Linux内核，它包括了最基本的驱动程序支持，硬件适配支持，网络支持，文件系统以及设备管理机制等。为了适应物联网的应用，Ostro对Linux内核做了一些微调，使得内核可以支持更多的传感器（Sensor），能够支持更多的连接类型，比如蓝牙/WiFi/Zigbee等等。
但是由于Linux内核本身的复杂性和不可分割性，使得Ostro物联网操作系统很难具备物联网操作系统所应该具备的高度伸缩性要求。
从上面的分析中可以看出，Ostro物联网操作系统与我们定义的物联网操作系统分层模型基本上是对应的，下图示意了这种对应关系：
HelloX是由国内操作系统爱好者开发的完全开源物联网操作系统，下图示意了HelloX的整体架构：
从整体结构上可以看出，HelloX操作系统也符合物联网操作系统的分层结构。最下方是驱动程序层，实现了大多数常见硬件的驱动支持，包括USB，以太网，SPI/UART等等。严格来说，驱动程序层应该属于内核的一部分。在HelloX的实现中，为了突出HelloX丰富的驱动支持的特点，把驱动程序单独拿出来，作为一个层次展示。
在驱动层之上，是内核层。内存管理，任务调度等机制，都是在内核中实现的。与其它物联网操作系统基于Linux内核定制的思路不同，HelloX的内核是根据物联网的特征，完全全新开发的。内核中各模块之间是松耦合的，可以根据需要，灵活的裁剪或者增加任何内核模块，这样就确保了内核的可伸缩性，能够满足多种多样的碎片化硬件需求。也可以根据需要，替换内核中的缺省模块或者算法，比如可以采用自定义的任务调度算法，替换内核中缺省的基于优先级轮询的调度算法。也可以采用更加实时的内存分配算法（比如固定尺寸链表法），来替换内核中缺省的空闲链表内存分配算法，等等。对于MMU的支持，HelloX也是作为可选模块来实现，裁剪掉MMU功能，不会对系统中的其它模块产生任何功能上的影响（但是内存保护，虚拟内存等机制就不能用了）。
在内核层之上，是外围组件层。HelloX提供了包括网络，文件系统，系统调用等在内的多种多样的外围组件，供物联网应用程序开发调用。
目前的HelloX，移植IoTivity物联网协同框架，作为自己的协同框架。未来根据需要，HelloX会开发更加灵活的物联网协同框架，与HelloX捆绑使用。
基于这些基本组件和功能，可以基于HelloX操作系统实现广泛的物联网应用，比如家庭网关，智能摄像头，智慧家庭中的家电设备，抄表，e-Health等。目前HelloX已经实现了同多个物联网云平台的对接和集成。
注：本文为交流目的，希望同业界同仁深入交流物联网操作系统的概念，功能，架构等内容，以更好的推进和优化HelloX物联网操作系统的开发。如转载请注明出处和作者。
如有问题，欢迎联系交流：
微信/QQ：89007638
QQ群：38467832
标签：
原文地址：http://blog.csdn.net/hellochina15/article/details/52838600
