支持MQTT與Sparkplug的發(fā)布-訂閱(publish-subscribe；pub-sub)網絡通訊模式，可解決工業(yè)物聯(lián)網(IIoT)應用常見的問題?？蛻舳藘H向外聯(lián)機至broker能提升安全性；提供聯(lián)機不穩(wěn)定的遠程裝置壓縮載荷(compressed payload)與狀態(tài)通訊(stateful communicaTIon)可確保資料傳輸可擴充性；離線裝置自動重新聯(lián)機與資料傳輸功能則減少對IT的倚賴。

據報導，IIoT應用須取得控制系統(tǒng)與設備中的資料，但不能被允許直接存取這些系統(tǒng)以確保安全；IIoT應用擷取的資料涵蓋本地與遠程設施的系統(tǒng)與設備，由于范圍廣泛資料擷取(data acquisiTIon)的可擴充性是關鍵課題；IT有本身的優(yōu)先事務，可能無法實時配合IIoT的需求。因此選擇能處理這些問題的資料通訊模式至為關鍵。

要求-回應(request-response)網絡通訊模式在自動化環(huán)境中，典型的客戶端為PC上的人機接口(HMI)，向控制器要求資料，而與生產現場傳感器聯(lián)機的可程序邏輯控制器(PLC)或可程序自動化控制器(PAC)則是回應HMI提供資料的服務器。

在要求-回應模式下，HMI與控制器間必須建立各別的直接聯(lián)機，且由于控制器資料更新時間不定，HMI需定期要求資料，而每個控制器也要不斷重覆回應所有HMI的要求。

若控制器能力與網絡帶寬充足，則要求-回應是經過驗證的可靠模式，適合安全的內部網絡。不過在多重HMI與多重控制器的自動化環(huán)境，網絡的流量很快會產生問題。

pub-sub網絡通訊模式中，所有的資料由中介的broker或服務器負責接收與分送，pub-sub的客戶端可向broker發(fā)布與訂閱資料。發(fā)布方以主動回報狀況變化(report by excepTIon)方式發(fā)布資料，僅傳送更新給broker，broker并不儲存資料，而是實時自動轉傳給訂閱這項資料的客戶端。

pub-sub模式在多重訂閱方與發(fā)布方的自動化環(huán)境，訂閱方與發(fā)布方不需建立個別的直接聯(lián)機，而由每個裝置與broker間的單一直接聯(lián)機取代，且由于僅傳輸更新的資料，網絡負擔顯著降低，因此能運用低帶寬、高成本或不可靠的網絡傳送資料，相當適合遠程設備監(jiān)測等IIoT應用。

pub-sub的傳輸協(xié)定MQTT發(fā)展于1999年，日后成為國際標準組織(ISO)與OASIS的標準，Cirrus Link SoluTIons于2016年發(fā)表Sparkplug規(guī)格，新增binary封裝(encapsulation)、裝置狀態(tài)(device state)與主題定義(topic definition)，讓MQTT更容易建置且更適合工業(yè)環(huán)境的關鍵應用。

由于所有MQTT與Sparkplug資料都是向外傳送，IIoT應用在安全性與IT支持的顧慮都可降至最低。此外，支持MQTT與Sparkplug的pub-sub架構，資料通訊方式的網絡負荷較輕，能讓大量資料以高效率且stateful的方式在多重訂閱方與發(fā)布方之間傳輸，解決資料傳輸可擴充性的問題。