朱善國

（福建聯合石油化工有限公司技術規(guī)劃部DCS 團隊）

目前，每一套DCS 系統(tǒng)都有自己的報警管理功能，用戶不費周折，就可以使系統(tǒng)將各種報警呈現出來。但是在某特大型石化聯合工廠內，DCS系統(tǒng)的數量多達10 套， 且每一套聯合裝置的DCS 系統(tǒng)都比較龐大，每一套系統(tǒng)每周產生的報警信息數量有十萬條之多，多者甚至達到每周五六十萬條，整個煉油化工一體化所有聯合裝置的DCS 系統(tǒng)每周產生的總報警信息數量巨大，對這些海量報警信息難以集中呈現管理，無法及時篩選出重要報警加以解決，給工藝操作員造成很大干擾，給進行DCS 系統(tǒng)維護的工程師帶來很大負擔。因此有必要采取措施將多套DCS 系統(tǒng)的重要報警匯集起來并進行管理。通過運用OPC 技術匯集多套DCS 系統(tǒng)報警信息并配置一臺報警工作站的方式來解決這個問題是一個不錯的選擇。

1 OPC 技術概述

OPC 是Object Linking and Embedding for Process Control 的縮寫，即用于過程控制的對象鏈接與嵌入技術。 OPC 技術是以微軟公司的組件對象模型（COM/DCOM/COM+）技術為基礎，用客戶端/服務器模式建立起來的一套用于工業(yè)應用程序之間信息集成與交互的接口規(guī)范［1］。 OPC 主要用于工業(yè)自動化的系統(tǒng)接口，從設備取得當前數據，并為管理應用提供實時歷史數據和事件。

OPC 技術有幾個主要的規(guī)范，包括OPC 數據訪問規(guī)范、OPC 報警與事件規(guī)范和歷史數據訪問規(guī)范。 筆者主要研究OPC 報警與事件規(guī)范。 OPC報警與事件規(guī)范描述了基于事件的信息接口，包括過程報警確認。 接口提供通過地址空間瀏覽的方法，并提供可用數據的信息［2］。

OPC 被設計成允許客戶端應用程序以一種統(tǒng)一的方式訪問現場數據。一個OPC 客戶端應用程序可以連接到由一個或者多個廠商提供的OPC 服務器程序。 OPC 是連接數據源（OPC 服務器）和數據使用者（OPC 應用程序）之間的軟件接口規(guī)范［1］，其訪問關系如圖1 所示。

圖1 OPC 應用程序與服務器訪問關系

作為數據源的OPC 服務器既可以是和OPC客戶端應用程序在同一臺計算機上運行的本地服務器，也可以是在另外的計算機上運行的遠程服務器［1］。 這條規(guī)范是OPC 問世早期提出來的，發(fā)展過程中不僅應用于OPC 數據訪問規(guī)范，而且同樣適用于OPC 報警與事件規(guī)范。 當然，前提條件是必須遵守微軟公司的組件對象模型（COM/DCOM/COM+）技術。 實際上現在的以微軟Windows 操作系統(tǒng)為平臺開發(fā)的OPC 程序都具備這個功能。

OPC 報警與事件規(guī)范提供了當現場特定的事件和報警條件發(fā)生時，OPC 報警與事件客戶端程序可由服務器程序得到通報的機制。 其規(guī)范相應的接口還允許OPC 報警與事件客戶端程序確定發(fā)生的事件和條件，并可獲得接口的當前狀態(tài)［1］。

OPC 報警與事件接口可以接收事件通知和報警通知。 事件通知是單條通知告訴客戶端一個事件的發(fā)生。 報警通知是告訴客戶端過程狀態(tài)的變化。 許多報警要求必須被確認，這種確認也是通過OPC 報警與事件接口完成的［2］。

在OPC 規(guī)范中， 報警是一個非正常狀態(tài)，因而也是一種特殊狀態(tài)，狀態(tài)可以用OPC 報警與事件服務器對象或其包容的對象來表示。 事件對OPC 服務器以及它所描述的設備客戶端程序都很重要，一個事件或者與某種狀態(tài)相關，或者與某種狀態(tài)不相關。OPC 客戶端程序可以指定發(fā)生的事件［1］。

OPC 報警與事件接口為傳輸來自不同事件源的過程報警和事件提供了靈活的接口。

OPC 報警與事件客戶端為了訪問服務器獲取消息通知， 必須先連接服務器并訂閱通知，而后再接收服務器觸發(fā)的所有通知。 為了限制通知的數量，OPC 報警與事件客戶端可以指定某種過濾器準則。

OPC 報警與事件客戶端連接首先是在OPC報警與事件服務器創(chuàng)建一個OPCEventServer(OPC 事件服務器)對象，然后生成OPCEventSubscription(OPC 事件訂閱)對象來接收事件消息。 這些事件消息的過濾器，可為每個訂閱單獨配置［2］。圖2 顯示了OPC 報警與事件客戶端在OPC 報警與事件服務器創(chuàng)建的不同對象。

圖2 OPC 客戶端創(chuàng)建對象以接收事件

2 DCS 系統(tǒng)的報警和事件

在每套DCS 系統(tǒng)中，都配備有自己的報警和事件功能。如EMERSON 公司的DCS 系統(tǒng)DeltaV軟件在工作站上安裝完畢后，DeltaV 的OPC 報警和事件服務器程序（DVOPCAE.exe）就自動隨DeltaV 軟件一起在工作站上安裝駐留完畢。 如果工作站節(jié)點的報警和事件子系統(tǒng)在系統(tǒng)組態(tài)時分配了某幾個單元裝置區(qū)域， 那么DeltaV 的OPC 報警和事件服務器能夠在該工作站上顯示出那幾個單元裝置區(qū)域有關的所有報警和事件。工作站上的OPC 報警和事件客戶端程序通過連接OPC 報警和事件服務器來訪問DeltaV 的報警和事件子系統(tǒng)，并采集顯示那些單元裝置區(qū)域有關的報警和事件。只要有客戶端程序連接OPC 報警和事件服務器程序， 服務器程序就自動運行。而且，OPC 報警和事件服務器程序允許客戶端程序設定各種過濾參數來采集顯示每一種報警和事件，過濾參數可以是過程報警、狀態(tài)改變及操作信息等。

另外，一般的DCS 系統(tǒng)都有將報警和事件記錄下來這個功能，DeltaV 系統(tǒng)也有。 DeltaV 系統(tǒng)的Professional PLUS Workstation 工作站、本地操作員工作站、本地應用工作站、遠程應用工作站都能采集記錄報警和事件數據。 如果用戶需要將報警和事件記錄下來，那么用戶只需要對DeltaV系統(tǒng)某工作站的報警和事件子系統(tǒng)屬性進行Event Chronicle（報警和事件歷史記錄）組態(tài)，之后，系統(tǒng)就自動進行報警和事件記錄。 報警和事件子系統(tǒng)通過Event Chronicle 保持報警和事件歷史數據，報警和事件歷史記錄數據庫的數據包里存儲了報警記錄、事件記錄、日志信息和SOE卡的事件。 工作站采集分配給它的幾個單元裝置區(qū)域的報警和事件并保持激活的報警和事件歷史記錄數據庫， 這樣工作站上的Process History View（過程歷史瀏覽）應用程序能夠呈現DCS 控制網絡里任何的報警和事件記錄。

一般情況下，DeltaV 系統(tǒng)的Professional PLUS Workstation 進行該聯合裝置的全區(qū)域的報警和事件歷史記錄，區(qū)別于只進行幾個單元裝置的局部區(qū)域的報警和事件歷史記錄的其他工作站。 DeltaV 系統(tǒng)的Professional PLUS Workstation工作站的報警和事件歷史記錄捕獲了按時間順序系統(tǒng)發(fā)生的所有事件，包括操作員改變、控制模件安裝、過程設備報警、SOE、設備狀態(tài)改變以及每個事件相關聯的細節(jié)（包括哪個用戶做了什么改變和什么時候改變等信息）［3］。DeltaV 系統(tǒng)的Professional PLUS Workstation 的報警和事件歷史記錄數據庫包括了工作站所在的該套DCS 系統(tǒng)中所有的報警和事件記錄，也是最全面的報警和事件記錄。

這是目前單套DCS 系統(tǒng)內的報警和事件管理情況，只要在系統(tǒng)投用前進行報警和事件的功能組態(tài)并在系統(tǒng)投用后根據管理要求進行各種報警和事件的過濾提取工作，就能夠滿足一套聯合裝置的報警管理要求。

3 組建報警管理網絡

某特大型石化聯合工廠內有10 套大型DCS系統(tǒng)， 要求將這10 套系統(tǒng)的報警數據源集合起來，進行集中管理并提取重要報警。

根據上文對DeltaV 系統(tǒng)報警和事件運行機理的描述：每一套聯合裝置所有的報警和事件記錄數據都集中在該套聯合裝置DCS 系統(tǒng)的Professional PLUS Workstation 工作站上。 因此，根據圖1 所示的OPC 客戶端程序與服務器的訪問關系， 將這些DCS 系統(tǒng)的Professional PLUS Workstation 工作站作為報警和事件的數據源， 用一種統(tǒng)一的OPC 客戶端應用程序進行連接并訪問這些報警和事件的數據源，從而收集整個特大型石化聯合工廠所有聯合裝置的報警和事件數據，并匯集成一個大型數據庫進行管理，最終達到匯集并管理報警和事件的目的。 依據這樣的思路，再結合該石化聯合工廠的現有具體狀況，配置一臺專門的報警和事件工作站來收集并管理報警和事件，構建了如圖3 所示的特大型石化聯合工廠10 套聯合裝置DCS 系統(tǒng)報警和事件管理網絡拓撲結構。

圖3 某特大型石化聯合工廠10 套聯合裝置DCS 系統(tǒng)報警和事件管理網絡拓撲簡圖

圖3 中，S01~S10 分別代表10 套DCS 系統(tǒng)，S01-EWSCR1-01~S10-EWSCR2-01 分別是S01~S10 的 Professional PLUS Station 站 （ 其 中S01EWSCR1-01、S09-EWSCR1-01 布置在CCR1，其余布置在CCR2）， 它們之間通過各自的網卡、交換機、網絡媒介和防火墻組成DCS 系統(tǒng)報警和事件管理網絡，S00-ALMCR2-01 站是報警和事件管理工作站。 由于實際中，該石化聯合工廠內先前根據工廠規(guī)定已經將全部的PLUS Station 工作站連接到Plant Information Network （PIN 工廠信息網）上，而實際要組建的多套DCS 系統(tǒng)報警和事件管理網絡只差1 臺Alarm Station 工作站，考慮到需要配置的Alarm Station 工作站相對于其他PLUS Station 工作站來說只是起到一個客戶端的作用，因此從經濟角度考慮就不再重新布置報警和事件管理網絡，而是利用石化聯合工廠現有的工廠信息網來達到目的，這樣既簡單方便又節(jié)約成本，而且不影響使用。

從硬件網絡組網方式上來看，報警和事件管理網絡成了PIN Network 里截取出來的一個虛擬網絡，要從一個虛擬網絡變?yōu)榉蠈嶋H運用的報警和事件管理網絡， 必須要有適當的軟件來支持，而且應具備以下功能：

a. 每一個作為報警和事件的數據源——每套DeltaV 系統(tǒng)的Professional PLUS Station 工作站必須具備OPC 報警和事件服務器功能，這樣才能被遠程的OPC 報警和事件客戶端訪問；

b. 報警和事件管理工作站必須具有OPC 報警和事件客戶端功能， 這樣才能遠程訪問各個OPC 報警和事件服務器；

c. 作為數據源的PLUS Station 工作站與遠程客戶端Alarm Station 工作站之間必須有可靠的通信連接， 或者說具備微軟的COM/DCOM 技術；

d. 報警和事件管理工作站必須具有數據庫的功能，這樣才能把各個DCS 系統(tǒng)的Professional PLUS Workstation 工作站的報警和事件歷史記錄匯集成一個大型數據庫進行統(tǒng)一調度和管理；

e. 報警和事件管理工作站必須具有報警和事件的管理與顯示功能，這樣才能使報警和事件結果有序、清晰地呈現出來。

從上面列出的功能來看， 符合功能a 的要求， 因為每套DeltaV 系統(tǒng)的Professional PLUS Station 站都安裝駐留了OPC 報警和事件服務器程序（DVOPCAE.exe）；功能c 顯然也容易達到，只要網絡上的每個工作站節(jié)點安裝了微軟Windows 操作系統(tǒng)和以此為平臺的OPC 應用程序，且配置了COM/DCOM 功能就可以， 本研究項目中的工作站都符合這個條件；對于功能b、d、e，通常的報警和事件收集管理軟件都具備這樣的功能，只不過這里的報警和事件管理工作站需要管理的報警和事件數量更加龐大，提煉和分析的功能更加強大而已。

為了滿足以上軟件要求，石化聯合工廠選擇購買Plantwide Event Historian (PEH 全廠事件歷史) 數據庫軟件和DeltaV Analyze 軟件來收集管理報警和事件。

4 Plantwide Event Historian 軟件工作機理

Plantwide Event Historian（PEH）是一款客戶端/服務器模式數據收集軟件，PEH 能夠捕獲和顯示來自DeltaV 系統(tǒng)或其他自動控制系統(tǒng)的事件數據，比如報警、操作行為、系統(tǒng)事件和SOE［3］。PEH 更是能夠通過OPC 報警和事件客戶端采集整個工廠所有系統(tǒng)的OPC 報警和事件服務器數據并匯入到一個MS SQL 服務器數據庫進行管理顯示的一整套應用程序。 PEH 由幾個服務器、幾個客戶端應用程序和SQL 數據庫組合而成。 圖4顯示了Plantwide Event Historian 的整體結構。

PEH 由3 個部分組成： 第1 部分包括PEH OPC Server Service、PEH Events Manager Server Service 和PEH Diagnostic Server Service 3 個服務器組件；第2 部分是Microsoft SQL Server 數據庫(即PEH SQL 數據庫)； 第3 部分包括PEH Diagnostic Tool、PEH Configuration Tool、PEH Administrator Tool 和PEH Viewer 共4 個軟件工具。

其中，PEH OPC 服務器組件通過本身自帶的OPC Alarms&Events Client (OPC A&E 客戶端)向PEH 外的各個自動控制系統(tǒng)的 OPC Alarms&Events Server(OPC A&E 服務器)收集報警和事件歷史記錄數據。 特別強調：這里的PEH OPC 服務器組件作為一個整體服務隨操作系統(tǒng)運行，雖然被稱作服務器，但是其實是一個典型的OPC A&E 客戶端， 正是由于有了這個OPC A&E 客戶端，才能訪問各個自動控制系統(tǒng)的工作站的遠程OPC A&E 服務器。本研究項目中，正是有了這個PEH OPC 服務器組件才能遠程訪問各個DeltaV 系統(tǒng)的PLUS Station 工作站的OPC 報警和事件服務器， 也才能把各個PLUS Station 站的報警和事件歷史記錄數據收集、整理、打包發(fā)送給PEH Events Manager 服務器組件，進而存入PEH SQL 數據庫， 達到匯集多套DCS 系統(tǒng)報警和事件的目的。

圖4 Plantwide Event Historian 的整體結構

PEH Events Manager 服務器組件運用組件本身內含的Microsoft Message Queue(MSMQ)將PEH OPC 服務器組件收集到的信息數據取回到PEH Events Manager 服務器組件， 進而再運用組件本身內含的MSMQ 經過SQL Interface 將數據存入PEH SQL 數據庫；PEH Diagnostic 服務器組件運用組件本身內含的MSMQ 從PEH OPC 服務器組件和PEH Events Manager 服務器組件取回診斷數據。

另外，4 個工具中，PEH Diagnostic Tool 應用程序用于監(jiān)控整個PEH 系統(tǒng)性能，通過PEH Diagnostic 服務器組件觀察顯示PEH OPC 服務器組件和PEH Events Manager 服務器組件的連接運行狀況；PEH Administrator Tool 應用程序用于管理(如歸檔和刪除) 和顯示PEH SQL 數據庫；PEH Viewer 應用程序用于呈現PEH 從各個自動控制系統(tǒng)的OPC A&E Servers 收集到的報警和事件歷史記錄數據，也就是，用于呈現存儲在PEH SQL 數據庫中的信息數據；PEH Configuration Tool 應用程序提供整個PEH 系統(tǒng)組態(tài)， 包括PEH OPC Server 與OPC A&E Server 組 態(tài)、PEH COM 組態(tài)、PEH MSMQ 組態(tài)和PEH SQL 數據庫備份與恢復組態(tài)。

特別的，PEH Viewer 應用程序與前面提到的Process History View（過程歷史瀏覽）應用程序在功能方面本質上差不多，只不過前者用于呈現的歷史記錄數據匯集了更多數量而已，并沒有對海量數據從功能上進行更細致更系統(tǒng)的統(tǒng)計、歸類、細分和整理，從而凸顯不出管理數量龐大的報警和事件的優(yōu)點，也達不到文章開頭提出的提取重要報警并進行管理的目的。 為此，再引入一款報警和事件分析軟件。

5 DeltaV Analyze 軟件功能

DeltaV Analyze 是一款以Microsoft Interner Explorer 為平臺開發(fā)的網絡客戶端應用程序，可以像訪問網站一樣訪問DCS 系統(tǒng)里的Event Chronicle 數據庫或Plantwide Event Historian。DeltaV Analyze 通過連接嵌入了報警和事件的DeltaV Event Chronicle 或PEH，能快速定位哪個區(qū)域或者哪個模件節(jié)點在一定時間內發(fā)生的最多的報警［4］。 更進一步，DeltaV Analyze 能夠解析DeltaV Event Chronicle 或者PEH 產品里的報警和事件數據，因此在本研究項目中，主要用來解析PEH 產品里的報警和事件數據，以供分析和評估使用。

DeltaV Analyze 運用最新技術開發(fā)并提供了一種分析過程事件數據的整體解決方案，預先定義了所有DeltaV Analyze Pages（分析頁面），這些頁面以友好的組態(tài)方式呈現出來。圖5 為DeltaV Analyze 組態(tài)界面。

圖5 DeltaV Analyze 組態(tài)界面

圖5 是DeltaV Analyze Administration 啟 動后以瀏覽器形式出現的組態(tài)界面（工作站必須安裝微軟瀏覽器）。 左邊畫面是組態(tài)的層次框架，右邊畫面是數據框架，頂部畫面是信息框架。 層次框架包含了管理功能、鏈接到網頁及鏈接到文檔等系統(tǒng)功能，鼠標點擊層次標題名就能直接訪問該功能，點擊“+”號就能展開顯示子標題；右邊畫面顯示左邊標題點擊后鏈接的數據框架畫面，用于具體數據組態(tài)，至于具體組態(tài)設置在這里不再贅述。 用戶根據需要進行組態(tài)， 完成后啟動DeltaV Analyze 就能獲得直觀的數據分析頁面。圖6 是DeltaV Analyze 系統(tǒng)啟動后呈現的DeltaV Analyze Overview 界面。

圖6 顯示了整個一體化工廠全區(qū)域所有DCS 系統(tǒng)在2018 年7 月～2019 年6 月期間一整年的所有報警和事件總概況，包括每套聯合裝置的子單元裝置在一整年每個月份產生的報警數量（圖中上半部分用棒圖顯示）、所有裝置在一整年每個月份產生的所有報警數量的分類分布（下半部分左圖按報警優(yōu)先級用分類棒圖顯示）、所有裝置在一整年每個月份所有操作人員的所有操作行為數量（下半部分中圖用棒圖顯示）、所有裝置在一整年每個月份產生的總事件數量（下半部分右圖用棒圖顯示）。這是DeltaV Analyze 啟動后眾多畫面之一，在圖6 中選擇左上角的菜單欄“Pages”，下拉點擊子菜單即可刷新不同區(qū)域不同功能畫面，這里不再一一列舉。 通過這些不同功能的畫面，用戶就能快速知道哪些報警是先前不斷干擾影響操作的報警（比如確定哪些是頻繁發(fā)生的報警、哪些是持續(xù)激活的報警、哪些是需要更多人工交互干涉的模件報警）， 根據報警發(fā)生的具體情況，采取不同的措施加以解決。 最終，通過定位很少的幾個報警并加以處理，就能明顯地降低操作員受報警干擾的影響，而且所有重要的報警和事件都會被及時發(fā)現并提取出來，同時針對性地采取措施，逐個解決，從根本上杜絕了安全隱患，為更好的安全管理、效益管理創(chuàng)造了有利條件。

圖6 DeltaV Analyze Overview 界面

6 結束語

運用OPC 技術匯集多套DCS 系統(tǒng)報警，并配置一臺報警工作站的方案實施兩年多以來運行良好，并逐步得到完善，由原來分散的龐大數量報警匯集成集中的海量報警，由原來海量報警的無序管理納入到有序管理，每周甚至每天可以提取出整個一體化工廠所有聯合裝置的前二十位不可忍受報警（TOP20）或者重要的系統(tǒng)報警，并及時針對性地采取有效措施加以解決，大幅降低了DCS 工程師和工藝操作人員的工作負荷。因此， 運用OPC 技術匯集多套DCS 系統(tǒng)報警的方案是可行的，其應用理念值得借鑒推廣。