1、OPC UA的信息模型與統一架構
有一些朋友常常會說OPCUA之所以能夠如此普及是因為它能跨平臺。遠程I/O模塊覺得這不是一個充分條件。我個人認為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協議也都是類似的面向對象的模型。所以說好的設計都是相似的，不好的設計各有各的磕磣。
2、OPC UA的安全性
工業通訊協議初期是以速率和穩定性優先的，那時候為了控制系統安全，很多網絡都是與外網隔離的，因為已經被物理隔離，所以協議就沒有做任何的安全設計。而且以前處理的芯片處理能力有限，如果要做加密解密運算的話，會消耗很多的資源，所以只能為了時效性而犧牲安全性。想想Modbus協議，如果你能連接到網絡里，用ModScan是不是可以隨意的修改Modbus從站的數據，無需用戶認證，權限控制；你也可以用一些類似Wireshark之類的抓包軟件很輕松的解析這些明文傳遞的數據包。可以說系統完全是在裸奔的情況下運行的。
不過因為系統與外界是隔離的，如果想攻擊它，你需要騙過廠門口的保安，躲過大狼狗，然后跑到車間，撬開控制柜，接入網絡，然后才能用黑客技術攻擊它。不過如果你已經這么厲害了，是不是直接給控制器上潑一盆水，用這種物理攻擊更高效一些。
但是現在這種情況發生了變化，因為工業網絡希望能夠插上互聯網的翅膀，去做OT與IT的融合，去做工業物聯網(IIOT)。所以，在這種需求下安全成為了最大的需求。就像王堅院士講：安全是互聯網公司的生命。在通訊的過程中面臨著眾多的外部安全威脅，例如：信息泄露，篡改指令，越權操作，偽造重發，泛濫攻擊等。面對這些威脅，OPC UA則使用加密，簽名，用戶認證，權限訪問控制，會話管理等方式一層一層完成深度防御。
OPC UA的安全也是得到業內認可的，不過世界上也沒有絕對安全的協議。Synopsys公司在對一些工業通訊協議進行測試的時候還是發現了一些問題的。所以，OPCUA的安全還是有些工作要去做的。欲戴王冠，必承其重。
3、OPC UA與物聯網(IoT)
物聯網是一個很熱的話題，也實實在在的影響和改變著我們的生活。從上面OPC UA對一個空調的監控的例子中，不難發現OPC UA協議對物的監視與控制是很簡潔流暢的。同時又有了強大的安全性為它保駕護航，因此，在面對物聯網這個風口，OPC UA也希望將自己打造成一款IoT主流協議。OPC UA能夠很好的支持HTTPS，在與HTTPS配合時，可以發送XML或者JSON格式的數據。
現在很多的物聯網平臺也已經支持OPC UA了，比如國外的Azure，國內的阿里云等物聯網平臺。
不過OPC UA最初的client與server之間的查詢與響應的一對一模式最適合通訊節點較少，通訊信息量大且穩定持續的場景。在物聯網的應用場景中，往往通訊節點比較多，但是節點間的通訊量不大，有時還需要一對多、多對一通訊。如果還用一對一的模式去擁抱物聯網，容易撲個空。這時OPC UA引入了pub/sub機制，融合了一些MQTT協議，就能比較好的支持物聯網的場景了。相關的白皮書已于2018年發布，感興趣的朋友可以去官網下載，看看細節。
4、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白皮書，兩天即可輕松實現從入門到精通。(其實學習任何網絡協議都可以這樣，左手協議解析器，右手白皮書。)
5、OPC UA開源庫
除了上面提到的調試工具之外，現在網上也涌現出很多的OPC UA開源庫，開發的語言也是琳瑯滿目。這也可以看出OPC UA的生態圈是非常好的。巧妙的使用這些庫可以很好的提高我們開發和測試產品的效率，比如完成一些功能測試，回歸測試，性能測試，模糊測試等等。
這里介紹兩款開源庫：
◆python-opcua：源代碼網址為：
優點：它最大的特點就是簡單，用pip install opcua安裝即可，經過幾年更新以后，對OPCUA協議的支持也越來越充分，既支持服務器，又支持客戶端。下面是官網給出的實例，用不到30行代碼就能創建一個包含一個動態點的服務器。
缺點：這個庫的性能差一些；有部分OPC UA協議標準中定義的服務還沒有支持。最后，在使用的過程中發現存在一些bug。
◆UA-.NETStandard：源代網址為：
優點：這個庫是OPC基金會官方出品的庫，包含服務器，客戶端，可以在windows，linux運行，也可以在iOS和Android運行。它的性能很好，拿到了OPCUA實驗室的官方認證，對OPC UA協議標準支持的全面程度自然沒得說了。
缺點：從工控人的角度看，需要一些C#的編程技能，上手稍微慢一點，沒有Python那個庫容易學習。Git上同樣有一些實例工程，可以在它們的基礎上根據自己的開發和測試需求做修改。
6、小結
可以說OPC UA的統一架構真的是包羅萬象，既能做實時數據，又能做歷史數據，既能上云，又能嵌入到控制器，甚至可能被封裝到PLC中的功能碼，將觸角深入到工控通訊行業的各個角落。真所謂：可上九天攬月，可下五洋捉鱉。這從它超過14卷的白皮書就能看出它的野心。而且還是一款成長中的協議，還有很多的功能在拓展，比如：OPC UA還在與TSN技術融合，要在數據鏈路層搞點事情。
作為吃瓜群眾，我有時候覺得OPC UA不只是想要統一架構，更是想一統江湖。可是世界上沒有完美的東西，這樣一個大而全的架構，它的缺點是什么？OPC UA又會用什么樣的方式完善呢？歡迎你也來聊聊你的想法！
相關閱讀
PCS 7通過OpenPCS 7站組件實現OPC UA通訊
通過OPC UA標準實現Kepware與SCADA軟件的數據交換
