進(jìn)入21世紀(jì)以后物聯(lián)網(wǎng)逐漸扮演者重要的角色，物聯(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í)間。

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

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

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

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

功耗是許多物聯(lián)網(wǎng)設(shè)備要解決的首要問(wèn)題。保持較長(zhǎng)電池使用壽命的最常用方法是最小化無(wú)線通信及核心微處理器等高功耗系統(tǒng)的活動(dòng)。這些子系統(tǒng)在系統(tǒng)的大部分生命周期都保持低功耗睡眠狀態(tài)。它們會(huì)在短時(shí)間內(nèi)醒來(lái)，并在再次睡眠前處理任務(wù)。最終減小運(yùn)作周期。也許系統(tǒng)生命周期中只有不到1%的時(shí)間處于完全清醒和高功耗狀態(tài)。在剩余的99%的時(shí)間內(nèi)，僅對(duì)維持系統(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ī)。這樣一來(lái)，可以通過(guò)實(shí)時(shí)時(shí)鐘觸發(fā)來(lái)定期喚醒重要的傳感器，且可在不喚醒主機(jī)微處理器的情況下獲取讀數(shù)。在微處理器被喚醒并執(zhí)行處理操作之前，某些系統(tǒng)可以采用一組預(yù)定讀數(shù)。其他系統(tǒng)也可將閾值編程至傳感器邏輯中，以便立即對(duì)較大偏差做出反應(yīng)。

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

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

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

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

云基礎(chǔ)設(shè)施平臺(tái)執(zhí)行的另一項(xiàng)服務(wù)是協(xié)議映射。云是圍繞TCP/IP 協(xié)議，以及其能夠承載服務(wù)的廣泛使用而發(fā)展起來(lái)的。雖然許多基于云的服務(wù)所用的超文本傳輸協(xié)議 (HTTP) 是一種無(wú)狀態(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)用直接通信。由互聯(lián)網(wǎng)工程任務(wù)組 (IETF)請(qǐng)求定義的受限應(yīng)用協(xié)議 (CoAP) 簡(jiǎn)化了 HTTP，使其與資源受限設(shè)備更加兼容，并消除了使用 TCP 層的需求。

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