原文由Beharrell, Mark (CERN) ; Barillère, Renaud (CERN)發(fā)表于23 Sep 2005，標(biāo)題為“OPC evolution toward UNIX (from Windows to world-wide domination?)”（http://cdsweb.cern.ch/record/922755）

一、摘要

面向過程控制的OLE（OPC)是一個工業(yè)應(yīng)用領(lǐng)域內(nèi)的中間件。它通常用來連接設(shè)備和更高端的控制系統(tǒng)（例如SCADA），自它1996年提出后，就被工業(yè)界所廣泛接受。現(xiàn)在，它已成為過程監(jiān)控事實(shí)上的標(biāo)準(zhǔn)。許多設(shè)備制造商都為他們的設(shè)備提供了OPC服務(wù)，這些“即插即用”的服務(wù)將設(shè)備信息整合到了整個監(jiān)控系統(tǒng)中。

在極大簡化系統(tǒng)整合者的工作的同時，一直以來OPC只能工作于MS windows工作平臺之上，由于1.DCOM標(biāo)準(zhǔn)的開放性；2.XML OPC的引入；3.OPC UA的引入，上面的情況并不完全如此。本文將討論各個解決方案－它的優(yōu)點(diǎn)和缺點(diǎn)。最后，我們總結(jié)這些解決方案的測試數(shù)據(jù)。

二、與DCS的通訊

下圖是DCS系統(tǒng)的數(shù)據(jù)流示意圖。

通常，SCADA系統(tǒng)從各種不同的設(shè)備中獲取數(shù)據(jù)，監(jiān)控這些設(shè)備，并將綜合信息傳遞給其它系統(tǒng)。光束狀態(tài)信息（Beam status）來自與加速器（Accelerator），安全系統(tǒng)（Safety systems）和通用服務(wù)系統(tǒng)（general services）之間需要傳遞信息。另外，遠(yuǎn)程站點(diǎn)也要訪問DCS，這些節(jié)點(diǎn)的信息交換是通過一種或多種通訊協(xié)議完成。開發(fā)、調(diào)試、維護(hù)這些通訊協(xié)議需要耗費(fèi)大量的精力。

當(dāng)需要與硬件設(shè)備通訊時，這個問題特別突出，這時，不同的通訊協(xié)議可能發(fā)生在1.不同制造商提供的設(shè)備之間；2.同一設(shè)備商的不同模塊之間；3.同一設(shè)備不同的通訊協(xié)議版本之間。

因此，一種理想的解決方式是能用商業(yè)化的標(biāo)準(zhǔn)協(xié)議，來掩蓋不同設(shè)備之間的差異。一種方案是使用中間件，它能提供一種通用的可以聯(lián)系各軟件（通常分布于各設(shè)備）的接口。CORBA，JavaRMI，DCOM就是現(xiàn)有的一些中間件解決方案。然而，它們要成為一種通用的解決方案，必須經(jīng)過不同程度的進(jìn)一步開發(fā)，才能用來獲得設(shè)備的數(shù)據(jù)。這些開發(fā)可能以不同的方式進(jìn)行，但是，在進(jìn)一步引入?yún)f(xié)議之前，需要一個能處理這種協(xié)議的客戶端。

已經(jīng)進(jìn)行了一些工作來使中間件標(biāo)準(zhǔn)化。2005年，OMG（Object Management Group)引入了一種將CORBA更專業(yè)化的標(biāo)準(zhǔn)來獲取數(shù)據(jù)。但是，在這之前9年，OPC基金會引入了一系列面向過程控制的基于OLE的標(biāo)準(zhǔn)。

1、OPC的方案

OPC基金會成立于1995年5月，目的是創(chuàng)建一種適合于工廠應(yīng)用的中間件解決方案。1996年8月，OPC基金會推出OPC數(shù)據(jù)獲取標(biāo)準(zhǔn)1.0版，它采用MS的接口定義語言(IDL)描述了一系列用來獲取和管理設(shè)備數(shù)據(jù)的接口，更進(jìn)一步，它詳細(xì)描述了一種數(shù)據(jù)模型，模型不但包括了設(shè)備數(shù)據(jù)，還包括諸如最大/最小值、數(shù)據(jù)描述、工程單位、時間戳等數(shù)據(jù)屬性，這樣，OPC用戶就可以很容易理解他們接收到的數(shù)據(jù)。最好，這個標(biāo)準(zhǔn)提供了客戶/服務(wù)和出版/訂閱通訊模型。應(yīng)用這些標(biāo)準(zhǔn)，開發(fā)著可以寫出OPC-DA客戶端和服務(wù)器端程序。

OPC-DA也有幾個弱點(diǎn)，如只支持簡單的數(shù)據(jù)類型，不支持命令；沒有顯式的安全支持等。經(jīng)過近幾年的發(fā)展，OPC基金會已經(jīng)擴(kuò)展了DA標(biāo)準(zhǔn)，并引入了額外的標(biāo)準(zhǔn)來彌補(bǔ)這些缺點(diǎn)。

OPC已經(jīng)成為一個事實(shí)上的工業(yè)通訊標(biāo)準(zhǔn)，現(xiàn)在已經(jīng)很難找到一個不包含OPC客戶端的SCADA系統(tǒng)，購買一個通過OPC服務(wù)器來通訊的硬件設(shè)備是很平常的事。

2、對傳感控制器的意義

在DCS中，購買一個采用標(biāo)準(zhǔn)方式控制的軟件和硬件是一個很好的事情，它減少了為大量的不同設(shè)備開發(fā)和維護(hù)中間件的成本，但是，要注意，它不是萬能藥。

OPC依賴于DCOM的安全機(jī)制有配置問題－DCOM的安全機(jī)制難于理解，因此用戶傾向于不使用或少使用安全機(jī)制。DCOM依賴的Windows注冊表，被證明是脆弱的和易于崩潰的。Windows升級包（尤其是SP2）也增加了維護(hù)OPC服務(wù)器運(yùn)行的復(fù)雜性。再者，OPC服務(wù)器越來越要承擔(dān)在有限的時間內(nèi)提供成千上萬點(diǎn)的數(shù)據(jù)，OPC服務(wù)器的效率就成為最重要的事情。最后，可能更顯著，控制系統(tǒng)天生就是不同的，通常，機(jī)器運(yùn)行基于X86架構(gòu)的Windows或Linux系統(tǒng)，但是，混用這些系統(tǒng)是存在的，由于使用了非Windows機(jī)器，就要求OPC服務(wù)器能在基于UNIX系統(tǒng)上運(yùn)行。標(biāo)準(zhǔn)上的給出的答案是這種情況不可以，雖然事實(shí)上并非嚴(yán)格如此...

三、非Windows上的OPC

有幾個方案解決OPC服務(wù)器在非Windows上運(yùn)行的問題，我們現(xiàn)在依次來看看。

1. DCOM

MS于1996年11月公開了他們的DCOM標(biāo)準(zhǔn)，這導(dǎo)致出現(xiàn)了一系列在Solaris、VXworks和Linux等上面DCOM的實(shí)現(xiàn)方法，這些方法都以庫的方式安裝在目標(biāo)平臺上，開發(fā)者采用這些DCOM庫，就可能提供運(yùn)行于UNIX平臺上OPC服務(wù)器。

我們關(guān)注這些實(shí)現(xiàn)方式，特別是它們在Linux下的性能和穩(wěn)定性。為了測試，我們采用OPC基金會OPC DA2.05樣例方法和AG公司的EntireX DCOM庫，在Linux上實(shí)現(xiàn)OPC服務(wù)器，我們要對比在Windows XP下的同樣的服務(wù)器，測試的方式是采用OPC-DA IOPCSyncIO讀方法（這個方法允許客戶端同時讀取多個OPC點(diǎn)）讀取1000個OPC點(diǎn)（浮點(diǎn)類型），取其平均值。下圖給出了XP和Linux平臺下，隨著OPC點(diǎn)增加，讀取時間的平均值。

我們能看到Linux實(shí)現(xiàn)要慢于Windows實(shí)現(xiàn)，有意思的是，Linux實(shí)現(xiàn)中，端到端的傳輸浮點(diǎn)數(shù)的流量，似乎最好為2.3Mbps（要說明的是，其它數(shù)據(jù)如時間戳、數(shù)據(jù)質(zhì)量也要傳輸），盡管顯得比較慢，每秒鐘可以傳送超過76000個點(diǎn)的數(shù)據(jù)。

我們的Linux實(shí)現(xiàn)有一些穩(wěn)定性問題：1.DCOM庫中轉(zhuǎn)換多字節(jié)為“寬字節(jié)”的方法有問題；2.“Windows注冊表"容易丟失存到里面的數(shù)據(jù)；3.DCOM依賴的DEC-RPC服務(wù)會突然失效（盡管它還在運(yùn)行）－只有重新安裝DCOM庫才能解決這個問題。在Linux上OPC DA服務(wù)器實(shí)用之前，這些問題需要解決，而且是可以解決的。另一種在Linux上實(shí)現(xiàn)DCOM的方式是采用Open Groups的FreeDCE，與在Windows上的實(shí)現(xiàn)方式相同。

2. XML DA

2003年6月，OPC基金會發(fā)布了OPC XML DA標(biāo)準(zhǔn)，它非常類似于DOPC DA 3.0版，但它與之前的OPC標(biāo)準(zhǔn)不同的是，它不再使用DCOM作為傳輸層，而是采用基于HTML和SOAP的Web服務(wù)。采用這種實(shí)現(xiàn)方式，一個XML DA服務(wù)器可以嵌入Web服務(wù)器（如 Apache, IIS）中或獨(dú)立運(yùn)行。

由于HTML是一個普遍的協(xié)議，那么，實(shí)現(xiàn)XML DA標(biāo)準(zhǔn)的OPC服務(wù)器就有可能在任何支持HTML的平臺上存在。XML DA將所有的數(shù)據(jù)采用XML字符串表達(dá)，對這種方式的效率就有一些憂慮。為了研究這個問題，我們采用了和上面DCOM比較測試中相同的方法，這一次，采用Read()方法（OPC XML DA 1.1中定義）獲取數(shù)據(jù)。我們分別采用TechnoSoftware AG公司的Windows評估版OPC XML Server C++ Framework和OPC Client Framework.net。下圖對比了我們采用XML讀的結(jié)果和采用DCOM IOPCSyncIO讀的結(jié)果。

我們可以看出OPC XML DA和OPC DA的性能有很大不同。采用其它更加有效率的編碼方式（如base64或十六進(jìn)制編碼）可以提高XML DA的性能，但沒有被XML DA標(biāo)準(zhǔn)所采納。

另一個效率上的考慮是缺少一個真的“發(fā)布/訂閱者”通訊模型。這被一個叫“輪詢更新（polled refresh）”的方式所取代，它需要客戶端每隔一段時間查詢服務(wù)器來獲得所訂閱的OPC點(diǎn)的信息。OPC服務(wù)器可能保存客戶端所關(guān)心的變化了的OPC點(diǎn)的信息，以至于在客戶端輪詢的間隔期，不丟失數(shù)據(jù)。如果客戶端查詢的周期慢于預(yù)設(shè)的周期，服務(wù)器就有可能釋放那個客戶端的所有資源。

在建造XML DA服務(wù)器時，我們發(fā)現(xiàn)用來解析WSDL文件（Web Service定義語言，描述了OPC Web服務(wù)）的工具不能總是產(chǎn)生正確的代碼。Web服務(wù)依賴于XML、XML schema、SOAP和WSDL，這些都是復(fù)雜的標(biāo)準(zhǔn)，任何對這些標(biāo)準(zhǔn)的解析錯誤都能導(dǎo)致服務(wù)器端和客戶端的不一致。這個問題不僅僅在OPC XML中存在，檢驗(yàn)是否符合標(biāo)準(zhǔn)的測試也確實(shí)做過，但即使如此，依然有兼容性問題。

3. OPC UA

OPC統(tǒng)一架構(gòu)（OPC UA）是OPC基金會最新的產(chǎn)品，它在2005年4月提出，細(xì)節(jié)仍制定中，它的目標(biāo)包括：

• 能夠?qū)⑵髽I(yè)級別的結(jié)構(gòu)化的工廠端數(shù)據(jù)和internet整合在一起
• 安全、可靠和高效的服務(wù)
• 平臺和協(xié)議無關(guān)性

它表達(dá)了使方案跨平臺和整合到企業(yè)級別或更高級別的一種努力，這個架構(gòu)將現(xiàn)存的OPC標(biāo)準(zhǔn)融合到一個前后連貫的標(biāo)準(zhǔn)中。各種對象（變量、屬性、命令）通過服務(wù)完成。服務(wù)器提供服務(wù)并且相關(guān)的服務(wù)組成服務(wù)集（這種服務(wù)集的例子如數(shù)據(jù)獲取服務(wù)集和訂閱服務(wù)集）。

UA的目標(biāo)是讓DCOM“退休"，而采用基于SOAP的方法替代DCOM，這個替代方法用WSDL定義接口并綁定HTML或TCP/IP。為解決XML DA的效率問題，UA將采用二進(jìn)制編碼。但最初，采用base64來編碼SOAP envelope中的數(shù)據(jù)，當(dāng)UA最終版時，base64被Message Transmission Optimization Mechanism(MTOM)所取代。

OPC UA的性能有待測試，但是，如果UA實(shí)現(xiàn)了它的目標(biāo)，并且解決了XML DA發(fā)現(xiàn)的解析工具問題，對控制系統(tǒng)領(lǐng)域內(nèi)或之外的通訊方法的使用，都是一件令人感興趣的事情。

四、總結(jié)

1. 端到端的性能

關(guān)于在UNIX系統(tǒng)上實(shí)現(xiàn)OPC服務(wù)器的的問題，我們研究了Linux上DCOM以及XML DA的性能，但是，OPC協(xié)議的性能只是我們需要考慮的一個方面。

根據(jù)我們經(jīng)驗(yàn)，”慢“OPC服務(wù)器不僅是由于OPC協(xié)議本身，而且還包括OPC服務(wù)器讀取現(xiàn)場設(shè)備數(shù)據(jù)的方式－特別那些基于網(wǎng)絡(luò)（以太網(wǎng)或現(xiàn)場總線）的設(shè)備。在這種情況下，有兩個典型的方式：1.一個OPC服務(wù)器讀取各個設(shè)備；2.通過網(wǎng)絡(luò)幀讀取多個值。下面兩個因素就可能提高性能：

• 在網(wǎng)絡(luò)能力允許時，服務(wù)器可以并行向多個設(shè)備發(fā)出請求，而不是在得到回應(yīng)之前等待。
• OPC服務(wù)器可以根據(jù)網(wǎng)絡(luò)幀成組讀取設(shè)備，這樣，OPC服務(wù)器就不需要每次為每個點(diǎn)發(fā)送幀，而是發(fā)送一次，更新相關(guān)所有的OPC點(diǎn)的信息。
  

2. 是否有用？

從上面我們可以看出，從技術(shù)上講，UNIX類平臺上都有可能實(shí)現(xiàn)XML和基于DCOM的OPC服務(wù)器，雖然它們都慢于Windows平臺上的DCOM實(shí)現(xiàn)，但還是能滿足多數(shù)DCS的數(shù)據(jù)速率要求。OPC的一個優(yōu)勢是設(shè)備制造商的支持，即如果買了一個設(shè)備，那么設(shè)備的OPC服務(wù)器是"白給"的，但這個OPC服務(wù)器要運(yùn)行于Windows。雖然在Linux上有OPC服務(wù)器和客戶端的開發(fā)工具，支持DCOM和XML ，但它們還沒有被設(shè)備制造商和最終用戶所接受，他們?nèi)詢A向于Windows平臺上被證明能很好工作的DCOM方案，這樣的結(jié)果就是，如果我們想要Linux上的OPC服務(wù)器，我們就需要定制開發(fā)。開發(fā)Linux上的基于DCOM的OPC服務(wù)器，主要基于兩點(diǎn)：1.性能；2.SCADA系統(tǒng)中存在大量的OPC客戶端，采用DCOM方式讀取服務(wù)器。XML DA有可能是一種唯一的用來封裝存在的基于DCOM的OPC服務(wù)器的方法，使OPC服務(wù)器能從Internet上訪問。

本文中未涉及但值得研究的是Linux上的OPC DA客戶端。它不應(yīng)該太困難并使基于Linux的SCADA可以讀取現(xiàn)在大量的OPC DA服務(wù)器。

五、結(jié)論

在不遠(yuǎn)的將來，我們繼續(xù)會看到基于Window的OPC DA大量用于工業(yè)界，XML DA用在服務(wù)器需要被遠(yuǎn)程訪問的場合，而不是主流的設(shè)備讀取場合。XML DA有可以能被OPC UA所替代，因?yàn)閁A承諾是一個更加安全、健壯、靈活和高效的，并且可以用于監(jiān)控通訊各方面的方案。用戶的接受程度將最終決定OPC UA是否替代OPC DA，成為一個新的多平臺的事實(shí)上的標(biāo)準(zhǔn)。現(xiàn)在，如果我們需要Linux上的OPC服務(wù)器，我們可能需要自己開發(fā)。

參考文獻(xiàn)

[1] Object Management Group, Inc., http://www.omg.org.
[2] http://java.sun.com/products/jdk/rmi/
[3] http://www.microsoft.com/com/default.mspx
[4] “Data Acquisition from Industrial Systems Specification – Version 1.1”, Object Management Group, Inc., June 2005
[5] “Data Access Custom Interface Standard”, currently v 3.0, OPC foundation, March 2003.
[6] “Congestion Control in IP/TCP Internetworks”, RFC 896, Network Working Group, John Nadle, 6 January 1984.

總結(jié)

以上是生活随笔為你收集整理的OPC向UNIX的演进（OPC evolution toward UNIX）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。