進入21世紀以后物聯(lián)網(wǎng)逐漸扮演者重要的角色，物聯(lián)網(wǎng) (IoT)推動嵌入式控制向前所未有的智能水平發(fā)展。在獨立使用設(shè)備之處，物聯(lián)網(wǎng)將它們集成至一個由多個子系統(tǒng)組成的系統(tǒng)中。這使得設(shè)備間能夠相互協(xié)作并與其他服務進行交互，從而提供更出色的性能、響應能力和正常運行時間。

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

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

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

對于那些從每種類型設(shè)備處獲取讀數(shù)的軟件，需要考慮每個傳感器的校準方法及獲得數(shù)據(jù)的方式。一些設(shè)備可以依據(jù)超出編程閾值的條件變化或通過基于云的應用按需定期發(fā)送數(shù)據(jù)。同時，它們可能使用不同的網(wǎng)絡連接，如使用有線網(wǎng)絡，而有的則使用藍牙或Zigbee等無線網(wǎng)絡。此時，應用需要考慮這種可變化性。但問題遠卻遠不止如此。

功耗是許多物聯(lián)網(wǎng)設(shè)備要解決的首要問題。保持較長電池使用壽命的最常用方法是最小化無線通信及核心微處理器等高功耗系統(tǒng)的活動。這些子系統(tǒng)在系統(tǒng)的大部分生命周期都保持低功耗睡眠狀態(tài)。它們會在短時間內(nèi)醒來，并在再次睡眠前處理任務。最終減小運作周期。也許系統(tǒng)生命周期中只有不到1%的時間處于完全清醒和高功耗狀態(tài)。在剩余的99%的時間內(nèi)，僅對維持系統(tǒng)狀態(tài)所需的系統(tǒng)(例如實時時鐘)進行供電。采用這樣的設(shè)計，物聯(lián)網(wǎng)節(jié)點可在單次充電后使用數(shù)年。

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

在云中運行的控制應用可能會從設(shè)備處請求需要的數(shù)據(jù)，或通過向設(shè)備發(fā)送命令來更改狀態(tài)。但為了確保低占空比需求，設(shè)備不會在短時間內(nèi)響應。因此當命令發(fā)出時，設(shè)備仍將處于低功耗狀態(tài)。該應用需要用邏輯思維來確保其對設(shè)備狀態(tài)的理解與現(xiàn)實保持一致。

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

集成商要確保故障恢復能力和高可用性，并處理未能永久連接到設(shè)備的復雜環(huán)境。實現(xiàn)這一目標的一種方法則是使用設(shè)備影子概念。這些設(shè)備影子指的是在云端存儲的文檔，可以緩存有關(guān)設(shè)備狀態(tài)(自上次報告后)和任何待定更改的信息。

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

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

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