01

發(fā)布者/訂閱者模型

Pub/Sub模型與客戶端/服務(wù)器模型完全不同，但在OPC UA中，兩者有相似之處。

在Pub/Sub模型中，我們有一個Publisher（發(fā)布者）組件，它可以定義為包含變量或事件類型的數(shù)據(jù)集。發(fā)布者將發(fā)布DataSetMessages（數(shù)據(jù)設(shè)置管理）信息，其中分別包含數(shù)據(jù)變化或事件的內(nèi)容。因此傳輸?shù)臄?shù)據(jù)類似于客戶端/服務(wù)器訂閱。但它的排列方式有點不同。

消息被發(fā)布到網(wǎng)絡(luò)中，訂閱者可以在網(wǎng)絡(luò)中收聽消息并過濾所需內(nèi)容。因此，與客戶端/服務(wù)器模型中的訂閱相反，是由發(fā)送方在數(shù)據(jù)集中定義將發(fā)送什么，而不是接收方。否則，DatasetMessages中的數(shù)據(jù)基本上與NotificationMessages中的數(shù)據(jù)相同(盡管格式不同)。

該模型可擴展，因為理論上可以有任意數(shù)量的發(fā)布者和任意數(shù)量的訂閱者。它們都通過同一網(wǎng)絡(luò)連接，但不是彼此連接，這是對客戶端/服務(wù)器模型的主要改進。

02

Pub/Sub模型的網(wǎng)絡(luò)類型

OPC UA為Pub/Sub定義了兩種不同的網(wǎng)絡(luò)類型。

1.本地網(wǎng)絡(luò)——可以使用UDP廣播(或在某些情況下單播)或以太網(wǎng)APL。消息是OPC UA規(guī)范中定義的優(yōu)化二進制UADP。因此，只有OPC UA訂閱者可以解釋消息。

2.消息隊列代理——實際上可以是MQTT或AMQP代理。在這種情況下，消息通常是JSON消息，可以使用UADP來提高性能。OPC基金會為信息定義了一個標準的內(nèi)容結(jié)構(gòu)，但基本上任何JSON訂閱者都可以解釋和理解它們。

03

Pub/Sub模型的優(yōu)缺點

Pub/Sub模型解決了網(wǎng)絡(luò)可伸縮性的問題，因此像MQTT這種協(xié)議已經(jīng)在許多(非OPC UA)應(yīng)用程序中非常流行，在這些應(yīng)用程序中，您需要連接數(shù)千個數(shù)據(jù)提供者，例如連接到中央監(jiān)控的小型傳感器或遠程表。因此OPC UA為消息內(nèi)容添加了一些標準化格式，以及將OPC UA數(shù)據(jù)映射到消息內(nèi)容的標準方法。

另一方面，OPC UA使用Pub/Sub模型在本地網(wǎng)絡(luò)中實現(xiàn)非常快速的通信，一旦網(wǎng)絡(luò)通過以太網(wǎng)TSN和APL技術(shù)變得確定和快速，我們可以預見通過OPC UA Pub/Sub進行實時通信的可能性。這就是OPC UA現(xiàn)場級通信(FLC)計劃的全部內(nèi)容，以及新的現(xiàn)場交換(FX)規(guī)范可以提供的內(nèi)容。

04

Pub/Sub場景

世界正緩慢地從基于自動化金字塔的工業(yè)3.0轉(zhuǎn)向工業(yè)4.0，在工業(yè)4.0中，工廠中的所有組件都連接到生產(chǎn)網(wǎng)絡(luò)。客戶端/服務(wù)器模型非常適合以前的工廠，在那里的智能組件的數(shù)量很少，連接也很少。在新的工業(yè)4.0中，當共享網(wǎng)絡(luò)生產(chǎn)和消費信息的組件數(shù)量增加時，連接問題可能會爆發(fā)，Pub/Sub模式應(yīng)該更適合這樣的新環(huán)境。

點此查看客戶端/服務(wù)器模型的歷史介紹文章

實際在大多數(shù)情況下，Pub/Sub可以與客戶端/服務(wù)器模型結(jié)合。這允許網(wǎng)絡(luò)構(gòu)建人員將發(fā)布服務(wù)器添加到服務(wù)器，將訂閱服務(wù)器添加到客戶端或任何其他組合。

05

結(jié)論

因此，我們?nèi)匀恍枰狾PC UA客戶端/服務(wù)器模型，以便能夠在典型的SCADA場景中“同步”通信。我們介紹了Pub/Sub模型，并通過它實現(xiàn)了更好的可伸縮性的網(wǎng)絡(luò)，并且提高了通信性能，這使其成為實時通信的優(yōu)質(zhì)備選方案。我們預測Pub/Sub模型在OPC UA現(xiàn)場級通信(FLC)計劃和新的現(xiàn)場交換(FX)標準中也發(fā)揮著重要作用。