DCOM，所以客戶程序和服務器可以分布在不同的主機上，形成網絡化的監控系統，基于OPC
的軟件結構如圖5-1所示。
圖5-1 0PC軟件結構
    OPC規范定義了客戶程序與服務器程序進行交互的方法，但并沒有規定具體的實現方
法，OPC服務器可由不同供應商提供，其代碼決定了服務器訪問物理設備的方式、數據處理
等細節。但這些對OPC客戶程序來說都是透明的，只需要遵循相同的規范或方法就能讀取
服務器中的數據。因此，對于OPC來說，開發是基礎。OPC按照面向對象的原則，將一個
應用程序（OPC服務器）作為一個對象封裝起來，只將接口方法暴露在外面，客戶以統一的
方式去調用這個方法，從而保證軟件對客戶的透明性，使得用戶完全從底層的開發中脫離出
來。OPC規范了接口函數，不管現場設備以何種形式存在，客戶都以統一的方式去訪問，從
而實現系統的開放性，易于實現與其他系統的接口。
    DCOM把COM的技術擴展到網絡，支持不同的計算機上服務器與客戶之間的相互通信，
這些計算機可以在局域網內，也可以在廣域網上，甚至可以通過Internet進行連接。所有底
層網絡協議的細節由DCOM負責處理，這使得我們可以很方便地開發適合分布式環境下的
客戶服努器程序。OPC技術把硬件和應用軟件有效地分離開，硬件廠商只需要提供一套軟件
組件，所有OPC客戶程序都可以使用這些組件，無需重復開發單位的驅動程序。一旦硬件
升級，只需修改OPC服務器端I，O接口部分，無需改動客戶端程序。其次，工控軟件公司
只要開發一套OPC接口就可采用統一的方式對不同硬件廠商的設備進行存取操作。這樣，
軟硬件廠商可以專注于各自的核心部分，而不是兼容問題。
    對于最終用戶而言，由于無需擔心互操作性，在選擇和更換軟硬件時有了更多的余地，
不再局限于從單一的廠商購買專用成套系統。同時，在異構計算機環境下的系統集成將變得
很簡單，應用程序之間很容易實現信息的共享和交互。用戶可以將重點放在整個系統的功能
及應用上，這也意味著成本的降低。此外，OPC組件的使用也十分方便，用戶只需進行簡單
的組態即可。OPC服務器在底層控制系統中采用統一的標準，實現了應用程序與現場設備
的有效連接，發揮著重要的橋梁作用，促進了企業現場控制層和生產過程管理層、經營決策
層的集成。
5.1.2 0PC的對象與接口
    1．OPC的對象及操作類模型
    OPC數據訪問服務器中主要包括三類對象：服務器(OPC Server)、組（OPC Group>
和項(OPC Item)。服務器對象維護自身的信息，并作為組對象的容器，通過它獲得其他對
象和服務的起始類，可用于返回OPC Group類對象；組對象維護自身的信息，同時為數據項
/64