1、引言
隨著國內外石油化工領域工業自動化的不斷發展，采用先進技術對現有裝置進行技術改 造，逐步提高裝置的生產規模和工藝技術水平，提高裝置的經濟效益是一種必然的趨勢。在 此趨勢下，很多企業希望通過先進控制的方法達到以上目的。而裝置先進控制以及回路自動 控制的基礎就是PID 參數的合適設置。 現階段 PID 參數的設置很大程度上依賴于操作工人的經驗，對于沒有經驗的工作人員 來說調整PID 參數有些難度。PID 優化整定系統正是針對此問題，自行設計開發的系統軟件， 其目的是為了實現PID 參數整定的簡單化，對于沒有合適參數的回路通過計算得到接近的 參數值，對已有的參數給出優化的參數值。PID 優化整定系統的基礎是數據采集模塊。數據 采集模塊以OPC 協議作為接口通訊方式，連接DCS 工程師站與上位機進行數據讀取。
2、DCS 及OPC 概述
DCS（Distributed Control System）集散控制系統產生于20 世紀70 年代，它滿足了大型 生產的自動化要求，大大提高了單套裝置的生產能力[1]。在國內大型石油化工聯合企業中， 主要煉油化工裝置已經基本實現了DCS 控制，優化了生產過程并提高了生產效率，但由于 大多數DCS 系統是封閉系統，普遍缺乏統一、標準的開放式接口，難以滿足企業信息化和 管控一體化的發展要求。為了解決這些問題，一些與微軟公司合作的自動化硬件和軟件供應商聯合制定了一套稱為OPC 規范的接口協議，以此來提高過程控制工業中的自動化／控制 應用程序，現場系統／設備以及商業／辦公室應用程序之間的互操作性[2]。
OPC是一個開放的工業接口標準，意指用于過程控制的OLE技術[3]。OPC基于微軟的 OLE、COM和DCOM技術，包括一整套接口、屬性和方法的標準集，用于過程控制和制造 業自動化系統[4]。OPC技術的實質是允許任何設備與其它設備自由通訊的一種機制，是一種 用于過程控制和工業自動化的即插即用的軟件技術，是一種過程實時數據交換的工業標準 [5]。這個接口規范不但能夠應用于單臺計算機，而且可以支持網絡上分布式應用程序之間的 通訊，以及不同平臺上應用程序之間的通訊。其基本思想是：每個硬件供應商為其設備開發 一個通用的數據接口(即OPC Server)，供其它系統讀寫信息，客戶應用軟件也可以通過OPC 規范的接口來讀寫硬件設備的信息(作為OPCClient)。我們在使OPC時，不必關心底層硬件內 部的具體細節，只需遵循OPC數據接口協議，就能夠從不同OPC數據服務器中取得數據[6]。
3、OPC接口的設計
OPC接口的設計包括OPC服務器端和客戶端兩個部分，其實質就是連接數據源和數據使 用者之間的通道。目前，許多DCS產品都推出和集成了OPC服務器，例如基于Windows操作 系統的YOKOGAWA CS3000 DCS和ROSEMOUNT DELTA V DCS。因此，設計PID優化整定 系統的OPC接口有很大的普遍性和實用性。
3.1 OPC接口的選擇及實現
OPC規范規定了兩套接口標準：OPC自定義接口和OPC自動化接口，如圖1所示。自定 義接口的效率高，通過該接口，客戶能夠發揮OPC服務器的最佳性能，采用C++語言的客戶 一般采用自定義接口方案；自動化接口使解釋性語言和宏語言訪問OPC服務器成為可能，采 用VB、Delphi等語言的客戶一般采用自動化接口[7]。
圖 1 OPC 接口類型
其中，客戶端程序的開發主要是指客戶端程序中 OPC 接口部分的開發。客戶端程序本 身可以完成很多復雜的數據處理與顯示功能，但需要通過OPC 接口部分訪問OPC 服務器， 對現場數據進行存取。設計時可根據不同的需求特點，應用不同的接口標準。
3.2 OPC數據存取服務器的訪問方式
OPC客戶程序對OPC服務器中數據的訪問方式主要有同步、異步和訂閱三種。客戶程序 可按照一定的周期對服務器程序進行數據同步存取操作，此時客戶方的調用函數一直運行到 所有數據讀寫完成。在異步通信方式下，服務器程序定期刷新OPC項，并判斷其數值或品質 是否變化，如果有變化則將變化后的數據發送給客戶程序，此時客戶方的調用函數可立刻返 回。顯然，異步通報方式的通信效率更高，但有多個客戶程序與服務器相連時，同步讀寫方 式更具時效性[8]。第三種訂閱方式，即OPC服務器監控的數據在狀態發生改變時主動的通知 客戶程序[9]，而不用客戶被動地、一次次地去查詢數據，判斷其是否發生改變。對于每個組 對象，客戶程序可根據需要采用其中一種數據存取方式。
4、PID優化整定系統OPC接口的架構與實現
4.1 PID優化整定系統的軟、硬件結構
PID優化整定系統的硬件為一臺裝有OPC接口客戶端程序的PC機，根據實際情況分別采 用添加網卡或使用路由器的方式接入到控制系統的工程師站上，使PID優化整定系統與工程 師站處在同一局域網內。如果原有的工程師站上配有雙網卡，則直接使用網線與工程師站連 接；如果沒有雙網卡，或不方便接入的，則添加路由器，將兩臺機器接入同一網內。
圖2 系統網絡結構圖
PID優化整定系統的軟件是指優化整定PC機上裝有的自行開發的PID優化整定軟件。數 據采集的通訊接口方式使用OPC自動化接口方式，數據采集所搭建的環境結構如圖2所示。
4.2 OPC接口的實現
由圖2可以看出，整個系統的服務器端采用DCS提供的OPC接口，在工程師站上放置使 用OPC數據訪問接口編寫的OPC應用程序，它主要有兩個方面的功能：一是作為控制系統的 客戶端，連接下位機與上位機，讀取現場數據；二是作為PID優化整定系統的服務器端，連 接PID優化整定系統與下位機，將數據讀取到PID優化整定站，供后期數據計算使用。而數 據采集部分的客戶端，則放置在PID優化整定站，是使用VB語言，按照OPC自動化訪問接口 編寫的應用程序。讀取數據后，將相關數據保存在Access數據庫中，以便于以后隨時查詢使 用。在全部數據讀取過程中，應用的網絡協議主要為TCP/IP協議。
4.2.1 OPC服務器端的實現
根據不同工廠DCS設備或者工程師站操作系統的具體情況，服務器端分別采用兩種接口 方式，即自動化接口和自定義接口編寫服務器端程序。例如，對于YOKOGAWA CS3000 DCS， 采用的是VB編寫的自動化接口方式；對于ROSEMOUNT DELTA V DCS采用的是C++編寫的 自定義接口方式。
4.2.2 OPC客戶端的實現
客戶端的主要實現方式是OPC自動化接口方式，使用VB編寫應用程序。對于工廠各裝 置回路中pv（實測值）、sv（設定值）、mv（閥門開度）參數的采集使用同步通訊的方式； 而對于回路控制的自動、手動情況的采集則使用訂閱通訊的方式，即在參數（控制狀態）發 生改變時主動通知客戶端程序。 OPC數據訪問對象由分層結構組成，它由上而下包括OPC服務器對象（OPCServer）、 組對象（OPCGroup）、項對象（OPCItem），在設計OPC客戶端程序時，基本按照以上順 序進行連接。對于OPC自動化接口方式，OPC基金會專門為它的開發提供了“自動化包裝器” OPCDAAuto.dll，在編寫程序前，應該首先在VB項目中引用該動態鏈接庫，這樣才能調用 OPC自動化規范中定義的屬性、方法和事件。客戶端程序設計的基本步驟如下：
（1）在VB工程中添加對OPCDAAuto.dll的引用。
（2）聲明OPC對象。
（3）連接OPC服務器，創建OPC對象。設計時需要調用OPC服務器對象的“Connect” 方法，和OPC服務器建立連接。之后，用OPC服務器對象的“OPCGroups”屬性生成一個組 集合，再調用“Add”方法在OPC組集合中添加新的OPC組。最后，在對OPC服務器進行訪 問前，要使用“OPCItems”屬性生成項集合，并使用“Add”添加新的OPC項。
（4）讀取數據。對于裝置回路PID參數采集采用同步讀取方式，對于裝置回路的控制 狀態采集采用訂閱讀取方式；最多可同時讀取16條回路的參數。
（5）刪除OPC對象，斷開與服務器的連接。連接著OPC服務器的OPC應用程序，在退 出之前必須斷開與OPC服務器的連接。否則，OPC服務器不知道OPC應用程序的退出，計算 機資源就一直不能被釋放，長此以往，會造成計算機資源枯竭而產生嚴重問題。斷開連接時， 使用“Disconnect”方法；并將OPCItems、OPCGroup和OPCServer都置為Nothing，刪除對象。
4.3 數據存儲及導出的實現
為了給后期PID優化整定提供大量完整的數據，在數據采集過程中需要將大量數據保存 在Access數據庫中，以備使用。由于同時讀取多條回路，數據量很大，為避免在最后保存數 據時由于數據量過大而造成時間過慢，甚至是死機現象，設計時采取每讀取30個數據自動保 存一次的方法。另外，在把數據導出到Excel過程中，由于Excel自身的限制，一張Sheet保存 的數據有限，為了避免數據溢出，設計成每保存一定數據自動生成一張新的Sheet進行存儲。
5、結束語
以OPC為接口通訊方式的數據采集模塊是PID優化整定系統的基礎，該模塊及整個PID 優化整定系統的設計都相對獨立于現場工程師站，使用OPC通訊也只進行讀操作而不進行寫 操作。該設計的好處是，既能使兩臺機器互相沒有影響，又能使客戶端采集到全部DCS數據。 鑒于石油化工企業的重要性，數據采集只讀不寫，具有較好的安全性，可以保證原系統數據 的安全和純潔，也避免了數據錯誤造成的影響，保證了生產的安全。目前，PID優化整定系 統經過實驗室長期檢驗，已經穩定的運行于國內許多石油化工企業中，且運行狀況良好。 現在，絕大多數工控廠商為實現系統的開放性，其DCS都提供了OPC接口。同時，OPC 基金會也在不斷推出新的產品，從OPC DA到OPC XML-DA，再到OPC UA。OPC必然會向 更為廣泛的跨語言、跨平臺、企業級的方向發展。