物聯(lián)網要求和協(xié)議

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

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

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

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

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

協(xié)議和供應商

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

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

與物聯(lián)網應用相關的基本假設是：

· 將使用各種無線連接

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

· 安全是核心要求

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

· 需要連接回云存儲

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

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

物聯(lián)網或 M2M 協(xié)議

對于協(xié)議棧中更高級別的 M2M 協(xié)議，有一組廣泛的協(xié)議被提升為物聯(lián)網通信的靈丹妙藥。請注意，這些 IoT 或 M2M 協(xié)議側重于應用程序數(shù)據傳輸和處理。以下列表總結了通?？紤]的協(xié)議。

· CoAP

· Continua – 家庭健康設備

· DDS

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

· HTTP/REST

· MQTT

· UPnP

· XMPP

· 零MQ

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

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

關鍵協(xié)議特性

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

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

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

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

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

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

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

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

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

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

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

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

· TLS

· IPSec/VPN

· SSH

· SFTP

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

· 過濾

· HTTPS

· SNMP v3

· 加解密

· DTLS（僅用于 UDP 安全）

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

實施要求

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

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

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

· 系統(tǒng)初始化

· 遠程現(xiàn)場服務選項（如現(xiàn)場升級、重置為默認參數(shù)和遠程測試）

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

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

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

· 在云系統(tǒng)上定制開發(fā)的管理應用程序

· 傳感器節(jié)點集合的SNMP管理

· 云中的計費集成程序

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

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

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

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

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

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

Unison OS 的物聯(lián)網協(xié)議

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

· POSIX API

· 廣泛的互聯(lián)網協(xié)議支持

· 各類無線支持

· 遠程現(xiàn)場服務

· USB

· 文件系統(tǒng)

· SQLite

· 安全模塊

這是對此處討論的廣泛協(xié)議集的現(xiàn)成支持和工廠支持的補充。

通過為物聯(lián)網開發(fā)提供一整套功能和模塊以及模塊化架構，開發(fā)人員可以插入他們選擇的物聯(lián)網開發(fā)協(xié)議。構建協(xié)議網關也是可能的。這種方法通過消除鎖定和縮短上市時間來最大限度地降低風險。

Unison 還具有可擴展性，使其能夠安裝到微型微控制器中，并為功能強大的微處理器提供全面支持。內存占用很小，直接導致非?？焖俚膶崿F(xiàn)。

物聯(lián)網協(xié)議

許多協(xié)議被吹捧為理想的物聯(lián)網 （IoT） 解決方案。通常，正確的協(xié)議選擇會被在其產品中擁有既得利益的供應商所掩蓋。用戶必須了解他們的具體要求和限制，并擁有精確的系統(tǒng)規(guī)范，以確保為各種管理、應用程序和通信功能選擇正確的協(xié)議集，并確保滿足所有實施規(guī)范。

RoweBots Unison RTOS 適合滿足物聯(lián)網需求，具有適用于各種協(xié)議的現(xiàn)成模塊和一整套支持模塊，可實現(xiàn)快速輕松的開發(fā)。

審核編輯：郭婷