發布日期：2022-04-17 點擊率：231
【導讀】物聯網操作系統是新一代信息技術的重要組成部分。其英文名稱是IOT（Internet Of Things）。由此，顧名思義，“物聯網就是物物相連的互聯網”。下一代的基礎通信網絡，包括未來的5G，通信網絡架構重構等，為物聯網提供泛連接網絡是核心目標。目前也已經有很多廠商推出解決方案，比如Google的thread/wave，華為的Hi-link，以及NB-IoT等。
1. 物聯網的主要特點
i. 連接
所謂連接，指的是各種各樣的終端設備，都能夠通過某種網絡技術，連接到一個統一的網絡上。任何終端之間都可以相互訪問。下一代的基礎通信網絡，包括未來的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，完成不同技術之間的轉換。下圖示意了物聯網網關的功能和網絡位置：
物聯網網關往往具備相對強大的計算能力，具備豐富的網絡接口，同時具備消息或數據的匯聚和分解功能。
在這種連接模式下，物聯網云平臺是所有物聯網終端設備的“大腦”，云平臺統一指揮物聯網終端的行為，如果這種連接一旦斷開，那物聯網終端將無所適從，完全失去控制。
更理想的連接，應該是物聯網設備之間，也實現本地的直接連接，如下圖所示：
物聯網設備之間也建立連接，同時保留與云平臺的連接。這樣的好處就是，一旦云平臺的連接中斷，物聯網終端可以采用本地之間的終端連接，繼續提供服務。同時，物聯網設備本地之間的交流和通信，直接通過本地連接完成，而不用再上升到云端。
要實現這種“云端連接”加“本地連接”的模型，需要物聯網設備支持消息中繼功能。即物聯網設備可以把另外的物聯網設備的消息或數據，轉發到云平臺，同時把云平臺發下來的數據，轉接給另外的物聯網設備。
ii. 協同
協同，則是指接入網絡的任何設備之間，能夠通過學習，實時的了解自己和對方的能力和狀態，能夠根據特定的輸入條件，或者特定的環境狀態，多種設備實現有效互動，協調工作，完成某種單一設備無法完成的工作。協同是物聯網的核心和本質。協同表現在下面幾個方面：
物聯網設備之間的自動發現，尤其是不同功能，不同類別的設備，如何相互發現。比如在智慧交通領域，汽車靠近路燈時，應該可以快速發現路燈，并建立聯系。這樣路燈就可以根據與自己建立聯系的汽車數量，來靈活調度信號燈的閃爍時間；
物聯網設備之間的能力交互。設備之間，只有相互了解對方的能力，了解對方能干什么，才能實現有效的交互和協同。類似中國人之間的“找關系”，只有知道對方是干什么的，有哪些能力，才會有目的的去“發起請求”，從而一起協作達到目標；
新增物聯網設備或功能的自動傳播。比如在一個局域網（智慧家庭）中，新加入了一個新的功能設備，這個新的設備需要盡快的“融入”原有的設備之中。這包括有一種機制，能夠廣播自己的能力，同時，原有的設備，應該也可以快速的“理解”新加入的設備的功能和角色，這樣后續就又達到一種統一的狀態。
iii. 智能
智能，則是指物聯網設備具備“類似于人”的智慧，比如根據特定條件和環境的自我調節能力，能夠通過持續的學習，不斷優化和改進，更“人性化”的為人類服務。
如果物聯網設備只是連接在一起，能夠遠程控制，被動的聽從人們的指揮，那不能算是真正的物聯網，只能算是“控制網”。理想的目標是，物聯網設備應該具備自我學習能力，能夠通過積累過往的經驗或數據，能夠對未來進行預判，為人們提供更加智能的服務。這種“機器學習”的能力，我們認為應該屬于物聯網操作系統的一部分，應該能夠抽象成一些基本的服務或API，內置到內核中，供應用開發者或者設備開發者調用。
而且，這種機器學習的服務，不僅僅只是位于終端操作系統中的一段代碼，還應該有一個龐大的后臺進行支撐。大量的計算和預測功能，在后臺上執行。而終端上只是做一些簡單計算和結果的執行。這樣終端加后臺軟件，就形成一個分布式的計算網格，有效分工，協同計算，有序執行，形成一個支撐物聯網的數字神經。
2. 物聯網操作系統整體架構概述
物聯網操作系統是支撐物聯網大規模發展的最核心軟件。根據上面總結的物聯網的主要特征，結合操作系統的主要功能和分層結構，我們總結出如下的物聯網操作系統整體架構：
總體來說，物聯網操作系統是由操作系統內核，外圍功能組件，物聯網協同框架，通用智能引擎，集成開發環境等幾個大的子系統組成。這些子系統之間相互配合，共同組成一個完整的面向各種各樣物聯網應用場景的軟件基礎平臺。需要說明的是，這些子系統之間有一定的層次依賴關系，比如外圍功能組件需要依賴于物聯網操作系統內核，物聯網協同框架需要依賴于外圍功能組件，而公共智能引擎，需要依賴于下層的內核，外圍功能組件，甚至是物聯網協同框架等。在這個架構圖中，也反映了這種層次化的依賴關系。
目前主流的物聯網操作系統，比如Google的Brillo，Linux開放基金會的Ostro項目，以及HelloX項目，都遵循這樣一種框架。下面對這幾個子系統做簡要介紹。
a) 物聯網操作系統內核概述
內核是任何操作系統都有的核心組件，操作系統的核心功能和核心機制，都是在內核中實現的。比如最核心的線程/任務管理，內存管理，內核安全和同步等機制。雖然從功能上說，大部分操作系統的內核都相差不大，但是在這些具體功能的實現上，面向不同領域的操作系統，其實現目標和實現技術都是不同的。
比如對傳統的通用個人計算機操作系統來說，內核更加關注用戶交互的響應時間，資源的充分利用，不同應用程序之間的隔離和安全等。這是與其應用場景有關的。而對于面向嵌入式領域的嵌入式操作系統，則更加關注對中斷的響應時間，更加關注線程或任務的調度算法，以使得整個系統能夠在可預知的時間內，完成對外部事件的響應。
而物聯網操作系統的內核，又有不同于其它操作系統的特點。最主要的是其伸縮性。物聯網操作系統的內核應該能夠適應各種配置的硬件環境，從小到幾十K內存的低端嵌入式應用，到高達幾十M內存的復雜應用領域，物聯網操作系統內核都應該可以適應。同時，物聯網操作系統的內核應該足夠節能，確保在一些能源受限的應用下，能夠持續足夠長的時間。比如，內核可以提供硬件休眠機制，包括CPU本身的休眠，以便在物聯網設備沒有任務處理的時候，能夠持續處于休眠狀態。在需要處理外部事件時，又能夠快速的喚醒。
物聯網操作系統的內核也應該具備嵌入式操作系統的一些特征，比如可預知可計算的外部事件響應時間，可預知的中斷響應時間，對多種多樣的外部硬件的控制和管理機制等。當然，物聯網操作系統內核必須足夠可靠和安全，以滿足物聯網對安全性的需求。
從功能上說，與其它操作系統基本類似，主要包括任務管理，內存管理，中斷管理，內核同步，安全與權限管理，應用管理等。為了確保內核的正常運行，內核也應提供內核統計與監控功能，即監視內核的運行狀態，監視內核對象的數量/狀態等，為維護或開發人員提供故障定位的工具。在每一個內核子模塊中，都會通過更加具體的機制或者算法，來滿足物聯網應用的需求。同時確保內核的整體安全性和可靠性。
內核也是直接與物理設備打交道的軟件，所有對物理設備的管理，包括物理設備檢測，物理設備驅動程序加載和卸載等等功能，也都是在內核中實現的。為了有效的管理物理設備，內核需要定義一套標準的設備管理框架，設備驅動程序需要遵循這一套框架，才能納入內核的管理。為了訪問多種多樣的物理設備，內核同時也會定義一套叫做硬件抽象層的軟件，這本質上是對一些常用硬件操作的抽象，比如讀寫設備配置空間，有的CPU是通過I/O接口來訪問設備空間的，有的則是把設備配置空間直接映射到內存空間，通過常規內存訪問來讀取設備配置空間。為了適應這種不同的情況，內核一般會定義一個叫做__device_read和__device_write的宏，根據設備類型的不同，這些宏定義的實現代碼會不同，但是對操作系統內核和設備驅動程序來說，只需要調用這兩個一致的宏，即可對設備配置空間進行訪問。這就是一個典型的硬件抽象層的例子。
除此之外，物聯網操作系統的內核還提供面向物聯網應用的常用連接功能，比如對藍牙的支持，對Zigbee的支持，對WiFi的支持，等等。各類領域應用可以直接利用物聯網操作系統內核的這些連接功能，實現最基本的通信需求。
下圖示意了內核的更進一步的功能結構：
b) 外圍功能組件概述
物聯網操作系統內核只是提供最基本的操作系統功能，供物聯網應用程序調用。但只有物聯網操作系統內核是遠遠不夠的，在很多情況下，還需要很多其它功能模塊的支持，比如文件系統，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”。下圖示意了常見的物聯網操作系統外圍功能組件：
c) 物聯網協同框架概述
物聯網協同框架是實現物聯網“協同”功能性需求的關鍵功能系統。物聯網操作系統的內核和外圍功能組件，僅僅實現了物聯網設備之間的“連接”功能。但是我們知道，僅僅實現物聯網設備的連接上網，是遠遠不夠的。物聯網的精髓在于，物聯網設備之間能夠相互交互和協同，使得物聯網設備能夠“充分合作”，相互協調一致，以達到單一物聯網設備無法完成的功能。而物聯網協同框架，就是為物聯網設備之間的協同提供了技術基礎。
一般情況下，物聯網協同框架是一組軟件的集合，由許多個功能相互獨立，但是又相互依賴的軟件模塊組成。比如，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這樣的物聯網協同框架就無需針對不同的目標硬件設計多套解決方案了，而只需要一套就可解決問題。
d) 公共智能引擎概述
通過物聯網協同框架，可以使得物聯網設備之間建立關聯，充分協作，完成單一物聯網設備無法完成的功能。但是這種協同的功能，還是局限于事先定義好的邏輯上。比如上述智慧商場中火警探測器和門禁系統的例子，必須在領域應用中編寫代碼，告訴火警探測器，一旦發生火警，則告訴門禁系統打開門禁。如果沒有這樣的程序邏輯，火警探測系統是不會通知門禁系統的。
如果希望物聯網系統超出預定義的范圍，能夠達到一種自學習的程度，比如最開始火警探測器并不知道在發生火警時通知門禁系統，而是隨著運行時間的增加，逐漸的“學習”到這種能力。這樣只有物聯網協同框架就無法做到了，必須引入智能引擎的支持。
物聯網智能引擎，就是指包含了諸如語音與語義識別，機器學習等等功能模塊，以使得物聯網能夠超出“事先定義好”的活動規則，能夠具備像人一樣具備“智慧”的能力。在物聯網智能引擎內的功能模塊，都是基礎能力，可以供各種物聯網應用所調用。比較典型的例子就是，在物聯網設備中加入語音識別功能，人們通過自然語言，與物聯網設備直接對話，來達到下達指令的目的。
另外一個公共智能引擎中的重要模塊，是DSL語言與其對應的處理引擎。DSL(DomainSpecific Language，領域特定語言)是針對某一種特定的應用領域開發的編程或操作語言，專門應用于一個相對獨立的領域。這與計算機編程語言不一樣，計算機編程語言大部分都比較通用，可以為多種應用領域編寫程序。正是因為它的通用性，無法照顧到某一個具體的領域，因此采用通用計算機語言來實現某一個具體領域的應用時，就非常麻煩，需要專業的程序員，經過復雜的編程工作。而DSL語言，則是針對某一個很細的功能領域開發，專門應用于這個特定的領域。這樣就可以針對這個特定的領域建立一些內置對象，定義領域特定的動作，并根據領域的習慣，定義領域特有語法。采用DSL語言來編寫領域應用，就非常簡單。
現在有很多軟件工具，可以用于定義DSL，并提供執行解釋引擎。物聯網操作系統的公共智能引擎模塊中，也應該提供DSL語言開發及解釋的功能，以方便物聯網特定場景的調用。
e) 集成開發環境概述
集成開發環境是任何一個完備的操作系統所必需提供的功能組件，程序員通過集成開發環境的輔助，完成具體應用的開發，這些應用最終運行在目標操作系統上。比如針對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語言是解釋型語言，即代碼可以被語言解釋器直接加載并分析運行，不需要事先編譯和鏈接。在這種情況下，就不需要編譯鏈接等工具。但是調試工具是必須的。
物聯網應用開發語言，物聯網運行庫，以及對應的編輯，編譯，連接，調試等工具，組成了物聯網開發環境的核心部分。除此之外，為了方便開發，分享，交流的目的，一個完善的開發社區，也是必須的。開發者可以在這個社區上共享代碼，討論技術問題等。更重要的是，物聯網集成開發環境可以與開發社區緊密結合，可以把成功的代碼或有價值的模塊，發布到社區中。物聯網開發環境可以直接根據程序員的需要，從社區中下載代碼，并納入到項目中。
f) 物聯網領域應用概述
領域應用是面向不同物聯網領域，通過綜合利用物聯網操作系統的各層功能模塊，借助物聯網操作系統集成開發環境，開發出來的可以完成一項或多項具體功能的應用程序。應用領域可以根據需要，調用一個或全部物聯網操作系統的功能。比如，如果是實現一個提供簡單網絡連接的實時溫度計應用，則只需要利用物聯網操作系統的內核和TCP/IP協議棧等外圍組件即可。但如果這個溫度計應用在智慧農業解決方案中，根據不同的溫度，來實時調節通風系統，則必須要集成物聯網系統框架，以使得溫度計與通風系統能夠建立聯系并有效協同。更進一步，如果希望溫度計具備某些“智慧”的功能，比如能夠識別人們的語音指令，能夠根據周圍環境的溫度和濕度等信息，判斷出是否下雨，并采取適當動作等，則必須要有公共智能引擎的支持。
總之，領域應用是物聯網操作系統的直接服務目標，它利用物聯網操作系統這個基礎軟件平臺，并根據具體領域的特征，來完成某項具體的功能。由于領域應用是與特定領域強相關的，不屬于公共的平臺軟件，因此我們不把它作為物聯網操作系統的組成部分。但是為了說明領域應用與物聯網操作系統的關系，也一起把它體現在了物聯網操作系統的架構圖中。
g) 物聯網操作系統整體架構總結
綜合上面的說明，可以把物聯網操作系統的框架做進一步細化，如下圖所示：
前面講到，物聯網的三個主要特征分別是連接，協同和智能。物聯網的這個整體框架，是與這三個特征分別對應的，如下圖所示：
如果物聯網應用只希望實現基本的連接功能，那么只要保留物聯網操作系統的內核，以及一兩個基本的外圍組件，比如TCP/IP協議棧，就足夠了。
如果物聯網應用需要實現協同功能，則必須包含物聯網協同框架這個功能模塊。通過引入物聯網協同框架，可以實現包括物聯網應用終端設備之間的交互和協同，物聯網設備與物聯網運平臺之間的交互和協同，甚至包括物聯網終端設備與智能手機之間的協同等功能。
如果僅僅提供連接和協同，并不能滿足物聯網的應用需求，那么物聯網的領域應用可以把物聯網操作系統的智能引擎利用起來。一個典型的場景就是，用戶可以通過語音控制物聯網設備，可以與物聯網設備進行對話。物聯網系統可以通過學習，來理解用戶的行為，并對用戶的行為進行預測和反饋。
可以看出，物聯網操作系統完整的解決了物聯網的三個功能性需求。
最后需要說明的是，雖然我們把物聯網操作系統分為了內核，外圍組件等四個層次，但是這些層次之間，并不是嚴格的涇渭分明，而是具備一些依賴關系的。比如外圍功能組件要依賴物聯網操作系統內核機制，而協同框架又依賴于某些外圍功能組件。同時，公共智能引擎也需要依賴于內核，外圍組件等來作為基礎支撐。這些不同的功能層次之間，通過預先定義好的接口，既能夠水乳交融的集成在一起，形成完成的解決方案，又可以根據應用場景的需求，只保留其中的一個或幾個部分，而仍然可以整齊劃一。同時，集成開發環境提供統一的API，使整個系統表現出一致的風格。
i) 常見物聯網操作系統架構分析
i. Google Brillo物聯網操作系統分析
下面列舉幾個比較典型的物聯網操作系統，來進一步說明物聯網操作系統的功能和架構。首先看一下業界比較有影響力的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上面，既體現了依賴邏輯，又體現了這兩者相互獨立的關系。不論哪種處理方式，都不會帶來理解上的偏差。
ii. Ostro物聯網操作系統分析
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物聯網操作系統與我們定義的物聯網操作系統分層模型基本上是對應的，下圖示意了這種對應關系：
iii. HelloX物聯網操作系統分析
HelloX是由國內操作系統愛好者開發的完全開源物聯網操作系統，下圖示意了HelloX的整體架構：
從整體結構上可以看出，HelloX操作系統也符合物聯網操作系統的分層結構。最下方是驅動程序層，實現了大多數常見硬件的驅動支持，包括USB，以太網，SPI/UART等等。嚴格來說，驅動程序層應該屬于內核的一部分。在HelloX的實現中，為了突出HelloX豐富的驅動支持的特點，把驅動程序單獨拿出來，作為一個層次展示。
在驅動層之上，是內核層。內存管理，任務調度等機制，都是在內核中實現的。與其它物聯網操作系統基于Linux內核定制的思路不同，HelloX的內核是根據物聯網的特征，完全全新開發的。內核中各模塊之間是松耦合的，可以根據需要，靈活的裁剪或者增加任何內核模塊，這樣就確保了內核的可伸縮性，能夠滿足多種多樣的碎片化硬件需求。也可以根據需要，替換內核中的缺省模塊或者算法，比如可以采用自定義的任務調度算法，替換內核中缺省的基于優先級輪詢的調度算法。也可以采用更加實時的內存分配算法（比如固定尺寸鏈表法），來替換內核中缺省的空閑鏈表內存分配算法，等等。對于MMU的支持，HelloX也是作為可選模塊來實現，裁剪掉MMU功能，不會對系統中的其它模塊產生任何功能上的影響（但是內存保護，虛擬內存等機制就不能用了）。
在內核層之上，是外圍組件層。HelloX提供了包括網絡，文件系統，系統調用等在內的多種多樣的外圍組件，供物聯網應用程序開發調用。
目前的HelloX，移植IoTivity物聯網協同框架，作為自己的協同框架。未來根據需要，HelloX會開發更加靈活的物聯網協同框架，與HelloX捆綁使用。
基于這些基本組件和功能，可以基于HelloX操作系統實現廣泛的物聯網應用，比如家庭網關，智能攝像頭，智慧家庭中的家電設備，抄表，e-Health等。目前HelloX已經實現了同多個物聯網云平臺的對接和集成。
推薦閱讀：
物聯網風潮驅動 傳感器專利布局動作頻頻
基于電場感應原理的3D手勢識別技術，你會玩嗎？
電容感應式與毫米波雷達，誰能挑起三維觸控的大梁？
電源地與信號地原來是這種關系
FPGA和音頻處理器實現獨特工業應用
下一篇： PLC、DCS、FCS三大控
上一篇： PowerXR EMI降低技術
