隧道防護(hù)門遠(yuǎn)程監(jiān)測(cè)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

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

同濟(jì)大學(xué)機(jī)械與能源工程學(xué)院 上海 201800

0 引言

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

1 相關(guān)技術(shù)及設(shè)計(jì)思想

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

1.1 策略模式

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

1.2 Spring Boot

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

1.3 ECharts

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

1.4 MySQL

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

1.5 MQTT

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

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

2 遠(yuǎn)程監(jiān)測(cè)系統(tǒng)整體架構(gòu)

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

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

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

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

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

3 存儲(chǔ)服務(wù)設(shè)計(jì)

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

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

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

以查詢SQL語(yǔ)句為例，說(shuō)明優(yōu)化過(guò)程。查詢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語(yǔ)句指明字段名稱

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

2）建立索引

對(duì)查詢語(yǔ)句進(jìn)行Explain分析其執(zhí)行計(jì)劃，得到結(jié)果如表1所示。

表1 Explain分析結(jié)果

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

SQL

CREATE INDEX receive_time_index ON vibrate_sensor(receive_time);

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

表2 Explain分析結(jié)果

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

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

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

4 服務(wù)層功能模塊設(shè)計(jì)

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

4.1 設(shè)備信息管理

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

圖2 設(shè)備關(guān)聯(lián)圖

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

表3 隧道信息表

表4 防護(hù)門信息表

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

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

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

圖3 前后端交互框架

4.3 設(shè)備故障診斷

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

圖4 設(shè)備故障診斷流程

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

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

4.4 設(shè)備故障報(bào)警

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

圖5 設(shè)備故障報(bào)警流程

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

圖6 通知模塊運(yùn)行流程

5 結(jié)語(yǔ)

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

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