今日頭條
官方微信
官方抖音
案例頻道
1 引言
OPC（OLE for Process Control）作為新一代工業自動化控制軟件部件，被稱為控制系統"中間件技術"，是專為在現場設備、自控應用、企業管理應用軟件之間實現系統無縫集成而設計的接口規范，是最近幾年才發展起來的基于Microsoft公司COM/DCOM連接技術。它的出現為基于客戶機/服務器結構體系的工業自動化過程控制設備和系統與工業控制人機界面軟件之間的數據信息交換提供了標準接口，目前已被確定為全球事實性的工業標準，得到過程控制設備制造商和工業控制軟件開發商的支持，但在應用中，OPC COM/DCOM表現了以下幾點不足：
● 集成性
OPC的DCOM是同Windows的安全注冊機制綁定的，通常采用動態分配TCP/IP端口方式，很難通過Internet/Intranet，尤其是企業防火墻。
● 跨平臺性
OPC COM/DCOM是基于微軟的對象遠程過程調用機制，可以在微軟環境中方便的進行組件、進程、通信機制的交互，很難運行在非微軟系統。
● 連通性
企業高層應用（如MRP/ERP等）所需要的實時數據通常都是通過OPC-COM服務器獲得，但很多高層應用沒有OPC-COM接口，遠程調用采用CORBA/IIOP形式，OPC DCOM 根本無法解決此類問題。
在此背景下，如何有效擴展OPC的應用范圍；面對現有企業高層應用軟件體系結構的不同（Windows系統、UNIX、Lunix等），如何讓高層應用軟件去適應OPC技術規范（基于Microsoft 的DCOM技術發展而來），成為亟待解決的問題。
HTTP的出現順理成章，HTTP與DCOM很相似，它簡單、配置廣泛，并且對防火墻比其它協議更容易發揮作用，克服了DCOM不足。HTTP請求一般由Web服務器軟件（如IIS和Apache）來處理，且大部分的應用服務器支持HTTP協議。但HTTP所缺少的是用單一的標準格式來表達一個RPC調用中的參數。XML的出現彌補了這點不足，XML是Web數據使用的通用語言，它具有結構化、規范化、簡潔化和可擴展性等特點，它是一個與平臺無關的中性的數據表達協議。HTTP和XML的結合較好的解決了OPC DCOM的不足,正是HTTP協議和XML的應用產生了SOAP(Simple Object Access Protocal)技術，它實現了大量異構程序和平臺之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問，如圖1所示。這些正是SOAP、XML、HTTP成為OPC XML技術規范的主要內容的原因。
圖1 OPC XML提供了工廠底層到企業高層應用的新途徑
2 OPC XML 技術基礎
OPC XML技術主要涉及WEB服務器技術及SOAP技術。
2.1 WEB服務器技術
簡單的說，Web Service就是一個應用程序，它向外界暴露出一個能夠通過Web進行調用的API。它使用戶能夠用編程的方法通過Web調用來實現某個功能的應用程序。從深層次上看，Web Service是一種新的Web應用程序分支，它們是自包含、自描述、模塊化的應用，可以在網絡（通常為Web）中被描述、發布、查找以及通過Web來調用。同時，Web Service是基于網絡的、分布式的模塊化組件，它執行特定的任務，遵守具體的技術規范，這些規范使得Web Service能與其他兼容的組件進行互操作，這些技術規范（協議）包括：
(1) XML（可擴展的標記語言）：Web Service平臺中表示數據的基本格式，除了易于建立和易于分析外，XML主要的優點在于它既與平臺無關，又與廠商無關；
(2) XSD：Web Service平臺數據類型，系統的所有使用的數據類型必須被轉換為XSD類型；
(3) WSDL：Web Service描述語言，基于XML的語言，用于描述Web Service及其函數、參數和返回值；
(4) UDDI：一套基于Web的、分布式的、為Web Service提供的、信息注冊中心的實現標準規范，同時也包含一組使企業能將自身提供的Web Service注冊，以使別的企業能夠發現的訪問協議的實現標準；
(5) 遠程過程調用RPC與消息傳遞：用于應用程序間的通信。
2.2 SOAP技術（簡單對象訪問協議）
SOAP是一個輕量級數據傳輸協議，通常應用于分散、分布式計算與控制環境中作為數據信息交換協議。簡單的說SOAP就是XML+HTTP，主要包括3部分內容：(1) 為一組數據信息中描述的是什么內容及怎樣處理定義了一種框架結構外殼；(2) 用于表達應用程序所定義數據類型實例的一套編碼規則；(3) 用于表征遠程過程調用和響應的一組約定。SOAP能夠潛在應用于與其他多種傳輸協議的結合，尤其是HTTP和HTTP擴展框架結構，（見以下SOAP例子）。SOAP自身不能定義任何應用程序語義，如程序模式或執行細節等，相反，它為描述應用程序語義確立了一種簡化機制，這需要通過為模件中的編碼數據提供一種模件化包裝模式和編碼機制來實現。
3 OPC XML-DA技術規范
OPC XML-DA 規范1.0 版是OPC基金會于2003 年7 月發布的，此規范是OPC 基金會的第1 個OPC XML 接口規范。其它OPC-COM 接口，如報警事件(AE) 接口和歷史數據訪問(HDA)接口，將來也會作為XML 接口被重新設計，并有相應的規范發布。OPC XML-DA 規范的核心部分是OPC XML-DA Schema，它定義了構成OPC XMLWeb服務的數據類型、結構和方法等，此外規范還對通信協議、發現機制、錯誤處理、互操作性等底層細節進行了規定。
3.1 XML-DA對象調用方法及步驟
XML-DA同COM-DA相比，對對象的調用方法已完全不同：COM-DA表現為緊耦合方式，組建間可以建立通信通路，通過COM連接點技術實現服務器和客戶端的通訊，大部分工作通過客戶端提供回調函數實現；XML-DA表現為松耦合，它不具備"通信通路"機制，因此為了實現數據的訂閱和更新，它采用了輪詢查詢方式，圖2為整個輪詢查詢的過程描述。
圖2 輪詢查詢的交互過程
整個輪詢查詢過程按照以下七個步驟進行：
第一步：客戶端向服務器端發初始化定義（Subscribe），指定所定義的數據（Item[ ]）；
第二步：服務器端相應客戶端初始化定義（SubscribeResponse），返回客戶端所定義的數據標識及初始化值；
第三步：客戶端根據服務器端返回數據標識，向服務器端發出SubscrptionPollRefresh請求；
注：客戶端使用SubscrptionPollRefresh請求時，可設置HoldTime和WaitTime參數，如果在Holdtime 期間任何一個項目的值發生了變化，就在Holdtime 結束時刻返回響應，否則開始等待。如果在等待時間(Waittime) 內任何一個項目的值發生了變化,就立即返回響應。如果在Holdtime 和Waittime 兩段時間內沒有一個項目的值發生變化，就在Waittime 結束時返回一個響應，但這個響應不包含任何項目的值；該模式設計目的在于減少了服務器和客戶端數據交換負荷，提高OPC XML的性能。
第四步：服務器端向客戶端返回SubscrptionPollRefresh調用以來，項目列表中發生的變化的所有項目；
第五步：客戶端處理相應的變化，如果需要繼續查詢，回到第三步；
第六步：否則，向服務器端發出SubscriptionCancel請求；
第七步：服務器響應SubscriptionCancel請求，刪除當前Subscribe 調用中指定的項目列表。
從中不難看出，XML-DA輪詢查詢過程非常接近與OPC-COM 的"異步回調機制"，客戶端在處理完一次服務器返回后，不需要等待可以直接進入下一次請求刷新，時間周期的控制已經轉移到服務器上，這種方式被稱為"假回調"。
3.2 XML-DA服務類型
OPC XML-DA 支持8 種服務，每種服務都包括一個請求(Request) 和一個響應(Re-sponse) 。通過對這些服務的定義，提供了訪問工業現場數據的標準接口。請求和響應照SOAP協議標準被包裝成SOAP 信封，信封標題（可選）說明消息如何被處理，信封正文則包含工業過程信息。
● Browse 在服務器的命名空間里搜索所有可獲取的項目(item) 的名字(標記名) 。
● GetProperties 返回一個或多個項目的相關信息。
● GetStatus 返回關于服務器、版本、當前模式、運行狀況等信息。
● Read 返回一個或多個項目的值、品質和時間戳。
● Subscribe 指定一個客戶希望持續更新的項目列表。
● SubscriptionCancel 刪除在前一個Subscribe 調用中指定的項目列表。
● SubscriptionPolledRefresh返回自前一個SubscrioptionPolledRefresh 調用以來，在項目列表中數值發生變化的所有項目。
● Write 向一個或多個項目中寫入新值。
3.3 XML-DA數據類型
OPC XML-DA 數據類型從高到低依次分為Request 、List 、Item 3個等級，較低的數據類型屬性可以涵蓋較高數據類型屬性。基本的數據類型有：string、boolean、float 等20 種簡單類型以及枚舉類型和數組類型。其中的簡單類型是XML數據類型的一個子集，并與OPC-COM-DA 定制接口規范規定的數據類型相一致。此外，規范還規定了一些復合類型(ComplexType)，主要包括：Re-questList、RequestItem、ItemValue 、RequestOptions、ServerState 、ReplyBase 、OPCError、ItemProperty 等。OPC XML-DA 規范的所有接口都基于這些數據類型定義。規范同時支持空參數。
3.4 OPC-COM-DA和OPC XML-DA的協調
OPC XML-DA 服務器和OPC-COM-DA服務器都可以單獨使用，當需要將OPC XML-DA 服務器轉換成OPC-COM-DA 服務器時，可以通過DCOM Wrapper（DCOM中間件）完成，如圖3所示。同樣，可以用XML Wrapper（XML中間件）將OPC-COM-DA服務器包裝成OPC XML-DA服務器；對于現有的成百上千種OPC-COM-DA服務器，由于它們具有標準的接口，因此只需要一個Wrapper，就可以包裝所有的OPC-COM-DA服務器，從而省去了重新編寫OPC XML-DA 服務器的工作，目前，很多公司已經發布了COM與XML接口之間進行轉換的網關，這些網關使兩種接口的通訊更加方便。
3.5 開發工具
目前，針對OPC XML-DA較為基礎的開發工具包包括：Axis，SUN Java Web Services Developer Pack，Microsoft SOAP Toolkit，IBM Web Services Toolkit，Borland Delphi 7等，增強工具包有：Microsoft.NET WSDK，SunOne Plattform，IBM WebSphere SDK for Web Services (WSDK)，由于這些工具包已經在電子商務有廣泛應用，技術相對成熟，為OPC XML-DA的應用打下良好基礎。
3.6 未涉及問題
(1) 安全性問題
OPC XML-DA 技術規范并沒有單獨規定安全性機制，而是依賴于傳輸協議（例如HTTPS）。此類問題的進一步研究將涉及整個互連網絡安全問題，當前由于操作平臺的互異性，相應的安全機制存在較大差異，近期不可能出現統一的標準，因此，OPC XML-DA技術規范也難以很快出現相應標準，用戶只能通過對網絡服務器的安全性進行適當的配置（例如在Microsoft IIS 服務器中配置SSL），來解決安全性問題。
(2) 發現現有的服務器機制問題
與安全性問題相似，OPC XML-DA技術規范沒有定義OPC XML-DA 服務器節點或在指定節點上發現OPC XML-DA服務器的機制。由于UDDI（通用描述、發現、集成）協議是廣泛使用的WEB服務發現標準，人們有理由相信，未來制定OPC XML Web 服務器發現規范將會以UDDI協議為基礎。
4 發展及展望
OPC XML的出現在很大程度上彌補了OPC DCOM在集成性、跨平臺性、聯通性等方面的不足，基于XML和HTTP技術傳輸協議將使其在很長時間里適應網絡技術發展，相信不久，OPC基金會將陸續推出基于WEB服務的報警和時間規范、歷史數據訪問規范等，OPC XML的應用將更加廣泛；同時，OPC DCOM以其高效性和實時性，將繼續在監控、管理層發揮其巨大作用，二者相輔相成，互為補充，必將為自動化工業的發展帶來強勁動力。
北京市公安局海淀分局備案號：11010802023656號