opc

OPC是一項應用於自動化行業及其他行業的數據安全交換可互操作性標準。它獨立於平台，並確保來自多個廠商的設備之間信息的無縫傳輸，OPC基金會負責該標準的開發和維護。

OPC標準是由行業供應商、終端用户和軟件開發者共同制定的一系列規範。這些規範定義了客户端與服務器之間以及服務器與服務器之間的接口，比如訪問實時數據、監控報警和事件、訪問歷史數據和其他應用程序等，都需要OPC標準的協調。

OPC標準於1996年首次發佈，其目的是把PLC特定的協議（如Modbus，Profibus等）抽象成為標準化的接口，作為“中間人”的角色把通用的OPC“讀寫”請求轉換成具體的設備協議來與HMI/SCADA系統直接對接，反之亦然。就此出現了一個完整的產品行業，終端用户可以藉助其來最優化產品，通過OPC協議來實現系統的無縫交互。

最初，OPC標準僅限於Windows操作系統。因此，OPC是OLE for Process Control的縮寫（中文意思：用於過程控制的OLE）。我們所熟知的OPC規範一般是指OPC Classic，被廣泛應用於各個行業，包括製造業，樓宇自動化，石油和天然氣，可再生能源和公用事業等領域。

隨着在製造系統以服務為導向架構的引入，如何重新定義架構來確保數據的安全性？這給OPC帶來了新的挑戰，也促使OPC基金會創立了新的架構----OPC UA，以滿足這些需求。與此同時，OPC UA也為將來的開發和拓展提供了一個功能豐富的開放式技術平台。

OPC全稱是Object Linking and Embedding（OLE） for Process Control，它的出現為基於Windows的應用程序和現場過程控制應用建立了橋樑。在過去，為了存取現場設備的數據信息，每一個應用軟件開發商都需要編寫專用的接口函數。由於現場設備的種類繁多，且產品的不斷升級，往往給用户和軟件開發商帶來了巨大的工作負擔。通常這樣也不能滿足工作的實際需要，系統集成商和開發商急切需要一種具有高效性、可靠性、開放性、可互操作性的即插即用的設備驅動程序。在這種情況下，OPC標準應運而生。OPC標準以微軟公司的OLE技術為基礎，它的制定是通過提供一套標準的OLE/COM接口完成的，在OPC技術中使用的是OLE 2技術，OLE標準允許多台微機之間交換文檔、圖形等對象。

COM是Component Object Model的縮寫，是所有OLE機制的基礎。COM是一種為了實現與編程語言無關的對象而制定的標準，該標準將Windows下的對象定義為獨立單元，可不受程序限制地訪問這些單元。這種標準可以使兩個應用程序通過對象化接口通訊，而不需要知道對方是如何創建的。例如，用户可以使用C++語言創建一個Windows對象，它支持一個接口，通過該接口，用户可以訪問該對象提供的各種功能，用户可以使用Visual Basic，C，Pascal，Smalltalk或其它語言編寫對象訪問程序。在Windows NT4.0操作系統下，COM規範擴展到可訪問本機以外的其它對象，一個應用程序所使用的對象可分佈在網絡上，COM的這個擴展被稱為DCOM（Distributed COM）。

通過DCOM技術和OPC標準，完全可以創建一個開放的、可互操作的控制系統軟件。OPC採用客户/服務器模式，把開發訪問接口的任務放在硬件生產廠家或第三方廠家，以OPC服務器的形式提供給用户，解決了軟、硬件廠商的矛盾，完成了系統的集成，提高了系統的開放性和可互操作性。

OPC服務器通常支持兩種類型的訪問接口，它們分別為不同的編程語言環境提供訪問機制。這兩種接口是：自動化接口（Automation interface）；自定義接口（Custom interface）。自動化接口通常是為基於腳本編程語言而定義的標準接口，可以使用VisualBasic、Delphi、PowerBuilder等編程語言開發OPC服務器的客户應用。而自定義接口是專門為C++等高級編程語言而制定的標準接口。OPC現已成為工業界系統互聯的缺省方案，為工業監控編程帶來了便利，用户不用為通訊協議的難題而苦惱。任何一家自動化軟件解決方案的提供者，如果它不能全方位地支持OPC，則必將被歷史所淘汰。

在控制領域中，系統往往由分散的各子系統構成；並且各子系統往往採用不同廠家的設備和方案。用户需要，將這些子系統集成，並架構統一的實時監控系統。這樣的實時監控系統需要解決分散子系統間的數據共享，各子系統需要統一協調相應控制指令。再考慮到實時監控系統往往需要升級和調整。就需要各子系統具備統一的開放接口。OPC(OLE for Process Control) 規範正是這一思維的產物。OPC 基於Microsoft公司的 Distributed interNet Application (DNA) 構架和 Component Object Model (COM) 技術的，根據易於擴展性而設計的。OPC規範定義了一個工業標準接口。OPC是以OLE/COM機制作為應用程序的通訊標準。OLE/COM是一種客户/服務器模式，具有語言無關性、代碼重用性、易於集成性等優點。OPC規範了接口函數，不管現場設備以何種形式存在，客户都以統一的方式去訪問，從而保證軟件對客户的透明性，使得用户完全從低層的開發中脱離出來。OPC定義了一個開放的接口，在這個接口上，基於PC的軟件組件能交換數據。它是基於Windows的OLE——對象鏈接和嵌入、COM——部件對象模型(Component Object Model)和DCOM——分佈式COM(Distributed COM)技術。因而，OPC為自動化層的典型現場設備連接工業應用程序和辦公室程序提供了一個理想的方法。

1、工控解決方案用户

2、樓控解決方案用户

3、工控解決方案廠商

4、樓控解決方案廠商

5、工控解決方案集成商

6、樓控解決方案集成商

7、所有自動化領域

OPC是為了連接數據源(OPC服務器)和數據的使用者(OPC應用程序)之間的軟件接口標準。數據源可以是PLC，DCS，條形碼讀取器等控制設備。隨控制系統構成的不同，作為數據源的OPC服務器既可以是和OPC應用程序在同一台計算機上運行的本地OPC服務器，也可以是在另外的計算機上運行的遠程OPC服務器。

OPC接口既適用於通過網絡把最下層的控制設備的原始數據提供給作為數據的使用者(OPC應用程序)的HMI(硬件監督接口)/SCADA(監督控制與數據採集)，批處理等自動化程序，以至更上層的歷史數據庫等應用程序，也適用於應用程序和物理設備的直接連接。所以OPC接口是適用於很多系統的具有高厚度柔軟性的接口標準。

OPC誕生以前，硬件的驅動器和與其連接的應用程序之間的接口並沒有統一的標準。例如，在FA(FactoryAutomation)——工廠自動化領域，連接PLC(Programmable Logic Controller)等控制設備和SCADA/HMI軟件，需要不同的FA網絡系統構成。根據某調查結果，在控制系統軟件開發的所需費用中，各種各樣機器的應用程序設計佔費用的7成，而開發機器設備間的連接接口則佔了3成。此外，在PA(Process Automation)——過程自動化領域，當希望把分佈式控制系統(DCS——Distributed Control System)中所有的過程數據傳送到生產管理系統時，必須按照各個供應廠商的各個機種開發特定的接口，例如，利用C語言DLL(動態鏈路數據庫)連接DDE(動態數據交換)服務器或者利用FTP(文件傳送協定)的文本等設計應用程序。如由4種控制設備和與其連接的監視、趨勢圖以及表報3種應用程序所構成的系統時，必須花費大量時間去開發分別對應設備A，B，C，D的監視，趨勢圖以及表報應用程序的接口軟件共計要用12種驅動器。同時由於系統中共存各種各樣的驅動器，也使維護運轉環境的穩定性和信賴性更加困難。

而OPC是為了不同供應廠商的設備和應用程序之間的軟件接口標準化，使其間的數據交換更加簡單化的目的而提出的。作為結果，從而可以向用户提供不依靠於特定開發語言和開發環境的可以自由組合使用的過程控制軟件組件產品。

利用OPC的系統，是由按照應用程序(客户程序)的要求提供數據採集服務的OPC服務器，使用OPC服務器所必需的OPC接口，以及接受服務的OPC應用程序所構成。OPC服務器是按照各個供應廠商的硬件所開發的，使之可以吸收各個供應廠商硬件和系統的差異，從而實現不依存於硬件的系統構成。同時利用一種叫做Variant的數據類型，可以不依存於硬件中固有數據類型，按照應用程序的要求提供數據格式。

利用OPC使接口標準化可以不依存於各設備的內部結構及它的供應廠商來選用監視，趨勢圖以及表報應用程序。

為什麼開發自主OPC Server和OPC Gateway？

1、國外原廠商的高價格

2、國外原廠商面對項目的不靈活性

3、國內項目中子系統的多樣性難以提供DRIVER

4、自主OPC服務器追求的是穩定、實時、迅速。

5、眾多子系統的不規範性

6、總包項目在投標前後可能出現的不一致性

7、價格昂貴的原廠平台服務器軟件

8、總包商集成是否投入大量的人力開發

9、平台和子系統的兼容性

10、建立了OPC平台和子系統的互通

11、解決廠商和集成商在項目集成的煩惱

12、解決廠商和集成商分散資源進行二次開發

13、解決項目中子系統廠商的困擾

14、為上下位的數據通訊提供透明的通道