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服務器為您解決了控制器之間的通信, 因為各產品均采用各自廠商的通信協議, 不同於控制器與應用軟件間的通信。 |
- 數據源端、數據接收端的控制器X和Y分別需使用OPC DA服務器 for X和OPC DA 服務器for Y。 |
| 控制器/設備 |
關系數據庫 |
關系數據庫利用“結構化查詢語言”（SQL）通過“開放數據庫互聯”（ODBC）協議進行通信；而控制器和控制設備則利用各自的自定義協議。找到一個貫穿兩者的數據橋並非易事, 通常需要一定的技術經驗才能建立起來。 |
- 利用 OPC DA Client for ODBC 從OPC服務器中獲取實時OPC數據, 通過SQL/ODBC將其准確地傳輸到數據庫。 |
| 控制器/設備 |
過程歷時數據庫（Historian） |
過程歷史數據庫采集的是實時數據, 它們通常有自己的通信協議和自定義驅動來收集各種設備或應用程序的數據。這里的難點是找到一個歷史數據庫不僅支持現有設備還要支持將來可能出現的數據源。 |
歷史數據庫有其自己的標准協議, 且幾乎所有的historian都有內置OPC DA客戶端。 OPC Desktop Historian 就是這種有內在OPC接口歷史數據庫的其中一個。 - 對於數據源：用一個用於數據源X的 OPC DA服務器即可。 |
| 冗余的設備 |
控制器/應用程序 |
按照傳統的方式, 如果控制器或應用程序不支持設備級冗余, 為保證設備的冗余性, 額外的硬件是需要的。 |
- 對控制器：需要用於控制器X的OPC服務器。 |
| 遠程設備（數據采集與監視控制系統）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數據訪問規范。