徐蘇君　高翔

關鍵詞：SCADA系統(tǒng)；SVG動態(tài)圖元解析；實時刷新；WebSocket 通訊；Web 發(fā)布系統(tǒng)

中圖分類號：TP391 文獻標識碼：A 文章編號：1006-8228（2023）11-116-05

0 引言

SCADA 系統(tǒng)是一個廣泛應用于工業(yè)自動化領域的監(jiān)視和控制系統(tǒng)，它通過實時采集和處理各種傳感器及其設備的數(shù)據(jù)，幫助管理人員/操作員監(jiān)視和控制生產(chǎn)和工藝過程[1]。然而傳統(tǒng)SCADA 系統(tǒng)存在升級維護困難、系統(tǒng)使用便捷性差、系統(tǒng)擴展性和靈活性不夠等問題。隨著Web 信息技術的發(fā)展，SCADA 系統(tǒng)的Web 應用在工業(yè)自動化領域也愈發(fā)廣泛，通過SCADA Web 發(fā)布系統(tǒng)[2]，將SCADA 系統(tǒng)中的實時運行數(shù)據(jù)、告警數(shù)據(jù)、監(jiān)視畫面在Web 系統(tǒng)中發(fā)布展示，使得相關管理人員方便快捷地在不同終端瀏覽器中實時監(jiān)視生產(chǎn)運行狀況，為Web 系統(tǒng)應用管控一體化打下基礎。SCADA 系統(tǒng)的實時監(jiān)視畫面有畫面復雜度高，實時數(shù)據(jù)量大，刷新頻率快等特點，SCADA 在Web 上不能只實現(xiàn)靜態(tài)畫面展示，對圖形畫面的加載速度、刷新頻率和數(shù)據(jù)同步都提出了高要求。

本文設計了一套基于SVG 和WebSocket 的SCADA Web 發(fā)布系統(tǒng)[3]，通過SVG 嵌入html 的方式實現(xiàn)SCADA 畫面在Web 端的展示，并提出了基于Redis 內存庫的SVG 動態(tài)圖元解析預處理機制[4]與基于WebSocket 的實時計算推送機制。通過這兩個技術結合，不僅實現(xiàn)傳統(tǒng)SCADA 系統(tǒng)在Web 端的發(fā)布應用，而且在系統(tǒng)穩(wěn)定性、流暢性、實時性等方面滿足自動化領域行業(yè)應用的要求。

1 系統(tǒng)總體設計

1.1 系統(tǒng)總體架構設計

目前既有系統(tǒng)在基于SVG圖形Web系統(tǒng)發(fā)布技術中，主要有以下兩種方式實現(xiàn)SVG 圖形展示和刷新：

⑴ Web 系統(tǒng)提供JS 文件，在瀏覽器加載SVG 圖形文件時，前端解析畫面圖元[5]，并定時通過Ajax 方式請求服務端，獲取圖形文件所需要的實時數(shù)據(jù)，再由前端JS 進行圖形的計算與渲染；

⑵ SVG 圖形文件解析全部由服務端完成，并定時從實時數(shù)據(jù)庫/關系數(shù)據(jù)庫獲取圖形所需要的最新數(shù)據(jù)，再根據(jù)解析的內容進行實時計算和結果填充，最終將計算結果返回至瀏覽器端進行圖形渲染[6]。

以上方式⑴中，JS 是腳本語言，進行SVG 動態(tài)圖元解析和計算的運行速度較慢，當SVG 畫面中動態(tài)圖元數(shù)量較多時，會造成瀏覽器卡頓及加載時間過長；當多個不同用戶同時打開同一張SVG 畫面時，存在前端重復解析圖元的情況。方式⑵中，需要定時在服務器端對所有用戶請求的SVG 圖形進行解析計算，當用戶數(shù)量較多且分別查看不同SVG 畫面的時候服務器需要在同一時間內處理大量的SVG 畫面請求，服務器消耗資源較高，且循環(huán)計算的間隔時長不穩(wěn)定，可能導致不同用戶在查看SVG 畫面的體驗不好。并且每個圖形在一個定時刷新周期動作中，這兩種方式都需要經(jīng)過從數(shù)據(jù)庫中讀取數(shù)據(jù)，然后以SVG 圖形為單位進行一次動態(tài)圖元實時計算過程才能完成圖形渲染，這在效率上有一定影響。

為了解決以上弊端，本文在系統(tǒng)架構層面重新進行設計，并針對以上兩種方式存在問題進行了改進和優(yōu)化。系統(tǒng)總體架構設計如圖1 所示。

本設計將SVG 圖形解析和渲染刷新分別放在不同層面去處理，將SVG 文件解析和實時計算放在服務層，并提出基于Redis 的動態(tài)圖元預解析處理機制，解決打開包含大量動態(tài)圖元的SVG 時耗時過長和瀏覽器卡頓的問題。將SVG 渲染和實時刷新放在應用層，通過WebSocket 機制，由原輪詢方式改為消息推送機制，服務端根據(jù)當前打開畫面，定時推送畫面所需實時渲染數(shù)據(jù)，提高畫面刷新效率和性能。在此基礎上，結合JAVA 緩存技術，避免頻繁讀取內存庫操作，進一步降低網(wǎng)絡延遲帶來的影響。

2 基于Redis 內存庫的SVG 動態(tài)圖元解析預處理設計

2.1 SVG 動態(tài)圖元解析預處理設計

由于SCADA 系統(tǒng)的畫面監(jiān)視系統(tǒng)對實時性和穩(wěn)定性有著很高的要求，如何高效完成SVG 圖形解析將直接影響整個系統(tǒng)的執(zhí)行效率，為此文本研究了一套將SVG 動態(tài)圖元解析和Redis 內存庫相結合的方式，每次用戶訪問SVG 圖形的時候，通過解析流程對當前訪問的SVG 圖形進行處理并保存相應結果，后續(xù)用戶打開相同SVG 圖形時無需重復解析，直接從Redis 中獲取解析結果用于內容計算。采用這種機制后，無論是訪問SVG 數(shù)量較多，還是單個SVG 畫面包含圖元復雜的情況，系統(tǒng)都可以在很短時間作出響應。解析預處理核心機制主要包括以下內容。

⑴ 對當前訪問的SVG 圖形與Redis 中版本信息進行對比。

⑵ 若版本信息對比一致，則從Redis 中獲取該圖需要使用的圖元引用元素和圖元內容，加入java 二級緩存，用于后續(xù)計算使用，減少每次從Redis 獲取圖元和計算公式的開銷，進一步提升系統(tǒng)性能。

⑶ 若版本信息對比不一致，則對該SVG 文件進行解析操作，處理對象包括版本信息、圖元模板、計算表達式[7]、參數(shù)定義、規(guī)則等。采用QLExpress[8]作為計算表達式解析與運算工具，QLExpress 是一種動態(tài)腳本解析引擎，用Java 語言來編寫、解釋腳本，其將耗時長的計算腳本編譯過程緩存在本地，運行時臨時變量的創(chuàng)建使用緩沖池技術實現(xiàn)，能有效提高運算性能。解析的結果見文本2.2 章節(jié)詳細處理流程如圖2 所示。

2.2 SVG 解析結果存儲設計

在上一個章節(jié)對用戶訪問的SVG 圖形進行了解析處理，如果以每張SVG 為單位進行存儲，那么不同SVG 存儲結果中會出現(xiàn)大量重復的圖元模板解析結果，這是因為不同SVG 圖形會引用相同的圖元和參數(shù)定義。

為了減少存儲容量及提升計算性能，本文提出以SVG 中圖形基本渲染規(guī)則（symbolId+paramIds）為key進行分組，從而實現(xiàn)將具有相同圖元模板元素和參數(shù)定義的useId，SVGId 進行聚合，以減少后續(xù)針對每個SVG 圖形的重復圖元計算量。同時在處理完成后會分別存于Redis 內存庫和Java 本地緩存中。前者用于后續(xù)打開對應的SVG 圖，可以快速獲得該圖包含的圖元模板、圖元引用元素和圖元模板計算公式參數(shù)；后者用于本次畫面的實時計算渲染。

通過預解析處理與結果存儲設計相結合技術，使得對于每張SVG 畫面，只有在系統(tǒng)啟動后首次被訪問或SVG 圖形文件發(fā)生變化的情況下才進行解析處理操作，后續(xù)的不同用戶、不同計算機再次訪問該SVG畫面時都可以基于解析完成的圖元模板和計算公式快速獲得計算參數(shù)，并完成結果計算。相較于既有系統(tǒng)的前端JS 解析或后端同時解析提高整體運行效率，有效縮短用戶打開SVG 畫面的等待時間。

3 基于WebSocket 的畫面實時刷新機制設計

3.1 畫面刷新機制設計

傳統(tǒng)監(jiān)視畫面的實時刷新大多采用的是輪詢的方式，由畫面定時發(fā)起請求，向服務器獲取最新的數(shù)據(jù)，然后進行畫面更新。這種方式適合畫面相對簡單、低并發(fā)，小數(shù)據(jù)量的場景，而SCADA 系統(tǒng)的畫面監(jiān)控實時性和穩(wěn)定性要求很高，單張SVG 圖形包含成百甚至上千圖元，畫面實時數(shù)據(jù)的變更周期也在秒級左右，隨著訪問量及單個畫面需要展示數(shù)據(jù)量的提升，或者對刷新頻率有較高要求的時候這種方式后端服務器需要在同一時間處理很多請求，這導致系統(tǒng)的響應時間變長。而如果畫面數(shù)據(jù)達到秒級刷新，那么傳統(tǒng)輪詢的方式可能導致產(chǎn)生丟失部分斷面數(shù)據(jù)的情況，以致丟失重要畫面數(shù)據(jù)。

為了解決以上問題，本文研究設計了基于WebSocket[9]的實時計算推送機制，以保障SVG 畫面在Web 系統(tǒng)的實時性和穩(wěn)定性。

本文提出的畫面刷新機制以SVG 動態(tài)圖元預解析為前提，當大量用戶打開不同SVG 畫面時，系統(tǒng)只需以<用戶id-圖號id>為映射關系記錄系統(tǒng)當前需要進行計算和推送的圖形信息。畫面刷新機制核心內容如下。

⑴ 將用戶信息和訪問的SVGid注冊進WebSocket客戶端主題，用于向服務端發(fā)送用戶和SVGid 信息以及接收服務端推送的渲染結果渲染瀏覽器畫面。

⑵ 服務端WebSocket 負責接收用戶打開的SVG畫面，并過濾不同用戶打開的相同畫面，獲取當前被打開的所有SVGid 信息。

⑶ 根據(jù)SVGid 從Redis 中獲取SVG 畫面中使用的symbol 圖元解析結果及計算表達式需要參與計算的參數(shù)以及引用圖元元素use。

⑷ 將目前所有參與計算的圖元添加至定時計算任務（見章節(jié)3.2），每秒定時計算渲染結果，并將結果和對應的userid、SVGid 通過WebSocket 推送至所有訂閱對應圖號的用戶畫面。

通過以上設計，采用WebSocket 與預解析相結合的技術方式，使得系統(tǒng)畫面的渲染刷新工作從單個SVG 畫面的<訪問->解析->計算->返回->渲染>轉變?yōu)?訪問->統(tǒng)一計算->定向推送->實時渲染>，極大地提高了系統(tǒng)的響應時間和刷新頻率。

畫面刷新詳細流程設計如圖3 所示。

3.2 定時計算處理設計

定時計算任務采用自定義函數(shù)實現(xiàn)，計算過程如下：

首先服務端每間隔一秒批量從Redis 中讀取所需計算圖形的參數(shù)值、圖形定義、公式定義、參數(shù)定義放至內存中；然后依次計算所需刷新的圖形，從內存中讀取每張圖計算需要的obid、otype、atype、鏈接關系，并尋找對應的屬性值。進行一次全圖計算，得出渲染指令，并推送至Web 前端。

為了減少數(shù)據(jù)庫讀取操作，進一步提升計算速度，在定時計算核心過程中提出三大優(yōu)化思想：

⑴ 雖然內存庫的讀取速度較關系型數(shù)據(jù)庫更快，但是頻繁讀取仍存在網(wǎng)絡延遲的情況，對于秒級刷新的監(jiān)視畫面來說依然會影響展示效果。本文采用服務端提前批量讀取Redis[10]數(shù)據(jù)技術，周期計算前讀取所需計算圖形的參數(shù)值、圖形定義、公式定義、參數(shù)定義等放至內存（HashMap）中，周期計算時直接從內存中讀取計算。

⑵ 充分利用Java 緩存技術，通過Java 緩存所有正在刷新的圖形集合（SVGID），在定時計算時僅需取這些圖形做計算即可。

⑶ 每個計算周期減少相同圖元、相同參數(shù)的重復計算量，通過HashMap 緩存相同圖元id、參數(shù)的計算結果，遇到不同圖形引用相同圖元參數(shù)的情況可以直接返回計算結果。

4 結束語

本文設計的基于SVG 與WebSocket 的SCADAWeb 發(fā)布系統(tǒng)滿足了用戶通過Web 平臺監(jiān)視生產(chǎn)運行情況的需求，同時保證了系統(tǒng)畫面的實時性和穩(wěn)定性。提出了基于內存庫的圖元解析預處理機制和實時計算推送機制。無論是SVG 圖形訪問較多或是SVG 畫面圖元數(shù)量龐大的情況，該系統(tǒng)都能有效減少畫面加載等待時間，保障系統(tǒng)的流暢性和實時性，提高用戶使用體驗。

本設計中關于WebSocket 實時推送方面還存在進一步優(yōu)化空間，本文在對每張SVG 圖形進行實時計算時是針對該圖所引用圖元進行計算并推送至前端畫面進行渲染，雖然避免了重復圖元的重復計算，但是沒有變化的圖元數(shù)據(jù)依舊統(tǒng)一推送至前端進行渲染，如何做到通過對不同SVG 圖形引用的圖元推送變化數(shù)據(jù)將進一步減少網(wǎng)絡帶寬，提高系統(tǒng)響應時間和渲染效率。

綜上所述，該設計可以有效地支撐傳統(tǒng)SCADA系統(tǒng)在Web 系統(tǒng)的發(fā)布技術要求，滿足用戶在Web 信息系統(tǒng)實現(xiàn)SCADA 畫面實時監(jiān)視的性能需求和功能需求。該設計的實現(xiàn)也將促進SCADA 系統(tǒng)在Web 系統(tǒng)的普及率、效率和可靠性，促進工業(yè)自動化領域的創(chuàng)新和發(fā)展。