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

(同濟大學 機械與能源工程學院，上海 201804)

0 引言

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

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

1 防護門遠程監(jiān)控系統(tǒng)設計

1.1 系統(tǒng)需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 平臺端整體框架

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

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

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

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

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

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

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

3.3.1 遠程監(jiān)控

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

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

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

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

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

3.3.3 故障預測

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

圖6 故障預測流程

4 結(jié)語

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

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