OPC協議解析-關於OPC協議的幾個問題

1    什麼是OPC協議？

爲了便於自動化行業不一樣廠家的設備和應用程序能相互交換數據，定義了一個統一的接口函數，就是OPC協議規範。有了OPC就可使用統一的方式去訪問不一樣設備廠商的產品數據。

OPC基金會前先後後規定了不一樣的接口定義，以下：

• OPC DA (Data Access, exchange of real-time values)

• OPC A&E (Alarms & Events, exchange of alarms and events)

• OPC HDA (Historical Data Access, exchange of historical values)

• OPC XML DA (XML-based exchange of real-time values)

2      OPC DA是什麼？

OPC DA指代的是 OPC數據訪問規範。它是由OPC基金會定義的其中一種通訊規範, 定義了實時數據如何在數據源和數據接收體（好比PLC, HMI）之間, 在不知道彼此特定通訊協議的狀況下仍然進行交換、傳輸。

2.1     爲何OPC DA如此受歡迎？它和過去的通訊協議有什麼不一樣?

OPC DA客戶端/服務器結構服務器結構是OPC基金會界定的首個結構。在OPC DA 以前, 供應商的產品（設備、PLCs、HMIs）要求與這些產品相鏈接的任何設備或應用程序要自帶「特製驅動」, 以在第三方通訊和所涉及的供應商產品之間進行數據傳譯。像這樣基於「特製驅動」的通信存在許多問題, 其中最多見的有：成本高、將用戶限制在某一特定供應商、因爲每個特製驅動都有其獨有的處理方式而形成配置和維護的困難、因爲新設備和應用程序的層出不窮而形成難於更新。相比之下,OPC DA卻能夠與任何實時數據源相鏈接, 也不須要爲數據源或數據接收端特製任何驅動程序。 所以, 數據接收器不須要了解數據源的本地協議或內部數據結構就能夠進行讀和寫。

2.2     OPC DA規範是隻有一種嗎？

很難說是或不是。由於OPC DA規範由OPC基金會來維護, 它們已經通過屢次修訂。主要版本包括:

年份     版本     備註

1996    1.0       初始規範。

1997    DA 1.0a      數據訪問（DA）, 該名稱用於區分與其並行開發的其它規範。

1998    DA 2.0 - DA 2.05a   多處規範澄清和修改。

2003    DA 3.0 進一步補充和修改。

考慮到有不一樣版本的OPC 數據訪問（OPC DA）規範, 關鍵問題是：這些版本反向兼容嗎? 例如：OPC DA 1.0a 客戶端是否能夠與OPC DA 3.0 OPC服務器通信？答案是：這取決於具體狀況。

2.3     數據訪問OPC客戶端及OPC服務器反向兼容性

開發商編寫反向兼容的OPC客戶端及OPC服務器是值得推薦的, 同時這也是能夠實現的。然而, 由於反向兼容性是可選功能, 而不是強制功能, 這意味着會有許多開發商選擇（而且會繼續）開發僅僅遵循一種或兩種規範的OPC DA服務器, 而不是遵循全部規範。這樣的話, 那些非反向兼容的OPC服務器及OPC客戶端仍然向用戶提供OPC所帶來的些許優點, 但僅僅侷限於特定版本的規範。好消息是MatirkonOPC不只開發徹底反向兼容的OPC服務器, 也提供OPC數據管理產品（如： OPC Data Manager及OPC Security Gateway）。這些產品在非向後兼容的OPC客戶端及服務器之間, 經過及時地在 OPC DA不一樣規範之間轉換實現彼此通信。

3      如何使用OPC 數據訪問規範 (DA)

3.1     什麼時候使用OPC DA？

簡單的回答就是：用於須要傳輸實時數據的任什麼時候刻。對於須要考慮的多種情形, 下表介紹了最多見的幾種類型, 簡述了一些難點, 並給出了利用標準OPC組件加以解決的相關建議。

數據源	數據接收端（用戶）	OPC解決問題	相關建議
控制器（外部PLC）	應用程序（HMI）	不一樣廠商的控制器均使用各自的通訊協議。OPC省去了HMI 針對各控制器「定製驅動器」的須要。	- 控制器：使用 OPC 服務器 for 控制器 X - 應用程序：一般有內置的OPC客戶端。若是沒有, 則可以使用適用於該應用程序Y的OPC DA 客戶端。
控制器/設備	控制器或控制設備	備 OPC服務器爲您解決了控制器之間的通訊, 由於各產品均採用各自廠商的通訊協議, 不一樣於控制器與應用軟件間的通訊。	- 數據源端、數據接收端的控制器X和Y分別需使用OPC DA服務器 for X和OPC DA 服務器for Y。 - 使用 OPC Data Manager, 在兩控制器間實現有關實時數據的智能化傳輸。
控制器/設備	關係數據庫	關係數據庫利用「結構化查詢語言」（SQL）經過「開放數據庫互聯」（ODBC）協議進行通訊；而控制器和控制設備則利用各自的自定義協議。找到一個貫穿二者的數據橋並不是易事, 一般須要必定的技術經驗才能創建起來。	- 利用 OPC DA Client for ODBC 從OPC服務器中獲取實時OPC數據, 經過SQL/ODBC將其準確地傳輸到數據庫。 - 利用 OPC DA 服務器 for 設備 X 公開數據。 - 注：OPC DA爲雙向式通訊, 所以在必要時, 也可將實時數據從數據庫寫入設備或控制器中, 或將應用程序的數據寫入OPC客戶端。
控制器/設備	過程歷時數據庫（Historian）	過程歷史數據庫採集的是實時數據, 它們一般有本身的通訊協議和自定義驅動來收集各類設備或應用程序的數據。這裏的難點是找到一個歷史數據庫不只支持現有設備還要支持未來可能出現的數據源。	歷史數據庫有其本身的標準協議, 且幾乎全部的historian都有內置OPC DA客戶端。 OPC Desktop Historian 就是這種有內在OPC接口歷史數據庫的其中一個。 - 對於數據源：用一個用於數據源X的 OPC DA服務器便可。
冗餘的設備	控制器/應用程序	按照傳統的方式, 若是控制器或應用程序不支持設備級冗餘, 爲保證設備的冗餘性, 額外的硬件是須要的。	- 對控制器：須要用於控制器X的OPC服務器。 - 不一樣的設備可使用不一樣的OPC服務器。 - 使用 OPC Redundancy Broker (ORB) 來實施冗餘機制。 - 對應用程序（如：HMI或Historian）：能夠用 OPC客戶端用於應用程序X。
遠程設備（數據採集與監視控制系統）SCADA:例如，遠程終端控制系統RTU	應用程序/控制器	因爲通信故障和低頻帶寬, 與遠程設備和數據來源之間的通訊通常較爲複雜, 同時也更昂貴。而自定義驅動程序的問題在於不一樣通訊渠道的穩定性難以保障	遠程設備應該選擇SCADA類的OPC服務器。跟通常現場應用的OPC服務器不一樣, 這類OPC服務器是專門爲適應複雜的SCADA工做環境而設計的。（例如, MatrikonOPC Server for SCADA Modbus)

 

3.2     能夠用OPC DA傳輸歷史數據嗎？

不能。任何OPC DA都是專用於傳輸當前數據的。一旦當前數據已經被讀, 下一數據的讀取就會開始, OPC DA沒有爲OPC DA客戶端提供歷史數據的接口。若是要傳輸歷史數據, 須要使用一樣基於 OPC客戶端-服務器結構 的OPC歷史數據存取規範（OPC HDA）。

3.3     同一供應商生產的OPC DA客戶端程序可與不一樣供應商的OPC服務器搭配工做嗎？

通常狀況下是能夠的, 在OPC DA客戶端與服務器都支持一樣版本的OPC DA規範（見上文）或者至少其中一個可以反向兼容的條件下。

4      OPC客戶端-服務器結構

OPC 通訊結構是指包含一個或多個OPC客戶端與服務器相互通訊的集合。最簡單的理解方式, 即是讀懂以下這張數據流程圖。它顯示了數據由數據源從下至上到達數據接收體的過程。

 

OPC 服務器：在這個例子中, 若是數據源有一個內在的OPC客戶端, 那麼外在的OPC客戶端就不是必須的了。

OPC 通訊：由於OPC基金組織定義了多種 OPC通訊規範 保證能夠傳送不一樣形式的數據信息, 因此OPC開發商和用戶必須理解OPC服務器和客戶端的通訊有時候不侷限於單一的數據訪問形式。這個概念的理解之因此重要, 是由於同一種OPC服務器每每會支持多於一種的OPC數據訪問規範。