本文概述多種通訊協定的作用，並說明這些協定的可用選項，以便設計工程師更輕鬆挑選最適合的進行整合。然而任何通訊協定都有其優缺點，開放原始碼的選擇則可快速部署，且具有最適合 IoT 應用的安全性。

圖1 : 工業自動化中的 IIoT 功能仰賴越來越多連網裝置採用工業通訊協定達到連網。這些網路的抽象層無需底層功能的專業知識，這也是為何有如此多設計工程師都專注在機器網路頂層 （應用） 的原因。（source：Getty Images）

採用物聯網（IoT）與工業4.0功能後，裝置透過工業通訊協定連網的情況逐漸普及。除此之外，如今的機器對機器（M2M）通訊協定也迅速成為這些協定的標準化選擇之一。比較複雜的是，IoT通訊協定並不會描述單一應用層的通訊協定，因為有多個標準同時操作中。因此，除了早期IoT實作使用的標準網際網路通訊協定外，目前更有專用的 IoT 通訊協定。

製作通訊結構的模型及判定適合特定應用的通訊協定並不容易。本文將概述多種通訊協定的作用，並說明這些協定的可用選項，以便設計工程師更輕鬆挑選最適合的進行整合。

制訂工業網路的應用層通訊協定

數位M2M與IoT系統的通訊協定結構在概念上可分成不同的的抽象層，最常見的模型有三、四、五或七層。這些概念架構會假定每一層基本上會對與其通訊的其他裝置或演算法，「隱藏」指定裝置或軟體層的詳細作業。這是因為這些層級制訂成，僅含有方便交換手邊資料的足夠資訊而已。

圖2 : 傳統的系統架構屬於階級式，但雲端和霧運算則打破元件功能間的界限。因此促進了新型網路通訊協定模型的運用。（source：motioncontroltips.com）

無論採用的模型為何，皆會建立應用層，在彼此透過網路通訊的裝置之間當作最高的抽象層。可將應用層當作開放式系統互連（OSI）模型的一個概念。此模型是由國際標準化組織（ISO）在將近三十年前針對網路通訊所制訂。此傳統的七層模型已經有點太過複雜，不適合描述如今一些通訊協定，但若要完整瞭解系統中的資料流，仍然相當實用。

通訊協定的實體層可將原始資料（數位位元）以電氣、無線電或光學訊號的方式傳遞。此層級會針對承載資料的實體元件規定其引腳佈局、電壓位準、數據傳輸率以及線路阻抗。乙太網路是常見的實體層通訊協定。

資料鏈層會將網路節點連接到裝置，以建立連線並修正實體層的錯誤。在 IEEE 802 標準中，資料鏈層分為媒體存取控制（MAC）層（一樣是用來讓裝置連線）以及邏輯鏈路控制（LLC）層，可用來辨識要使用的下一層（網路層），並進行錯誤檢查與同步處理。

相反地，網路層則可轉送資料封包到網路位址。網際網路通訊協定是指傳輸控制通訊協定以及網際網路協定（TCP/IP）模型（本文下一章節講解），且在資料鏈與網路層之間有網際網路層。事實上，網際網路層通嘗試為網路層的一部份。

接下來三個 OSI 模型層級的第一個是傳輸層，可確保在資料序列傳輸時達到通訊可靠度與安全性。作業階段層會控制裝置何時要彼此連線，以及連線屬於單向（單工）或雙向 （雙工）。最後，表現層可達到資料轉換，以便使用不同語法的裝置進行通訊。

本文的焦點應用層是最高層級的抽象層，也是使用者與系統軟體互動的一層。

圖3 : 現代化網路通訊協定（及應用層）通常是使用工業（與商業）網路的傳統 OSI 模型進行描述。相反地，三層 IoT 架構模型會將應用層設立在感知層與網路層上方；四層模型則會設立在資料處理、網路、與感測層的上方。五層 IoT 通訊協定模型也類似，但多了處理與企業層。（source：Design World）

工業自動化中的網際網路通訊協定

網際網路通訊協定屬於資料通訊系統，是以其在網路之間傳遞資料（通常為相互進行），達到邊界間通訊而命名。其功能通常以上述 TCP/IP 的四層模型進行描述。在此，實體層或鏈路層與 OSI 模型的實體層相同。相反地，TCP/IP 的網際網路層（大致上類似於 OSI 模型的資料鏈與網路層功能合併）則會處理連線以及資料封包。在IPv6中，此層級採用 128 位元 IP 位址來辨識網路上的主機，而且可允許超過 1038個獨特主機。

TCP/IP 的傳輸層通常由傳輸控制通訊協定（TCP）或使用者資料包通訊協定（UDP）組成。TCP通常用於人員互動，例如電子郵件與網路瀏覽。可提供邏輯連線、封包傳輸通知、遺失封包重新傳輸，以及流程控制。然而，嵌入式系統則會使用UDP來達到更低的額外負荷並達到更優異的即時效能。UDP 可用於網域名稱伺服器（DNS）、動態主機設定通訊協定（DHCP）以及新式IoT應用。

應用層是TCP/IP網路模型的最高層級。功能包括與 OSI 模型作業階段與表現層相關的功能。

一般 TCP/IP 應用層通訊協定

不同的應用層通訊協定在資料頻寬、即時能力與硬體要求上也有所不同。這些因素再加上工廠或OEM團隊對通訊協定的熟悉度，往往是重要的挑選條件。早期的網際網路通訊協定，包括超文字傳輸通訊協定（HTTP）與簡易郵件傳輸通訊協定（SMTP）在內，大多數都用於人員導向及人員使用的通訊作業，但IIoT導向的TCP/IP通訊協定則更著墨在機器對機器（M2M）與其他工業通訊。

比較複雜的是，TCP/IP中有多少已制訂的應用層通訊協定，原本是在網路上讓人員與資訊互動的，但其實也有消費性與工業 IoT 的用途。HTTP 與 SMTP，以及安全殼層 （SSH）和檔案傳輸通訊協定（FTP）正是這樣的例子。若使用可延伸標記語言（XML）和 JavaScript 物件標記法（JSON），通常是可以實作IoT功能搭配網路技術的。

要注意的是，使用HTTP會有安全疑慮。這就是為何這類系統中的任何IoT裝置最好只含有一個用戶端，而非伺服器的原因。如此才可避免裝置收到有可能會允許外部未授權網路存取連線的要求。

在此，WebSocket通訊協定可透過HTTP建立全雙工通訊。否則對於需要因應大量裝置又要兼顧良好安全性與即時資料通訊的設備來說，可能會偏好使用可延伸傳訊與顯示通訊協定（XMPP）。

若IoT專案是由具有IT背景知識的人員領導，可能會偏好使用這些熟悉的標準（從人類可讀網路）。然而較新型的 IIoT 通訊協定在某些情況下會更適合M2M及其他工業通訊。

MQTT 可用於垂直連線傳輸功能

在IIoT中最迅速受到採用的是訊息佇列遙測傳輸（MQTT）通訊協定，此精簡型通訊協定最初是用於記憶體有限的 IoT 裝置。MQTT可在小巧的處理覆蓋區上進行操作，且只需要最小的頻寬，一開始是由 IBM 開發用來連接油管上的感測器。與受限型應用通訊協定（CoAP）不一樣的是，MQTT已經依據 ISO/IEC 20922通過標準化。MQTT採用更為資源密集的TCP傳輸層，因此會耗用更多電力，但訊息大小可以只有兩個位元組，甚至比CoAP的還要小。

由於具備開放式本質，MQTT 也特別容易實作。難怪 Amazon Web Service的AWS IoT 採用MQTT進行訊息傳輸（含注意事項），並且依據v3.1.1規範支援MQTT。

相較於即將要講述的IoT專用精簡型機器對機器（LwM2M）通訊協定來說，MQTT有一些限制，可能是MQTT原本是要當作遙測通訊協定使用的緣故。此標準不包含物件、連線監測、遠端裝置動作等特點，因此若包含這些特點，通常都是由廠商決定，但多少會讓標準化通訊協定的價值降級。MQTT也提供無錯誤處理能力。最後，即便MQTT可採用完整TLS通訊協定提升安全性，但這會增加額外負荷。

主要用於企業層級：AMQP

進階訊息佇列通訊協定（AMQP）是另一種開放式標準，有點類似 MQTT。提供訊息佇列等進階功能。只是AMQP 的額外負擔比 MQTT 更高，因此不太適合連接受限較多的裝置。難怪此通訊協定不常用於工業 IoT 應用，而較常用於講究效能的企業傳訊。

連接簡易型裝置的 CoAP

網際網路工程工作小組（IETF）制訂的受限型應用通訊協定（CoAP），可讓僅有最少記憶體與處理能力的裝置，彼此在低功率網路中進行通訊。可在超低額外負荷與要求下操作，且回應最小僅有四位元組。CoAP會避免使用複雜的傳輸堆疊，而改為使用UDP。

CoAP跟HTTP一樣，都採用REST模型。伺服器會用 URL 提供可用資源，而用戶端可透過POST、GET、DELETE與PUT方法存取資源。除此之外，CoAP更可輕易轉換成 HTTP，以便與其他網路功能進行整合，也可整合 XML 與JSON。工程師可發現利用 CoAP連接 IoT裝置，與使用 Web API 連接裝置非常類似。

圖4 : Nordic的SiP屬於低功率MCU，具有整合式 LTE-M和窄頻（NB）-IoT數據機，以及GPS。有提供軟體開發套件，可設定CoAP。（source：Nordic Semiconductor）

使用 LwM2M 連接電池供電式裝置

開放行動通訊聯盟（Open Mobile Alliance）制訂的應用層通訊協定之一就是 LwM2M，專門針對IoT應用而打造。LwM2M以CoAP為基礎，因此共用諸多屬性，可用於智慧城市應用、貨櫃、卡車追蹤、自動化非公路例行作業，以及公用事業監測。此標準含有多種清楚界定與維護的標準物件，以及連線監測與遠端裝置動作。自動化韌體升級亦可簡化 LwM2M 連線裝置的管理作業。雖然納入JSON等模組會增加額外負荷，但也可讓開發人員更輕鬆進行設計工作。因為LwM2M專門針對IoT應用而設計，因此也可當作強大的DTLS安全通訊協定使用，且不會增加額外負荷。

DDS 適用於即時分散式應用

資料分散式服務（DDS）則有些許不同，通常會歸類為M2M中介軟體，而非應用層通訊協定。可在自駕車、發電、空中交通控制系統等應用中提供安全且高效能的連線。在這些應用中，DDS可支援嵌入式系統連線達到分散式控制，以免過度依賴閘道器。DDS亦可處理訊息的路由與傳遞，無需應用的干預。此外，DDS服務參數的品質可進行設定，因此可在系統限制下，將網路作業達到符合工作需求的最佳化程度。

圖5 : 自駕車用的 Connext Drive軟體是以資料分散式服務（DDS）中介軟體為基礎打造。而DDS可當作汽車開放式系統架構（AUTOSAR）Adaptive與 ROS2軟體架構的部分基礎。這僅是DDS支援IoT軟體整合的例子之一。（source：Real-Time Innovations）

結論：IIoT 應用層通訊協定

任何通訊協定都有其優缺點，但開放原始碼的選擇則可快速部署，且具有最適合IoT應用的安全性（因額外負荷低，因此偏好使用）。嵌入式系統與系統單晶片（SoC）裝置的運算能力日益提升，因此持續促進IIoT的實作，且更進一步擴充各種通訊協定應用層的潛在應用。

（本文作者Jody Muelaner為工程師，目前指導開發電動單車專案，也參與除碳技術的相關開發工作，屬於Digi-Key公司北美編輯群之一）