數據和信息是DCS監督控制的基礎，不僅來源于DCS現場控制層，還可來源于第三方設備和軟件。一個好的DCS監控應用軟件應能提供廣泛的應用接口或標準接口，可方便地實現將DCS控制器、第三方PLC、智能儀表和其他工控設備的數據接入到系統中。一般監控系統都把數據源看做外部設備，驅動程序與這些外部設備交換數據，包括采集數據和發送數據/指令。
    在com/tags/OPC" title="OPC" target="_blank">OPC出現以前，應用程序開發商（DCS廠商）需要不斷地開發這些設備的驅動程序，不但帶來了大量重復性勞動，也帶來了很多問題。如硬件供應商在硬件上作出一些小小的改動，應用程序就可能需要重寫；同時由于不同設備甚至同一設備的不同單元驅動程序可能不同，很難同時對這些設備進行優化操作。傳統的過程控制系統是一對一的系統，任何一種DCS、SCADA、MES等上位監控軟件或其他應用軟件在使用某種硬件設備時都需要開發專用的驅動程序，系統構建完成后的最終結果是：
    (1) 一種軟件要使用N類硬件設備需要開發N個驅動程序。(2) M類軟件要使用N類硬件設備需要開發M×N個驅動程序。(3) 每增加一個新的應用軟件需要另外開發N個硬件設備的驅動程序。(4) 每增加一個新的硬件設備需要為M個軟件開發新的設備驅動程序。
    圖1是傳統工業控制驅動程序的開發示意圖。

    為了解決傳統工業控制開發中的問題，硬件制造商一直試圖開發出一種可以被任何客戶應用程序使用的超級“設備驅動”程序。但是由于設備通信協議的不一致性，這項工作一直較為困難。
    在此背景下,本文提出了一種基于OPC的DCS第三方設備數據采集系統(COMMOPC)的設計與實現方法。本方法在高度抽象各種通信方式和通信協議的基礎上，實現了DCS與各種第三方設備的通信功能。
1 OPC技術簡介
    OPC[1](OLE for Process Control)是用于過程控制的OLE(Object Linking and Embedding)技術,它是世界上多個自動化公司、軟硬件供應商與微軟合作開發的一套工業標準，是專為在現場設備、自控應用、企業管理應用軟件之間實現系統無縫集成而設計的接口規范。這個標準使得COM技術適用于過程控制和制造自動化等應用領域。OPC以OLE、組件對象模型COM(Component Object Model)及分布式組件對象模型DCOM(Distributed COM)技術為基礎，定義了一套適于過程控制應用，支持過程數據訪問、報警、事件與歷史數據訪問等功能的接口，便于不同供應商的軟硬件實現“即插即用”的連接與系統集成[2]。
    OPC規范采用客戶/服務器模型，建立了一套在硬件供應商和軟件開發商之間相互遵循的規則。只要遵循這套規則，數據交換對兩者來說都是透明的，硬件供應商無需考慮應用程序的多種需求和傳輸協議，軟件開發商也無需了解硬件的實質和操作過程。圖2為使用OPC技術后工業程序的開發過程。

    基于OPC技術的系統構建完成后的最終結果是：
　 (1) M類軟件要使用N類硬件設備只需要開發N個驅動。
　 (2) 每增加一個新的應用軟件不需要另外開發硬件設備的驅動程序。
　 (3) 每增加一個新的硬件設備只需要為開發一個新設備的驅動程序。
    由此可見，任何一種設備只需要提供一種驅動就可以供任何軟件系統使用。
2 COMMOPC系統簡介
    基于OPC技術及多年驅動程序的開發背景，和利時公司開發了擁有自主專利的基于OPC的DCS第三方設備數據采集系統——COMMOPC。該系統是DCS、MES和RealMis等應用系統與現場設備之間的通用數據接口，實現對現場設備實時數據的訪問，可廣泛應用于企業自動化應用系統與現場設備之間的信息集成；可以把現場設備數據轉化成標準OPC數據，供OPC Client訪問，實現對現場數據的集中管理，并以OPC接口的方式供上層應用軟件訪問。只要具有OPC Client功能的應用軟件即可實現對現場設備數據的訪問，通用性好。
    COMMOPC系統結構如圖3所示，各個部分功能相對獨立又相互協作，形成一個統一的整體。

    COMMOPC系統IO驅動部分共有36種不同通信協議的第三方設備的設備驅動(由設備驅動開發包生成)，由OPC Server與外部設備及應用系統交換數據，包括采集數據和發送數據/指令，實質上是實現各種通信協議向OPC標準協議的轉換功能。這樣，DCS就不需理會具體的設備和應用類型，而只通過OPC Client與OPC Server的數據交換就能實現與外部設備和應用系統的數據交換。
3 COMMOPC的主要功能
    COMMOPC系統主要提供三個功能：
    (1)界面功能。包括:特殊操作控制，控制密碼可修改；點名、路徑兩種標簽瀏覽方式，默認為點名方式；界面配置；對組配置信息的導入導出；保存配置信息；OPC客戶端調試工具；串口監視工具；監視通信過程信息；監視實時通信數據；顯示樹型列表；手動控制單個通道通信啟停；托盤顯示當前運行狀態；提供測試版(測試版最多運行10小時)；運行版，測試版通過授權后自動轉為運行版；版本顯示；配置備份及恢復；安裝時自動注冊OPC服務器功能。
    (2)通信功能。包括:支持OPC DA 1.0、DA 2.0規范，滿足應用同步、異步、訂閱任一種訪問方式OPC客戶端實現數據通信；支持OPC客戶端重連接；提供各通道、各設備狀態信息，這些信息點作為有效點供OPC客戶端訪問；提供通道冗余；提供通信診斷；36種驅動，驅動滿足：采集設備的開關量、模擬量功能；對設備遙控、設定值功能；可進行特殊配置；支持串口通信方式，可掛接串口設備；支持以太網TCP通信方式，可掛接以太網TCP設備；支持以太網UDP通信方式，可掛接以太網UDP設備；提供OPCServer、通道、設備的狀態供OPC客戶端訪問。
    (3)日志功能。包括:日志信息種類可配置功能；日志自動生成、維護功能。
4 COMMOPC的系統設計方法
4.1模塊組成及邏輯
    COMMOPC系統由OPC接口模塊、數據管理模塊、數據顯示模塊、通信管理和調度模塊、規約處理模塊、通信測試和診斷模塊、日志模塊等組成。其系統邏輯圖如圖4所示。

4.2 OPC地址空間的設計
　OPC服務器中包含了很多可供客戶訪問的資源，這些資源在OPC中被稱為項(Item)。為了方便客戶訪問，這些項應該按照一種合理的方式進行組織。服務器中的每個項都有一個全局有效標識名FID(Full qualified ID)。有了FID，客戶就可以找到該項，因此稱該全局有效標識名為該項的服務器地址(簡稱地址)。這種具有服務器地址的項按照一定的方式組織在一起，就形成了服務器的地址空間。服務器地址空間就是服務器上包含的可以供客戶訪問的資源的集合。服務器地址空間是由服務器確定和管理的，其描述了服務器中包含了哪些項，以及這些項是按照什么形式進行組織的。
   本文地址空間設計為4層目錄結構，如圖5所示。

   根對象(CRoot::m_Root)是4層目錄結構的根，維護通道列表(ChannelList),所有的通道都可以通過m_Root找到；通道對象(CChannel::m_branches)是本系統地址空間的第1層，維護設備列表(DeviceList)，每個通道都可以有n個設備；設備對象(CDevice::m_branches)是第2層，維護組列表(GroupList)，組可以將標簽分為不同的類型；組對象(CGroup::m_tags)是第3層，維護標簽列表(TagList)；標簽(CExTag)是最后一層地址空間，標簽對應具體設備的點。
    在OPC接口內含有地址空間的根，用戶通過配置通道、設備、組及選擇組內的點之后即可完成地址空間的建立。當地址空間建立后，OPC Client可以通過OPC接口訪問地址空間內任意標簽點的值。標簽的地址格式為：ChName.DevName.GrpName.TagName。
4.3 設備驅動開發包的設計
    設備驅動開發包采用動態鏈接庫形式，不同通信協議的設備驅動程序都在開發包框架內編寫。這樣可以提高設備驅動的開發效率，同時方便維護升級，設備驅動的修改不會影響軟件主體部分。
    利用設備驅動開發包可以開發各種通信協議的設備驅動模塊。規約處理是設備驅動模塊的核心任務，不同的通信協議對應著不同的設備驅動模塊。根據需求，設備驅動模塊以DLL的形式生成，模塊修改或者添加功能后，只需要覆蓋原模塊，不需要重新編譯主程序。設備驅動模塊的主要功能是從主程序得到所要請求的標簽的信息，然后打包發送給設備，從設備讀取應答、解析數據，將相應的數據發送到數據管理和顯示模塊。如果OPC客戶端有控制命令，會發送給OPC服務器，OPC接口模塊將消息發送給設備驅動模塊，由設備驅動模塊進行打包，將命令報文發送給設備。
    設備驅動開發包生成的DLL形式的設備驅動模塊，如圖3驅動部分所示。

    本文在充分研究各種通信協議的基礎上,設計了COMMOPC系統，對第三方設備的數據采集進行了統一及標準管理，該方法有很好的靈活性和擴展性。通過實際應用證明，該方法設計的數據采集系統，不僅完全滿足了第三方設備數據采集的需求，還具有良好的穩定性、靈活性和可維護性。
參考文獻
[1] The OPC of data access custom interface standard version 2.05, Dec 17,2001.OPC基金會，www.opcfoundation.org.2001.
[2] 潘愛民. COM原理與應用[M]. 北京:清華大學出版社，1999:50-63.