引子

IoT(Internet of Things)一直是個市場沒爆發，但炒作夠火的概念。 最近看了Brillo(Goolge放出的OS for IoT)，再結合手頭做的項目，來聊聊打著IoT旗號的那些操作系統及其生態?？梢宰尨蠹以趯Υ祟惽度胧较到y軟件平臺選型時少些困惑。

首先，不在這里描述IoT到底是啥，這概念太籠統。但凡事都講套路，在我看來大部分的IoT操作系統都是順著這個套路(應用場景)來：

Internet            PAN 
Cloud <-> Board router <-> Nodes (things connected) 
   ^          ^             ^ 
   |          |             | 
    ---- Smart device ------ 
      (e.g. phone, tablet) 

這場景基本適用于家庭、樓宇及工業等等。所以哪家提啥方案都可以按這個套路來，下面你會看的到。文中我們會談到以下這些OS：

操作系統清單

• Brillo (a solution from Google for buildingconnected devices)
• mbedOS (ARM mbed, The ARM IoT DevicePlatform)
• RIOT (The friendly Operating System for theIoT)
• Contiki (an open source operating systemfor the IoT)
• Zephyr (a small, scalable real-timeoperating system for use on resource-constrained systems)
• Nuttx (a RTOS with an emphasis on standardscompliance and small footprint)

除了單獨對這些OS介紹外，我們也會來個橫向大比拼。目的是讓項目負責人，產品經理在對系統選型的時候能有個合理的參考。嵌入式系統中，比較好用當然是Linux。但當系統較小，能力不足以跑Linux的時候，就很容易糾結，特別是對于生態要求很高的應用。

一、Brillo

https://developers.google.com/brillo/

1.1 簡介

Brillo: Google’s OS for IoT MPU devices

• Targeted at smarthomes
• Expanding to buildingsand industry
• Supports MPU devicesw/ min 35MB of RAM

Brillo需要跑在帶MMU的AP上。其實很顯然，Brillo基于Android，它再怎么裁剪，也是需要跑在Linux，Kernel上還要打一堆patch。只是它把Android上關于圖形、JAVA虛擬機及Framework統統裁減掉。只保留了C/C++運行環境，Binder IPC，SSL等網絡安全必須組件。這也就意味著在Brillo上開發APP其實是Native的，而且驅動程序都由Android的那套HAL來做抽象，所以應用程序是直接和HAL、Lib來打交道。

1.2 Brillo 架構框圖

看似Google放了個IoT的操作系統出來，實際Google目前專注于應用場景中功能相對強大的節點，或者邊界節點Border Router這樣的角色。最重要的是Google利用Weave打通了設備節點到Google云端的通道。Google實際上是用了最小的代價，實現了移動設備平臺Android、物聯網節點和自己的云端的互聯互通。至于那些跑不了Brillo的節點怎么互聯互通，Google交給其他人去考慮了，反正Brillo也支持6LowPan, Thread之類的協議。如果你寫過Android HAL/Service，那么開發Brillo App易如反掌，直接調用Device HAL去操作設備;調用WeaveAPI去做通訊。

int ret =hw_get_module(LIGHTS_HARDWARE_MODULE_ID, &module); 
if (ret || !module) 
err(1, "Failed to load %s", LIGHTS_HARDWARE_MODULE_ID); 
ret =module->methods->open(module, 
LIGHT_ID_NOTIFICATIONS, 
reinterpret_cast(&light_device)); 
if (ret || !light_device) 
err(1, "Failed to open %s", LIGHT_ID_NOTIFICATIONS); 

以上代碼調用HAL統一接口打開一個LIGHT設備，是不是很熟悉?然后起個Daemon,利用Weave API來接收從網絡上來的XMPP請求，對設備進行配置或者狀態監測。在云端和移動端，可以使用網頁版的Weave Developers Console和Weave App來控制監測設備。

Brillo可以在資源較少的MPU上跑，35MB內存就行，老的ARM9估計也可以。它可建立很多低成本的設備節點，用來和智能設備、云端通訊，或者作為PAN內設備對外的橋梁Border router。Brillo可玩性應該很高，家里的PC機，路由器都可以拿來跑，生態系統強大。但致命缺點是，我們在天朝啊，你懂得。相信國內的BAT之類，會考慮移植，改造，變異。就如對Android一般。

二、mbedOS

2.1 簡介

mbed是ARM自己建立的IoT解決方案平臺

The ARM mbed IoT Device Platform providesthe operating system, cloud services, tools and developer ecosystem to make thecreation and deployment of commercial, standards-based IoT solutions possibleat scale.

它被ARM分成三大部分

1. mbed Cloud
2. mbed Device Connector
3. mbed Client

ARM居然也自己搞了個Cloud，可以通過“mbed DeviceConnector”來訪問連接到云端的設備。并提供網頁版的Connector來管理設備，用戶可以通過RESTful API over HTTP來寫自己的APP。

“mbed Client”的定義是這樣的：a library that connects devices to mbedDevice Connector Service

看似比較奇怪，其實就是一套可以移植到各種操作系統上的，能夠和mbed Device Connector Service通訊的，跑在硬件設備上的軟件庫。它使用基于UDP的CoAP協議來通訊，使用mbedTLS來實現安全連接，兼容LWM2M。

2.2 mbed Client 架構

說到這里，我們的主角mbedOS該登場了。ARM為了在基于ARM Cortex-M內核的硬件平臺上實現對設備的操作，及通過Device Connector訪問云端，它必須有一套可以支持mbedClient的軟件解決方案。mbedOS既是基于RTOS內核，并提供各種ARM SoC硬件平臺驅動和BSP的操作系統，在此之上，實現整個mbedClient庫。在PAN的物聯區域內，設備與設備的通訊都可以使用mbedOS提供的方案來解決，它支持NFC，RFID，BLE，6LowPAN甚至是Thread。在設備與云端的通訊上，mbedOS既支持以太網，WiFi，也支持3G。跑mbedOS的設備既可以是設備節點，也可以是邊界路由器(比如6LowPAN轉IPv6)，也可以和智能設備通過BLE通訊。mbed Device Connector又可以使用CoAP協議在設備端和云端通訊。

2.3 mbedOS對于網絡的支持可謂很強大

• LWIP IPv4/v6, TCP/UDP
• mbed BLE stack
• 6LowPAN (host, router, border router)
• Thread (ED, router, border router)
• BSD socket API

除此之外，它還支持

• 文件系統：cfstore,flash-journal等
• C++的驅動接口，及驅動抽象層HAL
• 幾乎所有使用ARM CortexM核的大廠硬件平臺。廣度可以，但深度有待提高

也就是說mbed把每一類驅動都抽象成一個基類，真正做驅動移植的時候，從這個類派生出來，然后實現相應的HAL函數。使得用戶在實例化該驅動派生類后，能夠調用相應的類接口，從而訪問實際的設備驅動程序。比如AnalogIn::read()，是返回ADC的采樣結果。

2.4 mbed生態

• ARM提供在線IDE，可以在線快速編譯
• 線下的開發環境也簡單易用, mbed cli類似于android的repo
• github上的例子很多，參考性強
• 社區相對比較活躍
• 合作伙伴眾多

ARM搞起了云和RTOS，令人聯想到之前的Linaro，看似前景不錯。而且據說國內的BAT也有在使用mbed做產品，其實就把mbed Cloud換自己的云，改造下DeviceConnector即可。本人也正在研究mbed，之后會寫些使用心得。

三、RIOT

https://github.com/RIOT-OS/RIOT

3.1 簡介

The friendly Operating System for theInternet of Things

RIOT官方的口號:)

if your tiny IoT device can’t run Linux,use RIOT

RIOT是面向開發者的，開源的，適合物聯網的操作系統。它的背后沒有某個公司的支持，而完全是由社區驅動。

他的一些特性：

• 標準的C/C++編程
• 標準的gcc編譯環境
• 可以跑在8位，16位和32位的嵌入式系統上
• 部分的POSIX接口兼容(以后的目標是全兼容)
• 支持在Linux/Unix的虛擬機上運行
• 實時性，快速的中斷響應(~50 clockcycles)
• 微內核，組件都可以動態加載，并且通過message來實現服務
• 極小開銷的多線程支持(< 25 bytesper thread)
• 豐富的網絡支持：6LoWPAN，IPv6，RPL，CoAP and CBOR
• 高精度的定時器
• 豐富的工具 (System shell, SHA-256, Bloom filters, …)

3.2 RIOT 架構框圖

RIOT的CPU的IP驅動基本都有一套統一接口，但是沒有任何抽象層，被放在源代碼的cpu\periph中。這意味著在做新的平臺支持時，你要注意驅動的接口要和API文檔里的一致，比如ADC的adc_init(), adc_read()。源代碼的drivers則放著板級的驅動，比如NXP的MMA8541，利用i2c統一接口來訪問。

由于是微內核(microkernel)的實現，所有的系統服務包括時鐘、網絡協議棧、網絡服務等，都是通過創建獨立的線程來實現。在線程中都有event_loop來接收服務請求，處理并發送服務結果。RIOT中最關鍵的是GNRC(Generic network stack)網絡協議棧，它實現了從MAC層一直到傳輸層的各種協議，如6LowPan，IPv4/v6，RPL，TCP/UDP。并且這些不同的協議棧之間通過netapi統一接口開放給用戶。對于應用層來說，GNRC提供了conn和socket兩種API。在安全方面，貌似802.15.4這層沒有加入AES的支持，只提供tinyDTLS在應用層給用戶使用。由于RIOT的POSIX的部分兼容性，及提供BSD socket的接口，很多應用都可以方便的移植過來，在pkg/你能找到例如libcoap，openwsn這樣的應用。

RIOT最早是由柏林自由大學開發的，目前完全由社區維護，貌似歐洲開發者居多。從devel maillist里來看，感覺社區活躍程度一般。每兩周都有一個Virtual meeting，都還是大學在牽頭。

總之，一個很有想法的微內核，加上開發環境相對于之前熟悉Linux的開發者來講很友好。應該是個潛力股。

四、Contiki

http://www.contiki-os.org/

4.1 簡介

以下是維基百科對Contiki的介紹：

Contiki is an operating system fornetworked, memory-constrained systems with a focus on low-power wirelessInternet of Things devices. Extant uses for Contiki include systems for streetlighting, sound monitoring for smart cities, radiation monitoring, and alarms

可以看得出來，原來Contiki是為智能城市而誕生的。支持的平臺有限，基本是內部集成CC24xx/25xx，MC1322x之類Radio的SensorTag平臺，或者一個很小的MCU加上這些Radio模塊的平臺。從它所支持的平臺也能看出，Contiki更加專注于小型傳感器節點。它更關注與PAN內的節點通訊，當然他也有傳統的IPv4/v6，TCP/UDP支持，使得利用CoAP可以用來和云端通訊。

4.2 Contiki的特性：

• 完整的網絡支持，HTTP，UDP/TCP，以及低功耗協議6lowpan，RPL和CoAP。整個IPv6協議棧都是有思科貢獻
• 專門為小內存設備設計的內存管理器
• 小巧的估算功耗的工具
• 豐富的實例
• 高效的支持外部Flash的Coffee flash的文件系統
• Protothreads，事件驅動及多線程的編程模型
• Cooja網絡模擬器
• Rime協議棧，比IPv6更輕量級的網絡層

Contiki也是個微內核(microkernel)，所有的系統服務都是通過啟線程完成，Protothreads線程整合了線程間事件通訊，使得編寫系統服務非常容易。驅動程序方面，Contiki沒有統一的驅動程序框架，驅動都是各家MCU自帶開發包提供，這樣的好處是能夠保證生成的二進制代碼夠小。

Contiki有個很有特色的模擬器，Cooja Network Simulator，可以運行很多例子，并且可以監控整個網絡的包及節點狀態。這樣可以讓用戶在沒有充足硬件設備的條件下做開發。

Contiki社區基本依靠maillist討論問題，github做pull request。從maillistarchive里看，社區活躍程度很一般。

五、Zephyr

https://www.zephyrproject.org/

Zephyr居然是Linux基金會的合作項目。應該是由INTEL將WindRiver的商用操作系統WindRiverRocket部分開源后誕生的項目(今年才誕生)。目前可用資料不多，而且支持的硬件平臺較少，ARM的平臺就沒幾個。

Zephyr像極了Linux，它的源代碼目錄結構Kconfig使用方式，啟動流程，Driver Model都可以看出來。用戶的應用程序是啟動后創建的末尾一個線程，用戶的main()會在所有的驅動，組件及硬件板子初始化后被調用，驅動使用DEVICE_INIT()，組件使用SYS_INIT()初始化，并帶有優先等級。驅動都會遵循統一的驅動結構：

struct device {  
struct device_config *config; 
const void *driver_api;  
void *driver_data;  
}; 

所以驅動要自己定義一個配置結構，一套API的函數指針，以及驅動狀態結構。和Linux很像。

網絡支持很奇葩，協議棧居然都是用的Contiki的，Bluetooth還算比較全。子系統方面，文件系統、USB都是很簡單，很原始的支持。安全方面，mbedTLS和tinyDTLS被拿了過來。

總體來講，Zephyr還處于初期，很多東西都不完善。Owner又是Intel，希望別重蹈Moblin的覆轍。

六、Nuttx

http://www.nuttx.org/

Nuttx,實時操作系統，POSIX接口支持，Loadable內核模塊支持，BSD socket，MMU支持，等等。我只能說，長的太像Linux了。Build也是Kconfig，目錄結構也基本和LinuxKernel一樣。

• ARM的核基本都支持
• 文件系統也是VFS支撐，大而全。網絡的，NAND MTD的，pseudo都支持
• 自己的Clib,也可以支持uCLib
• 全面的網絡協議棧，但是沒有wireless!
• 有自己的USB協議棧

我一開始沒打算談Nuttx，他的無線支持很差，就更別談無線互聯了。但是BAT居然有人用它做云OS。估計是團隊實在太熟悉Linux了，跑不了Linux也要找個類似的開發環境。有了BAT的支持，Nuttx估計可以發達了。

七、大比拼

這里用一張比較簡單的表來對比這些操作系統和生態

除了Brillo以外，其他都是RTOS有很小的內核。程序所占的內存和代碼大小取決你需要的硬件平臺的驅動多少，需要什么樣的協議棧等等的功能。

八、結尾

最近行業趨勢有所變化，除了互聯網依然火熱外，大家的焦點無疑都從手機投向了汽車、工業、物聯網。大家都希望能夠使用物聯網和互聯網將傳統行業中的產品實現互聯互通，實現信息共享、提高生活、生產效率和質量。我們所工作在的半導體行業中，除了給市場提供更符合需求的處理器以外，我們還需要提供基于自己處理器的軟硬件解決方案。操作系統作為應用的基礎、基石，顯得非常的重要。本文只是粗劣的介紹和對比了這些物聯網的操作系統，希望能對讀者有所幫助。