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

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

0 引言

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

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

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

1.1 策略模式

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

1.2 Spring Boot

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

1.3 ECharts

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

1.4 MySQL

MySQL數(shù)據(jù)庫是當(dāng)前最流行的關(guān)系型數(shù)據(jù)庫系統(tǒng)之一。MySQL數(shù)據(jù)庫由于其開源機制，降低了用戶使用成本，從而累積了大量用戶，形成了穩(wěn)定龐大的用戶社群，便于問題的溝通與解決。MySQL使用的SQL語言是訪問數(shù)據(jù)庫的標(biāo)準(zhǔn)語言，易于學(xué)習(xí)和上手。MySQL基于事務(wù)管理、索引和鎖機制上做了大量優(yōu)化，保障了其服務(wù)的穩(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ù)采集層與服務(wù)層監(jiān)測數(shù)據(jù)的傳輸功能。

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

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

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

基于遠(yuǎn)程監(jiān)測系統(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ù)采集模塊由振動傳感器，風(fēng)壓傳感器，溫濕度傳感器以及攝像頭組成。數(shù)據(jù)傳輸和處理模塊主要通過樹莓派實現(xiàn)，配合供電模塊和數(shù)模轉(zhuǎn)換模塊于一體，集成在黑匣子內(nèi)部。

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

3 存儲服務(wù)設(shè)計

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

假設(shè)隧道平均半小時經(jīng)過1趟列車，列車經(jīng)過時防護(hù)門振動采集器的采樣時間為4 s，那么1 d產(chǎn)生的數(shù)據(jù)量為20萬，1個月產(chǎn)生的數(shù)據(jù)量為600萬。因此，基于大數(shù)據(jù)量下的業(yè)務(wù)背景，需要對數(shù)據(jù)庫進(jìn)行一定的優(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）建立索引

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

表1 Explain分析結(jié)果

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

SQL

CREATE INDEX receive_time_index ON vibrate_sensor(receive_time);

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

表2 Explain分析結(jié)果

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

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

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

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

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

4.1 設(shè)備信息管理

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

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

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

表3 隧道信息表

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

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

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

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

圖3 前后端交互框架

4.3 設(shè)備故障診斷

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

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

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

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

4.4 設(shè)備故障報警

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

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

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

圖6 通知模塊運行流程

5 結(jié)語

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

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