概述

OPC UA是一種工業通訊協議，從2008年發展到今天，現在在業界已經非常的流行了。本文旨在介紹一些OPC UA的概念，分享一些相關經驗，希望對從事OPC UA相關工作的朋友有幫助。

02 OPC UA的資訊模型與統一架構

有一些朋友常常會說OPCUA之所以能夠如此普及是因為它能跨平臺。我個人覺得這不是一個充分條件。我個人認為OPCUA之所以能夠很廣泛的普及是因為它的統一架構與資訊模型做的太完善了。OPCUA的資訊模型來源於面向物件程式設計（OOP）的思想，這也是最契合實際需求的。

假設在工業現場有若干臺空調需要監控，首先我們需要監視它的溫度，溼度，執行狀態；其次我們需要對它進行啟停操作；然後我們需要接受它的非停事故報警資訊；最後我們常常需要分析某一時段的執行引數來判斷空調的狀態。運用面向物件程式設計的思想，我們建立一個類—空調，在這個類中分別定義相應的屬性，方法和事件，其中屬性即可以是簡單的資料，也可以是複雜的結構體。這個類即可理解成OPC UA的資訊模型。OPC UA將現場的這些實時資料(DA)，歷史資料(HDA)還有事故報警資料(A&E)，在同一平臺進行管理，即為統一架構。

用這種模式來通訊，效果怎麼樣呢？下面我們做一個簡單的演示。在unified automation公司出品的demo server中，已經定義了若干個空調，我們透過該公司出品的客戶端UA Expert進行監視。在選單欄的左側，列出了該空調的屬性，方法和事件；在右側中，這裡只是監視空調的溫度，溼度和執行狀態。這時，空調是停止(OFF)狀態。如果需要將空調啟動，並將執行目標溫度設定為比較舒服的25 ℃，只需要呼叫StartWithSetpoint方法，並在對話方塊中輸入目標值即可。

監控事件與報警資訊時，建立事件試圖並訂閱該空調的事件。空調的啟停狀態發生會觸發一個事件，空調處於停止狀態則會觸發一個報警，同時在客戶端也可以確認報警。

最後，如果在伺服器端，將空調某個屬性歷史儲存功能開啟，經過一段時間的儲存後，在客戶端就可以讀取歷史資料了。

這就是資訊模型與統一架構的魅力，讓一個通訊軟體有了HMI的感覺。

當然，OPC UA的這個資訊模型其實也不是在工控界獨領風騷的，在PTC的物聯網平臺Thingworx中的物模型（thing model），羅克韋爾的CIP協議也都是類似的面向物件的模型。所以說好的設計都是相似的，不好的設計各有各的磕磣。

03 OPC UA的安全性

工業通訊協議初期是以速率和穩定性優先的，那時候為了控制系統安全，很多網路都是與外網隔離的，因為已經被物理隔離，所以協議就沒有做任何的安全設計。而且以前處理的晶片處理能力有限，如果要做加密解密運算的話，會消耗很多的資源，所以只能為了時效性而犧牲安全性。想想Modbus協議，如果你能連線到網路裡，用ModScan是不是可以隨意的修改Modbus從站的資料，無需使用者認證，許可權控制；你也可以用一些類似Wireshark之類的抓包軟體很輕鬆的解析這些明文傳遞的資料包。可以說系統完全是在裸奔的情況下執行的。

不過因為系統與外界是隔離的，如果想攻擊它，你需要騙過廠門口的保安，躲過大狼狗，然後跑到車間，撬開控制櫃，接入網路，然後才能用駭客技術攻擊它。不過如果你已經這麼厲害了，是不是直接給控制器上潑一盆水，用這種物理攻擊更高效一些。

OPC UA的安全也是得到業內認可的，不過世界上也沒有絕對安全的協議。Synopsys公司在對一些工業通訊協議進行測試的時候還是發現了一些問題的。所以，OPCUA的安全還是有些工作要去做的。欲戴王冠，必承其重。

04 OPC UA與物聯網（IoT）

物聯網是一個很熱的話題，也實實在在的影響和改變著我們的生活。從上面OPC UA對一個空調的監控的例子中，不難發現OPC UA協議對物的監視與控制是很簡潔流暢的。同時又有了強大的安全性為它保駕護航，因此，在面對物聯網這個風口，OPC UA也希望將自己打造成一款IoT主流協議。OPC UA能夠很好的支援HTTPS，在與HTTPS配合時，可以傳送XML或者JSON格式的資料。

現在很多的物聯網平臺也已經支援OPC UA了，比如國外的Azure，國內的阿里雲等物聯網平臺。下圖是阿里雲的一個配置介面，接入閘道器協議中可以選擇OPC UA。

不過OPC UA最初的client與server之間的查詢與響應的一對一模式最適合通訊節點較少，通訊資訊量大且穩定持續的場景。在物聯網的應用場景中，往往通訊節點比較多，但是節點間的通訊量不大，有時還需要一對多、多對一通訊。如果還用一對一的模式去擁抱物聯網，容易撲個空。這時OPC UA引入了pub/sub機制，融合了一些MQTT協議，就能比較好的支援物聯網的場景了。相關的白皮書已於2018年釋出，感興趣的朋友可以去官網下載，看看細節。

05 OPC UA常用除錯工具

無論是開發OPCUA的產品，還是在現場除錯，常常需要一些除錯工具。這些工具包括客戶端和一些模擬伺服器，Matrikon, IntegrationObjects, unified-automation這些廠家都有出品，可以去官網免費下載的，使用也很簡單。這裡推薦unified-automation出品的除錯神器UA Expert和UA server。

在除錯通訊產品時，透過抓包，分析報文是很有效的手段。對於OPC UA協議，非常推薦使用抓包神器Wireshark來完成這項工作。Wireshark對OPCUA的支援也是很完善的，已經將OPCUA加入所支援的協議列表裡，預設的埠為4840.

開啟Wireshark,然後在OPC UA做些操作，比如browse節點。這時候在Wireshark中就能看到這個browse請求的細節，對照白皮書第四篇，瞬間秒懂各個細節。所以，只要左手Wireshark，右手OPC UA白皮書，兩天即可輕鬆實現從入門到精通。(其實學習任何網路協議都可以這樣，左手協議解析器，右手白皮書。)

06OPC UA開源庫

除了上面提到的除錯工具之外，現在網上也湧現出很多的OPC UA開源庫，開發的語言也是琳琅滿目。這也可以看出OPC UA的生態圈是非常好的。巧妙的使用這些庫可以很好的提高我們開發和測試產品的效率，比如完成一些功能測試，迴歸測試，效能測試，模糊測試等等。

這裡介紹兩款我個人比較喜歡的開源庫：

python-opcua：原始碼網址為：https://github.com/FreeOpcUa/python-opcua

優點：它最大的特點就是簡單，用pip install opcua安裝即可，經過幾年更新以後，對OPCUA協議的支援也越來越充分，既支援伺服器，又支援客戶端。下面是官網給出的例項，用不到30行程式碼就能建立一個包含一個動態點的伺服器。

缺點：這個庫的效能差一些；有部分OPC UA協議標準中定義的服務還沒有支援。最後，在使用的過程中發現存在一些bug。

UA-.NETStandard：源代網址為：https://github.com/OPCFoundation/UA-.NETStandard

優點：這個庫是OPC基金會官方出品的庫，包含伺服器，客戶端，可以在windows，linux執行，也可以在iOS和Android執行。它的效能很好，拿到了OPCUA實驗室的官方認證，對OPC UA協議標準支援的全面程度自然沒得說了。

缺點：從工控人的角度看，需要一些C#的程式設計技能，上手稍微慢一點，沒有Python那個庫容易學習。Git上同樣有一些例項工程，可以在它們的基礎上根據自己的開發和測試需求做修改。

07小結

可以說OPC UA的統一架構真的是包羅永珍，既能做實時資料，又能做歷史資料，既能上雲，又能嵌入到控制器，甚至可能被封裝到PLC中的功能碼，將觸角深入到工控通訊行業的各個角落。真所謂：可上九天攬月，可下五洋捉鱉。這從它超過14卷的白皮書就能看出它的野心。

而且OPC UA還是一款成長中的協議，還有很多的功能在拓展，比如：OPC UA還在與TSN技術融合，要在資料鏈路層搞點事情。