張文建，李昊夫

（1.國家能源投資集團有限責(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]。其中一個主要方向就是實現(xiàn)DCS可視化遠程實時監(jiān)控[3]，用戶僅通過Web 瀏覽器就可以在不同平臺上對DCS 進行訪問[4]。

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

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

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

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

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

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

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

2 圖形渲染引擎

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

2.1 基礎(chǔ)功能

圖形渲染引擎的工作分為初始化和實時渲染2 個階段。

2.1.1 初始化階段

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

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

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

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

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

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

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

2.1.2 實時渲染階段

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

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

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

2.2 性能優(yōu)化

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

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

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

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

3 實時通信模塊

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

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

3.1 基礎(chǔ)功能

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

3.1.1 初始化階段

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

3.1.2 實時刷新階段

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

3.2 對實時通信模塊的改進

3.2.1 實時數(shù)據(jù)傳輸采用二進制表達

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

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

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

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

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

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

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

4 其他輔助功能

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

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

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

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

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

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

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

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

5 應(yīng)用實例

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

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

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

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

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

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

表2 EDPF-NT+Web 擴展組件應(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ù)據(jù)和設(shè)備操作面板。由于監(jiān)控界面文件本質(zhì)上存儲的是結(jié)構(gòu)化的圖形元素，這些元素?zé)o論以何種格式存儲（二進制、XML、SVG 等），都能映射成本文所述的圖元對象樹。該映射過程只與文件存儲格式和內(nèi)容有關(guān)，與組態(tài)過程和組態(tài)軟件無關(guān)。因此，只要了解圖形文件的格式規(guī)范，即可使用本文所述的方法進行圖形文件的解析和渲染。

6 結(jié) 語

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