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

周奇才, 徐英龍, 熊肖磊, 趙 炯

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

0 引言

出于防火和救援設(shè)計等原因，鐵路隧道中需要設(shè)置防護(hù)門作為安全手段之一[1]，防護(hù)門主要設(shè)置于雙向隧道連接處或隧道設(shè)備安置處。列車在隧道內(nèi)運(yùn)行且通過時，由于隧道長度長，列車運(yùn)行速度快，列車會在隧道內(nèi)產(chǎn)生較大側(cè)向風(fēng)壓的“活塞效應(yīng)”，會使隧道內(nèi)的防護(hù)門產(chǎn)生破壞，而正常運(yùn)營的線路中未能及時檢查到防護(hù)門損壞，具有相當(dāng)大的危險性。傳統(tǒng)的人工現(xiàn)場巡檢方案一直存在著發(fā)現(xiàn)遲、效率低等缺點(diǎn)，因此如何對隧道防護(hù)門從施工到運(yùn)營進(jìn)行全生命周期的維護(hù)也是亟待解決的難題。

針對以上問題，本文提出了一種用于隧道防護(hù)門的遠(yuǎn)程監(jiān)控系統(tǒng)，可實(shí)現(xiàn)隧道防護(hù)門的遠(yuǎn)程監(jiān)控、施工數(shù)據(jù)管理、運(yùn)營數(shù)據(jù)管理、故障預(yù)測與診斷等功能。

1 防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)設(shè)計

1.1 系統(tǒng)需求

針對隧道防護(hù)門不斷增長的數(shù)量以及全生命周期維護(hù)要求，遠(yuǎn)程監(jiān)控系統(tǒng)需要實(shí)現(xiàn)以下功能：①管理人員可以遠(yuǎn)程查看防護(hù)門的實(shí)時狀態(tài)或故障信息等；②搭建施工數(shù)據(jù)管理平臺，施工與驗(yàn)收人員能遠(yuǎn)程將關(guān)鍵數(shù)據(jù)采集并登記到平臺系統(tǒng)中，提高施工期工作效率；③搭建運(yùn)營數(shù)據(jù)管理平臺，運(yùn)營人員可以遠(yuǎn)程通過移動終端和平臺交互，獲取并上傳相關(guān)的信息和數(shù)據(jù)，提高運(yùn)營效率和可靠性；④對于未發(fā)生故障的監(jiān)控對象，系統(tǒng)將通過相關(guān)算法得出對象是否薄弱，如果薄弱給出損壞發(fā)生的預(yù)測時間區(qū)間。遠(yuǎn)程監(jiān)控系統(tǒng)的需求概況如圖1所示。

圖1 遠(yuǎn)程監(jiān)控系統(tǒng)需求概況

1.2 控制系統(tǒng)整體架構(gòu)

根據(jù)所做工作不同，將整個控制系統(tǒng)劃分為五個層次，分別為數(shù)據(jù)采集層、數(shù)據(jù)處理層、數(shù)據(jù)持久層、服務(wù)層和表現(xiàn)層。其中數(shù)據(jù)采集層和數(shù)據(jù)處理層作為數(shù)據(jù)采集裝置部署在設(shè)備旁，稱為“邊緣端”[2]；而部署在遠(yuǎn)程服務(wù)器的數(shù)據(jù)持久層、服務(wù)層、表現(xiàn)層稱為“平臺端”，控制系統(tǒng)層次劃分如圖2所示。

圖2 控制系統(tǒng)層次劃分

數(shù)據(jù)采集層包括各種終端設(shè)備，其主要任務(wù)是采集防護(hù)門門體和門鎖、合頁等部件振動數(shù)據(jù)，以及防護(hù)門當(dāng)前狀態(tài)圖像等，并傳至數(shù)據(jù)處理層。

數(shù)據(jù)處理層由邊緣計算控制器和無線傳輸裝置組成，主要是將獲取到的數(shù)據(jù)在邊緣側(cè)進(jìn)行數(shù)據(jù)的預(yù)處理，并且將數(shù)據(jù)無線傳輸至平臺端，提高數(shù)據(jù)傳輸效率，降低傳輸功耗。

數(shù)據(jù)持久層由數(shù)據(jù)庫組成，平臺端通過MQTT協(xié)議接收數(shù)據(jù)處理層的數(shù)據(jù)，并準(zhǔn)確地將其存入數(shù)據(jù)庫中，以便于后續(xù)的分析與查詢。

服務(wù)層根據(jù)功能需求劃分子模塊，子模塊通過調(diào)用數(shù)據(jù)持久層接口獲得所需數(shù)據(jù)，通過數(shù)據(jù)分析和處理得到所需結(jié)果，并將結(jié)果傳至表現(xiàn)層。

表現(xiàn)層實(shí)時顯示設(shè)備狀態(tài)以及實(shí)現(xiàn)多平臺的運(yùn)營交互界面，供遠(yuǎn)程和現(xiàn)場運(yùn)營人員進(jìn)行交互與監(jiān)控。

2 相關(guān)技術(shù)

目前平臺端使用框架技術(shù)進(jìn)行開發(fā)，本文采用Spring Boot+Spring MVC+MyBatis框架作為主體進(jìn)行開發(fā)，并對接口統(tǒng)一使用RESTful風(fēng)格；表現(xiàn)層中網(wǎng)頁使用Bootstrap框架進(jìn)行展示；數(shù)據(jù)持久層采用MySQL和MongoDB對數(shù)據(jù)進(jìn)行緩存和持久化。

REST(Representational State Transfer)是web服務(wù)一種架構(gòu)思想，可以有效利用HTTP報文特性，使用JSON格式對報文主體進(jìn)行編輯，使服務(wù)端API供網(wǎng)頁端和移動端共同使用。

MongoDB是一種基于分布式文件存儲的NoSQL數(shù)據(jù)庫，適合存儲JSON風(fēng)格的信息，有利于直接接收并存儲數(shù)據(jù)處理層發(fā)來的信息。由于數(shù)據(jù)預(yù)處理場景中不需要使用事務(wù)，使用MongoDB能夠達(dá)到較高的效率。

3 平臺端系統(tǒng)設(shè)計

控制系統(tǒng)中的平臺端是整個系統(tǒng)的重點(diǎn)，運(yùn)營人員的需求主要是在平臺端進(jìn)行處理，并且在使用過程中對其進(jìn)行維護(hù)。

3.1 平臺端整體框架

由于系統(tǒng)的需求將不斷增長，涉及的業(yè)務(wù)流程會越來越多，為了合理地劃分業(yè)務(wù)模塊，增強(qiáng)系統(tǒng)的擴(kuò)展性和復(fù)用能力，平臺端使用領(lǐng)域驅(qū)動設(shè)計(Domain-Driven Design，DDD)的思想進(jìn)行系統(tǒng)設(shè)計[3]，將系統(tǒng)分為5個模塊，如圖3所示。

圖3 平臺端模塊結(jié)構(gòu)

Data用于實(shí)現(xiàn)數(shù)據(jù)庫中的實(shí)體以及數(shù)據(jù)庫訪問對象的構(gòu)建與訪問；Service作為輸出端，用于提供前端調(diào)用接口，并且調(diào)用Application模塊中的類和方法；Repository用于和外部數(shù)據(jù)源進(jìn)行交互，包括但不限于Data模塊；Application模塊負(fù)責(zé)和輸出端交互，主要職責(zé)包含有日志記錄、鑒權(quán)、調(diào)用Repository；Domain在整個框架中處于核心位置，存放一些構(gòu)造對象和接口；Repository模塊負(fù)責(zé)Domain中接口的實(shí)現(xiàn)，這樣可以解決循環(huán)依賴的問題。系統(tǒng)采用六邊形架構(gòu)，通過使用依賴倒置的原則，當(dāng)新的需求越來越多時，也能保證系統(tǒng)的獨(dú)立和精簡。

3.2 數(shù)據(jù)庫表設(shè)計

由于系統(tǒng)需求都與數(shù)據(jù)有密切關(guān)聯(lián)，且數(shù)據(jù)庫是連接用戶需求和編程實(shí)現(xiàn)的橋梁，數(shù)據(jù)庫的設(shè)計直接影響后續(xù)功能實(shí)現(xiàn)的難易。根據(jù)需求劃分，將整個數(shù)據(jù)庫分為人員信息、設(shè)備信息以及消息列表三大部分：人員信息主要包括管理員信息與現(xiàn)場操作人員信息；設(shè)備信息為防護(hù)門設(shè)備信息；消息列表包括數(shù)據(jù)采集裝置發(fā)送消息、現(xiàn)場人員發(fā)送消息、故障消息和預(yù)測消息。

3.3 系統(tǒng)模塊設(shè)計

系統(tǒng)按功能主要分為遠(yuǎn)程監(jiān)控、數(shù)據(jù)管理、故障預(yù)測三個模塊，現(xiàn)分別進(jìn)行模塊設(shè)計。

3.3.1 遠(yuǎn)程監(jiān)控

遠(yuǎn)程監(jiān)控模塊的功能流程如圖4所示。遠(yuǎn)程監(jiān)控模塊負(fù)責(zé)接收數(shù)據(jù)管理模塊發(fā)送來的實(shí)時防護(hù)門數(shù)據(jù)，并通過門體振動頻率以及幅度、門體絕對位移量是否超出合理范圍以及攝像頭采集到的照片進(jìn)行圖像識別，判斷防護(hù)門是否已經(jīng)出現(xiàn)故障，其中圖像識別采用雙邊濾波以及Hough變換[4]等算法進(jìn)行在線檢測。管理人員能通過系統(tǒng)平臺查詢相關(guān)防護(hù)門日志信息；管理人員也可以通過發(fā)送請求至數(shù)據(jù)采集裝置獲得當(dāng)前防護(hù)門未經(jīng)處理的圖像。

圖4 遠(yuǎn)程監(jiān)控流程

3.3.2 數(shù)據(jù)管理

施工數(shù)據(jù)管理和運(yùn)營數(shù)據(jù)管理原理相似，在此以運(yùn)營管理為例進(jìn)行介紹，運(yùn)營數(shù)據(jù)管理流程如圖5所示。系統(tǒng)獲得數(shù)據(jù)采集裝置發(fā)來信息，首先將其放入內(nèi)存進(jìn)行是否故障的判斷，然后根據(jù)判斷結(jié)果決定是否生成故障信息并推送至系統(tǒng)警報，最后將采集到的數(shù)據(jù)持久化到硬盤；通過持久化的數(shù)據(jù)進(jìn)行故障診斷與預(yù)測，如果預(yù)測有故障則生成預(yù)測消息并推送至系統(tǒng)警報并發(fā)送給現(xiàn)場操作人員；現(xiàn)場操作人員可以發(fā)送現(xiàn)場操作信息至系統(tǒng)，一旦發(fā)現(xiàn)故障也將觸發(fā)警報。

圖5 運(yùn)營數(shù)據(jù)管理流程圖

3.3.3 故障預(yù)測

模塊采用機(jī)器學(xué)習(xí)的方法對故障進(jìn)行預(yù)測以獲得預(yù)測結(jié)果，預(yù)測模型使用長短時記憶循環(huán)神經(jīng)網(wǎng)絡(luò)進(jìn)行訓(xùn)練[5,6]，通過部分失效防護(hù)門獲取失效工況下的振動數(shù)據(jù)，得到機(jī)器學(xué)習(xí)訓(xùn)練所需數(shù)據(jù)，將訓(xùn)練結(jié)果和實(shí)際情況對比，反復(fù)訓(xùn)練直到滿足訓(xùn)練要求。故障預(yù)測流程如圖6所示。故障預(yù)測模塊根據(jù)防護(hù)門編號讀取持久化數(shù)據(jù)中的日志信息，通過振動信息進(jìn)行故障預(yù)測，得出該防護(hù)門是否薄弱，如果薄弱將進(jìn)一步計算預(yù)測失效時間區(qū)間，將結(jié)果發(fā)送至管理平臺以及現(xiàn)場人員，以便現(xiàn)場排查；如果預(yù)測結(jié)果為非薄弱則循環(huán)選取下一扇防護(hù)門進(jìn)行預(yù)測。

圖6 故障預(yù)測流程

4 結(jié)語

本文提出了一種應(yīng)用于隧道防護(hù)門的遠(yuǎn)程監(jiān)控系統(tǒng)，用于隧道防護(hù)門的施工期與運(yùn)營期，針對系統(tǒng)需求提出了控制系統(tǒng)的整體架構(gòu)。對整體架構(gòu)中的平臺端采用領(lǐng)域驅(qū)動設(shè)計思想進(jìn)行系統(tǒng)設(shè)計，并設(shè)計了數(shù)據(jù)庫存儲結(jié)構(gòu)以及各功能模塊程序流程。

隧道防護(hù)門遠(yuǎn)程監(jiān)控系統(tǒng)可以實(shí)現(xiàn)對防護(hù)門失效的及時發(fā)現(xiàn)，標(biāo)準(zhǔn)化、信息化施工期和運(yùn)營期中對于人員和數(shù)據(jù)的管理，還能對薄弱的防護(hù)門進(jìn)行預(yù)測，提出預(yù)測失效區(qū)間，能使得運(yùn)營單位提前對相應(yīng)門體進(jìn)行檢測與更換。系統(tǒng)能夠較好地提高隧道內(nèi)部環(huán)境的安全性，降低運(yùn)營人員壓力，最終也可將各省市、各線路的監(jiān)控對象納入統(tǒng)一系統(tǒng)，實(shí)現(xiàn)全國隧道防護(hù)門信息組網(wǎng)。