地鐵信號系統大數據智能分析平臺的開發及應用

弓行

（北京京港地鐵有限公司，北京 100068）

目前，行業內各信號系統承包商對各自的信號系統智能運維平臺的技術開發已較為成熟，在各城市地鐵新建線路中均有較多應用，為運營維護工作中提高設備穩定性及維修質量方面起到了較為關鍵的作用，但信號系統智能運維平臺均需隨新線建設施工同時搭建，而在成熟線路中信息化改造費用較高，性價比低下，且成熟線路中的傳統以人為導向的粗放型維護模式在安全保障、質量控制、故障管理、維護支持等方面已經不適應新的運營環境。在《國家智能制造標準體系建設指南》中指出運維是智能服務的核心內容。為實現降本增效，充分發揮技術人員潛力，以企業文化“Can do”為驅動，深入挖掘信號日志報警數據信息并通過海量報警數據預測及定位信號系統中的各類故障，亟待引入信息化技術，開發一套適用于成熟地鐵線網環境下的信號大數據智慧型分析運營維護管理平臺。

1 系統設計概況及架構

本信號系統通過ATS（列車自動監控系統）工作站僅可查詢近1個月的報警信息，信息直接導出后為.pdf格式，不能進行二次編輯，也不具備數據信息統計分析功能。人工解析存在難度大、成本高、效率低等痛點，且易出現關鍵數據漏統計等問題，嚴重影響分析結果。NMS（網絡管理系統）日志內容為.txt格式，以毫秒級收集全線的數據通信信息，數據量大，無法開展人工統計分析。這兩類日志中存在較多冗余報警，無法通過人工為現場提供精確判斷各設備狀態、隱患的幫助，基于以上痛難點，故開發一套適用于本信號系統的智能運維系統。

ATS詳細數據存于DB（數據庫）服務器，內容為.dlg格式，以32節字段的數字代碼呈現。前期通過核對ATS報警信息、回放，分析出DB日志中的某個字段代碼所代表的具體故障名稱，并生成報警數據對應解碼表。通過采用Navicat Premium數據庫開發工具，將報警信息模塊化后的數據導入基礎數據庫，生成結構化數據。通過永洪BI工具對報警信息數據庫進行調用，根據不同的報警種類及數量，呈現出全周期可視化的大數據分析平臺。如圖1所示，主界面用于大屏展示，集中顯示信號系統運營狀態、各類設備故障統計，對重點關系的故障通過不同維度進行統計分析。通過人機交互界面，展示出ATS工作站、NMS工作站所記錄的ATS、NMS日志中的關鍵報警信息，通過柱狀圖、餅狀圖的方式呈現維護人員特別關注的報警種類；以日報表、月報表及自由設定時間段內的形式統計報警類型及數量；用故障占比突出目前急需關注的某類設備狀態。通過大數據實現設備狀態趨勢分析及預測，在此基礎上，將之前的維護經驗轉換為專家維修知識庫，通過點擊某一條報警信息，即可跳轉界面給出相應的故障處理策略，基本實現故障預測、主動指導維修的功能，實現一定程度上的智能運維功能。

圖1 平臺主界面

1.1 硬件架構

硬件配置如圖2所示，在車輛段備用控制中心設立一臺用于運行大數據分析平臺的信號日志服務器，采用惠普DL388 GEN10存儲服務器存儲數據庫，信號日志服務器通過TCP/IP協議與骨干網交換機連接，經由防火墻、骨干網交換機、核心交換機訪問ATS工作站、NMS工作站和DB服務器中的日志信息，通過信號日志服務器對數據進行處理后再上傳到智能運維工作站。后期可通過視頻矩陣，上傳到工程控制中心大屏全景展示運維數據。

圖2 硬件配置

全線設備集中站與非設備集中站均可通過網絡遠程訪問信號日志服務器，通過IE瀏覽器登錄本智能運維平臺。非設備集中站可通過通信系統的SDH（同步數字體系）網絡采用VPN模擬點對點專用鏈接的方式訪問日志服務器。設備集中站可通過信號系統的DCS網絡，接入骨干網交換機訪問日志服務器。設備集中站及非設備集中站用戶均可在本地終端選擇其管轄范圍內的某一站的某一臺軌旁設備運維信息，查看實時數據、查詢歷史數據等信息，實現對報警信息調用及訪問專家庫，快速獲取報警對應的故障處理指導建議。

1.2 軟件架構

如圖3所示，本系統由“數據接口層”“數據處理層”“業務應用層”及“展示服務層”4個層面組成。數據接口層包含VOBC（車載控制器）、道岔、PMI（軌旁聯鎖）、計軸設備、AP（無線接入點）等設備信息，所有報警信息可通過有線網絡實時上傳或使用U盤導入指定文件夾，為平臺提供數據源。數據處理層結和報警解碼表進行比對，通過編寫kettle腳本，不斷測試數據準確性前提下，實現將日志中關鍵報警信息提取出來，生成數據庫報表。通過MySQL數據庫將數據進行清洗、優化、緩存和入庫，并將入口數據打包分發，供上層模塊調取、處理和分析，如圖4所示。業務應用層包含必要的專家維修知識庫、統計報表、各關鍵設備的故障預測、分析模型及支持策略導入功能。以上所述軟件層最終實現“全景展示”“故障統計”“狀態檢測”等功能。且不同用戶可以根據用戶實際權限進行功能切換，避免非授權人員對后臺數據進行訪問。

圖3 系統技術框架

圖4 數據分發邏輯

2 功能實現

2.1 可視化

系統提供對全線所有信號設備狀態及報警的實時監測，為用戶提供頂層運維數據的全景展示，統計、展示設備可靠度、故障占比情況、關鍵設備狀態趨勢等內容以及可自由配置顯示內容，提供歷史數據的調取和分析預測，并可以統計表及圖片的形式導出保存。

2.2 大數據

本系統可實現將現場采集到的大量日志數據存于數據庫中長期保存，為用戶提供不同時間維度的查詢分析及可靠的數據背景進行參照，及歷時數據的調取。提供設備運行規律分析、充分挖掘日志信息、多子系統關聯分析、專項主題分析等功能。根據設備種類（列車、軌旁、ATS等）按照不同的報警等級進行分布存儲，分別顯示VOBC、道岔、聯鎖、計軸等設備在當天、當月、固定時間段上的所有報警分布，可下鉆到設備本月故障報警分析情況，也可下鉆到具體設備任意一天報警分布情況。

2.3 故障預測

對信號系統故障數據進行建模分析，系統根據信號各類報警建立不同維度的日志分析模型，可根據各類報警采集到的總數即時關聯分析，通過對設備性能監控給出設備狀態趨勢和彈出智能告警。通過預留模型導入接口，將預定的故障模型及設備前置條件導入系統，通過匹配可快速檢出設備異常情況，可以完整復現系統運行的實際情況和命令執行的鏈路信息，對信息傳遞的內容和時序進行分析，準確給出設備隱患部位，方便現場人員切入故障點。對保障設備全壽命周期內的高可靠性與低故障率發揮著重要作用。

2.4 專家知識庫

專家知識庫對每一種報警和故障提出維修建議，并針對實際維護或維修的故障定位和維修步驟對維修建議進行更新優化。系統通過建立針對典型故障原因和處理建議相關聯的專家知識庫來協助現場人員快速處置故障和排除設備隱患，將實踐過程中形成的經驗進行模塊化，并用實際數據進行自動化的驗證和迭代，從而形成相應的工具模塊，當系統檢測到設備故障時，根據匹配規則,自動在專家知識庫中查找典型故障案例，向現場人員推送故障原因、故障位置及詳細的故障處置方案，避免因人員水平參差不齊而導致故障無法及時有效的得到解決。

3 系統應用舉例

3.1 信標丟失故障

如圖5所示，通過ATS日志解析出列車的信標丟失信息，默認按月顯示列車信標丟失狀態，以列車編號為橫坐標，計軸段為縱坐標，可直觀明了的得出所有列車的信標丟失程度。且可通過不同維度的信標丟失場景進行分析，如按列車丟標分析、按計軸段分析、按時期分析、按定位信標分析，得出不同列車與不同信標丟標相關性、軌道信標性能以及車載信標接收器性能是否有減弱趨勢的結論。

現場人員根據專家知識庫給出的處理建議，快速準確定位到設備故障部分。以下圖為例，JZD2219（計軸段）單區間丟失信標次數較多，36號車單列車丟失信標次數較多，顯而易見的突出列車及信標的故障隱患。現場人員可按專家知識庫及時針對JZD2219的信標及36號車進行相應的故障處理，將列車丟失信標從而導致丟失位置隱患排除。表1列出專家知識庫給出的信標丟失故障原因及處理建議。

表1 信標丟失專家知識庫

3.2 列車通信故障

如圖6所示，通過NMS日志解析出不同列車的通信丟失次數、列車與AP通信中斷時的相對位置、離開本控區通信區域與下一個控區建立通信的時機，對三個維度進行分析。充分直觀的描繪出整個車地無線通信系統的運行狀態和質量，并以此發現故障趨勢。平臺有效分析通信中斷故障原因，直接定位到車載無線鏈路故障、軌旁AP故障或控區通信故障。

以圖6為例，JZD5013單區間通信丟失次數與其他區間相比較多，顯然突出此區間有AP通信不良，需進行深入分析某個AP工作狀態。現場人員可按專家知識庫快速準確定位到設備的工作不穩定問題，將列車在此區間造成通信丟失從而引發緊急制動的隱患排除。表2列出專家知識庫給出的通信中斷故障原因及處理建議。

圖6 通信中斷情況

表2 通信中斷專家知識庫

4 結語

鑒于篇幅有限，本文未能將所有報警信息數據分析界面一一展示。通過實際應用，本平臺已基本滿足地鐵信號系統通過大數據分析從而開展智能運維的需求，達到提高信號設備可維修性、優化既有維修策略、節約人力成本的目標，對保障信號系統的安全、穩定運行具有重要意義。后期可按需集成車輛、供電、通信和機電等其他運營相關專業系統的運維數據，提高跨系統的故障分析和維護指揮能力。