COM技術及OPC技術PPT課件

1、COM技術及技術及OPC技術技術第1頁/共69頁主要內容COM基礎知識OPC的概念OPC的作用OPC基礎知識實驗室OPC組相關的工作第2頁/共69頁一、COM基礎知識 COM(Component Object Model，組件對象模型)是Microsoft創(chuàng)建并已取得廣泛認可的一種組件標準。 在COM標準中，COM對象被很好的封裝起來，客戶無法訪問對象的實現(xiàn)細節(jié)，提供給用戶的唯一的訪問途徑是通過COM接口來訪問。對于COM接口有兩方面的含義： 首先它是一組可供調用的函數(shù)，由此客戶可以讓該對象做某些事情；其次，接口是組件程序及其客戶程序之間的協(xié)議。也就是說接口不但定義了可用什么函數(shù)，也定義了當調

2、用這些函數(shù)時對象要做什么。 COM提供了編寫組件的一個標準方法，遵循COM標準的組件可以被組合起來以形成應用程序。組件和客戶之間通過“接口”來發(fā)生聯(lián)系，至于這些組件是誰編寫的、如何實現(xiàn)的都是無關緊要的。第3頁/共69頁 IOPCAsyncIO : public IUnknown public: virtual HRESULT STDMETHODCALLTYPE Read( /* in */ DWORD dwConnection, /* in */ OPCDATASOURCE dwSource, /* in */ DWORD dwCount, /* size_isin */ OPCHANDLE

3、_RPC_FAR *phServer, /* out */ DWORD _RPC_FAR *pTransactionID, /* size_issize_isout */ HRESULT _RPC_FAR *_RPC_FAR *ppErrors) = 0; virtual HRESULT STDMETHODCALLTYPE Write( /* in */ DWORD dwConnection, /* in */ DWORD dwCount, /* size_isin */ OPCHANDLE _RPC_FAR *phServer, /* size_isin */ VARIANT _RPC_FA

4、R *pItemValues, /* out */ DWORD _RPC_FAR *pTransactionID, /* size_issize_isout */ HRESULT _RPC_FAR *_RPC_FAR *ppErrors) = 0; virtual HRESULT STDMETHODCALLTYPE Refresh( /* in */ DWORD dwConnection, /* in */ OPCDATASOURCE dwSource, /* out */ DWORD _RPC_FAR *pTransactionID) = 0; virtual HRESULT STDMETH

5、ODCALLTYPE Cancel( /* in */ DWORD dwTransactionID) = 0; ;第4頁/共69頁OPC與COM間關系 OPC（OLE for process control）是建立在微軟公司OLE/COM技術基礎上。 COM技術的出現(xiàn)為簡單地實現(xiàn)控制設備和控制管理系統(tǒng)之間的數(shù)據(jù)交換提供了技術基礎。但如果不提供一個工業(yè)標準化的COM接口，各個控制設備廠家開發(fā)的COM組件之間的相互連接仍然是不可能的。 OPC是作為工業(yè)標準定義的特殊的COM接口。對相關COM技術的理解是對OPC技術理解的關鍵所在。OPC技術還有著它本身的獨特性，理解了COM技術只是理解OPC技術的

6、第一步。第5頁/共69頁COM組件的特點 遵循COM規(guī)范編寫的組件具有以下特點： COM組件是以二進制的形式發(fā)布，所以COM組件是完全與語言無關的。 COM組件可以在不妨礙老客戶的情況下被升級。COM提供了一種實現(xiàn)同一組件不同版本的標準方法。升級其實就是在現(xiàn)有的組件上增加新的接口就可以了。 COM組件可以透明地在網(wǎng)絡上被重新分配位置。對遠程機器上的組件同本地機器上的組件的處理方式?jīng)]有什么差別。 COM組件是一種給其他應用程序提供面向對象的API服務的極好方法。第6頁/共69頁COM接口 客戶程序和組件程序通過接口進行相互之間的通信。組件程序就是通過接口暴露它的功能給客戶程序的，而COM客戶程序

7、是不可能看見組件對象本身的。僅有接口是可見的，它告訴客戶程序能利用組件能干什么，如何利用它的功能。 在組件內，接口以虛函數(shù)表的形式實現(xiàn)的。實際上，COM標準就是標準的接口和使用它所需協(xié)議的描述，所以說接口是COM允許對象跨進程、跨計算機進行交互的關鍵技術。第7頁/共69頁接口的定義、結構與分類 COM對于接口的定義和接口的實現(xiàn)作了嚴格的區(qū)分。通過下面的IUnknown接口可以知道，在接口中只有接口方法的描述，而沒有實現(xiàn)。 COM接口的名字以字母I打頭。其中IUnknown接口最重要，因為所有其它接口都是從IUnknown接口直接或間接繼承而來的。 IUnkown接口定義了三個方法： 1、HRE

8、SULT QueryInterface(in REFIID riid,out void *ppv); 2、ULONG AddRef(); 3、ULONG Release();第8頁/共69頁 COM定義的每一個接口都必須從IUnkown接口繼承過來。原因在于IUnkown接口提供了兩個非常重要的特性：生存期控制和接口查詢?？蛻舫绦蛑荒芡ㄟ^接口與COM對象進行通信，雖然客戶程序可以不管對象內部實現(xiàn)的細節(jié)，但它要控制對象存在與否。如果客戶還要繼續(xù)對對象進行操作，則它必須保證對象一直存在于內存中；如果客戶對對象的操作已經(jīng)完成，以后也不再需要該對象了，則應該及時地把對象釋放掉，以提高系統(tǒng)資源的利用率。

9、 IUnkown接口中的AddRef()和Release()負責對象引用計數(shù)，實現(xiàn)組件對象生命周期的管理。每當COM組件被引用一次就應調用一次AddRef()方法。而當客戶端在釋放COM組件的某個接口時就需要調用Release()方法。 如果一個COM對象實現(xiàn)了多個接口，在初始時刻客戶程序不太可能得到該對象的所有接口指針，它只會擁有一個接口指針。如果客戶程序需要其它的指針，則利用IUnkown接口中的QueryInterface()方法是用于查詢組件對象所實現(xiàn)的其它接口。第9頁/共69頁OPC對象接口定義 OPC服務器采用的就是以EXE方式實現(xiàn)的COM組件，它可以運行在本地計算機上，也可以運行

10、在網(wǎng)絡上的遠程計算機上。實際上就是一個典型的進程外COM組件，只不過OPC服務器的接口是有OPC標準組織規(guī)定的標準接口。OPC技術實際上就是COM技術在工業(yè)控制中的一個具體的應用。第10頁/共69頁客戶/服務器模型 客戶/服務器模型是一種發(fā)展比較成功的軟件模型。組件對象和客戶程序之間的相互作用是建立在客戶/服務器模型的基礎之上的，并且COM組件是運行在分布式環(huán)境中的。COM不僅僅是簡單的客戶/服務器模型，有時客戶也反過來提供服務，或服務器本身也需要其它對象的一些功能。一個組件對象可能既是服務器也是客戶，COM能有效地處理這些情況。在OPC異步通信訪問方式中，當OPC服務器觸發(fā)OPC應用程序的異

11、步訪問完成事件時，OPC服務器此時就扮演了客戶端的角色，將數(shù)據(jù)訪問結果傳送給OPC應用程序。第11頁/共69頁組件存在的類型 一般而言，組件具有三種類型：進程內組件、進程外組件和遠程組件。 第一種是駐留在本地機器上以DLL形式提供，該服務程序被調用時，嵌入到調用程序的線程中運行。此時客戶程序和組件程序位于同一臺計算機上，客戶程序調用組件時，客戶程序會把組件程序裝入自己的進程空間，即客戶程序和組件程序在同一個進程地址空間內。由于它占用和客戶端應用程序同樣的地址空間，它可以與客戶端更快地通信。在客戶端和服務器端組件有大量數(shù)據(jù)轉移操作的情況下是最理想的，進程內服務器會更快地裝載。 第二種是駐留在本地

12、機器上以EXE形式提供，具有獨立的進程?？蛻舫绦蚝徒M件程序也位于同一臺計算機上，但客戶程序和組件程序分別在不同的進程地址空間中。在COM中，采用了本地過程調用LRC(Local Procedure Call）來進行本地通信。 第三種駐留在遠端機器上以EXE形式提供，服務程序通過網(wǎng)絡被調用，它在遠端機器上運行，結果通過網(wǎng)絡返回給調用者。這種功能是使用DCOM實現(xiàn)的。DCOM的優(yōu)點在于它并不要求任何特別的編程來使其具有功能。另外服務器和客戶端通信是通過RRC（Remote Procedure Call）通信協(xié)議進行的。 雖然客戶程序和組件程序交互的內在方式是完全不同的，但是對于功能相同的進程內和進

13、程外組件，從程序編寫的角度看，客戶程序是以同樣的方法來使用組件程序的。OPC服務器采用的就是以EXE方式實現(xiàn)的COM組件。第12頁/共69頁通過COM庫創(chuàng)建COM對象 COM庫充當了組件程序和客戶程序之間的橋梁，在Microsoft Windows操作系統(tǒng)環(huán)境下，這些庫以DLL文件的形式存在。在組件對象的創(chuàng)建過程、對象管理、內存管理、以及在標準化操作等方面，都起了重要的作用。COM庫可以保證所有的組件按統(tǒng)一的方式進行交互操作，而且它使我們在編寫COM時，可不編寫為進行COM通信而必需的大量基礎代碼，而是直接利用COM庫的API進行編程，從而大大加快開發(fā)的速度。第13頁/共69頁客戶程序通過CO

14、M庫訪問組件程序的步驟 （1）在進行函數(shù)調用以前，必須調用COM庫的初始化函數(shù)：HRESULT= CoInitialize(NULL); （2）通過函數(shù)CLSIDFromProgID()或CLSIDFromProgIDEx()ProgID,查找注冊表中相關組件的CLSID。 （3）客戶端程序調用CoCreateInstance()，創(chuàng)建COM對象，傳遞組件對象類的CLSID以及所要接口的IID。 （4）COM庫在HKEY_CLASSES_ROOTCLSID.鍵值下查找服務器的CLSID鍵值，這個鍵值包含服務器的注冊信息。 （5）COM庫讀取服務器的全路徑并將組件程序加載。 （6）COM庫為組件

15、對象類請求類工廠。COM庫在類工廠中調用CreateInstance()方法創(chuàng)建客戶端程序請求的COM對象。 （7）CreateInstance()返回一個接口指針給客戶端程序。第14頁/共69頁通過COM庫刪除COM對象 IUnknown是每一個COM對象必須實現(xiàn)的接口，其中有一個Release()方法。調用這個方法通知COM對象你不再需要對象。一旦調用了這個方法之后，就不能再次使用這個接口，因為這個COM對象可能從此就從內存中消失了。 如果應用程序使用許多不同的COM對象，因此在用完某個接口后調用Release()就顯得非常重要。如果你不釋放接口，這個COM對象將保留在內存中，這會增加不必

16、要的開銷。如果應用程序要長時間運行，就應該在應用程序處于空閑期間調用CoFreeUnusedLibraries()API函數(shù)。這個API函數(shù)將卸載任何沒有明顯引用的COM服務器，因此這也降低了應用程序使用的內存開銷。第15頁/共69頁 / 像上面一樣創(chuàng)建COM對象，然后， if ( SUCCEEDED ( hr ) ) /通知COM對象不再使用它 m_IOPCServer -Release(); 應用程序對COM庫進行初始化之后，可以調用COM庫提供的各種服務，在調用過程中必然要消耗COM庫管理的資源。因此，COM程序在完成COM庫服務之后，通常在程序退出之前，終止COM庫服務函數(shù)，以便釋放C

17、OM庫所維護的資源。COM庫的終止函數(shù)為： void CoUninitialize(void); 凡是調用CoInitialize函數(shù)返回S_OK的進程或者程序模塊，都一定要調用對應的CoUninitialize函數(shù)以保證COM庫資源的有效利用。第16頁/共69頁C+調用OPC服務器的關鍵性代碼 OPC服務器實際上就是一種COM組件，以下是一個OPC客戶程序調用OPC服務器對象的關鍵性代碼，創(chuàng)建一個OPCServer對象的實例并請求指向這個對象m_IOPCServer接口指針。 HRESULT hr; / 首先聲明一個接受CoCreateInstance()返回值的HRESULT bool m

18、_bComInitialized;IOPCServer* m_IOPCServer;/ 指向IID_IOPCServer接口的指針hr= CoInitialize(NULL) /初始化COM庫m_bComInitialized = SUCCEEDED (hr);if (!m_bComInitialized)return (FALSE); /如果初始化COM庫失敗，程序就不必向下執(zhí)行/通過ProgID,查找注冊表中的相關CLSID，hr = CLSIDFromProgID(LNAPOPC.Svr, &clsid); if (hr != S_OK) AfxMessageBox(獲取CLSI

19、D失敗); CoUninitialize(); /調用CoUninitialize函數(shù)釋放COM庫的資源 return (FALSE);第17頁/共69頁 /創(chuàng)建OPC服務器對象，并查詢對象的IID_IOPCServer接口 hr = CoCreateInstance ( clsid, /coclass的CLSID NULL, /不是用聚合 CLSCTX_LOCAL_SERVER, /服務器類型 IID_IOPCServer, /接口的IID (void*) &m_IOPCServer); /指向接口的指針 if ( SUCCEEDED ( hr ) ) /用m_IOPCServer調

20、用其它的方法 else /不能創(chuàng)建OPC服務器對象 AfxMessageBox(創(chuàng)建OPC服務器對象失敗); CoUninitialize(); /調用CoUninitialize函數(shù)釋放COM庫的資源 調用CoCreateInstance()來創(chuàng)建新的OPC服務器對象。如果hr接受到一個表示成功的代碼，即S_OK，則SUCCEEDED宏返回TRUE，否則返回FALSE。FAILED是一個與SUCCEEDED對應的宏用來檢查失敗代碼。第18頁/共69頁二、 OPCOPC的概念 OLE for Process Control (用于過程控制的OLE(Object Lingking and Emb

21、edding)） OPC是一種過程控制中的標準化技術該技術基于OLECOMDCOM，采用客戶服務器模式。 OPC建立了一組符合工業(yè)控制要求的接口規(guī)范，主要包括：OPC數(shù)據(jù)訪問規(guī)范，OPC報警與事件規(guī)范，OPC歷史數(shù)據(jù)存取規(guī)范，OPC安全規(guī)范，OPC批處理規(guī)范，OPC服務器數(shù)據(jù)交換規(guī)范和OPC XML規(guī)范。第19頁/共69頁 其中應用最多的是數(shù)據(jù)訪問規(guī)范。不同的規(guī)范定義了不同的接口集合，以及這些接口需要實現(xiàn)的功能。只要硬件開發(fā)商提供了實現(xiàn)OPC接口的服務器，任何支持OPC接口的客戶程序均可采用統(tǒng)一的方式對不同硬件廠商的設備數(shù)據(jù)進行存取。第20頁/共69頁OPC OPC 特性OPC標準前第21頁/

22、共69頁OPC OPC 特性OPC標準后第22頁/共69頁 OPC是連接數(shù)據(jù)源(OPC服務器)和數(shù)據(jù)的使用者(OPC應用程序)之間的接口標準。數(shù)據(jù)源可以是PLC，DCS，條形碼讀取器等控制設備。服務器既可以是本地服務器，也可以是遠程服務器。OPC是具有高度柔軟性的接口標準。目前，OPC技術主要應用于以下幾大工業(yè)控制：在線數(shù)據(jù)監(jiān)測，報警和事件處理，歷史數(shù)據(jù)訪問遠程數(shù)據(jù)訪問。第23頁/共69頁OPC 的客戶/服務器模型（C/S） OPC一般采用客戶/服務器模式。通常把符合OPC規(guī)范的設備驅動程序稱為OPC服務器，它是一個典型的數(shù)據(jù)源程序。將符合OPC規(guī)范的應用軟件稱為OPC客戶，它是一個典型的數(shù)據(jù)

23、接受程序。服務器充當客戶和硬件設備之間的橋梁?？蛻魧τ布O備的讀寫操作由服務器代理完成。第24頁/共69頁 在客戶端和服務器端都各自定義了統(tǒng)一的標準接口，接口具有不變特性。接口明確定義了客戶同服務器間的通信機制，是連接客戶同服務器的橋梁和紐帶?？蛻敉ㄟ^接口實現(xiàn)與服務器通信，獲取現(xiàn)場設備的各種信息。統(tǒng)一的標準接口是OPC的實質和靈魂。第25頁/共69頁三、OPC的作用 OPC的優(yōu)勢，在于異構系統(tǒng)的集成可以通過OPC技術來解決（也可以通過協(xié)議轉換橋來解決）。OPC服務器集成了多種總線協(xié)議，在服務器中實現(xiàn)協(xié)議轉換，并將接收到的數(shù)據(jù)通過COM或DCOM傳給客戶端。 OPC服務器由硬件廠商提供，因為硬件

24、廠商了解底層協(xié)議，方便編寫OPC服務器。上層用戶可以用任意一個客戶端（很多組態(tài)軟件集成OPC客戶端），從接口把數(shù)據(jù)讀出即可。第26頁/共69頁第27頁/共69頁異構網(wǎng)絡互聯(lián)的實現(xiàn) 現(xiàn)場總線至今仍然是多種總線共存的局面，致使系統(tǒng)集成和異構網(wǎng)段之間的數(shù)據(jù)交換面臨許多困難。以OPC作為異構網(wǎng)段集成的中間件可以形成如下圖所示的系統(tǒng)集成軟件解決方案。每個總線段提供各自的OPC服務器，任一OPC客戶端軟件都可以通過一致的OPC接口訪問這些OPC服務器，從而獲得各個總線段的數(shù)據(jù)。第28頁/共69頁OPC優(yōu)勢異構網(wǎng)絡的互聯(lián)第29頁/共69頁利用協(xié)議轉換橋實現(xiàn)異構網(wǎng)絡集成第30頁/共69頁四、OPC基礎知識第3

25、1頁/共69頁OPC客戶端模型第32頁/共69頁OPC服務器的結構 OPC數(shù)據(jù)訪問服務器在結構上由服務器（Server）、組（Group）、項（Item）三級對象組成。邏輯關系上，服務器和組之間是聚合關系，組和項之間是包容關系。其中項對應著硬件設備中某個具體設備單元，它包括當前設備單元數(shù)據(jù)值、當前設備單元的數(shù)據(jù)時間標簽、數(shù)據(jù)品質信息等。第33頁/共69頁客戶端與服務器的關系OPC Client #1OPCServerVendor AOPCServerVendor COPCServerVendor BOPC Client #2OPC Client #3第34頁/共69頁服務器中組與項目的關系：I

26、tem 1GroupItem 2Item 3第35頁/共69頁OPCOPC數(shù)據(jù)傳輸方式：同步和異步方式是OPC Client與OPC Server之間交換數(shù)據(jù)的兩種方式： 同步方式是按照一定的時間頻率交換所有數(shù)據(jù)的方式，方法簡單，但效率較低。適用于發(fā)送數(shù)據(jù)量教少的場合。 異步方式則當服務器緩沖區(qū)發(fā)生更改時，向客戶發(fā)出通知，客戶得到通知后在進行處理的一種方式。異步方式需要在客戶程序中實現(xiàn)服務器的回調函數(shù)。適用于發(fā)送數(shù)據(jù)量大的場合。第36頁/共69頁同步訪問方式第37頁/共69頁異步訪問方式 第38頁/共69頁Cache方式與Device方式：OPC Server有一個數(shù)據(jù)緩沖區(qū)，存儲來自設備最新

27、的數(shù)據(jù)值，OPC Client通過該緩沖區(qū)讀寫數(shù)據(jù)的方式為Cache方式 不通過數(shù)據(jù)緩沖區(qū)，直接從設備讀取數(shù)據(jù)的方式為Device方式第39頁/共69頁OPC DA服務器對象接口第40頁/共69頁OPC DA組對象的接口第41頁/共69頁客戶端需實現(xiàn)的接口IOPCDataCallbackIOPCShutdownIAdviseSink (old)第42頁/共69頁三、OPC組所做的工作 以前版本的OPC服務器 OPC服務器開發(fā)工具包 新版本的OPC服務器第43頁/共69頁OPC服務器模型第44頁/共69頁1 1、基于EPAEPA的OPCOPC服務器模型 OPC服務器總體結構由OPC標準接口實現(xiàn)模

28、塊、服務器界面模塊、存儲緩沖區(qū)模塊、硬件驅動模塊組成，OPC服務器與EPA協(xié)議中的詳細交互部分,如圖所示。這樣，OPC保證了EPA與其它標準的產(chǎn)品互聯(lián)互通，解決了EPA設備與其它標準設備間的互操作性問題。第45頁/共69頁OPC服務器工作流程圖第46頁/共69頁存儲緩沖區(qū)模塊 存儲緩沖區(qū)中緩存從EPA現(xiàn)場設備采集到的實時數(shù)據(jù)，和存儲來自OPC客戶端的數(shù)據(jù)，而且在OPC客戶端需要時傳給客戶端。存儲緩沖區(qū)高速緩存現(xiàn)場設備的數(shù)據(jù)，使得OPC客戶端的調用不需等待而快速地從OPC服務器中返回，減少了OPC客戶端的應用程序阻塞時間，加快了其應用程序的執(zhí)行。第47頁/共69頁服務器界面模塊 服務器界面的主要

29、功能是方便用戶配置服務器的參數(shù)。組對象是用來管理標簽的，實際上就是對標簽的分類。最后就是創(chuàng)建標簽對象，數(shù)值就是服務器從現(xiàn)場設備取得的實時變化的數(shù)據(jù)。標簽對象和現(xiàn)場設備是一一對應的，OPC客戶端程序從OPC服務器讀取標簽對象的數(shù)據(jù)，就等于從現(xiàn)場設備讀取數(shù)據(jù)。第48頁/共69頁硬件驅動模塊現(xiàn)場設備通過驅動程序與OPC服務器進行數(shù)據(jù)交互，簡單的說，即對現(xiàn)場設備進行讀寫操作。在這里，我們通過EPA協(xié)議與主控制器的通信來實現(xiàn)OPC服務器的驅動部分。這里用到的EPA應用層服務是變量訪問服務，包含讀服務、寫服務和信息分發(fā)服務。第49頁/共69頁 由于EPA協(xié)議數(shù)據(jù)傳輸是基于TCP(UDP)/IP傳輸協(xié)議的，

30、為了使數(shù)據(jù)傳輸?shù)男侍岣?，OPC服務器采用UDP套接字進行通信，其中，讀寫服務的通信過程采用客戶機/服務器(C/S)模式進行通信。下面結合上圖以變量讀服務來說明數(shù)據(jù)傳輸流程。 首先，EPA通信發(fā)起方通過鏈接對象標識ID查找與其相對應的EPA鏈接對象，將EPA鏈接對象中本次通信所需的EPA鏈路信息，包括EPA通信應答方的設備IP地址、功能塊實例ID。 其次，當獲得這些信息后，調用相應的應用層服務，進行EPA報文的編碼。第50頁/共69頁 把EPA報文頭和變量讀請求服務報文封裝好后，EPA服務報文下傳到EPA套接字映射接口實體。套接字映射接口主要完成兩個功能：第一，按照應用層服務內容(本例中為讀服

31、務)確定其優(yōu)先級，并將報文送到相應的優(yōu)先級緩沖隊列中去；第二，監(jiān)控EPA鏈路，當鏈路空閑時按優(yōu)先級順序進行報文的發(fā)送。 第三，EPA現(xiàn)場設備收到讀請求報文后，采用EPA服務中的變量讀正響應服務回答，OPC硬件驅動程序模塊接收線程函數(shù)通過套接字接收到報文數(shù)據(jù)后，按照變量讀正響應報文進行報文解析，刷新OPC數(shù)據(jù)。第51頁/共69頁系統(tǒng)結構圖第52頁/共69頁 下面采用EPA服務中的信息分發(fā)服務為例說明數(shù)據(jù)傳輸過程。整個過程的流程如圖所示。首先，現(xiàn)場設備中集成了EPA協(xié)議棧，把現(xiàn)場實時數(shù)據(jù)打包成EPA數(shù)據(jù)，發(fā)送到EPA網(wǎng)絡上；然后，OPC服務器中的硬件驅動模塊把接收到EPA報文解包，并把數(shù)據(jù)放到存儲緩沖區(qū)中；第三，OPC客戶端從存儲緩沖區(qū)中讀取數(shù)據(jù)；最后，OPC客戶端將數(shù)據(jù)顯示出來。第53頁/共69頁基于OPC的EPA監(jiān)控系統(tǒng)界面第54頁/共