周奇才 湯鑫康 趙 炯 熊肖磊 王 偉

同濟大學機械與能源工程學院 上海 201800

0 引言

隨著鐵路里程的增長，鐵路隧道的數(shù)量也在急劇增加。隧道作為一個相對封閉的空間，出現(xiàn)火災將會嚴重威脅列車行車安全。而鐵路隧道防護門是隧道內(nèi)部重要的防火隔斷設備，可有效隔熱，防止有害氣體蔓延，在防災避難、保護設備設施安全方面發(fā)揮著至關重要的作用。但列車經(jīng)過隧道時產(chǎn)生的較大側向風壓，會對隧道防護門的可靠性造成破壞，故需對其進行日常檢查。而人工巡檢存在數(shù)據(jù)難整理、漏檢誤檢、無系統(tǒng)化管理以及故障報警不及時等問題。為克服人工巡檢存在的諸多問題，本文設計實現(xiàn)一套隧道防護門系統(tǒng)，用以提高對隧道防護門設備狀態(tài)的感知能力。

1 相關技術及設計思想

本系統(tǒng)數(shù)據(jù)展示、服務開發(fā)、數(shù)據(jù)存儲以及數(shù)據(jù)傳輸主要應用了ECharts圖表庫、Spring Boot框架、MySQL數(shù)據(jù)庫以及MQTT協(xié)議等相關技術。同時引入策略模式設計思想，提高項目的可讀性和可擴展性。

1.1 策略模式

策略模式是一種軟件設計模式，其實現(xiàn)了隨場景的變化，對象的行為也會發(fā)生變化。通過定義一組算法，同時將這組算法封裝成一組具體的策略類，并使它們實現(xiàn)共同的策略接口，從而在不同的場景下，通過傳入不同的具體策略，使得對象執(zhí)行不同的行為[1]。策略模式遵循開閉原則，對算法進行分離，減少代碼的耦合，提高代碼的可擴展性。策略模式可在不同的條件下，動態(tài)地改變對象的行為，減少了if-else分支，提高代碼的可讀性。其主要構成為：1）抽象策略角色 一般是接口或抽象類；2）具體策略角色 封裝了具體的算法和行為；3）環(huán)境角色 持有一個策略類的引用，以供外部使用。

1.2 Spring Boot

Spring框架是Java平臺上的一款開源應用框架，它是一個輕量級的面向切面編程（AOP）的框架，同時具有控制反轉（IOC）的特性。而Spring Boot不僅繼承了Spring眾多優(yōu)秀的特性，還通過簡化配置來進一步簡化了Spring應用的整個搭建和開發(fā)過程[2]。

1.3 ECharts

本系統(tǒng)客戶端可視化圖像的展示依賴于ECharts開源框架。ECharts圖表庫為開發(fā)者提供了豐富的數(shù)據(jù)可視化選擇，除了提供常規(guī)的圖表選擇，例如：柱狀圖、折線圖、散點圖以及餅圖等外，還提供其他專業(yè)圖形展示方式，例如：旭日圖、K線圖、儀表圖等。同時該框架的兼容性高，可適配當下絕大多數(shù)的瀏覽器，從而為用戶提供豐富直觀的交互體驗[3]。

1.4 MySQL

MySQL數(shù)據(jù)庫是當前最流行的關系型數(shù)據(jù)庫系統(tǒng)之一。MySQL數(shù)據(jù)庫由于其開源機制，降低了用戶使用成本，從而累積了大量用戶，形成了穩(wěn)定龐大的用戶社群，便于問題的溝通與解決。MySQL使用的SQL語言是訪問數(shù)據(jù)庫的標準語言，易于學習和上手。MySQL基于事務管理、索引和鎖機制上做了大量優(yōu)化，保障了其服務的穩(wěn)定性和高效性。同時MySQL提供了多種API接口，以支持多種操作系統(tǒng)和多種開發(fā)語言。

1.5 MQTT

本系統(tǒng)采用物聯(lián)網(wǎng)行業(yè)的MQTT協(xié)議，實現(xiàn)系統(tǒng)的數(shù)據(jù)采集層與服務層監(jiān)測數(shù)據(jù)的傳輸功能。

MQTT全稱為消息隊列遙測傳輸協(xié)議，是一種基于發(fā)布/訂閱模式的輕量級通訊協(xié)議。MQTT可通過極少的代碼和有限的帶寬，為遠程連接設備提過實時可靠的消息服務。這一特點使其在物聯(lián)網(wǎng)、小型設備、移動應用等方面有較廣泛的應用。

2 遠程監(jiān)測系統(tǒng)整體架構

遠程監(jiān)測系統(tǒng)是指通過在被監(jiān)測設備上配置監(jiān)測裝置，對設備的有關數(shù)據(jù)進行采集、處理，并能在遠程控制中心或網(wǎng)絡端及時獲取對應的數(shù)據(jù)分析結果、故障報警、趨勢分析等功能的系統(tǒng)。遠程監(jiān)測系統(tǒng)能彌補人工巡檢的不足，提高被監(jiān)測設備安全性的同時加強被監(jiān)測系統(tǒng)的數(shù)字化建設。

基于遠程監(jiān)測系統(tǒng)的功能分類，本系統(tǒng)主要分為4層，如圖1所示由下往上分別為數(shù)據(jù)采集層、數(shù)據(jù)傳輸層、數(shù)據(jù)持久層、服務層以及客戶端。

圖1 系統(tǒng)總體架構

數(shù)據(jù)采集層主要由數(shù)據(jù)采集模塊、數(shù)據(jù)傳輸模塊和數(shù)據(jù)處理模塊組成。數(shù)據(jù)采集模塊由振動傳感器，風壓傳感器，溫濕度傳感器以及攝像頭組成。數(shù)據(jù)傳輸和處理模塊主要通過樹莓派實現(xiàn)，配合供電模塊和數(shù)模轉換模塊于一體，集成在黑匣子內(nèi)部。

數(shù)據(jù)傳輸層應用MQTT協(xié)議，通過配置相同的主題段，實現(xiàn)數(shù)據(jù)從數(shù)據(jù)采集層到服務層的流轉。數(shù)據(jù)持久層主要由MySQL數(shù)據(jù)庫和Redis實現(xiàn)數(shù)據(jù)的持久化和緩存工作。服務層集成了設備信息管理、實時數(shù)據(jù)展示、設備故障診斷、故障報警等功能，是本系統(tǒng)的核心。

3 存儲服務設計

本系統(tǒng)主要將振動數(shù)據(jù)作為采集分析的主要數(shù)據(jù)來源。為了采集到適合分析的振動數(shù)據(jù)，需要將采集器的采樣頻率設置在1 000 Hz以上?？紤]到如果全天候24 h保持1 000 Hz的采樣頻率，其產(chǎn)生的數(shù)據(jù)對服務器來說是很大的負擔。因此，引入風壓傳感器，將風壓信號作為振動數(shù)據(jù)采集的啟停信號。如果風壓超過一定閾值，表明列車經(jīng)過，此時啟動振動信號采集器進行振動數(shù)據(jù)的采樣。當風壓信號小于閾值，表明列車已經(jīng)駛過，停止振動數(shù)據(jù)的采樣。

假設隧道平均半小時經(jīng)過1趟列車，列車經(jīng)過時防護門振動采集器的采樣時間為4 s，那么1 d產(chǎn)生的數(shù)據(jù)量為20萬，1個月產(chǎn)生的數(shù)據(jù)量為600萬。因此，基于大數(shù)據(jù)量下的業(yè)務背景，需要對數(shù)據(jù)庫進行一定的優(yōu)化操作。

3.1 SQL及索引優(yōu)化

以查詢SQL語句為例，說明優(yōu)化過程。查詢SQL示例為：

SQL

SELECT * FROM vibrate_sensor

WHERE receive_time BETWEEN

'2021-11-27 19:37:34' AND '2021-11-27 20:16:36'

ORDER BY receive_time;

1）select語句指明字段名稱

原語句在數(shù)據(jù)量4萬時的查詢耗時為0.24 s。指定查詢的內(nèi)容，將表示檢索所有字段的“*”改為具體字段后，查詢耗時由0.24 s下降到0.16 s。

2）建立索引

對查詢語句進行Explain分析其執(zhí)行計劃，得到結果如表1所示。

表1 Explain分析結果

由MySQL執(zhí)行計劃可知，屬性Type的值為All，表示該查詢進行了全表掃描，才找到所需要的數(shù)據(jù)。而全表掃描從查詢的效率上來說是最差的，故通過建立索引，來提高查詢的效率[4]。索引建立語句為：

SQL

CREATE INDEX receive_time_index ON vibrate_sensor(receive_time);

再次對查詢語句進行Explain分析其執(zhí)行計劃，得到如表2所示結果?？梢钥吹絋ype由All變?yōu)榱薘ange，表示當前檢索是一個有限的索引掃描，相對于全表掃描查詢效率得到了提高。同時屬性Key的值為Receive_time_index，表示當前查詢使用了索引。最終來說查詢耗時下降到0.06 s，查詢耗時下降到毫秒級，查詢的性能得到了顯著提升。

表2 Explain分析結果

3.2 水平分表優(yōu)化

由以上分析可得，1扇防護門日數(shù)據(jù)量為20萬，月度數(shù)據(jù)量則為600萬，年度數(shù)據(jù)量約為7 200萬。由此可見，隨著數(shù)據(jù)的不斷累積，單表的數(shù)據(jù)量會出現(xiàn)過大的問題，從而導致單表壓力過大，索引建立成本高，數(shù)據(jù)檢索效率降低，用戶體驗也下降等問題。因此，引入水平分表機制，降低每張表的數(shù)據(jù)量，從而提高查詢速度。

水平分表是將一個數(shù)據(jù)量大的表按照一定的規(guī)則拆分成多個結構相同的分表，將數(shù)據(jù)分散到分表中去[5]。拆分完成后，根據(jù)拆分的規(guī)則，確定所查詢數(shù)據(jù)所在的表。本文中，根據(jù)時間對表進行水平拆分，單表存儲1個月內(nèi)的振動數(shù)據(jù)。當需要查詢時，根據(jù)待查詢數(shù)據(jù)的時刻數(shù)據(jù)，即可定位到數(shù)據(jù)所在的數(shù)據(jù)庫表。

4 服務層功能模塊設計

服務層按功能劃分主要分為設備信息管理模塊、實時數(shù)據(jù)展示模塊、設備故障診斷模塊以及設備故障報警模塊等。

4.1 設備信息管理

設備組成主要有隧道信息和防護門信息，其關聯(lián)關系如圖2所示，系統(tǒng)管理著多個隧道的信息，同時每一個隧道下關聯(lián)著多個防護門的信息。

圖2 設備關聯(lián)圖

層級上來看，隧道是防護門的上層，防護門從屬于某一特定的隧道。設計隧道信息表與防護門信息表如表3和表4所示，防護門通過Tunnel_id外鍵關聯(lián)其所屬隧道。同時基于隧道以及防護門的業(yè)務管理需求，開發(fā)新增，模糊查詢，信息更新以及信息刪除接口，實現(xiàn)設備信息的系統(tǒng)管理。

表3 隧道信息表

表4 防護門信息表

4.2 實時數(shù)據(jù)展示

數(shù)據(jù)展示的內(nèi)容主要有振動數(shù)據(jù)、近期振動幅度峰值、風壓數(shù)據(jù)、接近開關狀態(tài)，防護門現(xiàn)場畫面等。當用戶在客戶端通過瀏覽器輸入URL，本地解析域名，向服務端發(fā)起TCP連接請求。客戶端與服務器端連接請求建立后，繼續(xù)發(fā)起HTTP連接請求。服務器端響應HTTP請求，封裝防護門前端展示界面的HTML、CSS以及其他數(shù)據(jù)內(nèi)容，并返回給客戶端?？蛻舳藶g覽器解析返回的數(shù)據(jù)，并對頁面進行渲染最終將防護門實時狀態(tài)界面呈現(xiàn)給用戶。

隧道防護門遠程監(jiān)測系統(tǒng)基于Bootstrap前端框架提供的菜單，導航欄、排版以及對話框等Web組件，搭建起簡潔直觀、功能齊備的人機交互界面。而設備狀態(tài)信息的展示上，基于ECharts豐富的商業(yè)級數(shù)據(jù)圖表庫，調用折線圖、柱狀圖、儀表盤以及餅圖等，完成包括振動數(shù)據(jù)在內(nèi)的各項設備指標的圖形化展示。同時為了滿足界面實時刷新數(shù)據(jù)信息的需求，采用基于JavaScript 的 Ajax 異步交互技術，通過間隔指定時間循環(huán)執(zhí)行Ajax請求以獲取最新的設備實時數(shù)據(jù)，并通過ECharts實現(xiàn)實時動態(tài)展示的效果，前后端交互框架如圖3所示。

圖3 前后端交互框架

4.3 設備故障診斷

系統(tǒng)在接收到設備數(shù)據(jù)后，根據(jù)指定規(guī)則對設備數(shù)據(jù)進行分析，評估設備狀態(tài)，設備故障診斷流程如圖4所示。

圖4 設備故障診斷流程

對于低頻振動，振動幅度的大小是振動強度的標識[6]。設定合理的振動幅度閾值，當振動幅度峰值超過了設定閾值的時候，判定防護門存在一定故障隱患，向相關工作人員發(fā)出報警信號；振動頻率是指單位時間內(nèi)振動的次數(shù)。在機械設備中，每一個運動的零部件都有其特定的振動頻率?？梢酝ㄟ^分析設備的頻率特征，來判斷設備當前的健康狀態(tài)。接近開關安裝在防護門門體的鎖盒內(nèi)，用于記錄防護門的開閉情況。通過判斷接近開關的開閉情況，直觀地監(jiān)測防護門的開閉情況。

隨著需求的不斷迭代，故障診斷的規(guī)則也在不斷地更新，即需要在不同的場景下采用不同的規(guī)則對底層源數(shù)據(jù)進行處理。而規(guī)則的新增和修改將導致代碼的維護難度不斷增加，因此，引入策略模式思想提高規(guī)則擴展的靈活性。例如引入圖像識別算法，對防護門現(xiàn)場圖像進行在線檢測[7]。只需要將圖像識別算法封裝成具體策略類，并與其他算法實現(xiàn)共同的策略接口，即可實現(xiàn)特定場景下調用圖像識別策略完成防護門狀態(tài)的檢測。

4.4 設備故障報警

當系統(tǒng)識別到設備存在異常時，發(fā)出故障報警。根據(jù)指定規(guī)則調用通知模塊，并向相關人員發(fā)送設備異常信息。設備故障報警流程如圖5所示。

圖5 設備故障報警流程

其中通知模塊根據(jù)事件的緊急級別分為郵件通知和短信通知，如圖6所示。由于發(fā)送郵件或短信的流程較長，耗時較久，故使用RabbitMQ技術異步發(fā)送實現(xiàn)長流程的解耦[8]。

圖6 通知模塊運行流程

5 結語

本文基于Spring Boot框架，搭建起一套B/S架構模型下的隧道防護門遠程監(jiān)測系統(tǒng)。系統(tǒng)采用MySQL數(shù)據(jù)庫實現(xiàn)采集器數(shù)據(jù)的存儲工作，并針對千萬級數(shù)據(jù)的業(yè)務背景，提出索引優(yōu)化和分表設計的存儲方案。引入策略模式思想，對故障診斷算法進行分離，減少代碼的耦合，提高代碼的可讀性和可擴展性。頁面展示采用Bootstrap前端框架以及ECharts圖表庫實現(xiàn)防護門數(shù)據(jù)及狀態(tài)的可視化呈現(xiàn)。

業(yè)務功能上，隧道防護門系統(tǒng)實隧道防護門通過設備信息管理，實時狀態(tài)展示和設備故障報警，搭建防護門管理的數(shù)字化基礎，實現(xiàn)防護門管理的信息化，提高防護門監(jiān)控的實時性，降低巡檢產(chǎn)生的人力成本，解決人工巡檢存在數(shù)據(jù)難整理、漏檢誤檢、無系統(tǒng)化管理以及故障報警不及時等問題。