物聯(lián)網(wǎng)應用系統(tǒng)軟件開發(fā)流程

物聯(lián)網(wǎng)操作系統(tǒng)幾乎都是在傳統(tǒng)的RTOS（如FreeRTOS、UCOS）添加網(wǎng)絡協(xié)議棧發(fā)展起來的。由于Linux自身保護網(wǎng)絡協(xié)議棧，所以也有操作系統(tǒng)是高度裁剪Linux內(nèi)核而來，但是由于linux需要跑MMU，所以一般需要高級CPU，也需要M級別的RAM。本文轉(zhuǎn)載自知乎技術博文（https://zhuanlan.zhihu.com/p/23618181），并進行部分刪減修改。

一、操作系統(tǒng)清單

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介紹外，我們也會來個橫向大比拼。目的是讓項目負責人，產(chǎn)品經(jīng)理在對系統(tǒng)選型的時候能有個合理的參考。嵌入式系統(tǒng)中，當然是Linux。但當系統(tǒng)較小，能力不足以跑Linux的時候，就很容易糾結(jié)，特別是對于生態(tài)要求很高的應用。

二、Brillo

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

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統(tǒng)統(tǒng)裁減掉。只保留了C/C++運行環(huán)境，Binder IPC，SSL等網(wǎng)絡必須組件。這也就意味著在Brillo上開發(fā)APP其實是Native的，而且驅(qū)動程序都由Android的那套HAL來做抽象，所以應用程序是直接和HAL、Lib來打交道。

Brillo 架構(gòu)框圖

 

看似Google放了個IoT的操作系統(tǒng)出來，實際Google目前專注于應用場景中功能相對強大的節(jié)點，或者邊界節(jié)點Border Router這樣的角色。最重要的是Google利用Weave打通了設備節(jié)點到Google云端的通道。Google實際上是用了最小的代價，實現(xiàn)了移動設備平臺Android、物聯(lián)網(wǎng)節(jié)點和自己的云端的互聯(lián)互通。至于那些跑不了Brillo的節(jié)點怎么互聯(lián)互通，Google交給其他人去考慮了，反正Brillo也支持6LowPan, Thread之類的協(xié)議。如果你寫過Android HAL/Service，那么開發(fā)Brillo App易如反掌，直接調(diào)用Device HAL去操作設備；調(diào)用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<structhw_device_t**>(&light_device));

if (ret || !light_device)

err(1, "Failed to open %s", LIGHT_ID_NOTIFICATIONS);

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

Brillo可以在資源較少的MPU上跑，35MB內(nèi)存就行，老的ARM9估計也可以。它可建立很多低成本的設備節(jié)點，用來和智能設備、云端通訊，或者作為PAN內(nèi)設備對外的橋梁Border router。Brillo可玩性應該很高，家里的PC機，路由器都可以拿來跑，生態(tài)系統(tǒng)強大。但致命缺點是，我們在天朝啊，你懂得。相信國內(nèi)的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分成三大部分

mbed Cloud

mbed Device Connector

mbed Client

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

“mbed Client”的定義是這樣的：

a library that connects devices to mbedDevice Connector Service

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

2.2 mbed Client 架構(gòu)

 

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

2.3 mbedOS對于網(wǎng)絡的支持可謂很強大

LWIP IPv4/v6, TCP/UDP

mbed BLE stack

6LowPAN (host, router, border router)

Thread (ED, router, border router)

BSD socket API

除此之外，它還支持

文件系統(tǒng)：cfstore,flash-journal等

C++的驅(qū)動接口，及驅(qū)動抽象層HAL

幾乎所有使用ARM CortexM核的大廠硬件平臺。廣度可以，但深度有待提高

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

2.4 mbed生態(tài)

ARM提供在線IDE，可以在線快速編譯

線下的開發(fā)環(huán)境也簡單易用, mbed cli類似于android的repo

github上的例子很多，參考性強

社區(qū)相對比較活躍

合作伙伴眾多

ARM搞起了云和RTOS，令人聯(lián)想到之前的Linaro，看似前景不錯。而且據(jù)說國內(nèi)的BAT也有在使用mbed做產(chǎn)品，其實就把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是面向開發(fā)者的，開源的，適合物聯(lián)網(wǎng)的操作系統(tǒng)。它的背后沒有某個公司的支持，而是由社區(qū)驅(qū)動。

他的一些特性：

標準的C/C++編程

標準的gcc編譯環(huán)境

可以跑在8位，16位和32位的嵌入式系統(tǒng)上

部分的POSIX接口兼容（以后的目標是全兼容）

支持在Linux/Unix的虛擬機上運行

實時性，快速的中斷響應（~50 clockcycles）

微內(nèi)核，組件都可以動態(tài)加載，并且通過message來實現(xiàn)服務

極小開銷的多線程支持（< 25 bytesper thread）

豐富的網(wǎng)絡支持：6LoWPAN，IPv6，RPL，CoAP and CBOR

高精度的定時器

豐富的工具 （System shell, SHA-256, Bloom filters, …）

3.2 RIOT 架構(gòu)框圖

 

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

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

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

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

四、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是為智能城市而誕生的。支持的平臺有限，基本是內(nèi)部集成CC24xx/25xx，MC1322x之類Radio的SensorTag平臺，或者一個很小的MCU加上這些Radio模塊的平臺。從它所支持的平臺也能看出，Contiki更加專注于小型傳感器節(jié)點。它更與PAN內(nèi)的節(jié)點通訊，當然他也有傳統(tǒng)的IPv4/v6，TCP/UDP支持，使得利用CoAP可以用來和云端通訊。

4.2 Contiki的特性：

完整的網(wǎng)絡支持，HTTP，UDP/TCP，以及低功耗協(xié)議6lowpan，RPL和CoAP。整個IPv6協(xié)議棧都是有思科貢獻

專門為小內(nèi)存設備設計的內(nèi)存管理器

小巧的估算功耗的工具

豐富的實例

支持外部Flash的Coffee flash文件系統(tǒng)

Protothreads，事件驅(qū)動及多線程的編程模型

Cooja網(wǎng)絡模擬器

Rime協(xié)議棧，比IPv6更輕量級的網(wǎng)絡層

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

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

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

五、Zephyr

https://www.zephyrproject.org/

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

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

struct device {

struct device_config *config;

const void *driver_api;

void *driver_data;

};

所以驅(qū)動要自己定義一個配置結(jié)構(gòu)，一套API的函數(shù)指針，以及驅(qū)動狀態(tài)結(jié)構(gòu)。和Linux很像。

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

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

六、Nuttx

http://www.nuttx.org/

Nuttx,實時操作系統(tǒng)，POSIX接口支持，Loadable內(nèi)核模塊支持，BSD socket，MMU支持，等等。我只能說，長的太像Linux了。Build也是Kconfig，目錄結(jié)構(gòu)也基本和LinuxKernel一樣。

ARM的核基本都支持

文件系統(tǒng)也是VFS支撐，大而全。網(wǎng)絡的，NAND MTD的，pseudo都支持

自己的Clib,也可以支持uCLib

網(wǎng)絡協(xié)議棧，但是沒有wireless！

有自己的USB協(xié)議棧

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

七、大比拼

這里用一張比較簡單的表來對比這些操作系統(tǒng)和生態(tài)

 

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

八、結(jié)尾

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