0219 【萬泉河】論OPC UA協(xié)議對工控行業(yè)的重要性
OPC UA協(xié)議已經(jīng)推出來大約10多年了。 然而具體的年數(shù)不清楚,因?yàn)閷τ谑褂谜邅碚f, 推出協(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)商機(jī),提前布局了。
關(guān)于OPC是什么,以及之前的OPC DA的概念,同行們應(yīng)該很熟悉了。 新入門的新手不懂的話可以自己從網(wǎng)上找相關(guān)文章看一看。
而關(guān)于OPC UA, 網(wǎng)上其實(shí)也早就有了很多概念性的介紹, 其中許多還是以通俗、簡介等目的介紹的。大家也不妨關(guān)鍵字搜索后逐篇過一下。了解個大概。
我這里絕不照抄所有網(wǎng)上已有文章內(nèi)容,只發(fā)表自己的觀點(diǎn)。請讀者獨(dú)立思考,客觀判斷, 有選擇地接受,謬誤之處,則請毫不留情的批評,拒絕。
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)平臺?因?yàn)閰f(xié)議本身只定義了通訊協(xié)議的內(nèi)容。那么各廠家,各操作系統(tǒng),只要能滿足協(xié)議規(guī)定的規(guī)范的內(nèi)容,則都可以實(shí)現(xiàn)。 所以具體的開發(fā)工作OPC基金會并不負(fù)責(zé)。 所以他當(dāng)然可以宣稱對所有平臺都支持,從而成為跨平臺的協(xié)議。因?yàn)樗x的協(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。因?yàn)樗鼈儧]有能力支持DCOM。
進(jìn)一步造成的后果是,以往, 所有的人機(jī)界面設(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。
所以, 以往在實(shí)現(xiàn)OPC DA的通訊的配置中,貌似以為上位機(jī)軟件與PLC進(jìn)行OPC通訊, 其實(shí)不然。 其實(shí)電腦上跟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之間都是通過交換機(jī)接到以太網(wǎng)的鏈接的時候, 通訊還要靠OPC來實(shí)現(xiàn)協(xié)議轉(zhuǎn)換, 第三方的觸摸屏如果沒有開發(fā)出針對特有品牌的通訊協(xié)議驅(qū)動的時候,有沒有通用協(xié)議?
沒有。這就很尷尬了。
而OPC UA的出現(xiàn),解決了這個問題。
既然UA協(xié)議不依賴于平臺, 那么各廠家的PLC在自家平臺上大展神通, 只要其PLC有提供以太網(wǎng)口, 只要在以太網(wǎng)口上實(shí)現(xiàn)了OPC UA SERVER功能, 那么所有的OPC 客戶端都可以直接來訪問,而不再依賴于一個特定的OPC SERVER 中間件。
如此可以實(shí)現(xiàn):
1, 觸摸屏通過OPC UA協(xié)議直接訪問PLC。
2, 不同的PLC之間通過OPC UA協(xié)議訪問。
3, 上位機(jī)電腦SCADA上位機(jī)軟件直接與PLC通訊。
這些功能擴(kuò)展都是以前OPC DA協(xié)議時不可能實(shí)現(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)。因?yàn)闆]有他們的生存空間了。若干年后,當(dāng)所有品牌PLC和HMI, SCADA都支持了OPC UA之后,就沒人再需要他們了。
所以,站在專業(yè)OPC SERVER軟件的角度, 描述OPC UA的態(tài)度就會很曖昧,就會很言不由衷,比如會不會有意無意發(fā)表一些誤導(dǎo)同行的觀點(diǎn)。
比如許多同行所理解的OPC UA,談到優(yōu)點(diǎn)的時候僅僅是在電腦之間做通訊的時候不需要配置DCOM,而過去據(jù)說DCOM配置起來相當(dāng)麻煩,非常難以成功。
從我個人的經(jīng)驗(yàn),DCOM完全沒有傳說中的那么難。 給一個簡單的提示, 如果一臺電腦完全安裝好需要的所有控制軟件后, 直接克隆到另一臺,之后對方僅僅更改電腦名,即兩臺電腦的操作系統(tǒng)、軟件環(huán)境完全一致, 用戶名和密碼等全部都一致的情況下, OPC DA通訊可以直接成功,不需要為DCOM做任何的配置,甚至完全可以無視。
所以,當(dāng)我看到許多人對OPC UA的錯誤言論的時候,首先猜測他們是不是因?yàn)槭艿搅艘恍┛桃獾恼`導(dǎo)。
然而,我所列出的上述的 OPC UA的優(yōu)點(diǎn)好像并不能引起很多人的興趣。也更不覺得有何重要性而言。
是的,一直以來我也這么認(rèn)為的。因?yàn)榈侥壳盀橹梗?不管是觸摸屏還是上位機(jī)軟件,當(dāng)下都有通訊實(shí)現(xiàn)方案,也不覺得有多少痛點(diǎn)。
而真正的重點(diǎn)在后面。
進(jìn)入重點(diǎ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才是最完美的解決之道,而且因?yàn)閁A的統(tǒng)一架構(gòu), 那么會成為所有品牌的統(tǒng)一解決方案。
即, OPC UA可以實(shí)現(xiàn)對PLC的符號尋址。
對所有品牌PLC。 甚至對S7-1200/1500,都不再需要數(shù)據(jù)塊非優(yōu)化。即,即便是優(yōu)化的數(shù)據(jù)塊, 也可以通過OPC UA直接進(jìn)行數(shù)據(jù)通訊,因?yàn)檫@種通訊已經(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,因?yàn)橹灰С,只要把UA通訊打通, 那我就不需要再學(xué)別的通訊方案了。 工作量也大為簡化了。 原有的WINCC程序可以直接無縫對接移植過來。
如果是真實(shí)的工程項(xiàng)目,這種無縫移植帶來的高效率自是無可比擬的。 所耗費(fèi)的時間簡直忽略不計(jì)!
而更進(jìn)一步, 如果所有的上位機(jī)軟件如果也支持OPC UA, 那只要再做一套上位機(jī)的項(xiàng)目程序模板,在項(xiàng)目開發(fā)、程序移植各環(huán)節(jié)的工作量,也全部非常簡單。從wincc到上位機(jī), 從一個項(xiàng)目的上位機(jī)到下一個項(xiàng)目的上位機(jī)。都會帶來異乎尋常的高效率體驗(yàn)。
甚至, 在OPC UA的協(xié)議規(guī)范中,還特別涉及了對面向?qū)ο蟮闹С?梢园岩粋設(shè)備對象的數(shù)據(jù)打包整體對接,這些工作到目前為止,都還在幻想藍(lán)圖里,還沒有落地成為現(xiàn)實(shí),所以絕對值得我們每個人期待。。。。
我在前面一篇文章推薦過的上位機(jī)開發(fā)工具PCHMI.DLL,
《0210【萬泉河】用組態(tài)觸摸屏程序的方法生成上位機(jī)EXE軟件》
https://mp.weixin.qq.com/s/5hfgLZrWNvnt0TqopDDQcg這個工具里面包含了對OPC UA的支持,然而我研究后發(fā)現(xiàn),其支持力度還很弱, 甚至作者對OPC UA的理解都很淺,當(dāng)然也是因?yàn)椴恢匾暎?不感興趣,因而更不支持變量瀏覽功能。所以要達(dá)到實(shí)戰(zhàn)功能, 能實(shí)現(xiàn)我們要求的符號尋址,都還有很長的路要走。
所以暫時放棄了UA路線, 還是先能實(shí)現(xiàn)與BST的對接為目標(biāo),先實(shí)現(xiàn)彈出式窗口的設(shè)計(jì)操作模式。變量效率的提高方面,可以作為將來的話題。
然而,我發(fā)現(xiàn)工控同行中的大多數(shù),通常思想懶惰,沒有上進(jìn)心。
當(dāng)遇到各種功能實(shí)現(xiàn)不了效率低下的時候,不會首先審視是不是自己的能力和水平的原因,而是只會自顧個兒的在那兒抱怨,更不會想到自己挖掘其中的需求,找到好的解決方案,除了能提高自己的工作效率,同時說不定還能為自己儲備積累一些資源。
我上周與一位有C#經(jīng)驗(yàn)的朋友交流開發(fā)需求的時候, 對方竟然指點(diǎn)我去找某某高手去定制開發(fā), 完全沒有看到這其中存在的機(jī)會。
當(dāng)所有人都在抱怨這個行業(yè)臟苦累的時候,有沒有想過這其中反而蘊(yùn)藏了無限的機(jī)會, 你只要能做出一點(diǎn)點(diǎn)創(chuàng)新, 幫助別人有一點(diǎn)點(diǎn)效率的提高, 都有可能為你自己帶來豐富的回報(bào)。
越是落后的行業(yè),機(jī)會越多。 如果你時常抱怨這個行業(yè)落后,那說明機(jī)會就擺在你面前。
就看你有沒有能力抓住機(jī)遇。
最后,上文中征集PCHMI二次開發(fā)合作項(xiàng)目繼續(xù)進(jìn)行中,目前響應(yīng)者了了。說明這個行業(yè)具備這項(xiàng)能力且工作之余有閑暇進(jìn)行技術(shù)開發(fā)的人還太少了, 說明了什么, 說明這里面都是機(jī)會。