0219 【萬泉河】論OPC UA協(xié)議對工控行業(yè)的重要性

OPC UA協(xié)議已經(jīng)推出來大約10多年了。 然而具體的年數(shù)不清楚，因為對于使用者來說， 推出協(xié)議沒啥用，重要的是需要有支持這個協(xié)議的產(chǎn)品。而且需要市面上支持的產(chǎn)品足夠多，產(chǎn)品之間互相通訊的時候可以選擇這個協(xié)議，然后才會重視它使用它。

所以，盡管OPC UA已經(jīng)誕生10多年，但在產(chǎn)業(yè)界，支持的產(chǎn)品力度還不夠的情況下，工控同行不重視它，甚至即便有使用過，但仍然不重視，也是正常的。

然而，我在這里要跟大家推薦的是， 對工控行業(yè)來說OPC UA會越來越重要，同行們需要逐漸認(rèn)識到它的重要性， 甚至有能力有前瞻性的工程師，從現(xiàn)在開始就要逐漸鋪墊積累，提前布局掌握它了。而更有能力的產(chǎn)品開發(fā)者，軟件開發(fā)者，則更可以從中發(fā)現(xiàn)商機，提前布局了。

關(guān)于OPC是什么，以及之前的OPC DA的概念，同行們應(yīng)該很熟悉了。 新入門的新手不懂的話可以自己從網(wǎng)上找相關(guān)文章看一看。

而關(guān)于OPC UA， 網(wǎng)上其實也早就有了很多概念性的介紹， 其中許多還是以通俗、簡介等目的介紹的。大家也不妨關(guān)鍵字搜索后逐篇過一下。了解個大概。

我這里絕不照抄所有網(wǎng)上已有文章內(nèi)容，只發(fā)表自己的觀點。請讀者獨立思考，客觀判斷， 有選擇地接受，謬誤之處，則請毫不留情的批評，拒絕。

UA是Unified Architecture 的簡寫，中文字面含義是統(tǒng)一架構(gòu)。

然而，如果從字面理解統(tǒng)一架構(gòu)，僅僅把他當(dāng)作已有所有OPC概念的升級版或者大一統(tǒng)，就徹底的錯了，就看不到其重要性了。

UA統(tǒng)一架構(gòu)的不是OPC自己，而是對操作系統(tǒng)平臺的統(tǒng)一。即，它是支持所有操作系統(tǒng)平臺之間的直接通訊。

操作系統(tǒng)就是除了微軟的WINDOWS系統(tǒng)， 其它所有的平臺都可以支持。 包括了各種我們現(xiàn)在耳熟能詳?shù)腖INUX,  ANDRIOD ,  IOS，CODESYS， 以及微軟自己的WINCE等等。以及未來可能出現(xiàn)并流行的所有的操作系統(tǒng)。

為什么講它可以通用于所有操作系統(tǒng)平臺？因為協(xié)議本身只定義了通訊協(xié)議的內(nèi)容。那么各廠家，各操作系統(tǒng)，只要能滿足協(xié)議規(guī)定的規(guī)范的內(nèi)容，則都可以實現(xiàn)。 所以具體的開發(fā)工作OPC基金會并不負(fù)責(zé)。 所以他當(dāng)然可以宣稱對所有平臺都支持，從而成為跨平臺的協(xié)議。因為他所定義的協(xié)議不依賴于操作系統(tǒng)。

而與此對應(yīng)的是老的OPC DA協(xié)議， 是嚴(yán)重依賴DCOM協(xié)議的，而DCOM協(xié)議是微軟推出的用于電腦間通訊的協(xié)議，微軟也曾經(jīng)參與了OPC DA的制訂，造成的后果便是，所有非微軟的操作系統(tǒng)平臺全部無法使用OPC DA協(xié)議，甚至微軟自己的WINCE。因為它們沒有能力支持DCOM。

進(jìn)一步造成的后果是，以往， 所有的人機界面設(shè)備在跟PLC通訊的時候， 如果不包含PLC品牌的驅(qū)動， 而需要走OPC協(xié)議的時候，就必須在電腦上安裝一個OPC SERVER的軟件中間件。 這個中間件作為一個后臺系統(tǒng)服務(wù)，一方面負(fù)責(zé)跟就地的PLC通訊，另一方面向本地或網(wǎng)絡(luò)內(nèi)的其他電腦設(shè)備提供OPC數(shù)據(jù)服務(wù)。

這個OPC SERVER軟件通常是由PLC廠家提供，比如西門子的 SIMATIC NET， 三菱的MX OPSERVER等等。同時也有一些通用于各廠家協(xié)議的專業(yè)的OPC SERVER軟件， 最著名的即大名鼎鼎的 KEPSERVER。

所以， 以往在實現(xiàn)OPC DA的通訊的配置中，貌似以為上位機軟件與PLC進(jìn)行OPC通訊， 其實不然。 其實電腦上跟PLC通訊的還是PLC的協(xié)議，如西門子的S7協(xié)議。 如果只有一臺電腦， 那么所謂的OPC通訊，只是電腦上的兩個程序進(jìn)程之間的通訊而已。 比如WINCC或者IFIX或者組態(tài)王跟 OPC SERVER之間的通信。

所以，那個時候，電腦跟PLC的通訊網(wǎng)絡(luò)各種各樣，基本都基于各廠家自己的協(xié)議和網(wǎng)卡， 有少部分以太網(wǎng)，但大部分是基于RS485的網(wǎng)絡(luò)。

然而，當(dāng)所有主流PLC都支持以太網(wǎng)的時候，電腦和PLC之間，以及觸摸屏和PLC之間都是通過交換機接到以太網(wǎng)的鏈接的時候， 通訊還要靠OPC來實現(xiàn)協(xié)議轉(zhuǎn)換， 第三方的觸摸屏如果沒有開發(fā)出針對特有品牌的通訊協(xié)議驅(qū)動的時候，有沒有通用協(xié)議？

沒有。這就很尷尬了。

而OPC UA的出現(xiàn)，解決了這個問題。

既然UA協(xié)議不依賴于平臺， 那么各廠家的PLC在自家平臺上大展神通， 只要其PLC有提供以太網(wǎng)口， 只要在以太網(wǎng)口上實現(xiàn)了OPC UA SERVER功能， 那么所有的OPC 客戶端都可以直接來訪問，而不再依賴于一個特定的OPC SERVER 中間件。

如此可以實現(xiàn)：
1，    觸摸屏通過OPC UA協(xié)議直接訪問PLC。
2，    不同的PLC之間通過OPC UA協(xié)議訪問。
3，    上位機電腦SCADA上位機軟件直接與PLC通訊。

這些功能擴展都是以前OPC DA協(xié)議時不可能實現(xiàn)的。
其中，1和2是完全全新的配置模式，而3的變化比較少，僅僅少了OPC SERVER中間件。

這對各PLC廠商無所謂， 他們反而可以省了開發(fā)OPC SERVER 軟件的人力，不過這部分研發(fā)人員轉(zhuǎn)向其自身嵌入系統(tǒng)的OPC UA SERVER的功能開發(fā)，大致可以相當(dāng)于不虧不賺。

然而對專業(yè)售賣OPC SERVER的軟件公司，比如KEP和MATRIK等來說，幾乎是滅頂之災(zāi)。因為沒有他們的生存空間了。若干年后，當(dāng)所有品牌PLC和HMI, SCADA都支持了OPC UA之后，就沒人再需要他們了。

所以，站在專業(yè)OPC SERVER軟件的角度， 描述OPC UA的態(tài)度就會很曖昧，就會很言不由衷，比如會不會有意無意發(fā)表一些誤導(dǎo)同行的觀點。

比如許多同行所理解的OPC UA，談到優(yōu)點的時候僅僅是在電腦之間做通訊的時候不需要配置DCOM，而過去據(jù)說DCOM配置起來相當(dāng)麻煩，非常難以成功。

從我個人的經(jīng)驗，DCOM完全沒有傳說中的那么難。 給一個簡單的提示， 如果一臺電腦完全安裝好需要的所有控制軟件后， 直接克隆到另一臺，之后對方僅僅更改電腦名，即兩臺電腦的操作系統(tǒng)、軟件環(huán)境完全一致， 用戶名和密碼等全部都一致的情況下， OPC DA通訊可以直接成功，不需要為DCOM做任何的配置，甚至完全可以無視。

所以，當(dāng)我看到許多人對OPC UA的錯誤言論的時候，首先猜測他們是不是因為受到了一些刻意的誤導(dǎo)。

然而，我所列出的上述的 OPC UA的優(yōu)點好像并不能引起很多人的興趣。也更不覺得有何重要性而言。

是的，一直以來我也這么認(rèn)為的。因為到目前為止， 不管是觸摸屏還是上位機軟件，當(dāng)下都有通訊實現(xiàn)方案，也不覺得有多少痛點。


而真正的重點在后面。

進(jìn)入重點之前， 先看一篇我2年前寫過的一篇文章：
《【萬泉河】PLC編程：我夢寐以求的符號尋址》
http://www.ad.siemens.com.cn/club/bbs/PostStory.aspx?a_id=1565815&b_id=80


當(dāng)時我苦苦追求的符號尋址，后來發(fā)現(xiàn)， 解決方案竟然是OPC UA。

西門子WINCC和S7-1500之間的通訊自然有固有的方法， 然而換一些品牌，比如把WINCC換為觸摸屏， 甚至第三方品牌觸摸屏的時候， 逐漸發(fā)現(xiàn)OPC UA才是最完美的解決之道，而且因為UA的統(tǒng)一架構(gòu)， 那么會成為所有品牌的統(tǒng)一解決方案。

即， OPC UA可以實現(xiàn)對PLC的符號尋址。

對所有品牌PLC。 甚至對S7-1200/1500，都不再需要數(shù)據(jù)塊非優(yōu)化。即，即便是優(yōu)化的數(shù)據(jù)塊， 也可以通過OPC UA直接進(jìn)行數(shù)據(jù)通訊，因為這種通訊已經(jīng)不需要絕對地址了。

有了OPC UA， 如果觸摸屏也支持了（現(xiàn)在已經(jīng)開始有品牌支持），那么只要選擇OPC UA通道，對PLC的數(shù)據(jù)就可以直接建立訪問。

然而，需要客戶端軟件有完備的瀏覽變量功能。

通過在線瀏覽變量，就可以選擇并在數(shù)秒內(nèi)建立所有需要的變量。

這相當(dāng)便捷。

所以，去年我在開發(fā)其他品牌的標(biāo)準(zhǔn)化架構(gòu)的時候，最看重的是這個品牌的PLC是否已經(jīng)支持了OPC UA，因為只要支持，只要把UA通訊打通， 那我就不需要再學(xué)別的通訊方案了。 工作量也大為簡化了。 原有的WINCC程序可以直接無縫對接移植過來。

如果是真實的工程項目，這種無縫移植帶來的高效率自是無可比擬的。 所耗費的時間簡直忽略不計��！

而更進(jìn)一步， 如果所有的上位機軟件如果也支持OPC UA， 那只要再做一套上位機的項目程序模板，在項目開發(fā)、程序移植各環(huán)節(jié)的工作量，也全部非常簡單。從wincc到上位機， 從一個項目的上位機到下一個項目的上位機。都會帶來異乎尋常的高效率體驗。

甚至， 在OPC UA的協(xié)議規(guī)范中，還特別涉及了對面向?qū)ο蟮闹С帧？梢园岩粋�設(shè)備對象的數(shù)據(jù)打包整體對接，這些工作到目前為止，都還在幻想藍(lán)圖里，還沒有落地成為現(xiàn)實，所以絕對值得我們每個人期待。。。。

我在前面一篇文章推薦過的上位機開發(fā)工具PCHMI.DLL，

《0210【萬泉河】用組態(tài)觸摸屏程序的方法生成上位機EXE軟件》
https://mp.weixin.qq.com/s/5hfgLZrWNvnt0TqopDDQcg

這個工具里面包含了對OPC UA的支持，然而我研究后發(fā)現(xiàn)，其支持力度還很弱， 甚至作者對OPC UA的理解都很淺，當(dāng)然也是因為不重視， 不感興趣，因而更不支持變量瀏覽功能。所以要達(dá)到實戰(zhàn)功能， 能實現(xiàn)我們要求的符號尋址，都還有很長的路要走。

所以暫時放棄了UA路線， 還是先能實現(xiàn)與BST的對接為目標(biāo)，先實現(xiàn)彈出式窗口的設(shè)計操作模式。變量效率的提高方面，可以作為將來的話題。

然而，我發(fā)現(xiàn)工控同行中的大多數(shù)，通常思想懶惰，沒有上進(jìn)心。

當(dāng)遇到各種功能實現(xiàn)不了效率低下的時候，不會首先審視是不是自己的能力和水平的原因，而是只會自顧個兒的在那兒抱怨，更不會想到自己挖掘其中的需求，找到好的解決方案，除了能提高自己的工作效率，同時說不定還能為自己儲備積累一些資源。

我上周與一位有C#經(jīng)驗的朋友交流開發(fā)需求的時候， 對方竟然指點我去找某某高手去定制開發(fā)， 完全沒有看到這其中存在的機會。

當(dāng)所有人都在抱怨這個行業(yè)臟苦累的時候，有沒有想過這其中反而蘊藏了無限的機會， 你只要能做出一點點創(chuàng)新， 幫助別人有一點點效率的提高， 都有可能為你自己帶來豐富的回報。

越是落后的行業(yè)，機會越多。 如果你時常抱怨這個行業(yè)落后，那說明機會就擺在你面前。

就看你有沒有能力抓住機遇。

最后，上文中征集PCHMI二次開發(fā)合作項目繼續(xù)進(jìn)行中，目前響應(yīng)者了了。說明這個行業(yè)具備這項能力且工作之余有閑暇進(jìn)行技術(shù)開發(fā)的人還太少了， 說明了什么， 說明這里面都是機會�。�