物聯網要求和協議

物聯網（IoT）的高級協議提供了各種特性，使其適用于廣泛的應用。例如，SNMP 多年來一直用于管理網絡設備和配置網絡，而 DDNS 已用于提供對 Web 設備的瀏覽器訪問。任一協議也可用于管理和配置各種家庭設備。相比之下，CoAP 更適合具有微小硬件和完全不同安全性的非常小的傳感器部署。有必要對這些協議和應用程序要求進行更深入的了解，以正確選擇最適合手頭應用程序的協議。

一旦知道正確的協議或幾個協議集具有應用程序部署、管理和應用程序支持的正確特性，就應該了解每個協議的最佳實現。根據這種理解，設計人員可以為系統選擇每個協議的最佳實現，然后從中選擇系統的最佳協議實現。

協議選擇問題與協議的實現密切相關，支持協議的組件在最終設計中通常是必不可少的。這使得決定變得非常復雜。部署、操作、管理和安全的所有方面都必須考慮作為協議選擇的一部分，包括實施環境。

此外，對于特定的應用并沒有任何融合的標準，這些標準一般都是由市場來選擇的。這是一個問題也是一個機會，因為今天為應用程序選擇的協議在未來可能會過時并且可能需要被替換，或者如果做得正確，可能會成為標準。作為開發人員，使用環境的特定功能來滿足系統要求，而這反過來又依賴于協議的細節，這會使將來的更改變得非常困難。

本文研究了可用協議的范圍、驅動這些協議特性的具體要求，并考慮了構建完整系統的實現要求。

協議和供應商

物聯網的高級協議具有各種特性并提供不同的功能。這些協議中的大多數是由特定供應商開發的，這些供應商通常會宣傳他們自己的協議選擇，沒有明確定義他們的假設，并忽略其他替代方案。出于這個原因，依靠供應商信息來選擇物聯網協議是有問題的，并且已經產生的大多數比較不足以理解權衡。

物聯網協議通常與業務模型綁定。有時這些協議是不完整的和/或用于支持現有的業務模型和方法。其他時候，它們提供了更完整的解決方案，但資源需求對于較小的傳感器來說是不可接受的。此外，使用協議背后的關鍵假設沒有明確說明，這使得比較變得困難。

與物聯網應用相關的基本假設是：

· 將使用各種無線連接

· 設備范圍從微型 MCU 到以小型 MCU 為重點的高性能系統

· 安全是核心要求

· 數據將存儲在云端，并可能在云端進行處理

· 需要連接回云存儲

· 需要通過無線和有線連接將信息路由到云存儲

協議開發人員做出的其他假設需要更深入的調查，并將強烈影響他們的選擇。通過查看這些協議的關鍵特性和關鍵實現要求，設計人員可以更清楚地了解協議領域和支持特性領域究竟需要什么來改進他們的設計。在我們看這個之前，讓我們回顧一下有問題的協議。

物聯網或 M2M 協議

對于協議棧中更高級別的 M2M 協議，有一組廣泛的協議被提升為物聯網通信的靈丹妙藥。請注意，這些 IoT 或 M2M 協議側重于應用程序數據傳輸和處理。以下列表總結了通常考慮的協議。

· CoAP

· Continua – 家庭健康設備

· DDS

· DPWS：WS-Discovery、SOAP、WSAddressing、WDSL 和 XML Schema

· HTTP/REST

· MQTT

· UPnP

· XMPP

· 零MQ

圖 1 總結了這些協議的特性。與基礎設施和部署相關的幾個關鍵因素將在下面單獨討論。

圖 1：如果 POSIX/Linux API 可用，則可以更輕松地支持所有 M2M 或 IoT 協議。Unison OS 配備了物聯網協議的關鍵組合，作為現成的選項，使用它的 POSIX API 來實現快速和簡單的設備支持。

關鍵協議特性

物聯網（IoT）中的通信基于 Internet TCP/UDP 協議和相關的 Internet 協議進行設置。對于基本通信，這意味著 TCP 流套接字的 UDP 數據報。小型設備的開發人員聲稱 UDP 在性能和尺寸方面具有很大優勢，這反過來又可以最大限度地降低成本。雖然是真的，但在許多情況下并不重要。

流套接字的性能受到影響，但它們確實保證了所有數據的按順序傳遞。在 STM32F4 上以 167 MHz 發送傳感器數據的性能損失低于 16.7%（使用 2 KB 數據包測量 - 較小的數據包會降低性能損失）。通過采用流套接字的方法，還可以使用標準安全協議來簡化環境（盡管如果可用，DTLS 可以與 UDP 一起使用）。

同樣，升級到 TCP 的額外 20 KB 閃存和 8 KB RAM 的內存成本差異通常很小。對于微不足道的應用和體積龐大的傳感器，這可能很有意義，但通常不會影響 ARM Cortex-M3 及更高版本或其他架構（如 RX、PIC32 和 ARM Cortex-Ax）的設計。

消息傳遞常見的 IoT 方法非常重要，許多協議已遷移到發布/訂閱模型。由于連接和斷開連接的節點很多，并且這些節點需要連接到云中的各種應用程序，發布/訂閱請求/響應模型具有優勢。它動態響應隨機開/關操作，并且可以支持許多節點。

CoAP 和 HTTP/REST 兩種協議都基于請求響應而沒有發布/訂閱方法。在 CoAP 的情況下，使用 6LoWPAN 和 IPv6 的自動尋址來唯一標識節點。在 HTTP/REST 的情況下，方法是不同的，因為請求可以是任何東西，包括發布請求或訂閱請求，所以事實上，如果以這種方式設計，它就會成為一般情況。今天，這些協議正在合并以提供完整的發布/訂閱請求/響應模型。

系統架構多種多樣，包括客戶端服務器、樹形或星形、總線和 P2P。大多數使用客戶端-服務器，但其他使用總線和 P2P 方法。星形是一種截斷樹方法。這些各種架構都存在性能問題，通常在 P2P 和總線架構中可以找到最佳性能。模擬方法或原型方法在設計早期是首選，以防止意外。

可擴展性取決于在現場添加許多節點，并輕松增加云資源以服務這些新節點。各種架構具有不同的屬性。對于客戶端服務器架構，增加可用服務器池就足夠了，而且很容易。對于總線和 P2P 架構，規模是架構中固有的，但沒有云服務。在樹形或星形連接架構的情況下，可能會出現與在樹上添加額外葉子相關的問題，這會給通信節點帶來負擔。

可擴展性的另一個方面是處理大量變化的節點并將這些節點鏈接到云應用程序。如前所述，發布/訂閱請求/響應系統旨在實現可擴展性，因為它們處理因各種原因離線的節點，這允許應用程序在決定訂閱和請求數據時接收特定數據，從而實現精細的數據流控制。不太健壯的方法幾乎不能擴展。

低功耗和有損網絡具有打開和關閉的節點。這種動態行為可能會影響整個網絡部分，因此協議是為多路徑動態重新配置而設計的。ZigBee、ZigBee IP（使用 6LoWPAN）和本機 6LoWPAN 中的特定動態路由協議可確保網絡適應。如果沒有這些特性，處理這些節點就變成了一種不連續的操作，并且對節點的資源要求更高

隨著應用程序數量的增加，資源需求是關鍵。微控制器以非常低的成本提供智能，并有能力處理上面列出的問題。有些協議太耗費資源，無法在小節點上實用。除非包含大量串行閃存或其他存儲介質，否則不連續操作和大數據存儲將受到限制。隨著資源的增加，為了降低整體系統成本，更有可能添加聚合節點以提供額外的共享存儲資源。

互操作性對于未來的大多數設備至關重要。到目前為止，業界已經看到了多套單點解決方案，但最終用戶希望傳感器和設備能夠協同工作。通過使用一組標準化協議以及標準化消息傳遞，設備可以與支持它們的云服務分離。這種方法可以提供完整的設備互操作性。此外，使用智能發布/訂閱選項，不同的設備甚至可以使用相同的云服務，并提供不同的功能。使用開放的方法，應用標準將會出現，但今天 M2M 標準才剛剛出現，應用標準是未來幾年的事情。今天，所有主要協議都在標準化。

使用標準信息技術安全解決方案的安全性是大多數提供安全性的協議的核心安全機制。這些安全方法基于：

· TLS

· IPSec/VPN

· SSH

· SFTP

· 安全引導加載程序和自動回退

· 過濾

· HTTPS

· SNMP v3

· 加解密

· DTLS（僅用于 UDP 安全）

由于系統將部署多年，因此將安全作為軟件包的一部分進行設計是必不可少的。

實施要求

隱私是一項基本的實施要求。在隱私法的支持下，幾乎所有系統都需要與云進行安全通信，以確保無法訪問或修改個人數據并消除責任。此外，設備的管理和云中出現的數據需要分開管理。如果沒有此功能，用戶的關鍵個人信息將無法得到適當的保護，并且任何擁有管理權限的人都可以使用。

圖 2：使用兩個獨立的后端或云解決方案來分離管理和用戶數據是保證用戶隱私的首選解決方案。管理系統的計費和應用程序的計費也可以使用這種方法分開管理。

在系統架構圖中，我們展示了云內部系統管理和應用程序處理以滿足隱私法所需的兩個獨立組件。這兩個組件可能具有單獨的計費選項，并且可以在單獨的環境中運行。管理站還可能包括：

· 系統初始化

· 遠程現場服務選項（如現場升級、重置為默認參數和遠程測試）

· 用于計費目的的控制（例如帳戶禁用、帳戶啟用和計費功能）

· 用于盜竊目的的控制（相當于將設備變磚）

鑒于這種類型的架構，還應考慮其他協議和程序：

· 在云系統上定制開發的管理應用程序

· 傳感器節點集合的SNMP管理

· 云中的計費集成程序

· 支持使用在 Unison OS 上運行的 SQLite 的不連續操作來存儲和選擇性地將數據更新到云端

計費是商業系統的一個關鍵方面。電信運營商已經證明，按月付費模式是最佳的收入選擇。此外，用于無縫計費的自動服務選擇和集成也很重要。信用卡依賴也會產生問題，包括超額問題、過期卡和刪除帳戶。

自我支持的用戶也是實施成功的關鍵。這包括遠程現場服務，因此設備永遠不會返回工廠，智能或自動配置，在線幫助，社區幫助和非常直觀的產品都是關鍵。

應用程序集成也很重要。今天點系統占主導地位，但未來的關鍵是讓傳感器可用于用戶選擇的廣泛應用。準確性和可靠性會極大地影響結果應用結果，一旦標準接口出現，預計該領域的競爭就會出現。通過服務器的間接訪問可確保安全性、無需更改應用程序的演進和計費控制。

非連續運營和大數據齊頭并進。隨著設備隨機連接和斷開連接，需要為傳感器保存數據并稍后更新云。由于功率和成本原因，存在存儲限制。如果某些數據很重要，則可以保存它而丟棄其他數據。可能會保存所有數據，并稍后執行對云的選擇性更新。處理數據的算法可以在云或傳感器或任何中間節點中運行。所有這些選項都對傳感器、云、通信和外部應用程序提出了特殊挑戰。

多連接傳感器訪問也是使傳感器真正可用于廣泛應用的一項要求。這種連接很可能通過服務器進行，以簡化傳感器并消除重復消息的電源要求。

Unison OS 的物聯網協議

Unison RTOS 針對物聯網應用的小型微處理器和微控制器。因此，它提供了設計師期望的許多東西。Unison 的特點包括：

· POSIX API

· 廣泛的互聯網協議支持

· 各類無線支持

· 遠程現場服務

· USB

· 文件系統

· SQLite

· 安全模塊

這是對此處討論的廣泛協議集的現成支持和工廠支持的補充。