基于HTML5的DCS遠(yuǎn)程實(shí)時(shí)監(jiān)控關(guān)鍵技術(shù)研究及應(yīng)用

張文建，李昊夫

（1.國家能源投資集團(tuán)有限責(zé)任公司，北京 100011；2.北京國電智深控制技術(shù)有限公司，北京 102209）

分散控制系統(tǒng)（distributed control system，DCS）是智能制造直接承載平臺，如何將互聯(lián)網(wǎng)技術(shù)應(yīng)用于DCS 當(dāng)中，是近年來工業(yè)自動化產(chǎn)品研發(fā)人員一直關(guān)心的課題[1-2]。其中一個(gè)主要方向就是實(shí)現(xiàn)DCS可視化遠(yuǎn)程實(shí)時(shí)監(jiān)控[3]，用戶僅通過Web 瀏覽器就可以在不同平臺上對DCS 進(jìn)行訪問[4]。

將Web 技術(shù)用于DCS 的嘗試并不鮮見，行業(yè)內(nèi)的多篇文獻(xiàn)都有相關(guān)報(bào)道[2-7]。這些文獻(xiàn)中所采用的Web 技術(shù)都不盡相同，其中部分技術(shù)已經(jīng)過時(shí)或?yàn)l臨淘汰。HTML5 作為HTML 標(biāo)準(zhǔn)的最新版本[8]，其標(biāo)準(zhǔn)和特性已經(jīng)被絕大多數(shù)瀏覽器廠商所接受和實(shí)現(xiàn)，HTML5 中提供了一些高性能的工具和接口，配合現(xiàn)代瀏覽器的高性能JavaScript 引擎，讓“通過瀏覽器實(shí)現(xiàn)高效的實(shí)時(shí)監(jiān)控”成為可能[5]。本文在以往方案的基礎(chǔ)上，采用HTML5 標(biāo)準(zhǔn)技術(shù)，為實(shí)現(xiàn)DCS 產(chǎn)品的高性能跨廣域網(wǎng)監(jiān)控功能提出一套通用的解決方案。

1 系統(tǒng)架構(gòu)設(shè)計(jì)

為盡量減小對DCS 的影響，本方案在DCS 之外設(shè)置一臺Web 服務(wù)器，DCS 通過通信站（COM站）與Web 服務(wù)器進(jìn)行通信，通信鏈路中可根據(jù)實(shí)際要求加裝不同等級的安全防護(hù)設(shè)備。

圖1 網(wǎng)絡(luò)結(jié)構(gòu)示意Fig.1 Schematic diagram of the network structure

按照B/S 架構(gòu)的習(xí)慣，將軟件功能分為瀏覽器端和服務(wù)器端兩個(gè)部分。瀏覽器端從服務(wù)器獲取監(jiān)控界面的圖形文件和監(jiān)控系統(tǒng)的實(shí)時(shí)數(shù)據(jù)，將兩者的信息合并后呈現(xiàn)在用戶面前，同時(shí)接收用戶的操作指令，并將其轉(zhuǎn)發(fā)給服務(wù)器。服務(wù)器端為瀏覽器提供HTTP 協(xié)議和WebSocket 協(xié)議服務(wù)，其中HTTP提供靜態(tài)文件、圖形文件讀取等服務(wù)，WebSocket 提供實(shí)時(shí)數(shù)據(jù)訂閱和指令轉(zhuǎn)發(fā)服務(wù)。服務(wù)器端通過接口與DCS 進(jìn)行通信，獲取實(shí)時(shí)數(shù)據(jù)、發(fā)送控制指令等。

圖2 系統(tǒng)架構(gòu)示意Fig.2 Schematic diagram of the system architecture

服務(wù)器端與瀏覽器之間采用標(biāo)準(zhǔn)的HTTP 和WebSocket 協(xié)議通信，與DCS 之間的通信按照DCS的接口要求實(shí)現(xiàn)。圖形渲染引擎和實(shí)時(shí)通信模塊是瀏覽器端的兩個(gè)核心模塊，兩者配合共同完成監(jiān)控界面的實(shí)時(shí)刷新。

2 圖形渲染引擎

通過瀏覽器實(shí)現(xiàn)實(shí)時(shí)監(jiān)控，首先就要解決圖形界面的呈現(xiàn)和實(shí)時(shí)刷新問題。在以往的方案中，曾采用了VML[5]、ActiveX[6]、Flash[7]、SVG[4]、Canvas[5]等不同技術(shù)，代表了不同時(shí)期Web 領(lǐng)域的技術(shù)發(fā)展趨勢。這些方案通常需要工作人員對DCS 已有的監(jiān)控界面進(jìn)行重新繪制，或?qū)ΡO(jiān)控界面文件做格式轉(zhuǎn)化，特別是當(dāng)DCS 側(cè)的監(jiān)控界面出現(xiàn)了修改和調(diào)整時(shí)，Web 監(jiān)控側(cè)必須做出同步的修改和調(diào)整，在工程實(shí)踐中通常會造成時(shí)間延誤和成本增加。為此，本文提出由圖形渲染引擎直接讀取DCS 監(jiān)控界面文件，解析后渲染在瀏覽器頁面中。該方案充分考慮到降低工程實(shí)施成本，省去了監(jiān)控界面重繪或格式轉(zhuǎn)化的工作，由此實(shí)現(xiàn)了DCS 到Web 監(jiān)控的無縫銜接。圖像渲染引擎使用HTML5 提供的Canvas技術(shù)來繪制2D 監(jiān)控界面。Canvas 是滿足實(shí)時(shí)監(jiān)控高效圖形繪制需求的最佳選擇，與以往的各種瀏覽器圖形繪制技術(shù)相比，Canvas 具備更高的執(zhí)行效率，并得到了絕大多數(shù)主流瀏覽器的支持[9]。圖形渲染引擎邏輯架構(gòu)如圖3所示。

2.1 基礎(chǔ)功能

圖形渲染引擎的工作分為初始化和實(shí)時(shí)渲染2 個(gè)階段。

2.1.1 初始化階段

本階段是指從獲取圖形文件到進(jìn)入實(shí)時(shí)渲染循環(huán)之間的過程，其主要任務(wù)是完成圖形實(shí)時(shí)渲染的準(zhǔn)備工作，即對DCS 圖形文件進(jìn)行解析，識別文件中包含的圖形元素（簡稱圖元），進(jìn)而生成圖元對象樹和測點(diǎn)池。本階段工作由圖3中的“圖形文件解析”模塊完成，其工作主要分為以下幾個(gè)方面。

1）從服務(wù)器端獲取圖形文件，并對圖形文件進(jìn)行結(jié)構(gòu)化解析。

2）將結(jié)構(gòu)化的圖形對象轉(zhuǎn)化為標(biāo)準(zhǔn)的圖元對象樹。期間需要考慮圖元的層疊關(guān)系（z-index），對樹中同級節(jié)點(diǎn)的順序做適當(dāng)調(diào)整。

3）對圖元中包含的測點(diǎn)進(jìn)行提取，匯總到測點(diǎn)池中，同時(shí)建立圖元對象屬性到測點(diǎn)池的對應(yīng)關(guān)系。

4）對圖元中包含的指令進(jìn)行識別和解析，并轉(zhuǎn)化為相關(guān)的操作熱區(qū)和操作行為代碼（JavaScript 代碼）。

5）對圖元中包含的條件控制語句（圖元的變色、變形、位移、顯隱等）提取，并編譯為條件控制代碼（JavaScript 代碼）。

圖3 圖形渲染引擎邏輯架構(gòu)Fig.3 The logic architecture diagram of graphics rendering engine

2.1.2 實(shí)時(shí)渲染階段

在這一階段中，監(jiān)控界面開始呈現(xiàn)在用戶面前，并隨著實(shí)時(shí)通信不斷刷新監(jiān)控界面中的測點(diǎn)數(shù)值和圖形狀態(tài)，同時(shí)接收用戶的操作指令。本階段工作由“圖元樹渲染”模塊完成，其工作分為以下2 個(gè)部分。

1）實(shí)時(shí)渲染循環(huán) 讀取圖元對象樹，并通過測點(diǎn)池刷新其中的測點(diǎn)數(shù)值；執(zhí)行條件控制代碼（用JavaScript 的eval()函數(shù)執(zhí)行），改變圖元的屬性；深度優(yōu)先遍歷圖元對象樹，并依照圖元對象的當(dāng)前屬性，將其繪制在瀏覽器頁面的元素中。按照一定時(shí)間周期循環(huán)執(zhí)行本部分工作。

2）指令識別與執(zhí)行 接收用戶在元素上發(fā)生的所有鼠標(biāo)事件，并對其分類處理。移動事件只影響鼠標(biāo)指針的形態(tài)，右鍵單擊事件觸發(fā)顯示上下文菜單，左鍵單擊事件進(jìn)行熱區(qū)判定，其他事件忽略。對于左鍵單擊事件，將事件坐標(biāo)與圖元對象樹中的對象依次比對，如果出現(xiàn)“命中”（事件坐標(biāo)落在圖元繪制區(qū)域內(nèi)），則觸發(fā)該圖元對象的操作行為。操作行為是頁面跳轉(zhuǎn)的，向服務(wù)器請求新的監(jiān)控界面文件，并重新進(jìn)入初始化階段；操作行為是控制指令的，將控制指令發(fā)送到指令隊(duì)列中。本部分工作以回調(diào)函數(shù)（callback）的形式綁定在元素的鼠標(biāo)事件上，在事件發(fā)生時(shí)執(zhí)行。

2.2 性能優(yōu)化

在實(shí)現(xiàn)圖形渲染引擎的基本功能之后，還可以通過一些輔助手段來優(yōu)化用戶體驗(yàn)。

1）對監(jiān)控界面文件的緩存 利用HTTP 的文件緩存機(jī)制，可實(shí)現(xiàn)對DCS 監(jiān)控界面文件的緩存。在瀏覽器向服務(wù)器請求文件時(shí)，如果文件未發(fā)生更改，服務(wù)器會告知瀏覽器直接使用文件的緩存版本，避免了文件的重復(fù)傳輸[10]。該緩存機(jī)制為瀏覽器級別，瀏覽器關(guān)閉后依然有效。

2）圖元對象樹的緩存 在發(fā)生監(jiān)控界面跳轉(zhuǎn)時(shí)，雖然呈現(xiàn)在用戶面前的監(jiān)控界面會發(fā)生改變，但并不會將前一監(jiān)控界面的內(nèi)容清除，而是將其保存在瀏覽器內(nèi)存中，在重新切換到曾經(jīng)打開的監(jiān)控界面時(shí)，可跳過初始化階段直接進(jìn)入實(shí)時(shí)渲染階段，提升頁面切換的流暢性。該緩存機(jī)制在瀏覽器頁面關(guān)閉或刷新后失效。

3）圖元對象樹的圖形緩存 利用離屏Canvas技術(shù)[11]，為圖元對象樹中的圖元（或圖元對象子樹）繪制圖像緩存，對于未發(fā)生改變的圖元（或圖元對象子樹），直接將緩存結(jié)果繪制出來。此方法以增加瀏覽器內(nèi)存占用為代價(jià)，降低圖形繪制造成的CPU負(fù)荷。該緩存機(jī)制在瀏覽器頁面關(guān)閉或刷新后失效。

3 實(shí)時(shí)通信模塊

通過瀏覽器實(shí)現(xiàn)實(shí)時(shí)監(jiān)控的第2 個(gè)問題，就是實(shí)時(shí)數(shù)據(jù)的傳輸問題。Web 領(lǐng)域最常見的HTTP 協(xié)議是一種無狀態(tài)的通信協(xié)議，其設(shè)計(jì)初衷就是為了獲取服務(wù)器上的靜態(tài)文件，沒有考慮到頻繁的前后端數(shù)據(jù)傳輸。后來出現(xiàn)的Ajax 技術(shù)雖然提升了數(shù)據(jù)刷新的用戶體驗(yàn)，但是并未從本質(zhì)上改變前后端的交互方式。開發(fā)者只能通過輪詢、長輪詢等方式在HTTP 協(xié)議的基礎(chǔ)上近似的模擬實(shí)時(shí)通信[12]，還有的開發(fā)者采用Flash 內(nèi)置的Socket 接口實(shí)現(xiàn)實(shí)時(shí)通信[13]。直到HTML5 標(biāo)準(zhǔn)中提出的WebSocket 技術(shù)，才為B/S 架構(gòu)下的實(shí)時(shí)數(shù)據(jù)傳輸給出了較好的解決方案[12,14-15]。WebSocket 目前已被絕大多數(shù)現(xiàn)代瀏覽器兼容，在實(shí)時(shí)監(jiān)控領(lǐng)域也有較多的應(yīng)用。實(shí)時(shí)通信模塊邏輯架構(gòu)如圖4所示。

圖4 實(shí)時(shí)通信模塊邏輯架構(gòu)Fig.4 The logic architecture diagram of real-time communication module

3.1 基礎(chǔ)功能

實(shí)時(shí)數(shù)據(jù)通信模塊的工作分為初始化和實(shí)時(shí)刷新2 個(gè)階段。

3.1.1 初始化階段

在這一階段中，實(shí)時(shí)通信模塊主要完成2 項(xiàng)任務(wù)：一是實(shí)時(shí)通信模塊與WebSocket 服務(wù)器握手，并創(chuàng)建WebSocket 連接；二是將測點(diǎn)池中的測點(diǎn)整理成測點(diǎn)列表，并將此列表發(fā)送給WebSocket 服務(wù)器，此項(xiàng)工作要在圖形渲染引擎完成對測點(diǎn)池的初始化之后執(zhí)行。

3.1.2 實(shí)時(shí)刷新階段

在此階段中，實(shí)時(shí)通信模塊主要完成實(shí)時(shí)數(shù)據(jù)刷新和指令讀取與轉(zhuǎn)發(fā)2 項(xiàng)工作。WebSocket 服務(wù)器根據(jù)接收到的測點(diǎn)列表，將相應(yīng)的測點(diǎn)實(shí)時(shí)值發(fā)送給實(shí)時(shí)通信模塊，實(shí)時(shí)通信模塊接收到數(shù)據(jù)包之后，將數(shù)據(jù)包內(nèi)容解析成測點(diǎn)的實(shí)時(shí)值，并將數(shù)值寫入到測點(diǎn)池中，此項(xiàng)工作由WebSocket 連接上的回調(diào)函數(shù)執(zhí)行；當(dāng)指令隊(duì)列發(fā)生寫入操作時(shí)，實(shí)時(shí)通信模塊讀取指令隊(duì)列的內(nèi)容，并將指令內(nèi)容通過WebSocket 連接發(fā)送到服務(wù)器端，這項(xiàng)工作的執(zhí)行也是由回調(diào)函數(shù)機(jī)制來實(shí)現(xiàn)，由此可以保證極低的指令發(fā)送延遲。

3.2 對實(shí)時(shí)通信模塊的改進(jìn)

3.2.1 實(shí)時(shí)數(shù)據(jù)傳輸采用二進(jìn)制表達(dá)

對于前端領(lǐng)域，常見數(shù)據(jù)傳輸格式為XML 和Json，這兩種格式都是基于字符串來實(shí)現(xiàn)結(jié)構(gòu)化數(shù)據(jù)的傳輸，在測點(diǎn)數(shù)值的傳輸中會造成較大的浪費(fèi)。以編碼長度較少的Json 為例，其傳輸內(nèi)容是鍵-值對的形式表達(dá)，傳輸?shù)臄?shù)據(jù)包括名稱、值和邊界符。如{“AP0001”:“123”},傳輸?shù)臄?shù)據(jù)除了值123,還包括名稱AP0001 和{“”:“”} 7 個(gè)邊界符[16]。在工程實(shí)踐中，Json 和XML 格式下平均每個(gè)測點(diǎn)的傳輸數(shù)據(jù)量通常在18～40 字節(jié)，同時(shí)數(shù)值的序列化和反序列化操作會消耗通信鏈路兩端的CPU 資源。為了滿足監(jiān)控的實(shí)時(shí)性要求，服務(wù)器端對實(shí)時(shí)通信模塊的數(shù)據(jù)推送頻率通常為每秒一次以上。為此，本文提出采用二進(jìn)制格式進(jìn)行實(shí)時(shí)數(shù)據(jù)的傳輸。在二進(jìn)制編碼方式下平均每個(gè)測點(diǎn)的傳輸數(shù)據(jù)長度在8～16 字節(jié)（4 字節(jié)ID、4 字節(jié)數(shù)值，或4 字節(jié)ID、4 字節(jié)狀態(tài)、8 字節(jié)數(shù)值），在保持?jǐn)?shù)據(jù)精度的同時(shí)降低50%以上通信負(fù)荷，同時(shí)降低通信兩端的CPU 負(fù)載。

瀏覽器端的實(shí)時(shí)通信模塊可使用JavaScript 的ArrayBuffer 對象創(chuàng)建的緩沖區(qū)來容納二進(jìn)制實(shí)時(shí)數(shù)據(jù)包，使用DataView 對緩沖區(qū)中的數(shù)據(jù)進(jìn)行讀取，完成二進(jìn)制數(shù)據(jù)的解析。

3.2.2 使用SharedWorker 優(yōu)化實(shí)時(shí)通信

前述的實(shí)時(shí)數(shù)據(jù)刷新方案已經(jīng)可以滿足實(shí)時(shí)監(jiān)控的要求，但是在工程應(yīng)用中出現(xiàn)了非技術(shù)原因造成的通信資源浪費(fèi)。用戶在使用瀏覽器進(jìn)行實(shí)時(shí)監(jiān)控時(shí)，通常會打開多個(gè)瀏覽器頁面，有的甚至在多個(gè)瀏覽器頁面中打開相同的監(jiān)控畫面。在原有方案中，每個(gè)瀏覽器頁面都會創(chuàng)建自己的實(shí)時(shí)通信模塊，并與服務(wù)器建立WebSocket 連接，這就導(dǎo)致了一個(gè)用戶可能產(chǎn)生大量的WebSocket 連接，會嚴(yán)重浪費(fèi)服務(wù)器端的資源，并且造成數(shù)據(jù)的重復(fù)傳輸。

本文提出使用HTML5 的SharedWorker 將實(shí)時(shí)通信模塊轉(zhuǎn)化為瀏覽器后臺運(yùn)行的公用進(jìn)程，每個(gè)瀏覽器頁面只保留自己的圖形渲染引擎，兩者之間通過進(jìn)程間通信的方式進(jìn)行交互。原方案中的測點(diǎn)池保留在圖形渲染引擎中，在實(shí)時(shí)數(shù)據(jù)通信模塊中建立一個(gè)公用測點(diǎn)池，并為每個(gè)接入的圖形渲染引擎創(chuàng)建相應(yīng)鏡像測點(diǎn)池。實(shí)時(shí)通信模塊與服務(wù)端交互時(shí)，只刷新公用測點(diǎn)池中的數(shù)據(jù)，而與各圖形渲染引擎交互時(shí)使用相應(yīng)的鏡像測點(diǎn)池。由此實(shí)現(xiàn)多個(gè)頁面共享一個(gè)WebSocket 連接的效果。優(yōu)化的實(shí)時(shí)通信模塊邏輯架構(gòu)如圖5所示。

圖5 優(yōu)化的實(shí)時(shí)通信模塊邏輯架構(gòu)Fig.5 The improved logic architecture diagram of real-time communication module

目前，個(gè)別瀏覽器（Edge、Safari）尚未支持SharedWorker，因此應(yīng)當(dāng)在實(shí)時(shí)通信模塊的代碼中考慮到兼容性問題。對無法支持SharedWorker 的瀏覽器自動可采用多路WebSocket 連接方式完成實(shí)時(shí)數(shù)據(jù)的刷新。

4 其他輔助功能

前文所述的監(jiān)控功能，只能滿足最基本的監(jiān)視和控制需求，對于生產(chǎn)環(huán)境中的實(shí)時(shí)監(jiān)控，還應(yīng)提供以下功能。

1）頁面導(dǎo)航 即監(jiān)控畫面之間的前進(jìn)、后退、返回主頁等功能。在工程實(shí)踐中，可在圖形渲染引擎中內(nèi)置監(jiān)控畫面的跳轉(zhuǎn)記錄，并在最終渲染的監(jiān)控畫面外部提供導(dǎo)航按鈕，從而實(shí)現(xiàn)此功能。

2）設(shè)備控制面板 有的DCS 將設(shè)備控制面板顯示在監(jiān)控界面的固定區(qū)域中，有的則將其顯示在浮動窗口中。兩者雖然形式不同，但本質(zhì)上都是將設(shè)備操作的圖形界面顯示在監(jiān)控界面的指定區(qū)域。該項(xiàng)功能也在圖形渲染引擎中完成，即將特定類型的監(jiān)控界面渲染到瀏覽器的另一個(gè)元素中。

3）畫面截圖 常規(guī)的DCS 通常會提供“打印當(dāng)前監(jiān)控界面”功能，由于瀏覽器本身包含了打印功能，可以隨時(shí)將監(jiān)控界面打印出來。同時(shí)，也可以在圖形渲染引擎中內(nèi)置畫面截圖功能，即對元素的內(nèi)容通過離屏渲染的方式保存為png 格式，并在瀏覽器中自動下載圖像文件。

4）顯示比例設(shè)定 工程應(yīng)用中的監(jiān)控界面，通常按用戶需要設(shè)定為某一特定分辨率或顯示比例，但是瀏覽器窗口通常是可以隨意改變大小的，為滿足不同應(yīng)用場景下的需求，在圖形渲染引擎中可提供“原始”和“填充”2 種圖形顯示模式。前者按照監(jiān)控界面的原始分辨率（或比例）進(jìn)行圖形顯示，后者按照瀏覽器的當(dāng)前尺寸進(jìn)行縮放填充。

5）手動刷新 監(jiān)控界面中提供手動刷新畫面文件的功能。當(dāng)DCS 側(cè)的畫面文件被修改時(shí)，點(diǎn)擊此按鈕即可完成畫面文件的重新讀取和加載，而無需刷新整個(gè)頁面。此舉節(jié)約了畫面刷新時(shí)間，也保護(hù)導(dǎo)航記錄不會因頁面重載而丟失。

6）斷線重連 由于互聯(lián)網(wǎng)通信鏈路存在不穩(wěn)定性，要求實(shí)時(shí)通信模塊隨時(shí)監(jiān)視WebSocket 連接的狀態(tài)，當(dāng)發(fā)生連接中斷時(shí)在監(jiān)控界面中向用戶發(fā)出提示，并嘗試重新建立WebSocket 連接。此舉可確保監(jiān)控的連續(xù)性和可靠性。

此外，對于一個(gè)完整的DCS，除前文所述的監(jiān)控功能外，還應(yīng)包含實(shí)時(shí)趨勢、歷史趨勢、報(bào)警記錄查詢、測點(diǎn)信息查詢等功能。這些功能都不涉及實(shí)時(shí)通信，可以通過HTTP 協(xié)議實(shí)現(xiàn)。與這些功能相關(guān)的數(shù)據(jù)接口在DCS 中已經(jīng)存在，只要在Web服務(wù)器端對這些信息查詢功能提供協(xié)議轉(zhuǎn)換即可。

5 應(yīng)用實(shí)例

基于本文提出的技術(shù)方案，為EDPF-NT+系列DCS 產(chǎn)品開發(fā)了Web 擴(kuò)展組件。

EDPF-NT+的監(jiān)控畫面文件(擴(kuò)展名為gbp 和gbw)，采用XML 格式，GB2312 編碼。監(jiān)控界面中的圖元以XML 節(jié)點(diǎn)保存，指令語句和條件控制語句以字符串的方式保存在XML 節(jié)點(diǎn)的屬性中。圖形渲染引擎采用JavaScript 語言，采用面向?qū)ο蠓椒?，為不同的圖元設(shè)計(jì)了不同的類。圖元對象樹生成之后，遞歸調(diào)用圖元的render()方法來將頁面內(nèi)容繪制在瀏覽器頁面的元素中。

EDPF-NT+可通過2 種途徑提供實(shí)時(shí)數(shù)據(jù)：DIP接口，基于UDP 的實(shí)時(shí)數(shù)據(jù)發(fā)布接口，常用于通過單向隔離網(wǎng)關(guān)對外提供實(shí)時(shí)數(shù)據(jù)，只能實(shí)現(xiàn)實(shí)時(shí)監(jiān)視功能；NetAsk 接口，EDPF-NT+內(nèi)部的實(shí)時(shí)數(shù)據(jù)API，用于實(shí)時(shí)數(shù)據(jù)的獲取和指令發(fā)送，可實(shí)現(xiàn)監(jiān)視和控制功能。為滿足各行業(yè)用戶的不同要求，在實(shí)時(shí)通信模塊的開發(fā)中同時(shí)兼容2 種接口，可在部署時(shí)根據(jù)需要靈活配置?？紤]到跨平臺兼容性，實(shí)時(shí)通信功能的服務(wù)器端程序采用Python2.7 開發(fā)。

在某火電廠300 MW 機(jī)組DCS 遠(yuǎn)程監(jiān)視項(xiàng)目中，對Web 擴(kuò)展組件的主要性能指標(biāo)進(jìn)行了測試，測試結(jié)果的平均值見表1。由表1可見，Web 擴(kuò)展組件的各項(xiàng)性能指標(biāo)均不低于EDPF-NT+，滿足遠(yuǎn)程監(jiān)控的需要，在實(shí)際應(yīng)用中可以提供與原系統(tǒng)幾乎一致的用戶體驗(yàn)。

表1 EDPF-NT+Web 擴(kuò)展組件主要性能指標(biāo)Tab.1 Main performance indicators of the Web extension component of EDPF-NT+ s

該組件為EDPF-NT+提供了監(jiān)控界面的Web 發(fā)布功能，能夠?yàn)橐淹懂a(chǎn)的DCS 產(chǎn)品快速實(shí)現(xiàn)跨廣域網(wǎng)遠(yuǎn)程監(jiān)控功能。該產(chǎn)品已經(jīng)在不同行業(yè)的多個(gè)項(xiàng)目中得到應(yīng)用（表2），取得了較好的效果。

表2 EDPF-NT+Web 擴(kuò)展組件應(yīng)用情況Tab.2 Applications of the Web extension component of EDPF-NT+

與EDPF-NT+類似，絕大多數(shù)DCS 產(chǎn)品的監(jiān)控界面都是以生產(chǎn)現(xiàn)場的抽象二維圖形場景為基礎(chǔ)，疊加實(shí)時(shí)數(shù)據(jù)和設(shè)備操作面板。由于監(jiān)控界面文件本質(zhì)上存儲的是結(jié)構(gòu)化的圖形元素，這些元素?zé)o論以何種格式存儲（二進(jìn)制、XML、SVG 等），都能映射成本文所述的圖元對象樹。該映射過程只與文件存儲格式和內(nèi)容有關(guān)，與組態(tài)過程和組態(tài)軟件無關(guān)。因此，只要了解圖形文件的格式規(guī)范，即可使用本文所述的方法進(jìn)行圖形文件的解析和渲染。

6 結(jié) 語

本文提出的技術(shù)方案，可以通過較低的投入快速為DCS 產(chǎn)品實(shí)現(xiàn)Web 擴(kuò)展能力，為DCS 提供跨廣域網(wǎng)遠(yuǎn)程監(jiān)控或監(jiān)視功能。由于全部采用Web 標(biāo)準(zhǔn)技術(shù)，本方案能實(shí)現(xiàn)與其他Web 類監(jiān)控產(chǎn)品無縫融合。此外，本方案采用讀取DCS 監(jiān)控界面文件并直接在瀏覽器中呈現(xiàn)的方式，使工程實(shí)施成本降至最低，便于產(chǎn)品的應(yīng)用和推廣。