隧道防護(hù)門安全監(jiān)測技術(shù)研究及應(yīng)用

周奇才 屈先亮 熊肖磊 趙 炯

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

0 引言

隨著我國鐵路網(wǎng)絡(luò)的發(fā)展，鐵路隧道里程增長迅速，隧道的安全要求得到了越來越多的關(guān)注。為了保障隧道安全，隧道內(nèi)配置了緊急救援站、避難所、緊急出口、橫通道、疏散通道等土建設(shè)施[2]，這些設(shè)施與隧道內(nèi)之間設(shè)置了防護(hù)門，來保護(hù)隧道內(nèi)的設(shè)備和起到安全隔離防護(hù)的作用。但是，受到列車經(jīng)過時(shí)產(chǎn)生的活塞風(fēng)的風(fēng)壓的影響，防護(hù)門有可能產(chǎn)生門體脫落、門體變形、門軸斷裂、門體的鎖具變形等故障，影響隧道洞室內(nèi)部電力、通信等設(shè)備的安全，門體脫落并且倒向軌道一側(cè)，還會(huì)極大影響隧道內(nèi)的行車安全。圖1所示為隧道內(nèi)防護(hù)門脫落現(xiàn)象。

圖1 防護(hù)門門體脫落照片

為保障防護(hù)門安全，目前提出的方式有人工巡檢、微結(jié)構(gòu)光纖探測[3]、基于ZigBee的鐵路隧道防護(hù)門監(jiān)控[4]等。人工巡檢方式是通過工人定期進(jìn)入隧道逐個(gè)檢查門體狀況，人工巡檢一方面巡檢難度大效率低下，另一方面人工巡檢無法檢測到可能出現(xiàn)的隱患，例如在活塞風(fēng)的影響下門體可能出現(xiàn)的異常姿態(tài)變化；基于微結(jié)構(gòu)光纖分布式傳感技術(shù)能夠感知門體的形變、振動(dòng)等物理參數(shù)，但需要現(xiàn)場鋪設(shè)光纖，具有一定的成本和難度；基于ZigBee的防護(hù)門監(jiān)控技術(shù)能夠?qū)崿F(xiàn)隧道內(nèi)防護(hù)門監(jiān)控單元之間靈活組網(wǎng)，實(shí)現(xiàn)隧道內(nèi)多扇防護(hù)門數(shù)據(jù)無線傳輸，但傳輸速率較低，只能傳輸一些門體開關(guān)量信息等少量數(shù)據(jù)信息。

針對目前防護(hù)門監(jiān)控存在的安全監(jiān)測技術(shù)的需求和不足，本文設(shè)計(jì)了一套基于MQTT（Message Queuing Telemetry Transport）協(xié)議的隧道防護(hù)門安全監(jiān)測系統(tǒng)。隧道內(nèi)的每個(gè)防護(hù)門都安裝一套采集終端，以采集門體的姿態(tài)、振動(dòng)、風(fēng)壓、溫度等相關(guān)信息，每套采集終端采集的數(shù)據(jù)經(jīng)過預(yù)處理，而且每個(gè)防護(hù)門有自己的門體標(biāo)識(shí)信息，將所有信息打包并通過MQTT協(xié)議傳輸?shù)酱矸?wù)器，網(wǎng)頁端從服務(wù)器訂閱防護(hù)門主題的數(shù)據(jù)，展示不同隧道內(nèi)所有防護(hù)門的狀態(tài)信息。

1 隧道防護(hù)門安全監(jiān)測系統(tǒng)架構(gòu)設(shè)計(jì)

針對隧道防護(hù)門的安全監(jiān)測需求，隧道防護(hù)門安全監(jiān)測系統(tǒng)的架構(gòu)如圖2所示。該系統(tǒng)由采集終端采集數(shù)據(jù)、MQTT數(shù)據(jù)傳輸、云端存儲(chǔ)和處理數(shù)據(jù)并展示3部分。

圖2 隧道防護(hù)門安全監(jiān)測系統(tǒng)架構(gòu)

采集終端部分負(fù)責(zé)隧道內(nèi)每個(gè)防護(hù)門的數(shù)據(jù)采集，利用閾值處理判斷門體是否開閉、判斷列車是否到來，然后采集風(fēng)壓數(shù)據(jù)，判斷MEMS傳感器每一包的包頭數(shù)據(jù)并解析出想要的門體數(shù)據(jù)信息。通常情況下，每一個(gè)隧道有多個(gè)防護(hù)門，在需要監(jiān)測的每個(gè)防護(hù)門上安裝一個(gè)采集終端。將每個(gè)防護(hù)門自定義配置其唯一的客戶端ID，用于區(qū)分和定位隧道內(nèi)的防護(hù)門。將傳感器采集到的數(shù)據(jù)進(jìn)行解析和處理，然后將不同類型的傳感器傳來的數(shù)據(jù)臨時(shí)存儲(chǔ)，以便進(jìn)行下一步數(shù)據(jù)打包和發(fā)送。

MQTT傳輸部分的監(jiān)控系統(tǒng)數(shù)據(jù)傳輸采用MQTT傳輸協(xié)議，MQTT傳輸協(xié)議為即時(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ù)器連接。由于隧道內(nèi)有多個(gè)防護(hù)門，且需要監(jiān)測的隧道也可能有多段，故使用MQTT協(xié)議傳輸數(shù)據(jù)具有一定的優(yōu)勢。

預(yù)處理后的數(shù)據(jù)通過MQTT協(xié)議發(fā)送到MQTT代理服務(wù)器。在完成客戶端配置后，為了方便網(wǎng)頁端從服務(wù)器中取出數(shù)據(jù)并處理和展示，MQTT傳輸?shù)拿堪⑥D(zhuǎn)換成JSON格式。JSON（JavaScript Object Notation，JS對象簡譜）是一種輕量級(jí)的數(shù)據(jù)交換格式，它基于ECMAScript （歐洲計(jì)算機(jī)協(xié)會(huì)制定的JS規(guī)范）的一個(gè)子集，采用完全獨(dú)立于編程語言的文本格式來存儲(chǔ)和表示數(shù)據(jù)。簡潔和清晰的層次結(jié)構(gòu)使JSON成為理想的數(shù)據(jù)交換語言，易于人閱讀和編寫，同時(shí)也易于機(jī)器解析和生成，并有效地提升網(wǎng)絡(luò)傳輸效率，通常用于網(wǎng)站上表示和傳輸數(shù)據(jù)。在本系統(tǒng)中，采集端采集完數(shù)據(jù)上傳到MQTT服務(wù)器，客戶端訂閱相應(yīng)數(shù)據(jù)并展示在網(wǎng)頁上，使用JSON格式便于終端編碼以及網(wǎng)頁端的解碼，同時(shí)可讀性較強(qiáng)。

云端部分在代理服務(wù)器接收到數(shù)據(jù)后將數(shù)據(jù)取出存儲(chǔ)在數(shù)據(jù)庫中，并將數(shù)據(jù)進(jìn)一步處理，網(wǎng)頁端訂閱以防護(hù)門為主題的數(shù)據(jù)，最后將處理后的數(shù)據(jù)展示到前端頁面。

2 數(shù)據(jù)采集終端設(shè)計(jì)

2.1 系統(tǒng)組成

數(shù)據(jù)采集終端系統(tǒng)的組成如圖3所示。針對防護(hù)門數(shù)據(jù)采集需求，要采集門體的振動(dòng)、姿態(tài)、溫度、風(fēng)壓數(shù)據(jù)，需要分別配置相應(yīng)傳感器終端。

圖3 數(shù)據(jù)采集終端系統(tǒng)組成

采集終端由采集卡，MEMS傳感器、溫度傳感器、風(fēng)壓傳感器、WiFi模塊組成。MEMS傳感器能夠采集門體的三軸姿態(tài)、三軸加速度和三軸磁場數(shù)據(jù)；溫度傳感器采集門體附近的空間溫度；風(fēng)壓傳感器采集列車到來時(shí)的風(fēng)壓，模擬量數(shù)據(jù)需要經(jīng)過采集卡進(jìn)行AD轉(zhuǎn)換之后轉(zhuǎn)換成數(shù)字量數(shù)據(jù)。整個(gè)采集終端由5V直流供電。

2.2 硬件設(shè)計(jì)

采集卡采用了某公司推出的一款32位高性能微控制器STM32F407ZGT6，該控制器采用Cortex-M4內(nèi)核，集成了豐富的接口資源和外設(shè)。該產(chǎn)品主頻最高可達(dá)168 MHz，支持多種工作模式，集成了1 MB的Flash和192 KB的SRAM，且接口資源豐富，包括SPI、I2C、USART，集成了12位的ADC和12位DAC，支持高級(jí)定時(shí)器和用于精確時(shí)間測量的SysTick定時(shí)器。

WiFi模塊采用了ESP-01S模塊，ESP-01S模塊是WiFi模塊，其核心處理器ESP8266在較小尺寸封裝中集成了業(yè)界領(lǐng)先的TensilicaL106超低功耗的32位微型MCU，帶有16位精簡模式，主頻支持80 MHz和160 MHz，支持RTOS，集成WiFi MAC/BB/RF/LNA。支持UART/GPIO/PWM接口，支持STA/AP/STA+AP工作模式，燒寫MQTT固件后還可通過AT指令完成MQTT協(xié)議的實(shí)現(xiàn)。ESP-01S模塊通過UART與采集卡通訊。本系統(tǒng)中使用燒寫了MQTT固件的ESP模塊實(shí)現(xiàn)MQTT協(xié)議的傳輸。

MEMS傳感器采用維特智能姿態(tài)傳感器HWT906，HWT906姿態(tài)傳感器是基于MEMS技術(shù)的高性能三維運(yùn)動(dòng)姿態(tài)測量系統(tǒng)，包括三軸陀螺儀、三軸加速度計(jì)、三軸電子羅盤等運(yùn)動(dòng)傳感器，MEMS傳感器與采集卡通過UART通訊。HWT906姿態(tài)傳感器具備基于Kalman濾波原理的傳感器融合算法，可以實(shí)時(shí)提供高達(dá)1000 Hz更新速率的數(shù)據(jù)，且輸出速率0.2～1 000 Hz可調(diào)節(jié)，支持串口速率4 800～921 600 bps可調(diào)節(jié)。

溫度傳感器采用DHT11，DHT11數(shù)字溫濕度傳感器是一款含有已校準(zhǔn)數(shù)字信號(hào)輸出的溫濕度復(fù)合傳感器，內(nèi)部由一個(gè)8位單片機(jī)控制一個(gè)電阻式感濕元件和一個(gè)NTC測溫元件。DHT11采用單總線協(xié)議，其溫度測量范圍為0℃～50℃，誤差在±2℃。

風(fēng)壓傳感器選擇榮光儀表生產(chǎn)的HALO-FY-WG型風(fēng)壓傳感器，此前測得當(dāng)列車以350 km/h速度經(jīng)過的情況下隧道防護(hù)門所承受的風(fēng)壓最大值約為±6 kPa，所選用的HALO-FY-WG型風(fēng)壓傳感器量程為-10～10 kPa，滿足風(fēng)壓測量需求。三線制電壓輸出，5 V供電模塊采用某司開關(guān)電源220 V轉(zhuǎn)5 V，輸入電壓110/220 VAC，單組輸出，輸出功率35 W。

2.3 軟件設(shè)計(jì)

采集終端的程序設(shè)計(jì)流程如圖4所示。系統(tǒng)上電后，首先完成系統(tǒng)時(shí)鐘初始化以及中斷優(yōu)先級(jí)分組，由于采集卡接有不同的傳感器，數(shù)據(jù)到來時(shí)候需要根據(jù)傳感器采集數(shù)據(jù)的重要性設(shè)置中斷優(yōu)先級(jí)分組。搶占優(yōu)先級(jí)的級(jí)別高于響應(yīng)優(yōu)先級(jí)，而數(shù)值越小所代表的優(yōu)先級(jí)越高。STM32有5個(gè)中斷分組，并由相應(yīng)的寄存器SCBAIRCR的位10-8控制，分配關(guān)系如表1所示。

圖4 采集終端程序設(shè)計(jì)流程

采用中斷分組2的方式設(shè)置中斷優(yōu)先級(jí)，將門體開閉設(shè)置為最高優(yōu)先級(jí)0，門體振動(dòng)加速度、姿態(tài)、風(fēng)壓、溫度數(shù)據(jù)到來觸發(fā)的中斷設(shè)置為較低的相同優(yōu)先級(jí)的中斷，根據(jù)中斷優(yōu)先級(jí)和各中斷到達(dá)的時(shí)間處理每種數(shù)據(jù)。并在中斷中處理和解析MEMS傳感器傳來的數(shù)據(jù)，然后臨時(shí)存儲(chǔ)到數(shù)組中。

繼續(xù)完成與傳感器通信的硬件接口的初始化，采集卡給MEMS傳感器模塊發(fā)送一定協(xié)議格式的指令（見表2），完成MEMS傳感器的加速度校準(zhǔn)以及磁場校準(zhǔn)等初始化工作。MEMS傳感器初始化指令格式為5個(gè)十六進(jìn)制字符，采集卡通過串口給MEMS傳感器發(fā)送的所有指令要在10 s內(nèi)完成，否則傳感器會(huì)自動(dòng)上鎖。

表2 MEMS傳感器配置指令

接下來給WiFi模塊發(fā)送AT指令，配置MQTT協(xié)議相關(guān)內(nèi)容。配置完成之后等待傳感器發(fā)送數(shù)據(jù)，每種類型的傳感器發(fā)送到采集端之后會(huì)產(chǎn)生中斷，根據(jù)不同類型傳感器觸發(fā)的中斷設(shè)置對應(yīng)的優(yōu)先級(jí)的高低以及信息到來先后對數(shù)據(jù)進(jìn)行處理，將傳感器發(fā)送的數(shù)據(jù)解析后，將所有數(shù)據(jù)打包成JSON格式后再發(fā)送到MQTT代理服務(wù)器。

3 監(jiān)測系統(tǒng)數(shù)據(jù)傳輸

采集卡通過給esp01模塊發(fā)送AT指令實(shí)現(xiàn)MQTT協(xié)議的配置，配置流程如圖5所示。首先，將WiFi模塊退出透傳模式，然后配置為STA（Station）模式，然后檢索是否有相應(yīng)的WiFi名稱并連接局域網(wǎng)，接著設(shè)置模塊單連接模式、配置防護(hù)門采集端的客戶端的用戶信息，包括用戶ID、賬號(hào)、密碼等，最后連接MQTT服務(wù)器。AT指令發(fā)送順序如表3所示。

表3 AT指令發(fā)送順序

圖5 WiFi模塊配置流程

圖6 數(shù)據(jù)采集盒照片

其中，配置客戶端參數(shù)具體配置為：“AT+MQTTUSERCFG=0，1，clientid，，，0，0”，客戶端ID初始設(shè)置為Clientid，MQTT代理服務(wù)器的用戶名和用戶密碼都設(shè)置為空，故客戶端設(shè)置的用戶名和密碼都為空。連接服務(wù)器的參數(shù)配置為：“AT+MQTTCONN=0，域名，端口，0”，填入服務(wù)器的域名或IP地址以及端口號(hào)，即可連接MQTT服務(wù)器。在本系統(tǒng)中，利用已經(jīng)搭建好的MQTT代理服務(wù)器，已知其域名和開放的端口。esp01模塊接收的每條AT指令配置之后都會(huì)返回一條指令配置狀態(tài)，配置成功返回OK字符，配置失敗返回ERROR字符。MQTT協(xié)議配置完成之后，通過AT+MQTTPUB指令發(fā)布MQTT消息。

為了能清楚展示不同防護(hù)門之間的信息，每個(gè)防護(hù)門傳輸?shù)腏SON數(shù)據(jù)包需要加一些標(biāo)識(shí)符，每個(gè)防護(hù)門發(fā)送的JSON數(shù)據(jù)包內(nèi)容格式如表4所示。每一個(gè)JSON數(shù)據(jù)包具有多個(gè)定義字段和值，能夠展示防護(hù)門的數(shù)據(jù)信息和自身的身份信息。

表4 JSON數(shù)據(jù)包內(nèi)容

4 監(jiān)測數(shù)據(jù)應(yīng)用

將數(shù)據(jù)發(fā)送到代理服務(wù)器之后，從服務(wù)器中取出數(shù)據(jù)并將相關(guān)數(shù)據(jù)進(jìn)一步處理并展示到網(wǎng)頁端來顯示門體的狀態(tài)信息。

為了測試整套系統(tǒng)的可行性，首先設(shè)計(jì)了一款采集盒，根據(jù)采集卡和傳感器的大小以及傳感器固定孔位距離，在采集盒底部鋪設(shè)了一塊孔位定制的亞克力板，將MEMS傳感器與亞克力板上的孔位對應(yīng)固定，然后將采集盒安裝到門體上進(jìn)行測試。通過敲擊門體和旋轉(zhuǎn)門體，測試門體的振動(dòng)數(shù)據(jù)和姿態(tài)數(shù)據(jù)能否傳輸?shù)皆贫瞬⒄故镜骄W(wǎng)頁端。

通過測試門體開閉以及敲擊門體，網(wǎng)頁端能夠?qū)崟r(shí)響應(yīng)到門體的狀態(tài)變化并顯示出來，測試和展示的效果如圖7所示。驗(yàn)證了采集終端的可行性。

圖7 防護(hù)門信息網(wǎng)頁端展示

5 結(jié)語

針對列車經(jīng)過產(chǎn)生的活塞風(fēng)風(fēng)壓下，鐵路隧道防護(hù)門可能出現(xiàn)的隱患，本文提出了一種隧道防護(hù)門安全監(jiān)測系統(tǒng)。整套的隧道防護(hù)門智能安全監(jiān)測系統(tǒng)可以實(shí)現(xiàn)對隧道防護(hù)門開閉、振動(dòng)、姿態(tài)、溫度狀態(tài)信息的監(jiān)測，傳輸?shù)臄?shù)據(jù)量信息較多，對隧道內(nèi)防護(hù)門的安全隱患能起到預(yù)警作用，同時(shí)該系統(tǒng)具有一定的可擴(kuò)展性，能通過配置采集卡GPIO能夠添加多種類型的傳感器，可根據(jù)后續(xù)的需求進(jìn)行傳感器的添加。為目前隧道防護(hù)門安全監(jiān)測提供了一種新的方式。