郝建明，劉天鵬

（中遠(yuǎn)海運(yùn)科技股份有限公司，上海 200135）

0 引言

截至2021年底，全國(guó)公路隧道23268處、2469.89萬(wàn)延米，其中特長(zhǎng)隧道1599處、717.08萬(wàn)延米，長(zhǎng)隧道6211處、1084.43萬(wàn)延米。隨著高速公路通車(chē)隧道里程的日益增多，高速公路運(yùn)行、組織和管理的難度與日俱增，對(duì)于隧道的運(yùn)行、安全、保暢、應(yīng)急等有著更加迫切的現(xiàn)實(shí)需求。2019年，交通運(yùn)輸部印發(fā)了《促進(jìn)公路隧道提質(zhì)升級(jí)行動(dòng)方案》和《公路隧道提質(zhì)升級(jí)行動(dòng)技術(shù)指南》，在全國(guó)實(shí)施促進(jìn)公路隧道提質(zhì)升級(jí)行動(dòng)，更好地為公眾提供安全便捷的出行服務(wù)。

隧道監(jiān)控軟件是隧道運(yùn)營(yíng)管理、保通保暢、保障安全的重要信息化支撐手段。對(duì)于隧道信息化管理方面的研究，李旭華提出C/S架構(gòu)和B/S架構(gòu)相結(jié)合的隧道監(jiān)控系統(tǒng)，保障數(shù)據(jù)采集實(shí)時(shí)性的同時(shí)兼容先進(jìn)信息化技術(shù)；黃文彬等提出將多元融合感知技術(shù)應(yīng)用于高速公路隧道信息化建設(shè)，實(shí)現(xiàn)隧道的精細(xì)化管理；劉志輝等提出基于物聯(lián)網(wǎng)技術(shù)的智慧隧道運(yùn)營(yíng)管控系統(tǒng)，實(shí)現(xiàn)隧道各系統(tǒng)互聯(lián)互通、集中管控、綠色節(jié)能、安全防控、服務(wù)協(xié)同；馬慶祿等為了從整體上實(shí)現(xiàn)隧道群的區(qū)域性控制，提出面向交通安全的隧道群區(qū)域性聯(lián)測(cè)聯(lián)控理念。

綜上所述，雖然隧道信息化管理取得了一些應(yīng)用成果，但軟件系統(tǒng)基本以傳統(tǒng)的“綜合監(jiān)控”管理模式為設(shè)計(jì)原則，僅實(shí)現(xiàn)對(duì)單個(gè)隧道或少量相鄰隧道群的集成監(jiān)控。為了縮減管理中間環(huán)節(jié)，降低人員運(yùn)營(yíng)成本及配套設(shè)施成本，提高系統(tǒng)響應(yīng)效率，現(xiàn)階段各省市正在大力推進(jìn)基于數(shù)據(jù)化的“集中監(jiān)控”管理模式，將監(jiān)控管理與現(xiàn)場(chǎng)救援分離，在區(qū)域中心開(kāi)展轄區(qū)內(nèi)所有隧道的日常監(jiān)控管理工作，隧管所僅設(shè)置救援站。本文結(jié)合行業(yè)發(fā)展趨勢(shì)，設(shè)計(jì)區(qū)域級(jí)高速公路隧道集中管控平臺(tái)，實(shí)現(xiàn)對(duì)大批量隧道的集中監(jiān)控管理，解決海量數(shù)據(jù)采集處置延遲高、標(biāo)準(zhǔn)不統(tǒng)一、數(shù)據(jù)缺失等問(wèn)題，在優(yōu)化資源配置的基礎(chǔ)上提升隧道運(yùn)營(yíng)管控和服務(wù)水平。

1 需求分析

1.1 傳統(tǒng)隧道管理體制

目前各省市自治區(qū)基本采用“隧管所-（路段分中心）-區(qū)域中心-省級(jí)路網(wǎng)中心”的隧道運(yùn)營(yíng)管理體制，如圖1所示。傳統(tǒng)的“綜合監(jiān)控”管理模式下，隧管所負(fù)責(zé)隧道日常運(yùn)營(yíng)、設(shè)備維護(hù)、突發(fā)事件處置及信息上報(bào)等工作，是隧道安全管理的主要主體；路段分中心、區(qū)域中心、省級(jí)路網(wǎng)中心負(fù)責(zé)對(duì)隧道運(yùn)營(yíng)養(yǎng)護(hù)工作進(jìn)行監(jiān)管和考核，以及對(duì)涉及跨區(qū)域的突發(fā)事件進(jìn)行協(xié)調(diào)處置。而在“集中監(jiān)控”管理模式下，隧道日常監(jiān)控管理、突發(fā)事件接警處置及指揮調(diào)度等均由區(qū)域中心負(fù)責(zé)，隧管所根據(jù)區(qū)域中心調(diào)度指令開(kāi)展現(xiàn)場(chǎng)應(yīng)急救援工作。

圖1 隧道運(yùn)營(yíng)管理體制框架圖

1.2 隧道信息化現(xiàn)狀

當(dāng)前，隧管所已經(jīng)獨(dú)立建設(shè)有照明、視頻監(jiān)控、信息發(fā)布、緊急電話等子系統(tǒng)，有些隧道監(jiān)控軟件已實(shí)現(xiàn)隧管所級(jí)的各子系統(tǒng)集成聯(lián)動(dòng)，但還有較多隧管所各子系統(tǒng)處于分散部署的狀態(tài)。隧道管理系統(tǒng)一體化程度不高、綜合管控功能不足、設(shè)備數(shù)據(jù)共享能力薄弱，且上一級(jí)部門(mén)無(wú)法對(duì)隧道內(nèi)的照明、環(huán)境監(jiān)控、風(fēng)機(jī)等機(jī)電系統(tǒng)運(yùn)行情況進(jìn)行監(jiān)管監(jiān)控，從而降低了交通事件應(yīng)急處理的及時(shí)性，延長(zhǎng)了應(yīng)急處置時(shí)間，加劇了意外事件造成的影響。

隧道內(nèi)發(fā)生突發(fā)事件時(shí)，需要緊急調(diào)配各類(lèi)應(yīng)急資源，特別是相當(dāng)一部分應(yīng)急資源還屬于社會(huì)化資源。但是，隧管所級(jí)的監(jiān)控系統(tǒng)無(wú)法實(shí)現(xiàn)跨區(qū)域、跨職能范圍的應(yīng)急資源管理和調(diào)配，交通誘導(dǎo)也需要上級(jí)部門(mén)統(tǒng)一組織。目前此類(lèi)工作大多以線下方式為主，現(xiàn)場(chǎng)處置、中心調(diào)度、決策指揮等工作相對(duì)獨(dú)立，缺乏統(tǒng)一的縱向、橫向間的指揮調(diào)度體系。

1.3 隧道集中管控需求

高速公路隧道需要建立集中的管控平臺(tái)，實(shí)現(xiàn)區(qū)域級(jí)或省級(jí)范圍內(nèi)隧道的統(tǒng)一管理，便于統(tǒng)一監(jiān)控預(yù)警、統(tǒng)一指揮調(diào)度。具體業(yè)務(wù)需求包括：

1.3.1 集中管理

對(duì)區(qū)域內(nèi)各隧管所的設(shè)備運(yùn)行狀況和人員進(jìn)行集中管理，通過(guò)信息化手段形成統(tǒng)一的隧道管理模式，實(shí)現(xiàn)精簡(jiǎn)人員、權(quán)責(zé)分明、決策迅速的目標(biāo)。

1.3.2 簡(jiǎn)化流程

通過(guò)管理界面整合簡(jiǎn)化操作，做到監(jiān)控?cái)?shù)據(jù)和設(shè)備控制一屏全包，所有監(jiān)控?cái)?shù)據(jù)一屏掌握，基于數(shù)據(jù)挖掘提供各類(lèi)輔助決策支持。

1.3.3 資源共享

實(shí)現(xiàn)對(duì)各隧管所通風(fēng)、照明、交通、消防等數(shù)據(jù)的實(shí)時(shí)采集和監(jiān)控，通過(guò)數(shù)據(jù)融合、質(zhì)量提升，可進(jìn)一步向其他部門(mén)共享分發(fā)。

1.3.4 統(tǒng)一接入

基于統(tǒng)一協(xié)議和數(shù)據(jù)接口進(jìn)行數(shù)據(jù)采集和交換，將原本分散的基礎(chǔ)數(shù)據(jù)和運(yùn)行數(shù)據(jù)進(jìn)行融合處理，滿(mǎn)足接口標(biāo)準(zhǔn)化、隧道統(tǒng)一接入的要求。

1.3.5 運(yùn)維高效

實(shí)時(shí)監(jiān)管隧道機(jī)電設(shè)備運(yùn)行情況，綜合評(píng)定隧道運(yùn)營(yíng)水平，為隧道運(yùn)維人員提供數(shù)據(jù)支撐，提升隧道機(jī)電運(yùn)維和巡檢工作的效率。

1.3.6 提升安全

應(yīng)急預(yù)案數(shù)字化，根據(jù)事件類(lèi)型及嚴(yán)重程度實(shí)現(xiàn)事件分級(jí)響應(yīng)，一鍵式啟動(dòng)應(yīng)急預(yù)案，調(diào)用大范圍應(yīng)急資源并進(jìn)行協(xié)同處置與指揮。通過(guò)信息無(wú)縫流轉(zhuǎn)，實(shí)現(xiàn)各系統(tǒng)快速聯(lián)動(dòng)，提高事件處置效率，減低事故損失。

2 平臺(tái)關(guān)鍵技術(shù)

2.1 海量實(shí)時(shí)數(shù)據(jù)處理

隧道內(nèi)監(jiān)控設(shè)備數(shù)量較多，單條隧道的開(kāi)關(guān)量、模擬量和結(jié)構(gòu)化數(shù)據(jù)的規(guī)模通常在幾千條/秒左右，區(qū)域級(jí)隧道管控平臺(tái)對(duì)于數(shù)據(jù)監(jiān)測(cè)和指令控制的響應(yīng)時(shí)間要求是1～3秒。因此，隨著區(qū)域內(nèi)接入隧道數(shù)量的增加，基于傳統(tǒng)架構(gòu)設(shè)計(jì)的數(shù)據(jù)交換平臺(tái)已不能滿(mǎn)足相應(yīng)性能要求。

平臺(tái)基于分布式消息隊(duì)列（Kafka）和分布式實(shí)時(shí)大數(shù)據(jù)處理系統(tǒng)（Storm）搭建大規(guī)模消息分發(fā)和實(shí)時(shí)數(shù)據(jù)流處理系統(tǒng)，滿(mǎn)足海量實(shí)時(shí)數(shù)據(jù)的采集和處理需求。Kafka作為中間件為數(shù)據(jù)提供緩沖機(jī)會(huì)，有效緩解數(shù)據(jù)采集和數(shù)據(jù)分析不同步的問(wèn)題；Storm是一套開(kāi)源的分布式實(shí)時(shí)計(jì)算系統(tǒng)，處理速度非?？欤瑔喂?jié)點(diǎn)可以達(dá)到百萬(wàn)個(gè)元組每秒，可以完成數(shù)據(jù)的實(shí)時(shí)計(jì)算處理。平臺(tái)邏輯層次架構(gòu)如圖2所示。

圖2 實(shí)時(shí)數(shù)據(jù)流處理邏輯層次架構(gòu)圖

如圖2所示，首先使用Nginx支撐的應(yīng)用服務(wù)來(lái)實(shí)現(xiàn)對(duì)隧管所監(jiān)控系統(tǒng)上傳海量數(shù)據(jù)的實(shí)時(shí)接收；然后Kafka集群將采集的數(shù)據(jù)放置到消息隊(duì)列中，實(shí)現(xiàn)數(shù)據(jù)緩沖，防止因數(shù)據(jù)量過(guò)大或者處理數(shù)據(jù)的集群效率不高而丟失數(shù)據(jù)；由Storm從Kafka集群消息隊(duì)列拉取數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行計(jì)算處理；最終，計(jì)算結(jié)果一方面存入Redis結(jié)果緩存中，提供前端應(yīng)用實(shí)時(shí)展示；另一方面持久化存儲(chǔ)進(jìn)分布式數(shù)據(jù)庫(kù)MySQL中，用于前端歷史數(shù)據(jù)統(tǒng)計(jì)分析展示。

2.2 數(shù)據(jù)接入標(biāo)準(zhǔn)接口

為規(guī)范不同隧道數(shù)據(jù)的統(tǒng)一接入，需要制定平臺(tái)數(shù)據(jù)接入的標(biāo)準(zhǔn)接口。各隧管所監(jiān)控系統(tǒng)作為下級(jí)平臺(tái)，負(fù)責(zé)對(duì)各自管理隧道設(shè)備的數(shù)據(jù)進(jìn)行統(tǒng)一匯聚，并按照標(biāo)準(zhǔn)接口接入?yún)^(qū)域中心平臺(tái)。

2.2.1 通信連接方式

中心平臺(tái)與下級(jí)平臺(tái)網(wǎng)絡(luò)通信采用TCP/IP方式，基于Socket方式建立連接，連接建立后持續(xù)保持，采用這種方式可減少網(wǎng)絡(luò)傳輸耗時(shí)。Socket連接由下級(jí)平臺(tái)作為客戶(hù)端，中心平臺(tái)作為服務(wù)端。中心平臺(tái)啟動(dòng)后處于等待連接狀態(tài)，下級(jí)平臺(tái)主動(dòng)發(fā)起連接請(qǐng)求，連接成功后雙方進(jìn)行雙工通訊，實(shí)現(xiàn)數(shù)據(jù)發(fā)送和接收。網(wǎng)絡(luò)中斷恢復(fù)后應(yīng)重新建立連接。

2.2.2 通信報(bào)文規(guī)范

通信數(shù)據(jù)報(bào)文采用二進(jìn)制格式，允許使用字符串和各種長(zhǎng)整型數(shù)據(jù)，浮點(diǎn)數(shù)以字符串表示，不包含小數(shù)點(diǎn)，末兩位為小數(shù)，存在字節(jié)順序問(wèn)題的數(shù)據(jù)類(lèi)型一律統(tǒng)一到網(wǎng)絡(luò)字節(jié)順序（低址高字節(jié)），避免跨平臺(tái)通信時(shí)出現(xiàn)問(wèn)題。報(bào)文數(shù)據(jù)需要進(jìn)行合規(guī)性校驗(yàn)，具體規(guī)則包括：版本號(hào)和幀頭長(zhǎng)度的合規(guī)性；報(bào)文中數(shù)據(jù)長(zhǎng)度與實(shí)際報(bào)文計(jì)算長(zhǎng)度是否一致；機(jī)構(gòu)編碼和保留字中的機(jī)構(gòu)代碼是否存在；加密方式是否符合要求。

2.2.3 報(bào)文傳輸要求

大數(shù)據(jù)包設(shè)計(jì)為分包發(fā)送，如果數(shù)據(jù)包與擴(kuò)展數(shù)據(jù)包的長(zhǎng)度大于65400字節(jié)則采用分包發(fā)送，即65535字節(jié)減去報(bào)文頭103字節(jié)和預(yù)留的32字節(jié)。壓縮報(bào)文的數(shù)據(jù)包長(zhǎng)度為壓縮后的長(zhǎng)度，數(shù)據(jù)包為壓縮后的包，壓縮算法采用標(biāo)準(zhǔn)的GZIP壓縮算法。報(bào)文傳輸前應(yīng)進(jìn)行加密、壓縮、分包處理，報(bào)文接收完畢后再反向處理，分包傳輸時(shí)應(yīng)按順序發(fā)送。

2.2.4 報(bào)文定義

通信管理類(lèi)報(bào)文：包括心跳檢測(cè)、公鑰獲取、加密傳輸、校正時(shí)間消息。

下級(jí)平臺(tái)上傳業(yè)務(wù)報(bào)文：包括氣象數(shù)據(jù)、交通流量數(shù)據(jù)、環(huán)境監(jiān)測(cè)數(shù)據(jù)、風(fēng)速風(fēng)向數(shù)據(jù)、照度亮度數(shù)據(jù)、設(shè)備狀態(tài)數(shù)據(jù)、情報(bào)板播放內(nèi)容、限速標(biāo)志數(shù)據(jù)、廣播音區(qū)狀態(tài)數(shù)據(jù)、視頻事件檢測(cè)數(shù)據(jù)、火災(zāi)報(bào)警數(shù)據(jù)、液位數(shù)據(jù)、電力數(shù)據(jù)等設(shè)備監(jiān)測(cè)數(shù)據(jù)，以及突發(fā)事件、養(yǎng)護(hù)施工、交通管制等上報(bào)信息。

中心平臺(tái)下發(fā)業(yè)務(wù)報(bào)文：包括設(shè)備操作指令、情報(bào)板信息發(fā)布指令、廣播音區(qū)控制指令、歷史數(shù)據(jù)上傳指令、預(yù)警消息、通知消息等。

2.2.5 平臺(tái)數(shù)據(jù)對(duì)接流程

中心平臺(tái)向申請(qǐng)接入的下級(jí)平臺(tái)分配11位單元編碼，按照接入標(biāo)準(zhǔn)開(kāi)展對(duì)接調(diào)試，平臺(tái)間數(shù)據(jù)流向如圖3所示。

圖3 平臺(tái)間數(shù)據(jù)流向圖

2.3 缺失數(shù)據(jù)補(bǔ)全

由于網(wǎng)絡(luò)通信偶發(fā)性中斷、設(shè)備數(shù)據(jù)采集失敗、數(shù)據(jù)解析出錯(cuò)等原因，會(huì)導(dǎo)致隧道監(jiān)控?cái)?shù)據(jù)在采集過(guò)程中出現(xiàn)缺失。數(shù)據(jù)缺失極大地影響后續(xù)數(shù)據(jù)分析的準(zhǔn)確性，因此需要對(duì)缺失值進(jìn)行處理，缺失值處理方法可采用策略包括刪除、填充、不處理。

隧道監(jiān)控?cái)?shù)據(jù)根據(jù)數(shù)據(jù)類(lèi)型進(jìn)行分類(lèi)，分別采用不同的數(shù)據(jù)缺失處理方法：

（1）對(duì)于定時(shí)采集的設(shè)備狀態(tài)及開(kāi)關(guān)量數(shù)據(jù)，主要用于設(shè)備狀態(tài)監(jiān)測(cè)。當(dāng)出現(xiàn)數(shù)據(jù)缺失時(shí)，下一周期采集的數(shù)據(jù)可繼續(xù)反映設(shè)備當(dāng)前情況，前一周期缺失數(shù)據(jù)不影響監(jiān)測(cè)功能。此類(lèi)含有缺失值的數(shù)據(jù)采用簡(jiǎn)單刪除法直接刪除即可。

（2）數(shù)據(jù)缺失有多種填充方法，根據(jù)數(shù)據(jù)特征情況主要采用均值填充和聚類(lèi)填充兩種方法。

1）均值填充。對(duì)于一氧化碳濃度、風(fēng)速、液位等單一模擬量數(shù)據(jù)，數(shù)據(jù)一般是線性變化的，因此適合采用均值填充法補(bǔ)全缺失數(shù)據(jù)?？蛇x取缺失項(xiàng)前后各3個(gè)采樣周期的數(shù)據(jù)，計(jì)算數(shù)學(xué)均值填充到缺失樣本。

2）聚類(lèi)填充。對(duì)于交通流量、車(chē)速、占有率等結(jié)構(gòu)化數(shù)據(jù)包類(lèi)型的數(shù)據(jù)，由于和歷史數(shù)據(jù)相比有較大的類(lèi)似性，因此適合采用聚類(lèi)填充法補(bǔ)全缺失數(shù)據(jù)。選取前后一段時(shí)間及歷史相同時(shí)間段的數(shù)據(jù)，用非缺失字段作為特征值，對(duì)特征數(shù)據(jù)歸一化后，采用K-means算法進(jìn)行聚類(lèi)分析，然后計(jì)算缺失數(shù)據(jù)與每個(gè)聚類(lèi)簇中心的相似度，選取最相似的簇的屬性均值填充給該缺失項(xiàng)。

（3）缺失數(shù)據(jù)不處理是指在原數(shù)據(jù)上直接進(jìn)行數(shù)據(jù)挖掘，采用貝葉斯網(wǎng)絡(luò)、人工神經(jīng)網(wǎng)絡(luò)、粗糙集等方法，由于模型過(guò)程復(fù)雜，存在指數(shù)爆炸的危險(xiǎn)，本文不涉及此類(lèi)方法。

3 平臺(tái)系統(tǒng)設(shè)計(jì)

3.1 邏輯架構(gòu)設(shè)計(jì)

平臺(tái)采用分層架構(gòu)設(shè)計(jì)，包括設(shè)備層、網(wǎng)絡(luò)層、數(shù)據(jù)層、支撐層、應(yīng)用層、用戶(hù)層，以及信息安全保障體系和接口通信標(biāo)準(zhǔn)規(guī)范保障體系，如圖4所示。

圖4 平臺(tái)邏輯架構(gòu)圖

（1）設(shè)備層。包含隧管所內(nèi)各類(lèi)系統(tǒng)和隧道前端采集設(shè)備，如：攝像頭、風(fēng)機(jī)、照明、一氧化碳能見(jiàn)度檢測(cè)器、車(chē)道指示器、火警檢測(cè)器、車(chē)檢器等。

（2）網(wǎng)絡(luò)層。主要通過(guò)光纖網(wǎng)、視頻專(zhuān)網(wǎng)等完成數(shù)據(jù)傳輸，為數(shù)據(jù)層提供數(shù)據(jù)傳輸通道。

（3）數(shù)據(jù)層。實(shí)現(xiàn)對(duì)隧管所現(xiàn)有系統(tǒng)數(shù)據(jù)的采集、存儲(chǔ)與數(shù)據(jù)交換，為應(yīng)用層提供數(shù)據(jù)支撐。

（4）支撐層。提供統(tǒng)一用戶(hù)管理、數(shù)據(jù)交換引擎、日志服務(wù)、安全管理等功能，為各類(lèi)應(yīng)用提供基礎(chǔ)支撐。

（5）應(yīng)用層。主要實(shí)現(xiàn)各類(lèi)應(yīng)用及分析功能，為用戶(hù)提供統(tǒng)一的可視化監(jiān)控平臺(tái)。

（6）用戶(hù)層。是平臺(tái)的使用對(duì)象，平臺(tái)可根據(jù)權(quán)限在管理公司、區(qū)域中心和隧管所分級(jí)使用。

信息安全保障體系是支撐平臺(tái)安全運(yùn)行的各類(lèi)措施，接口通信標(biāo)準(zhǔn)規(guī)范保障體系用于統(tǒng)一數(shù)據(jù)接口和數(shù)據(jù)交互標(biāo)準(zhǔn)。

3.2 物理架構(gòu)設(shè)計(jì)

平臺(tái)設(shè)計(jì)至少采用15臺(tái)服務(wù)器，組成局域以太環(huán)網(wǎng)（采用TCP/IP通信協(xié)議），部署在高速公路區(qū)域中心或省中心，通過(guò)高速公路監(jiān)控專(zhuān)網(wǎng)與各隧管所監(jiān)控系統(tǒng)進(jìn)行數(shù)據(jù)交互。服務(wù)器使用實(shí)體物理機(jī)或虛擬機(jī)均可，采用分布式架構(gòu)，可根據(jù)接入隧道的數(shù)量動(dòng)態(tài)擴(kuò)充。平臺(tái)物理架構(gòu)如圖5所示。

圖5 平臺(tái)物理架構(gòu)圖

3.3 功能設(shè)計(jì)

平臺(tái)的主要功能包括應(yīng)急待辦、運(yùn)營(yíng)展示、隧道監(jiān)控、智慧應(yīng)急、養(yǎng)護(hù)巡檢、運(yùn)維管理、統(tǒng)計(jì)分析、平臺(tái)管理、數(shù)據(jù)接入等。

3.3.1 應(yīng)急待辦

通過(guò)統(tǒng)一認(rèn)證服務(wù)和統(tǒng)一應(yīng)用授權(quán)，將日常工作按照應(yīng)辦和待辦分類(lèi)進(jìn)行集中展示和提醒。

3.3.2 運(yùn)營(yíng)展示

對(duì)隧道設(shè)備運(yùn)行情況、人員運(yùn)維養(yǎng)護(hù)情況、應(yīng)急指揮數(shù)據(jù)、過(guò)車(chē)數(shù)據(jù)和重點(diǎn)區(qū)域氣象數(shù)據(jù)匯聚融合，通過(guò)線形圖、圓餅圖、折線圖等綜合數(shù)據(jù)展示方式，形成隧道運(yùn)營(yíng)管理“一張圖”。

3.3.3 隧道監(jiān)控

實(shí)現(xiàn)對(duì)隧道各子系統(tǒng)的集成監(jiān)控，根據(jù)隧道內(nèi)監(jiān)控?cái)?shù)據(jù)，調(diào)控相關(guān)設(shè)備的運(yùn)行狀況，包括隧道交通監(jiān)控、環(huán)境監(jiān)控、視頻監(jiān)控、火災(zāi)監(jiān)控及消防、照明監(jiān)控、電力監(jiān)控等。

3.3.4 智慧應(yīng)急

實(shí)現(xiàn)應(yīng)急預(yù)案的統(tǒng)一管理，包括救援預(yù)案、繞行預(yù)案、協(xié)同預(yù)案、應(yīng)急資源管理和預(yù)案評(píng)價(jià)等功能。提供隧道內(nèi)智能監(jiān)測(cè)報(bào)警及其他相關(guān)單位報(bào)警事件的接收及確認(rèn)，事件等級(jí)研判、事件跟蹤、應(yīng)急預(yù)案聯(lián)動(dòng)、指揮協(xié)調(diào)調(diào)度、應(yīng)急信息發(fā)布、應(yīng)急處置評(píng)估等功能。

3.3.5 養(yǎng)護(hù)巡檢

對(duì)隧道日常和專(zhuān)項(xiàng)養(yǎng)護(hù)工作進(jìn)行管理，包括養(yǎng)護(hù)項(xiàng)目管理、養(yǎng)護(hù)計(jì)劃制定、養(yǎng)護(hù)排班、巡檢工作記錄及考核、工程檔案管理、養(yǎng)護(hù)知識(shí)庫(kù)等功能。

3.3.6 運(yùn)維管理

實(shí)現(xiàn)對(duì)隧道機(jī)電設(shè)備的故障監(jiān)測(cè)、資產(chǎn)管理、保養(yǎng)維修、備件管理等。

3.3.7 統(tǒng)計(jì)分析

根據(jù)不同業(yè)務(wù)應(yīng)用場(chǎng)景，通過(guò)圖表全方位分析隧道運(yùn)行情況，為運(yùn)營(yíng)決策和應(yīng)急處置提供數(shù)據(jù)支撐。

3.3.8 平臺(tái)管理

提供組織結(jié)構(gòu)管理、用戶(hù)權(quán)限管理、部署及流程管理、操作日志記錄等平臺(tái)基礎(chǔ)管理功能。

3.3.9 數(shù)據(jù)接入

對(duì)隧道監(jiān)控設(shè)備的數(shù)據(jù)編碼、數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)格式、通信傳輸接口等進(jìn)行統(tǒng)一規(guī)范，通過(guò)平臺(tái)與各隧管所監(jiān)控系統(tǒng)的數(shù)據(jù)交互，實(shí)現(xiàn)數(shù)據(jù)采集、過(guò)濾、存儲(chǔ)及指令發(fā)布。

4 平臺(tái)實(shí)現(xiàn)

4.1 軟硬件配置

服務(wù)器、系統(tǒng)軟件、開(kāi)發(fā)環(huán)境清單如表1所示。

表1 服務(wù)器、系統(tǒng)軟件、開(kāi)發(fā)環(huán)境清單

4.2 實(shí)現(xiàn)效果

平臺(tái)在寧夏、青海等省份實(shí)際落地應(yīng)用。寧夏和青海均采用“隧管所-區(qū)域中心-省級(jí)路網(wǎng)中心”的運(yùn)營(yíng)管理體制，寧夏高速公路隧道集中管控平臺(tái)接入全自治區(qū)高速公路隧道29座，青海高速公路隧道集中管控平臺(tái)接入全省高速公路隧道81座，區(qū)域中心負(fù)責(zé)對(duì)轄區(qū)內(nèi)的隧道進(jìn)行集中監(jiān)控，省中心負(fù)責(zé)全省隧道運(yùn)營(yíng)工作監(jiān)管和跨區(qū)域協(xié)同調(diào)度。平臺(tái)綜合運(yùn)營(yíng)分析功能界面如圖6所示，在寧夏高速公路隧道集中管控場(chǎng)景的應(yīng)用測(cè)試數(shù)據(jù)如圖7所示。

圖6 寧夏高速公路隧道集中管控平臺(tái)綜合運(yùn)營(yíng)分析軟件界面

圖7 寧夏高速公路隧道集中車(chē)流量及數(shù)據(jù)處理時(shí)間

經(jīng)實(shí)際應(yīng)用測(cè)試，在采用8核16G服務(wù)器，Nginx、Kafka、Redis、MySQL、前端應(yīng)用各分配2臺(tái)服務(wù)器，Storm分配3臺(tái)服務(wù)器的環(huán)境下，每秒處理一百萬(wàn)條消息時(shí)，服務(wù)器CPU占用率平均在30%左右，消息響應(yīng)延時(shí)1秒左右，如圖7所示單日通過(guò)隧道的車(chē)流量比較穩(wěn)定，車(chē)輛通過(guò)時(shí)系統(tǒng)對(duì)數(shù)據(jù)的處理時(shí)間保持比較穩(wěn)定的狀態(tài)，完全滿(mǎn)足平臺(tái)運(yùn)營(yíng)需求。

5 結(jié)語(yǔ)

本文結(jié)合隧道“集中監(jiān)控”管理模式，設(shè)計(jì)區(qū)域級(jí)高速公路隧道集中管控平臺(tái)，實(shí)現(xiàn)對(duì)大批量隧道的集中監(jiān)控管理，滿(mǎn)足高速公路區(qū)域中心、省中心隧道運(yùn)營(yíng)集中管理業(yè)務(wù)需求。通過(guò)實(shí)際項(xiàng)目驗(yàn)證表明，本文設(shè)計(jì)的區(qū)域級(jí)高速公路隧道集中管控平臺(tái)可有效解決海量數(shù)據(jù)采集處置延遲高、標(biāo)準(zhǔn)不統(tǒng)一、數(shù)據(jù)缺失等問(wèn)題，在功能、性能等方面均可滿(mǎn)足技術(shù)要求，可切實(shí)提升隧道運(yùn)營(yíng)管控和服務(wù)水平。下一步，將結(jié)合數(shù)字孿生、雷視融合、事件智能檢測(cè)、多源感知等技術(shù)開(kāi)展研究，提升隧道智能化管控能力。