有一些朋友常常會說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協議也都是類似的面向對象的模型。所以說好的設計都是相似的，不好的設計各有各的磕磣。

責任編輯：lq