??物聯網 (IoT) 推動嵌入式控制向前所未有的智能水平發展。對于過去獨立使用設備之處，物聯網將它們集成至一個由多個子系統組成的系統中。這種方式令設備能夠相互協作并與其他服務進行交互，從而提供更出色的性能、響應能力和正常運行時間。

對于應用涉及到的所有物聯網設備提供的數據流，用戶可以利用云技術的強大計算能力，讓機器學習、數據挖掘和其他技術對這些數據流進行處理。同時，這些物聯網設備也無需專門針對應用進行設計。基于云的系統可以利用 Spark 和 Hadoop 等數據整理技術對不同來源的實時信息和歷史信息進行整合，可以實現跨多個來源的關聯作業，同時在實現過程中能夠獲得有價值的信息。雖然物聯網具備一定的處理能力，但也不可避免可能會遇到各種復雜情況。

物聯網應用交付的一個關鍵問題在于每個解決方案組成部分的多樣性。物聯網應用需要獲取來自不同類型傳感器的讀數，例如溫度、運動和空氣質量。即使對于相同類型的傳感器讀數，數據也可能采集自不同制造商提供的設備，或者來自非物聯網設計的舊硬件。

以監控酒店內每個房間內溫度的物聯網項目為示例。每個房間可以有三個傳感器，而且每個傳感器都能監控溫度。靠門的傳感器可以將其溫度傳感器作為火警報警器模塊的一部分，另一個靠近床的傳感器可以與室內空調控制相關聯，而浴室中的傳感器可以作為物聯網升級部分的專用裝置安裝。

對于從每種類型的設備獲得讀數的軟件，其需要考慮每個傳感器的校準方法及獲得數據的方式。某些設備可以依據超出編程閾值的條件變化或通過基于云的應用按需定期發送數據。同時，它們可能分別使用不同的網絡連接實現數據中繼 – 有的使用有線網絡，而有的利用藍牙或 Zigbee 等無線網絡。此時，該應用需要考慮這種可變化性。但問題遠不止這些。

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

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

在云端運行的控制應用可能會向設備或向設備發送狀態更改命令來請求需要的數據。但是設備可能會在一段時間內沒有響應，這是為了確保低占空比需求，因此當命令發出時，設備仍將處于低功耗狀態。該應用需要有邏輯，以確保其對設備狀態的理解與現實保持一致。

在物聯網的初始階段，集成商發現他們必須使用自定義協議或遠程過程調用 (RPC) 技術為云集成構建自己的軟件基礎設施。通常，他們會在專用設施中使用自己的數據中心或租借的刀片式服務器，而且在這里他們可以運行從互聯嵌入式設備接收數據的應用程序，將信息推送到中央數據庫，并運行向用戶呈現數據和執行模式分析的應用程序。

集成商將負責確保故障恢復能力和高可用性，并解決設備未與網絡建立永久連接的復雜環境。實現這一目標的一種方法是使用設備影子概念。這些設備影子指的是在云端存儲的文檔，它們可以緩存有關設備狀態（自上次報告后）和任何待定更改的信息。

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

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

CoAP 采用 4 字節報頭和緊湊編碼，能夠支持數據包長度比通常由骨干以太網連接所提供數據包長度更短的協議。CoAP 的常見替代方案是 IBM 開發的消息隊列遙測傳輸 (MQTT) 協議，其所具備的特性被認為更適合眾多物聯網實現。該協議可以在各種數據包格式上運行，例如藍牙和 Zigbee 以及 TCP/IP。與傳統 HTTP Web 服務的客戶端服務器模式相比，MQTT 支持發布訂閱模式。該模式具有盡量減少單個物聯網設備請求的優點。

??

圖 1 - 網關映射 MQTT 和 CoAP

圖 2 - MQTT 發布/訂閱模型示例

為了確保不同平臺間數據傳輸的一致性，云平臺采用 JavaScript 對象表示法 (JSON) 格式。要將數據發送到云，設備必須首先將其擁有的數據編碼為 JSON 表示形式，然后用作 CoAP、HTTP 或 MQTT 消息的有效負載。實施者可選擇：讓終端設備執行此任務或依靠網關來處理該過程。在廣泛使用傳統硬件的系統中，網關通常是首選。網關可以使用專有或預設物聯網標準來收集設備使用的數據，并將數據在 JSON 表示形式之間轉換，也可以作為從云接收的任何命令的代理。網關實現將決定是否需要以設備可以理解的形式轉換和中繼這些命令。

為了處理 JSON 轉換以及與云的交互，為物聯網設計的設備可能包含自己的軟件堆棧。對 JSON 和網絡接口的支持可以整合到核心實時操作系統 (RTOS)，并使用 C 語言之類的編程語言進行訪問。由某些物聯網集成商采用且受云基礎設施提供商支持的技術會在每個針對物聯網云集成進行優化的終端設備上實施虛擬機。

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

在每個物聯網設備平臺上實施的設備驅動程序用于將來自虛擬機的命令轉換為底層 RTOS 和固件可以理解的形式。固件負責優化功耗和低級計時，并提供云端層可以依賴的標準化服務集。

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

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

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