區(qū)域級高速公路隧道集中管控架構(gòu)研究與實現(xiàn)

郝建明，劉天鵬

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

0 引言

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

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

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

1 需求分析

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

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

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

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

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

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

1.3 隧道集中管控需求

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

1.3.1 集中管理

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

1.3.2 簡化流程

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

1.3.3 資源共享

實現(xiàn)對各隧管所通風(fēng)、照明、交通、消防等數(shù)據(jù)的實時采集和監(jiān)控，通過數(shù)據(jù)融合、質(zhì)量提升，可進(jì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)行融合處理，滿足接口標(biāo)準(zhǔn)化、隧道統(tǒng)一接入的要求。

1.3.5 運(yùn)維高效

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

1.3.6 提升安全

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

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

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

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

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

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

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

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

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

2.2.1 通信連接方式

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

2.2.2 通信報文規(guī)范

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

2.2.3 報文傳輸要求

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

2.2.4 報文定義

通信管理類報文：包括心跳檢測、公鑰獲取、加密傳輸、校正時間消息。

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

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

2.2.5 平臺數(shù)據(jù)對接流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 功能設(shè)計

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

3.3.1 應(yīng)急待辦

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

3.3.2 運(yùn)營展示

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

3.3.3 隧道監(jiān)控

實現(xiàn)對隧道各子系統(tǒng)的集成監(jiān)控，根據(jù)隧道內(nèi)監(jiān)控數(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)急

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

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

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

3.3.6 運(yùn)維管理

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

3.3.7 統(tǒng)計分析

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

3.3.8 平臺管理

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

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

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

4 平臺實現(xiàn)

4.1 軟硬件配置

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

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

4.2 實現(xiàn)效果

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

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

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

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

5 結(jié)語

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