有一些朋友常常會說opcUA之所以能夠如此普及是因?yàn)樗芸缙脚_。遠(yuǎn)程I/O模塊覺得這不是一個充分條件。我個人認(rèn)為OPCUA之所以能夠很廣泛的普及是因?yàn)樗慕y(tǒng)一架構(gòu)與信息模型做的太完善了。OPCUA的信息模型來源于面向?qū)ο?a target="_blank">編程（OOP）的思想，這也是最契合實(shí)際需求的。

假設(shè)在工業(yè)現(xiàn)場有若干臺空調(diào)需要監(jiān)控，首先我們需要監(jiān)視它的溫度，濕度，運(yùn)行狀態(tài)；其次我們需要對它進(jìn)行啟停操作；然后我們需要接受它的非停事故報(bào)警信息；最后我們常常需要分析某一時段的運(yùn)行參數(shù)來判斷空調(diào)的狀態(tài)。運(yùn)用面向?qū)ο缶幊痰乃枷耄覀儎?chuàng)建一個類—空調(diào)，在這個類中分別定義相應(yīng)的屬性，方法和事件，其中屬性即可以是簡單的數(shù)據(jù)，也可以是復(fù)雜的結(jié)構(gòu)體。這個類即可理解成OPC UA的信息模型。OPC UA將現(xiàn)場的這些實(shí)時數(shù)據(jù)（DA），歷史數(shù)據(jù)（HDA）還有事故報(bào)警數(shù)據(jù)（A&E），在同一平臺進(jìn)行管理，即為統(tǒng)一架構(gòu)。

用這種模式來通訊，效果怎么樣呢？下面我們做一個簡單的演示。在unified automation公司出品的demo server中，已經(jīng)定義了若干個空調(diào)，我們通過該公司出品的客戶端UA Expert進(jìn)行監(jiān)視。在菜單欄的左側(cè)，列出了該空調(diào)的屬性，方法和事件；在右側(cè)中，這里只是監(jiān)視空調(diào)的溫度，濕度和運(yùn)行狀態(tài)。這時，空調(diào)是停止（OFF）狀態(tài)。如果需要將空調(diào)啟動，并將運(yùn)行目標(biāo)溫度設(shè)定為比較舒服的25℃，只需要調(diào)用StartWithSetpoint方法，并在對話框中輸入目標(biāo)值即可。

監(jiān)控事件與報(bào)警信息時，創(chuàng)建事件試圖并訂閱該空調(diào)的事件。空調(diào)的啟停狀態(tài)發(fā)生會觸發(fā)一個事件，空調(diào)處于停止?fàn)顟B(tài)則會觸發(fā)一個報(bào)警，同時在客戶端也可以確認(rèn)報(bào)警。

最后，如果在服務(wù)器端，將空調(diào)某個屬性歷史存儲功能打開，經(jīng)過一段時間的存儲后，在客戶端就可以讀取歷史數(shù)據(jù)了。

這就是信息模型與統(tǒng)一架構(gòu)的魅力，讓一個通訊軟件有了hmi的感覺。

當(dāng)然，OPC UA的這個信息模型其實(shí)也不是在工控界獨(dú)領(lǐng)風(fēng)騷的，在PTC的物聯(lián)網(wǎng)平臺Thingworx中的物模型（thing model），羅克韋爾的CIP協(xié)議也都是類似的面向?qū)ο蟮哪Ｐ汀Ｋ哉f好的設(shè)計(jì)都是相似的，不好的設(shè)計(jì)各有各的磕磣。

責(zé)任編輯：lq