??物聯(lián)網(wǎng) (IoT) 推動(dòng)嵌入式控制向前所未有的智能水平發(fā)展。對于過去獨(dú)立使用設(shè)備之處，物聯(lián)網(wǎng)將它們集成至一個(gè)由多個(gè)子系統(tǒng)組成的系統(tǒng)中。這種方式令設(shè)備能夠相互協(xié)作并與其他服務(wù)進(jìn)行交互，從而提供更出色的性能、響應(yīng)能力和正常運(yùn)行時(shí)間。

對于應(yīng)用涉及到的所有物聯(lián)網(wǎng)設(shè)備提供的數(shù)據(jù)流，用戶可以利用云技術(shù)的強(qiáng)大計(jì)算能力，讓機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘和其他技術(shù)對這些數(shù)據(jù)流進(jìn)行處理。同時(shí)，這些物聯(lián)網(wǎng)設(shè)備也無需專門針對應(yīng)用進(jìn)行設(shè)計(jì)。基于云的系統(tǒng)可以利用 Spark 和 Hadoop 等數(shù)據(jù)整理技術(shù)對不同來源的實(shí)時(shí)信息和歷史信息進(jìn)行整合，可以實(shí)現(xiàn)跨多個(gè)來源的關(guān)聯(lián)作業(yè)，同時(shí)在實(shí)現(xiàn)過程中能夠獲得有價(jià)值的信息。雖然物聯(lián)網(wǎng)具備一定的處理能力，但也不可避免可能會(huì)遇到各種復(fù)雜情況。

物聯(lián)網(wǎng)應(yīng)用交付的一個(gè)關(guān)鍵問題在于每個(gè)解決方案組成部分的多樣性。物聯(lián)網(wǎng)應(yīng)用需要獲取來自不同類型傳感器的讀數(shù)，例如溫度、運(yùn)動(dòng)和空氣質(zhì)量。即使對于相同類型的傳感器讀數(shù)，數(shù)據(jù)也可能采集自不同制造商提供的設(shè)備，或者來自非物聯(lián)網(wǎng)設(shè)計(jì)的舊硬件。

以監(jiān)控酒店內(nèi)每個(gè)房間內(nèi)溫度的物聯(lián)網(wǎng)項(xiàng)目為示例。每個(gè)房間可以有三個(gè)傳感器，而且每個(gè)傳感器都能監(jiān)控溫度。靠門的傳感器可以將其溫度傳感器作為火警報(bào)警器模塊的一部分，另一個(gè)靠近床的傳感器可以與室內(nèi)空調(diào)控制相關(guān)聯(lián)，而浴室中的傳感器可以作為物聯(lián)網(wǎng)升級部分的專用裝置安裝。

對于從每種類型的設(shè)備獲得讀數(shù)的軟件，其需要考慮每個(gè)傳感器的校準(zhǔn)方法及獲得數(shù)據(jù)的方式。某些設(shè)備可以依據(jù)超出編程閾值的條件變化或通過基于云的應(yīng)用按需定期發(fā)送數(shù)據(jù)。同時(shí)，它們可能分別使用不同的網(wǎng)絡(luò)連接實(shí)現(xiàn)數(shù)據(jù)中繼 – 有的使用有線網(wǎng)絡(luò)，而有的利用藍(lán)牙或 Zigbee 等無線網(wǎng)絡(luò)。此時(shí)，該應(yīng)用需要考慮這種可變化性。但問題遠(yuǎn)不止這些。

功耗是許多物聯(lián)網(wǎng)設(shè)備的主要課題。保持較長電池使用壽命的最常用方法是盡可能減少無線通信及核心微處理器等高功耗系統(tǒng)的活動(dòng)。這些子系統(tǒng)在系統(tǒng)生命周期的大部分時(shí)間內(nèi)都保持低功耗睡眠狀態(tài)。它們會(huì)在短時(shí)間內(nèi)醒來，并在再次睡眠前處理任務(wù)。結(jié)果實(shí)現(xiàn)了低占空比。也許只有不到系統(tǒng)生命周期 1% 的時(shí)間是處于完全清醒的高功耗狀態(tài)。在剩余 99% 的時(shí)間內(nèi)，只需對維持系統(tǒng)狀態(tài)所需的系統(tǒng)（例如實(shí)時(shí)時(shí)鐘）進(jìn)行供電。采用這樣的設(shè)計(jì)，物聯(lián)網(wǎng)節(jié)點(diǎn)可以在一次電池充電后使用數(shù)年。

現(xiàn)在，許多微控制器 (MCU) 都集成了硬件狀態(tài)機(jī)。這樣一來，可以通過實(shí)時(shí)時(shí)鐘觸發(fā)來定期喚醒重要的傳感器，而且在不喚醒主機(jī)微處理器的情況下即可獲取讀數(shù)。在喚醒微處理器執(zhí)行處理操作之前，某些系統(tǒng)可以采用一組預(yù)定讀數(shù)。其他系統(tǒng)也可以將閾值編程至傳感器邏輯中，以便能夠?qū)^大偏差立即做出反應(yīng)。

在云端運(yùn)行的控制應(yīng)用可能會(huì)向設(shè)備或向設(shè)備發(fā)送狀態(tài)更改命令來請求需要的數(shù)據(jù)。但是設(shè)備可能會(huì)在一段時(shí)間內(nèi)沒有響應(yīng)，這是為了確保低占空比需求，因此當(dāng)命令發(fā)出時(shí)，設(shè)備仍將處于低功耗狀態(tài)。該應(yīng)用需要有邏輯，以確保其對設(shè)備狀態(tài)的理解與現(xiàn)實(shí)保持一致。

在物聯(lián)網(wǎng)的初始階段，集成商發(fā)現(xiàn)他們必須使用自定義協(xié)議或遠(yuǎn)程過程調(diào)用 (RPC) 技術(shù)為云集成構(gòu)建自己的軟件基礎(chǔ)設(shè)施。通常，他們會(huì)在專用設(shè)施中使用自己的數(shù)據(jù)中心或租借的刀片式服務(wù)器，而且在這里他們可以運(yùn)行從互聯(lián)嵌入式設(shè)備接收數(shù)據(jù)的應(yīng)用程序，將信息推送到中央數(shù)據(jù)庫，并運(yùn)行向用戶呈現(xiàn)數(shù)據(jù)和執(zhí)行模式分析的應(yīng)用程序。

集成商將負(fù)責(zé)確保故障恢復(fù)能力和高可用性，并解決設(shè)備未與網(wǎng)絡(luò)建立永久連接的復(fù)雜環(huán)境。實(shí)現(xiàn)這一目標(biāo)的一種方法是使用設(shè)備影子概念。這些設(shè)備影子指的是在云端存儲(chǔ)的文檔，它們可以緩存有關(guān)設(shè)備狀態(tài)（自上次報(bào)告后）和任何待定更改的信息。

雖然應(yīng)用程序可以自己管理設(shè)備影子，但如果將其轉(zhuǎn)移到可以跨多種類型的設(shè)備提供標(biāo)準(zhǔn)化接口的服務(wù)層，則可以更輕松地管理該任務(wù)。目前，這是由 Amazon Web Services、IBM Watson IoT 和 Google Cloud 等云基礎(chǔ)設(shè)施產(chǎn)品提供處理的眾多功能之一。

云基礎(chǔ)設(shè)施平臺(tái)執(zhí)行的另一項(xiàng)服務(wù)是協(xié)議映射。云的發(fā)展圍繞廣泛使用的 TCP/IP 協(xié)議，以及協(xié)議可以承載的服務(wù)。雖然許多基于云的服務(wù)所用的超文本傳輸協(xié)議 (HTTP) 是一種無狀態(tài)協(xié)議，但由于 TCP 的廣泛支持，該協(xié)議運(yùn)行于面向狀態(tài)的 TCP 層之上。但是，只有少數(shù)物聯(lián)網(wǎng)設(shè)備具有所需的資源來實(shí)現(xiàn)完整的 TCP/IP 堆棧，進(jìn)而實(shí)現(xiàn)與云應(yīng)用直接通信。根據(jù)互聯(lián)網(wǎng)工程任務(wù)組 (IETF) 請求評議的定義，受限應(yīng)用協(xié)議 (CoAP) 簡化了 HTTP，使其與資源受限設(shè)備的兼容程度更高，并且無需使用 TCP 層。

CoAP 采用 4 字節(jié)報(bào)頭和緊湊編碼，能夠支持?jǐn)?shù)據(jù)包長度比通常由骨干以太網(wǎng)連接所提供數(shù)據(jù)包長度更短的協(xié)議。CoAP 的常見替代方案是 IBM 開發(fā)的消息隊(duì)列遙測傳輸 (MQTT) 協(xié)議，其所具備的特性被認(rèn)為更適合眾多物聯(lián)網(wǎng)實(shí)現(xiàn)。該協(xié)議可以在各種數(shù)據(jù)包格式上運(yùn)行，例如藍(lán)牙和 Zigbee 以及 TCP/IP。與傳統(tǒng) HTTP Web 服務(wù)的客戶端服務(wù)器模式相比，MQTT 支持發(fā)布訂閱模式。該模式具有盡量減少單個(gè)物聯(lián)網(wǎng)設(shè)備請求的優(yōu)點(diǎn)。

??

圖 1 - 網(wǎng)關(guān)映射 MQTT 和 CoAP

圖 2 - MQTT 發(fā)布/訂閱模型示例

為了確保不同平臺(tái)間數(shù)據(jù)傳輸?shù)囊恢滦裕破脚_(tái)采用 JavaScript 對象表示法 (JSON) 格式。要將數(shù)據(jù)發(fā)送到云，設(shè)備必須首先將其擁有的數(shù)據(jù)編碼為 JSON 表示形式，然后用作 CoAP、HTTP 或 MQTT 消息的有效負(fù)載。實(shí)施者可選擇：讓終端設(shè)備執(zhí)行此任務(wù)或依靠網(wǎng)關(guān)來處理該過程。在廣泛使用傳統(tǒng)硬件的系統(tǒng)中，網(wǎng)關(guān)通常是首選。網(wǎng)關(guān)可以使用專有或預(yù)設(shè)物聯(lián)網(wǎng)標(biāo)準(zhǔn)來收集設(shè)備使用的數(shù)據(jù)，并將數(shù)據(jù)在 JSON 表示形式之間轉(zhuǎn)換，也可以作為從云接收的任何命令的代理。網(wǎng)關(guān)實(shí)現(xiàn)將決定是否需要以設(shè)備可以理解的形式轉(zhuǎn)換和中繼這些命令。

為了處理 JSON 轉(zhuǎn)換以及與云的交互，為物聯(lián)網(wǎng)設(shè)計(jì)的設(shè)備可能包含自己的軟件堆棧。對 JSON 和網(wǎng)絡(luò)接口的支持可以整合到核心實(shí)時(shí)操作系統(tǒng) (RTOS)，并使用 C 語言之類的編程語言進(jìn)行訪問。由某些物聯(lián)網(wǎng)集成商采用且受云基礎(chǔ)設(shè)施提供商支持的技術(shù)會(huì)在每個(gè)針對物聯(lián)網(wǎng)云集成進(jìn)行優(yōu)化的終端設(shè)備上實(shí)施虛擬機(jī)。

圖 3 - JSON 格式的傳感器輸出示例

在每個(gè)物聯(lián)網(wǎng)設(shè)備平臺(tái)上實(shí)施的設(shè)備驅(qū)動(dòng)程序用于將來自虛擬機(jī)的命令轉(zhuǎn)換為底層 RTOS 和固件可以理解的形式。固件負(fù)責(zé)優(yōu)化功耗和低級計(jì)時(shí)，并提供云端層可以依賴的標(biāo)準(zhǔn)化服務(wù)集。

與傳統(tǒng)嵌入式環(huán)境相比，云環(huán)境中的開發(fā)可提供各種更豐富的編程工具。今天，用于云編程的語言往往被設(shè)計(jì)為在受管代碼環(huán)境中運(yùn)行。代碼并不是被編譯，而是在運(yùn)行時(shí)進(jìn)行解釋，或者如果要提供更高的性能，則需要即時(shí) (JIT) 編譯。雖然嵌入式開發(fā)人員通常選擇的編程語言有限（主要是 C 語言和 C++），但云開發(fā)人員可以訪問各種編程語言，而且其中許多語言針對特定需求進(jìn)行了優(yōu)化。盡管 Java 和 Python 支持許多應(yīng)用需求，但 Hadoop 對 Java 進(jìn)行了擴(kuò)展，以便更輕松地在多個(gè)計(jì)算節(jié)點(diǎn)之間傳播數(shù)據(jù)處理工作負(fù)載。

雖然嵌入式和云編程都意味著使用交叉開發(fā)資源，但為服務(wù)器編寫代碼的開發(fā)人員通常可以使用虛擬機(jī)技術(shù)在自己的計(jì)算機(jī)上構(gòu)建目標(biāo)環(huán)境的縮小版本。嵌入式開發(fā)人員通常需要針對目標(biāo)單獨(dú)開發(fā)代碼，并且在每個(gè)編輯-編譯-下載序列后運(yùn)行測試，因此會(huì)增加周轉(zhuǎn)時(shí)間。支持受管代碼語言的中間件環(huán)境通過在本地虛擬機(jī)上實(shí)現(xiàn)原型代碼來幫助簡化開發(fā)，從而提供了類似于云開發(fā)人員所體驗(yàn)到的效果。

由于可以使用云基礎(chǔ)設(shè)施服務(wù)，因此集成商現(xiàn)在可以訪問一系列工具，從而使完整物聯(lián)網(wǎng)解決方案的構(gòu)建變得更加容易。這些面向云的服務(wù)深入到了設(shè)備層，可確保大大降低部署的復(fù)雜性，并且讓集成商能夠充分利用物聯(lián)網(wǎng)的全部功能。