pub-sub網(wǎng)絡(luò)通訊模式 可解決IIoT建置常見問題

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

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

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

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

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

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

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

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

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