OPC協定解析-關于OPC協定的幾個問題 OPC協定OPC DA

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伺服器。 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資料通路規範。