隧道防護門遠程監測系統設計與實現

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

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

0 引言

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

1 相關技術及設計思想

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

1.1 策略模式

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

1.2 Spring Boot

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

1.3 ECharts

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

1.4 MySQL

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

1.5 MQTT

本系統采用物聯網行業的MQTT協議，實現系統的數據采集層與服務層監測數據的傳輸功能。

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

2 遠程監測系統整體架構

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

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

圖1 系統總體架構

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

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

3 存儲服務設計

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

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

3.1 SQL及索引優化

以查詢SQL語句為例，說明優化過程。查詢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語句指明字段名稱

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

2）建立索引

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

表1 Explain分析結果

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

SQL

CREATE INDEX receive_time_index ON vibrate_sensor(receive_time);

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

表2 Explain分析結果

3.2 水平分表優化

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

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

4 服務層功能模塊設計

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

4.1 設備信息管理

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

圖2 設備關聯圖

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

表3 隧道信息表

表4 防護門信息表

4.2 實時數據展示

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

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

圖3 前后端交互框架

4.3 設備故障診斷

系統在接收到設備數據后，根據指定規則對設備數據進行分析，評估設備狀態，設備故障診斷流程如圖4所示。

圖4 設備故障診斷流程

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

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

4.4 設備故障報警

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

圖5 設備故障報警流程

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

圖6 通知模塊運行流程

5 結語

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

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