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

一、摘要

面向過程控制的OLE（OPC)是一個工業應用領域內的中間件。它通常用來連接設備和更高端的控制系統（例如SCADA），自它1996年提出后，就被工業界所廣泛接受。現在，它已成為過程監控事實上的標準。許多設備制造商都為他們的設備提供了OPC服務，這些“即插即用”的服務將設備信息整合到了整個監控系統中。

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

二、與DCS的通訊

下圖是DCS系統的數據流示意圖。

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

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

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

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

1、OPC的方案

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

OPC-DA也有幾個弱點，如只支持簡單的數據類型，不支持命令；沒有顯式的安全支持等。經過近幾年的發展，OPC基金會已經擴展了DA標準，并引入了額外的標準來彌補這些缺點。

OPC已經成為一個事實上的工業通訊標準，現在已經很難找到一個不包含OPC客戶端的SCADA系統，購買一個通過OPC服務器來通訊的硬件設備是很平常的事。

2、對傳感控制器的意義

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

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

三、非Windows上的OPC

有幾個方案解決OPC服務器在非Windows上運行的問題，我們現在依次來看看。

1. DCOM

MS于1996年11月公開了他們的DCOM標準，這導致出現了一系列在Solaris、VXworks和Linux等上面DCOM的實現方法，這些方法都以庫的方式安裝在目標平臺上，開發者采用這些DCOM庫，就可能提供運行于UNIX平臺上OPC服務器。

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

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

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

2. XML DA

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

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

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

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

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

3. OPC UA

OPC統一架構（OPC UA）是OPC基金會最新的產品，它在2005年4月提出，細節仍制定中，它的目標包括：

• 能夠將企業級別的結構化的工廠端數據和internet整合在一起
• 安全、可靠和高效的服務
• 平臺和協議無關性

它表達了使方案跨平臺和整合到企業級別或更高級別的一種努力，這個架構將現存的OPC標準融合到一個前后連貫的標準中。各種對象（變量、屬性、命令）通過服務完成。服務器提供服務并且相關的服務組成服務集（這種服務集的例子如數據獲取服務集和訂閱服務集）。

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

OPC UA的性能有待測試，但是，如果UA實現了它的目標，并且解決了XML DA發現的解析工具問題，對控制系統領域內或之外的通訊方法的使用，都是一件令人感興趣的事情。

四、總結

1. 端到端的性能

關于在UNIX系統上實現OPC服務器的的問題，我們研究了Linux上DCOM以及XML DA的性能，但是，OPC協議的性能只是我們需要考慮的一個方面。

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

• 在網絡能力允許時，服務器可以并行向多個設備發出請求，而不是在得到回應之前等待。
• OPC服務器可以根據網絡幀成組讀取設備，這樣，OPC服務器就不需要每次為每個點發送幀，而是發送一次，更新相關所有的OPC點的信息。
  

2. 是否有用？

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

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

五、結論

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

參考文獻

[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.

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。