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

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

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

0 引言

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

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

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

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

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

第一層為感知層。感知層主要負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)底層的數(shù)據(jù)采集功能，由樹莓派與多種傳感器組成。考慮到部分隧道地理位置較為偏僻，網(wǎng)絡(luò)條件較差甚至無(wú)網(wǎng)絡(luò)的情況，該采集器需要具有數(shù)據(jù)本地存儲(chǔ)與分析計(jì)算的功能，因此選擇樹莓派作為中心采集器。樹莓派是一種只有信用卡大小的卡片式電腦，具有價(jià)格低、體積小的優(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)控平臺(tái)進(jìn)行數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析以及數(shù)據(jù)展示等。

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

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

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

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

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

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

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

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

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

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

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

3 MQTT服務(wù)器搭建

MQTT協(xié)議是由IBM開發(fā)的即時(shí)通訊協(xié)議，它是一種輕量級(jí)消息傳遞協(xié)議，通常與基于服務(wù)器的發(fā)布-訂閱模式一起使用，在TCP/IP之上運(yùn)行。在發(fā)布-訂閱模式中，發(fā)布消息的客戶端與其他一個(gè)或多個(gè)接收消息的客戶端分離。客戶端可以發(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)用層之間的解耦，并且消息隊(duì)列還具有削峰的作用，可以避免同一時(shí)間采集到的大量數(shù)據(jù)涌入監(jiān)控平臺(tái)導(dǎo)致監(jiān)控平臺(tái)服務(wù)器宕機(jī)。

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

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

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

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

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

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

5 結(jié)語(yǔ)

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