ＯＰＣ規范
ＯＰＣ規范包括數據訪問服務器接口規范、歷史數據訪問服務器接口規范、事件與報警服務器接口規范、批處理服務器接口規范、ＯＰＣDA 服務器接口規范和XML DA服務器接口規范等一系列標准規范。現在成熟並發布的ＯＰＣ規范主要包括數據存取規范、報警和事件處理規范以及歷史數據存取規范。
ＯＰＣ的設計目的
1、在控制領域中，系統往往由分散的各子系統構成；並且各子系統往往采用不同廠家的設備和方案。用戶需要，將這些子系統集成，並架構統一的實時監控系統。
2、這樣的實時監控系統需要解決分散子系統間的數據共享，各子系統需要統一協調相應控制指令。
3、再考慮到實時監控系統往往需要升級和調整。
4、就需要各子系統具備統一的開放接口。
OPC就是為了不同供應廠商的設備和應用程序之間的接口標准化，使其間的數據交換更加簡單化的目的而提出的。作為結果，從而可以向用戶提供不依靠於特定開發語言和開發環境的可以自由組合使用的過程控制軟件組件產品。ＯＰＣ的設計目的最重要的是即插即用,也就是采用標准方式配置硬件和軟件接口。一個設備可以很容易地加入現有系統並立即投入使用,不需要復雜的配置,且不會影響現有的系統。
OPC的優點和不足
與早期的現場設備接口相比, OPC 具有如下幾個優點:
( 1) 減少了重復開發;
( 2) 降低了數據設備間的不兼容;
( 3) 降低了系統集成商的開發成本;
( 4) 改善性能。
OPC 存在的不足
雖然OPC 接口具有種種優勢, 但是如果直接通過OPC 連接實時數據庫依然存在一些問題: ( 1) 雖然OPC 標准中包含了OPC History 標准, 但是多數OPC 服務器並未給予支持, 所以難以為實時數據庫提供數據緩存功能。
( 2) OPC 服務器無法提供一些常用的計算功能, 如累計、濾波和幾個位號相加的綜合計算功能, 增加了實時數據庫的負擔, 影響了實時數據庫的穩定性和魯棒性。
( 3) OPC 基於微軟的COM/DCOM體系, 在分布式應用中其所用的RPC 方式常常與企業級的防火牆發生沖突。不能通過防火牆。
OPC體系結構
圖1所示為ＯＰＣ接口、 ＯＰＣ服務器及ＯＰＣ客戶應用的聯系。
像所有的ＣＯＭ實現一樣,ＯＰＣ的結構是客戶機服務器模式。各個ＯＰＣ客戶程序通過ＯＰＣ標准接口對各ＯＰＣ服務器管理的設備進行操作,而不需關心服務器的實現細節及設備內部的具體細節。OPC把開發訪問接口的任務放在硬件生產廠家或第三方廠家，以OPC服務器的形式提供給用戶，解決了軟、硬件廠商的矛盾，完成了系統的集成，提高了系統的開放性和可互操作性。
以前的過程監控中硬件和軟件的設置情況如圖2 所示。各種應用軟件都必須提供這三種設備的驅動程序,即需要12個驅動程序維持系統的正常運行,而且各軟件間不能相互通信。因為各個軟件來自不同的開發商,具有不同的相互獨立的對同一設備的驅動程序,所以多個軟件也不能同時對同一個設備存取數據,否則可能造成系統的癱瘓。同時,某一個設備的升級要求該設備的所有驅動程序升級,否則隱患無窮。這樣的一個系統要想長期維護,工作量可想而知。ＯＰＣ規范的引入,使得過程控制的硬件軟件配置可以由圖3 表示。
OPC規范了接口函數，不管現場設備以何種形式存在，客戶都以統一的方式去訪問，從而保證軟件對客戶的透明性，使得用戶完全從低層的開發中脫離出來。對於軟件開發商而言,不再費神於開發各種硬件設備的驅動程序,而是把精力和時間集中在增加和完善軟件的功能上,使自己的軟件更易被用戶接受和使用。對於硬件設備制造商,再也不必擔心自己的產品因為沒有為某些軟件提供驅動程序而被用戶所忽視或放棄。一次編寫的驅動程序(ＯＰＣ服務器),可以被所有的應用軟件所用。不僅節省了各種Ｉ/Ｏ驅動程序的開發費用,而且可以讓制造商集中精力生產更易於用戶使用的、功能完善的硬件。
OLE（Active X）/COM
Active X/COM技術定義各種不同的軟件部件如何交互使用和分享數據。OLE/COM是一種
客戶/服務器模式，具有語言無關性、代碼重用性、易於集成性等優點。