物联网的出现，推动了集成电路产业、传感器产业、自动化产业、计算机软件产业、移动网络产业的发展，冠以“智慧”之词的行业层出不穷，如智慧交通、智慧电网、智慧医疗、智慧校园、智慧工厂、智慧城市等。物联网操作系统更是百花齐放，物联网工程的复杂性、广覆盖性，意味着物联网操作系统具有多样性。统一的、普适的物联网操作系统是技术“小白”的梦想，是垄断厂商追求的目标。
概述
物联网操作系统有不同于其他操作系统的特点，最主要的是其伸缩性。物联网操作系统的内核应该能够适应各种配置的硬件环境，从小到几十KB内存的低端嵌入式应用，到高达几十MB内存的复杂应用领域，物联网操作系统内核都应该可以适应。同时，物联网操作系统的内核应该足够节能，确保在一些能源受限的应用下，能够持续足够长的时间。比如，内核可以提供硬件休眠机制，包括CPU本身的休眠，以便在物联网设备没有任务处理的时候能够持续处于休眠状态。在需要处理外部事件时，又能够快速地唤醒。
物联网首先要解决的是“连接”“区别”“识别”“沟通”和“操作”5大问题，只有这些问题解决了，才能继续涉及安全性、易用性、低成本等问题。而传统的PC操作系统、网络操作系统和嵌入式操作系统等均无法有效解决以上问题。
在物联网飞速发展和水平化转型的大背景下，运行在资源受限设备之上的操作系统内涵也将不断丰富，例如硬件抽象、安全、协议连接、互联互通和设备管理等。
物联网有3个层次：终端应用层、网络层和感知层。其中最能体现物联网特征的就是物联网的感知层。感知层由各种传感器、协议转换网关、通信网关和智能终端设备组成。物联网操作系统就是运行在物联网终端上，对终端进行控制和管理，并提供统一编程接口的操作系统软件。
具体来说，物联网操作系统除具备传统操作系统的设备资源管理功能外，还具备下列功能：
●屏蔽物联网碎片化的特征，提供统一的编程接口；
●物联网生态环境培育；
●降低物联网应用开发的成本和时间；
●为物联网统一管理奠定基础。
物联网操作系统架构正在由原来的垂直沙漏模型向水平模型转化，从水平化角度看，其发展趋势是更重视设备管理和设备连接性，不再拘泥于特定操作系统的功能。如Wind River和ARM都将物联网平台定位在提供连接性和设备管理上。
物联网操作系统按工作模式分为实时操作系统和非实时操作系统。
国际上常见的嵌入式操作系统大约有40种，如：Linux、uClinux、WinCE、PalmOS、Symbian、uCOS-II、VxWorks、Nucleus、ThreadX和QNX等。它们基本可以分为两类：一类是面向控制、通信等领域的实时操作系统，如windriver公司的vxWorks、QNX系统软件公司的QNX、ATI的Nucleus等；另一类是面向消费电子产品的非实时操作系统，这类产品包括个人数字助理（PDA）、移动电话、机顶盒、电子书、Webphone等，操作系统有Microsoft的WinCE,3Com的Palm,Google的Android，以及Symbian等。
“实时”的真正含义是指任务的完成时间可确定、可预知。操作系统面对的负载通常是变化的，有时任务少，有时任务多，实时操作系统要求无论负载多少，都必须保证满足时间要求。
实时操作系统要求的不是运行速度，而是任务执行时间的确定性。
物联网操作按市场运作模式分为开源操作系统和商用操作系统。
开源操作系统（Open source operating system），是指源代码公开的操作系统软件，要遵循开源协议进行使用、编译和再发布。在遵守相关开源协议的前提下，任何人都可以免费使用，随意控制软件的运行方式。开源操作系统最大的特点就是开放源代码和自由定制，列举优势如下：
●易理解：开源操作系统源代码公开，开发人员更容易查看和理解代码，获取相关知识。
●公开透明：操作系统漏洞和缺陷更容易曝光，同时代码的开发和维护也是公开的。
●可定制：用户可以根据需求，依照不同的硬件平台和应用场景进行定制。
●低成本：无商业版权费，节省了相关开发管理和人力投入成本。
●可持续：操作系统开发公司无法提供后续服务，依靠开源社区的开发人员参与持续维护系统。
●集思广益：因为开源操作系统是公开，可以让更多的开发者参与开发，汇集更多的智慧和想法。
对于物联网发展而言，碎片化是主要的问题，其中，芯片、传感器、通信协议、应用场景千差万别，厂商、学派山头林立。比如无线通信标准就有蓝牙、Wi-Fi、ZigBee、PLC、Z-Wave、RF、Thread、Z-Wave、NFC、UWB、LiFi、NB-IoT和LoRa等。很明显，技术方案不统一，体系结构不一致，阻碍了物联网的发展，也局限了互联互通的范围。
各种操作系统可以支持不同的硬件、通信标准和应用场景。开源，有利于打破技术障碍和壁垒，提高互操作性和可移植性，减小开发成本，同时也适合开源社区的开发人员参与进来。
操作系统是物联网中一个十分关键的环节，开源更助推了物联网的开放和发展。目前，开源操作系统在物联网中的应用已经十分广泛，以后也必将在物联网中扮演越来越重要的角色。
手机操作系统市场，经过多年的市场优胜劣汰，Android操作系统因为开源而占市场84%以上的份额，iOS操作系统因为苹果公司科技领先的优势，占市场份额16%左右，形成两家独大的局面，其他手机操作系统基本被市场淘汰。在物联网普及初期，由于物联网通信协议的多样性和微处理器芯片的多样性，物联网操作系统必然呈现出多样性的特点，而几年后，经过市场风雨的洗礼，物联网操作系统的种类会减少，优质的物联网操作系统会存活下来。
另外，商用操作系统需要付费授权才可使用，一般不允许客户改动操作系统核心编码。
特点
物联网操作系统的特点分为3个：连接、协同、智能。
1．连接
连接是各种各样的终端设备能够通过某种网络技术，连接到一个统一的网络上，任何终端之间都可以相互访问。下一代的基础通信网络，包括5G通信技术和网络架构重构，核心目标是为物联网提供泛连接网络。目前已经有很多厂商推出了相应的解决方案，比如Google的thread/wave，华为的Hi-Link，以及NB-IoT等。
传统的物联网连接，都是指物联网终端设备与物联网云平台之间的连接；
传统的物联网连接
在这种模式下，物联网设备通过各种各样的连接技术，比如Wi-Fi、Ethernet、BLE和ZigBee等技术，连接到位于云端的物联网平台上。需要注意的是，这仅仅是一个逻辑结构，在物理层面上，物联网设备在接入云平台之前可能需要一个物联网网关。因为很多连接技术是无法直接连接到位于Internet上的物联网云平台的，比如ZigBee、BLE、Z-Wave和NFC等。这些技术的通信范围是一个小的局域网，比如一个家庭、一间办公室等。而连入Internet的技术，则往往是Wi-Fi、Ethernet、2G/3G/4G等这类网络技术，大部分物联网设备并不能提供这种连接的能力。因此，需要有一个物联网网关来弥补这个空隙，完成不同技术之间的转换。如图4.5所示为物联网网关的功能和网络位置。
含有物联网网关的连接方式
物联网网关具备相对强大的计算能力，具备丰富的网络接口，同时具备消息或数据的汇聚和分解功能。
在这种连接模式下，物联网云平台是所有物联网终端设备的大脑，云平台统一指挥物联网终端的行为，如果这种连接一旦断开，那么物联网终端将无所适从，完全失去控制。
更理想的连接，应该是物联网设备之间也能实现本地的直接连接:
本地连接方式
物联网设备之间也建立连接，同时保留与云平台的连接。这样的好处就是，一旦云平台的连接中断，物联网终端可以采用本地之间的终端连接，继续提供服务。同时，物联网设备本地之间的交流和通信，直接通过本地连接完成，而不用再上升到云端。
要实现这种“云端连接”加“本地连接”的模型，需要物联网设备支持消息中继功能。即物联网设备可以把另外的物联网设备消息或数据转发到云平台，同时把云平台下发的数据转接给另外的物联网设备。
2．协同
协同是指接入网络的任何设备之间，能够通过学习，实时地了解自己和对方的能力与状态，能够根据特定的输入条件或者特定的环境状态，多种设备间实现有效互动、协调工作，完成某种单一设备无法完成的工作。协同是物联网的核心和本质，主要表现在下面几个方面：
物联网设备之间的自动发现，尤其是不同功能、不同类别的设备的相互发现。比如在智慧交通领域，汽车靠近信号灯时，应该可以快速发现信号灯并建立联系。这样，信号灯就可以根据与自己建立联系的汽车数量，来灵活调度信号灯的切换时间。
物联网设备之间的能力交互。设备之间，只有相互了解对方的能力，了解对方能干什么，才能实现有效的交互和协同。类似中国人之间的“找关系”，只有知道对方是干什么的，有哪些能力，才会有目的地发起请求，从而一起协作互动达到目标。
新增物联网成员（设备、功能）的自动传播。在一个局域网（智慧家庭）中，加入了一个新（成员）的功能设备，这个新的（成员）设备需要尽快地“融入”原有的（网络组织）设备群之中。新设备有能够广播自己的能力，同时原有的设备也可以快速地“理解”新加入的（成员）设备的功能和角色，达到一种统一的新网络状态。
3．智能
智能是指物联网设备具备类似于人的智慧，比如根据特定条件和环境的自我调节能力，能够通过持续的学习不断优化和改进，以便更人性化地为人类服务。
物联网设备应该具备自我学习能力，能够通过积累过往的经验或数据，对未来进行预判，为人们提供更加智能的服务。这种机器学习的能力，属于物联网操作系统的一部分，能够抽象成一些基本的服务或API，内置到内核中，提供给应用开发者或设备开发者调用。
机器学习服务不仅是位于终端操作系统中的一段代码，还应该有一个庞大的云平台作为支撑。大量的计算和预测功能在云平台上执行，而终端上只是做一些简单计算和结果的执行。这样终端加云平台软件，就形成了一个分布式的计算网格，有效分工，协同计算，有序执行，形成一个支撑物联网的数字神经系统。
架构
物联网操作系统是支撑物联网大规模发展的最核心软件。根据上面总结的物联网的主要特征，结合操作系统的主要功能和分层结构，总结出以下物联网操作系统整体架构
物联网操作系统整体架构
物联网操作系统是由操作系统内核、外围功能组件、物联网协同框架、通用智能引擎和集成开发环境等几个大的子系统组成。这些子系统之间相互配合，共同组成一个完整的面向各种各样物联网应用场景的软件基础平台。需要说明的是，这些子系统之间有一定的层次依赖关系，比如外围功能组件需要依赖于物联网操作系统内核，物联网协同框架需要依赖于外围功能组件，而公共智能引擎，需要依赖于下层的内核、外围功能组件甚至是物联网协同框架。
目前主流的物联网操作系统，比如Google的Brillo、Linux开放基金会的Ostro项目，以及HelloX项目，都遵循这种框架。根据这个框架，我们自下而上解析物联网结构如下：
1．系统内核
内核是操作系统的核心组件，线程、任务管理、内存管理、内核安全和同步等机制，都是在内核中实现的。从功能上说，大部分操作系统的内核都相差不大，在功能的实现上，面向不同领域的操作系统，其实现目标和实现技术是不同的。比如对传统的通用个人计算机操作系统来说，内核更加关注用户交互的响应时间、资源的充分利用、不同应用程序之间的隔离和安全等。
物联网操作系统内核功能结构
物联网操作系统的内核也应该具备嵌入式操作系统的一些特征，比如可预知可计算的外部事件响应时间、可预知中断响应时间、对多种多样的外部硬件的控制和管理机制等。当然，物联网操作系统内核必须足够可靠和安全，以满足物联网对安全性的需求。
物联网操作系统的功能与其他操作系统基本类似，主要包括任务管理、内存管理、中断管理、内核同步、安全与权限管理，以及应用管理等。为了确保内核的正常运行，也应提供内核统计与监控功能，即监视内核的运行状态、监视内核对象的数量和状态等，为维护人员或开发人员提供故障定位的工具。在每一个内核子模块中，都会通过更加具体的机制或者算法，来满足物联网应用的需求，同时确保内核的整体安全性和可靠性。
内核也是直接与物理设备打交道的软件，所有对物理设备的管理，包括物理设备检测，以及物理设备驱动程序加载和卸载等功能，都是在内核中实现的。为了有效地管理物理设备，内核需要定义一套标准的设备管理框架，设备驱动程序需要遵循这套框架，才能纳入内核的管理。为了访问多种多样的物理设备，内核同时也会定义一套叫做硬件抽象层的软件，这本质上是对一些常用硬件操作的抽象，比如读写设备配置空间，有的CPU是通过I/O接口来访问设备空间的，有的则是把设备配置空间直接映射到内存空间，通过常规内存访问来读取设备配置空间。为了适应这种不同的情况，内核一般会定义两个叫做__device_read和__device_write的宏，根据设备类型的不同，这些宏定义的实现代码也会不同，但是对操作系统内核和设备驱动程序来说，只需要调用这两个一致的宏，即可对设备配置空间进行访问。这是典型的硬件抽象层的例子。
除此之外，物联网操作系统的内核还提供面向物联网应用的常用连接功能，比如对蓝牙的支持、对ZigBee的支持和对Wi-Fi的支持等。各类领域应用可以直接利用物联网操作系统内核的这些连接功能，实现最基本的通信需求。
2．外围组件
物联网操作系统内核只是提供最基本的操作系统功能，供物联网应用程序调用。但只有物联网操作系统内核是远远不够的，在很多情况下，还需要很多其他功能模块的支持，比如文件系统、TCP/IP网络协议栈和数据库等。把这些功能组件从物联网操作系统内核中独立出来，组成一个独立的功能系统，称为外围组件。
之所以把这些功能组件称为“外围”，是因为在很多情况下，这些功能组件都是可选的。在实际的物联网应用中，这些外围组件不会全部用到，大部分情况下用到一个或两个外围组件就可以满足需求了，其他的功能组件必须裁剪掉。在物联网应用中，很多情况下的系统硬件资源非常有限，如果保留没有用到的功能组件，会浪费很多资源。同时，保留一些用不到的组件，会对整个系统带来安全隐患。这些外围组件都是针对物联网操作系统进行定制和开发的，与物联网操作系统内核之间的接口非常清晰，具备高度的可裁剪性。
在通用（PC）操作系统中，这些外围组件的处理方式却与物联网操作系统不同，这些组件会被统一归类到内核中，随内核一起分发，作为一个整体提供给用户。即使应用程序不用这些组件，也不能把这些组件裁剪掉。之所以这样做，是因为通用（PC）操作系统的资源相对丰富，多保留一些功能模块对整体系统的影响并不大。同时，通用（PC）操作系统的安全性要求相对较低。
物联网操作系统内核和外围组件结合起来可以解决物联网的“连接”需求。这包括内核提供的基本物联网本地连接（蓝牙、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。
物联网操作系统外围功能组件结构
3．物联网协同框架
物联网协同框架实现物联网“协同”功能，是物联网系统架构的组成部分。物联网操作系统的内核和外围组件实现了物联网设备之间的“连接”功能。但是，仅仅实现物联网设备的连接网络，是远远不够的。物联网的精髓在于，物联网设备之间能够相互交互和协同，使物联网设备能够充分合作，相互协调一致，以达到单一物联网设备无法完成的功能。物联网协同框架，就是为物联网设备之间的协同提供技术支撑。
物联网协同框架是一组软件的集合，由多个功能相互独立，又相互依赖的软件模块组成。比如，Google的Weave物联网协同框架，由云平台组件Weave Cloud、面向设备端的LibWeave及面向智能手机客户端的Weave Client等组件组成。WeaveCloud是整个框架的中心管理器，所有基于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 accesscontrol，这样这两者可以通过名字知道对方的功能角色。当然，这只是一个例子，在实际的命名系统中，应该有一套计算机能够识别的编码体系。
目前物联网行业内的一些协同框架，基本都是与物联网操作系统内核独立的，即这些协同框架可以被应用在基于任何操作系统的物联网解决方案中，只要这些操作系统能够提供必要的接口即可。但采取这种方式显然有其明显的弊端，那就是无法采用一套统一的代码，来适应所有的操作系统。比如Google的Waeve，针对Linux和Android等复杂的操作系统，采用C++语言开发了LibWeave组件。而针对资源受限的嵌入式应用场景，则又采用C语言开发了uWeave。这样对物联网设备的开发者来说，就不得不掌握两套完全迥异的API，了解两套机理完全不同的物联网协同框架，显然无法降低成本。
理想的实现方式是，物联网协同框架能够与物联网操作系统内核紧密绑定，只提供一套API给开发者，通过物联网操作系统内核本身的伸缩机制，来适应不同的应用场景。比如在没有Wi-Fi支持的嵌入式场景中，物联网操作系统内核会裁剪掉TCP/IP等组件，而采用低功耗蓝牙技术实现数据通信。而如果目标硬件配置了Wi-Fi或者Ethernet等网络接口设备，则会保留TCP/IP协议栈。不论是哪种形态，物联网操作系统内核都会提供统一的API给物联网协同框架使用，即底层的通信机制对物联网协同框架是透明的。基于这样的设计原则，类似Google Weave这样的物联网协同框架就无须针对不同的目标硬件设计多套解决方案了，只需要一套就可解决问题。
4．公共智能
引擎通过物联网协同框架，可以使物联网设备之间建立关联，充分协作，完成单一物联网设备无法完成的功能。但是这种协同的功能，还是局限于事先定义好的逻辑。比如上述智慧商场中火警探测器和门禁系统的例子，必须在领域应用中编写代码，告诉火警探测器，一旦发生火警就告诉门禁系统打开门禁。如果没有这样的程序逻辑，火警探测系统是不会通知门禁系统打开门禁的。
如果希望物联网系统超出预定义的范围，能够达到一种自学习的程度，比如最开始火警探测器并不知道在发生火警时通知门禁系统打开门禁，而是随着运行时间的增加，逐渐地学习到这种能力。这样，只有物联网协同框架是无法做到的，必须引入智能引擎的支持。
公共智能引擎
物联网智能引擎，是指包含了如语音与语义识别、机器学习等功能模块，以使得物联网能够超出事先定义好的活动规则，能够像人一样具备智慧的能力。在物联网智能引擎内的功能模块，都是基础能力，可以供各种物联网应用所调用。比较典型的例子就是，在物联网设备中加入语音识别功能，人们通过自然语言，与物联网设备直接对话，以此达到下达指令的目的。
另外一个公共智能引擎中的重要模块，是DSL语言与其对应的处理引擎。DSL（DomainSpecific Language，领域特定语言）是针对某一种特定的应用领域开发的编程或操作语言，专门应用于一个相对独立的领域。这与计算机编程语言不一样，计算机编程语言大部分都通用，可以为多种应用领域编写程序。正是因为它的通用性，无法照顾到某一个具体的领域，因此采用通用计算机语言来实现某一个具体领域的应用时就非常麻烦，需要专业的程序员经过复杂的编程工作来实现。DSL语言则是针对某一个很细的功能领域开发，专门应用于这个特定的领域。这样就可以针对这个特定的领域建立一些内置对象，定义领域特定的动作，并根据领域的习惯定义领域特有的语法。采用DSL语言来编写领域应用就非常简单。
