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

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

一、操作系統(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)

除了單獨(dú)對(duì)這些OS介紹外，我們也會(huì)來個(gè)橫向大比拼。目的是讓項(xiàng)目負(fù)責(zé)人，產(chǎn)品經(jīng)理在對(duì)系統(tǒng)選型的時(shí)候能有個(gè)合理的參考。嵌入式系統(tǒng)中，當(dāng)然是Linux。但當(dāng)系統(tǒng)較小，能力不足以跑Linux的時(shí)候，就很容易糾結(jié)，特別是對(duì)于生態(tài)要求很高的應(yīng)用。

二、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上。其實(shí)很顯然，Brillo基于Android，它再怎么裁剪，也是需要跑在Linux，Kernel上還要打一堆patch。只是它把Android上關(guān)于圖形、JAVA虛擬機(jī)及Framework統(tǒng)統(tǒng)裁減掉。只保留了C/C++運(yùn)行環(huán)境，Binder IPC，SSL等網(wǎng)絡(luò)必須組件。這也就意味著在Brillo上開發(fā)APP其實(shí)是Native的，而且驅(qū)動(dòng)程序都由Android的那套HAL來做抽象，所以應(yīng)用程序是直接和HAL、Lib來打交道。

Brillo 架構(gòu)框圖

 

看似Google放了個(gè)IoT的操作系統(tǒng)出來，實(shí)際Google目前專注于應(yīng)用場景中功能相對(duì)強(qiáng)大的節(jié)點(diǎn)，或者邊界節(jié)點(diǎn)Border Router這樣的角色。最重要的是Google利用Weave打通了設(shè)備節(jié)點(diǎn)到Google云端的通道。Google實(shí)際上是用了最小的代價(jià)，實(shí)現(xiàn)了移動(dòng)設(shè)備平臺(tái)Android、物聯(lián)網(wǎng)節(jié)點(diǎn)和自己的云端的互聯(lián)互通。至于那些跑不了Brillo的節(jié)點(diǎn)怎么互聯(lián)互通，Google交給其他人去考慮了，反正Brillo也支持6LowPan, Thread之類的協(xié)議。如果你寫過Android HAL/Service，那么開發(fā)Brillo App易如反掌，直接調(diào)用Device HAL去操作設(shè)備；調(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)一接口打開一個(gè)LIGHT設(shè)備，是不是很熟悉？然后起個(gè)Daemon,利用Weave API來接收從網(wǎng)絡(luò)上來的XMPP請(qǐng)求，對(duì)設(shè)備進(jìn)行配置或者狀態(tài)監(jiān)測(cè)。在云端和移動(dòng)端，可以使用網(wǎng)頁版的Weave Developers Console和Weave App來控制監(jiān)測(cè)設(shè)備。

Brillo可以在資源較少的MPU上跑，35MB內(nèi)存就行，老的ARM9估計(jì)也可以。它可建立很多低成本的設(shè)備節(jié)點(diǎn)，用來和智能設(shè)備、云端通訊，或者作為PAN內(nèi)設(shè)備對(duì)外的橋梁Border router。Brillo可玩性應(yīng)該很高，家里的PC機(jī)，路由器都可以拿來跑，生態(tài)系統(tǒng)強(qiáng)大。但致命缺點(diǎn)是，我們?cè)谔斐?，你懂得。相信國?nèi)的BAT之類，會(huì)考慮移植，改造，變異。就如對(duì)Android一般。

二、mbedOS

2.1 簡介

mbed是ARM自己建立的IoT解決方案平臺(tái)

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

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

a library that connects devices to mbedDevice Connector Service

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

2.2 mbed Client 架構(gòu)

 

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

2.3 mbedOS對(duì)于網(wǎng)絡(luò)的支持可謂很強(qiá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ū)動(dòng)接口，及驅(qū)動(dòng)抽象層HAL

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

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

2.4 mbed生態(tài)

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

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

github上的例子很多，參考性強(qiáng)

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

合作伙伴眾多

ARM搞起了云和RTOS，令人聯(lián)想到之前的Linaro，看似前景不錯(cuò)。而且據(jù)說國內(nèi)的BAT也有在使用mbed做產(chǎn)品，其實(shí)就把mbed Cloud換自己的云，改造下DeviceConnector即可。本人也正在研究mbed，之后會(huì)寫些使用心得。

三、RIOT

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

3.1 簡介

The friendly Operating System for theInternet of Things

RIOT官方的口號(hào):)

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

RIOT是面向開發(fā)者的，開源的，適合物聯(lián)網(wǎng)的操作系統(tǒng)。它的背后沒有某個(gè)公司的支持，而是由社區(qū)驅(qū)動(dòng)。

他的一些特性：

標(biāo)準(zhǔn)的C/C++編程

標(biāo)準(zhǔn)的gcc編譯環(huán)境

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

部分的POSIX接口兼容（以后的目標(biāo)是全兼容）

支持在Linux/Unix的虛擬機(jī)上運(yùn)行

實(shí)時(shí)性，快速的中斷響應(yīng)（~50 clockcycles）

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

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

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

高精度的定時(shí)器

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

3.2 RIOT 架構(gòu)框圖

 

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

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

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

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

四、Contiki

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

4.1 簡介

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

4.2 Contiki的特性：

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

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

小巧的估算功耗的工具

豐富的實(shí)例

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

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

Cooja網(wǎng)絡(luò)模擬器

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

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

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

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

五、Zephyr

https://www.zephyrproject.org/

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

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

struct device {

struct device_config *config;

const void *driver_api;

void *driver_data;

};

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

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

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

六、Nuttx

http://www.nuttx.org/

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

ARM的核基本都支持

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

自己的Clib,也可以支持uCLib

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

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

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

七、大比拼

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

 

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

八、結(jié)尾

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