鐵路隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)設(shè)計研究

趙 炯，王蘇桁，熊肖磊，周奇才

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

0 引言

在我國鐵路網(wǎng)高速發(fā)展的背景下，鐵路隧道特別是長大隧道內(nèi)的災(zāi)害預(yù)防和救援受到了越來越多的關(guān)注。由于列車經(jīng)過隧道時會在隧道內(nèi)產(chǎn)生較大側(cè)向風(fēng)壓的“活塞效應(yīng)”，從而對隧道內(nèi)存放的通信、信號、電力等設(shè)備產(chǎn)生不利影響，因此在鐵路隧道內(nèi)通常都會設(shè)有隧道防護(hù)門，從而保證軌旁設(shè)備的長期穩(wěn)定運(yùn)行。

近幾年隧道防護(hù)門事故頻發(fā)，這是因為在“活塞效應(yīng)”的循環(huán)作用下，隧道防護(hù)門可能會出現(xiàn)門板撕裂、門鎖變形甚至門體坍塌等問題，如果隧道防護(hù)門脫落并且倒向軌道一側(cè)，將會造成嚴(yán)重的列車運(yùn)行事故，因此在“活塞效應(yīng)”循環(huán)作用下確保隧道防護(hù)門的可靠性顯得尤為重要。目前，國內(nèi)針對隧道防護(hù)門的使用狀況檢查大部分仍然采用人工巡檢的方式，不僅耗時耗力，并且難以判斷隧道防護(hù)門的真實(shí)狀況，因此在隧道服役期內(nèi)對隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)進(jìn)行研究成為亟需解決的問題。

本文針對上述情況，設(shè)計了基于MQTT(Message Queuing Telemetry Transport)協(xié)議的隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)，可以實(shí)現(xiàn)對隧道防護(hù)門開閉、風(fēng)壓以及振動等狀態(tài)信息的實(shí)時監(jiān)測，提升了隧道防護(hù)門的可靠性。

1 鐵路隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)總體架構(gòu)

結(jié)合隧道的應(yīng)用環(huán)境特點(diǎn)，選擇具有獨(dú)立計算能力的樹莓派(Raspberry Pi)作為中心采集器，通信協(xié)議采用輕量級物聯(lián)網(wǎng)協(xié)議——MQTT協(xié)議。依據(jù)上述條件設(shè)計的鐵路隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)主要由感知層、通信層和應(yīng)用層三部分組成，如圖1所示。

第一層為感知層。感知層主要負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)底層的數(shù)據(jù)采集功能，由樹莓派與多種傳感器組成?？紤]到部分隧道地理位置較為偏僻，網(wǎng)絡(luò)條件較差甚至無網(wǎng)絡(luò)的情況，該采集器需要具有數(shù)據(jù)本地存儲與分析計算的功能，因此選擇樹莓派作為中心采集器。樹莓派是一種只有信用卡大小的卡片式電腦，具有價格低、體積小的優(yōu)點(diǎn)，與常見的51單片機(jī)和STM32等嵌入式微控制器相比，不僅可以完成IO引腳控制，還能運(yùn)行Linux操作系統(tǒng)，因此可以完成更復(fù)雜的任務(wù)管理與調(diào)度，支持更上層應(yīng)用的開發(fā)。除此之外，樹莓派還支持I2C、串口以及WiFi等多種通信方式，具有較高的可擴(kuò)展性。

第二層為通信層。通信層主要負(fù)責(zé)實(shí)現(xiàn)感知層與應(yīng)用層之間的通信，樹莓派通過WiFi或4G模塊將數(shù)據(jù)發(fā)送到MQTT服務(wù)器，再由MQTT服務(wù)器將數(shù)據(jù)轉(zhuǎn)發(fā)到監(jiān)控平臺進(jìn)行數(shù)據(jù)存儲、數(shù)據(jù)分析以及數(shù)據(jù)展示等。

第三層為應(yīng)用層。應(yīng)用層主要負(fù)責(zé)搭建監(jiān)控平臺，首先訂閱感知層所采集到的實(shí)時數(shù)據(jù)并對其進(jìn)行解析，然后執(zhí)行存儲、分析、可視化等操作。目前平臺端開發(fā)主流的方法是使用框架技術(shù)進(jìn)行開發(fā)，因此采用Spring Boot + Spring MVC + MyBatis框架作為主體進(jìn)行開發(fā)，采用Mysql數(shù)據(jù)庫對數(shù)據(jù)進(jìn)行持久化，然后在前端網(wǎng)頁采用Bootstrap框架進(jìn)行展示。

2 數(shù)據(jù)采集器工作原理

感知層主要由樹莓派、監(jiān)控攝像頭、接近開關(guān)、風(fēng)壓傳感器以及振動傳感器組成。

攝像頭主要用于記錄隧道洞室內(nèi)場景發(fā)生變化的情況，考慮到隧道洞室在安裝完成后通常很少有人員出入，因此實(shí)時視頻的意義較小，并且在樹莓派上實(shí)現(xiàn)實(shí)時視頻推流的資源開銷巨大，因此對于圖像采集采用固定時間間隔拍照的方案，將當(dāng)前圖像與之前保存的圖像進(jìn)行對比，如果兩次圖像整體變化較小，則認(rèn)為圖像無變化，不會進(jìn)行上傳；如果圖像整體變化較大，則會覆蓋之前圖像并進(jìn)行上傳，其特點(diǎn)為在不使用高消耗的視頻推流技術(shù)的條件下，又提供了隧道內(nèi)獲取的圖像。

圖1 鐵路隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)總體架構(gòu)

接近開關(guān)安裝于鎖盒內(nèi)，用于記錄隧道防護(hù)門的開閉情況，在門體上側(cè)會有指示燈提示防護(hù)門開閉情況，并且在發(fā)生變化時會將該防護(hù)門的開關(guān)信息上傳到服務(wù)器端。

風(fēng)壓傳感器與振動傳感器安裝于防護(hù)門前面板處，用于采集列車經(jīng)過時的風(fēng)壓以及振動數(shù)據(jù)。由于鐵路隧道防護(hù)門大都是在“活塞效應(yīng)”的循環(huán)載荷作用下引起的疲勞破壞，在遭到破壞前通常都沒有特定的物理量來進(jìn)行判斷，因此可以通過采集大量的振動數(shù)據(jù)，先在服務(wù)器端對振動數(shù)據(jù)進(jìn)行分析，提取出用于判斷隧道防護(hù)門健康狀況的特征量，再對隧道防護(hù)門的真實(shí)狀態(tài)進(jìn)行評估。

采集程序運(yùn)行后會開辟多個進(jìn)程，按功能主要可分為四類：數(shù)據(jù)采集線程、數(shù)據(jù)傳輸線程、數(shù)據(jù)分析線程以及數(shù)據(jù)清理線程。其中數(shù)據(jù)采集線程主要用于獲取傳感器所采集到的數(shù)據(jù)并存儲到本地數(shù)據(jù)庫中；數(shù)據(jù)傳輸線程主要用于從數(shù)據(jù)庫中加載剛剛采集到的數(shù)據(jù)并發(fā)送至MQTT服務(wù)器端；數(shù)據(jù)分析線程用于對本地數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行分析，從而判斷隧道防護(hù)門的實(shí)時狀況；數(shù)據(jù)清理線程主要用于對數(shù)據(jù)庫中過期信息進(jìn)行及時清理，以免因為存儲了過量數(shù)據(jù)而導(dǎo)致系統(tǒng)崩潰。這種劃分多個線程的方式實(shí)現(xiàn)了數(shù)據(jù)采集與數(shù)據(jù)發(fā)送等功能的解耦，避免了由于網(wǎng)絡(luò)較差的場合導(dǎo)致采集到的大量未發(fā)送數(shù)據(jù)堆積內(nèi)存中致使內(nèi)存溢出，并且充分利用了樹莓派多核CPU的計算能力，提高了數(shù)據(jù)的采集、發(fā)送以及分析的效率。

在樹莓派通電啟動后會自動執(zhí)行該采集程序運(yùn)行腳本，其采集流程如圖2所示。

圖2 數(shù)據(jù)采集流程

該程序首先對樹莓派進(jìn)行初始化，確保樹莓派可以通過IO、I2C以及串口等方式與傳感器正確通信并獲取到數(shù)據(jù)，如果初始化失敗，則會將錯誤日志存入數(shù)據(jù)庫中并且將該錯誤日志進(jìn)行上傳和打印。在初始化成功后，監(jiān)控攝像頭采集線程以及接近開關(guān)采集線程是長期運(yùn)行的，不受其他線程的影響，并且在采集到數(shù)據(jù)后會直接上傳。對于風(fēng)壓傳感器以及振動傳感器，由于采集頻率較高并且只有列車經(jīng)過時才能采集到有效數(shù)據(jù)，為了降低功耗，在樹莓派初始化成功后，風(fēng)壓數(shù)據(jù)采集線程進(jìn)入低速采集模式，每秒采集10次，當(dāng)風(fēng)壓大于0.1 kPa時，則會喚醒振動數(shù)據(jù)采集線程，并且自身進(jìn)入高速采集模式，每秒采集數(shù)據(jù)約1 000次，持續(xù)1 min，然后再次判斷最后一次采集到的風(fēng)壓數(shù)據(jù)是否大于0.1 kPa，如果仍大于，則繼續(xù)采集，否則，則結(jié)束本次采集流程，接著喚醒數(shù)據(jù)分析線程對剛剛采集到的數(shù)據(jù)進(jìn)行分析，如果得到錯誤或報警信息則先存入本地數(shù)據(jù)庫報警信息表中，再將采集到的數(shù)據(jù)以及錯誤及報警信息上傳至MQTT服務(wù)器端進(jìn)行轉(zhuǎn)發(fā)，最后恢復(fù)到風(fēng)壓傳感器低速采集模式。

3 MQTT服務(wù)器搭建

MQTT協(xié)議是由IBM開發(fā)的即時通訊協(xié)議，它是一種輕量級消息傳遞協(xié)議，通常與基于服務(wù)器的發(fā)布-訂閱模式一起使用，在TCP/IP之上運(yùn)行。在發(fā)布-訂閱模式中，發(fā)布消息的客戶端與其他一個或多個接收消息的客戶端分離。客戶端可以發(fā)布特定主題的消息，并且只有訂閱了該主題的客戶端才能接收已發(fā)布的消息。

發(fā)布-訂閱模式需要代理服務(wù)器， 所有客戶端都與服務(wù)器建立連接。 通過服務(wù)器發(fā)送消息的客戶端稱為發(fā)布者，在服務(wù)器上訂閱了特定主題的客戶端稱為訂閱者。 服務(wù)器過濾傳入的消息，并將其分發(fā)給該消息主題的訂閱者，因此，發(fā)布者和訂閱者都需要與服務(wù)器建立連接。

本系統(tǒng)中，在Linux服務(wù)器上搭建Mosquitto物聯(lián)網(wǎng)MQTT消息服務(wù)器作為通信層的核心，其管理界面如圖3所示。該模式實(shí)現(xiàn)了感知層與應(yīng)用層之間的解耦，并且消息隊列還具有削峰的作用，可以避免同一時間采集到的大量數(shù)據(jù)涌入監(jiān)控平臺導(dǎo)致監(jiān)控平臺服務(wù)器宕機(jī)。

圖3 Mosquitto服務(wù)器管理界面

4 監(jiān)控平臺搭建

監(jiān)控平臺主要負(fù)責(zé)對該隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)進(jìn)行綜合管理，分為前端和后端兩個部分。

在后端采用Spring Boot結(jié)合SSM框架進(jìn)行搭建，Spring Boot能快速構(gòu)建項目、對主流開發(fā)框架無配置集成、獨(dú)立運(yùn)行項目、無須外部依賴Servlet容器、提供運(yùn)行時的應(yīng)用監(jiān)控，極大地提高了開發(fā)和部署效率。

在前端網(wǎng)頁采用Bootstrap框架進(jìn)行展示，Bootstrap具有簡潔且靈活的特點(diǎn)，它將HTML、CSS、JavaScript封裝成一個個組件，可以快速搭建一個適合本控制系統(tǒng)的前端框架。使用Bootstrap制作的平臺兼容性好，并且通過響應(yīng)式布局設(shè)計可以提供更良好的視覺體驗。監(jiān)控平臺登錄界面如圖4所示，數(shù)據(jù)展示界面如圖5所示。

圖4 監(jiān)控平臺登錄界面 圖5 數(shù)據(jù)展示界面

5 結(jié)語

針對“活塞效應(yīng)”下鐵路隧道防護(hù)門的可靠性問題，提出了一種適用于鐵路隧道防護(hù)門的遠(yuǎn)程監(jiān)控系統(tǒng)，該系統(tǒng)可以實(shí)時有效地對隧道防護(hù)門進(jìn)行數(shù)據(jù)采集、數(shù)據(jù)分析，然后將數(shù)據(jù)上傳至服務(wù)器端進(jìn)行中心化展示和處理。該系統(tǒng)具有極高的可擴(kuò)展性以及兼容性，能夠適應(yīng)多種隧道場景下的采集、通信要求，并且高度解耦，便于系統(tǒng)的擴(kuò)展與模塊化處理。通過該系統(tǒng)，可以對隧道防護(hù)門的實(shí)時狀態(tài)進(jìn)行分析與預(yù)警，為隧道防護(hù)門的可靠性提供安全保障。