服務于地鐵運營的車輛智能運維系統研究及應用

摘" 要：隨著地鐵列車通信不斷發展和軌道交通車輛設備智能化程度的不斷提高，地鐵運營對通過智能化技術改變運營方式也越來越迫切，這對車輛智能運維運用提出更高的要求。該文研究地鐵車輛運營的需求，深入分析智能化技術提升地鐵運營效率可行性，設計服務列車運營的車輛智能運維系統。

關鍵詞：地鐵運營；智能化；車輛智能運維；軌道交通；大數據技術

中圖分類號：U279.32" " " 文獻標志碼：A" " " " " 文章編號：2095-2945（2023）15-0026-04

Abstract： With the continuous development of metro train communication technology and the continuous improvement of the intelligent means of equipment for rail transit vehicles， the metro operation has also become increasingly urgent in changing the operation mode through intelligent technology， which poses higher requirements for the intelligent operation and maintenance of metro. This paper studies the demand for the metro operation， analyzes the feasibility of intelligent technology to improve metro operation efficiency， and thus designs an intelligent metro operation and maintenance system.

Keywords： metro rail transit vehicles; intelligence; vehicle intelligent operation and maintenance; rail transit; big data technology

隨著大數據技術不斷發展，以地鐵車輛為代表的軌道交通裝備的智能化程度也越來越高，大數據、物聯網、5G等技術也在車輛感知、專家診斷領域獲得了越來越多的應用，使得更多的車輛數據可以被采集、傳輸，故障可以被診斷、預測，為車輛運營的智能化運維化奠定了基礎[1]。而軌道交通行業是注重安全、效率的行業，但傳統運營管理存在部分缺陷，調度難以掌握車輛的運行狀況，司機和地面溝通成本高、效率低，正線地鐵一旦出現故障，故障分析時間長。本文主要研究地鐵車輛運營的需求，深入分析車輛智能運維技術如何實現，并匹配地鐵運營管理模式，提升運營管理效率。

1" 需求分析

傳統地鐵車輛正線運營時，車輛一旦發生故障，正線司機進行相關緊急操作，如果車輛故障不能復位，立刻通知行車調度（OCC），并把相關問題、車輛當時狀態描述給OCC，OCC行車調度通知車輛段或者停車場檢修調度，檢修調度根據行車調度的描述，推薦相關的緊急操作；如果3～5 min以內司機未能根據指示恢復，可能導致列車晚點、嚴重甚至清客下線。針對正線的故障，技術人員需要待車回庫后，上車拷貝數據，并通過專用軟件分析，最后給出故障分析報告，安排相關廠家進行檢修。該傳統的地鐵運營模式存在以下缺點。

1）正線司機處理故障的時間寶貴，正線司機故障處置時間通常只有3～5 min，時間范圍之內未及時恢復車輛進行清客下線處理；但通常3～5 min時間內都是處于司機、OCC行車調度、檢調調度溝通中，并且很難準確、有效傳達車輛狀態、故障前后現象。根據以往運營統計，很多列車晚點是由于信息互相傳達不準確、溝通時間較長，從而造成車輛晚點

2）司機按照指導處理過程中，難以實時掌控司機處理的是否有問題，無法中途快速干預。

3）故障事件后無法第一時間快速獲取列車運行數據，通常都是等待列車回庫才能下載數據，存在大量的等待時間，特別是一些緊急、突發安全故障，如果無法第一時間處理，則會影響地鐵運營公共形象。

4）數據下載后，需要組織不同專業技術人員分析原因，通常至少需要1 d的時間提供故障分析報告，影響列車。

針對傳統模式現狀，迫切需要搭建一套車輛智能運維系統。故障觸發時，檢修調度第一時間、快速掌握故障及其關鍵系統信息，地面DCC調度快速為司機提供解決方案、針對司機操作不準確的地方及時干預，事后短時間內支撐技術人員快速分析，實現售后人員上車不拷貝數據，通過地面車輛智能運維平臺分析，并提供故障分析報告，車輛回庫前，檢修人員提前準備相關的工具、備件，并進行工單通知，檢修工作提前準備。

2" 詳細設計

車輛智能運維整體設計包括車地數據傳輸、地面故障報警、故障引導、應急場景、故障快速分析和故障詳細分析。

2.1" 車地數據傳輸

車輛車載安裝無線傳輸設備，設備具備MVB板卡、以太網板卡，并接入列車控制網絡、車輛維護以太網，通過2個網絡采集整車及車載設備的狀態、故障相關數據；無線傳輸接入車地無線傳輸網絡，并通過車地傳輸通道按照TCP、FTP接口發送回地面車輛智能運維平臺[2]。

車廂攝像頭視頻統一匯入車載CCTV視頻主機，視頻主機接入車地無線傳輸網絡，支持地面軟件平臺按照RSTP接口調取攝像頭視頻流（見表1）。

2.2" 地面故障告警

2.2.1" 故障聲光報警

系統識別車輛故障信息，并根據故障的影響程度，DCC觸發不同級別的進行聲光報警提醒，針對影響行車安全的時間并鳳鳴，保障故障發生的第一時間調度人員進行識別，減少司機和地面溝通時間。故障提醒方式按照是否影響行車安全分成三類（表2）。

2.2.2" 不同車輛段故障提醒方式

針對單條地鐵線運營線路，所有故障的報警都由車輛段DCC進行呈現。針對車輛在不同線路混跑，需要考慮當前車輛所跑線路、軌旁檢測設備所屬線路。如果車輛當前跑線路A，則一般當天都跑線路A；如果多線路存在共線部分，以車輛首次到達非共線部分判定當前所跑線路。該線路車輛段的平臺報警只顯示當前線路所跑的車輛。車輛經過軌旁設備報告的故障，判斷軌旁設備所歸屬的車輛段，該車輛段平臺進行報警。

1）車載、預警類彈窗故障。根據車輛發生故障時的實際線路或段場位置，匹配不同的段場系統賬號進行彈窗信息的區分展示。

2）軌旁檢測類彈窗故障。根據軌旁設備在線路或段場的實際檢測位置，匹配不同的段場系統賬號進行彈窗信息的區分展示。

2.3" 故障引導

通過部署在DCC的聲光報警器、系統顯示大屏快速提醒DCC調度人員車輛正線運營發生故障，調度人員進入系統后，系統根據不同故障場景匹配不同引導方案，引導調度人員獲取不同類型的故障相關信息，輔助調度人員或者技術人員分析、決策（表3）。

整個故障觸發、引導調度/技術人員的流程見表4。

2.4" 應急場景

針對影響列車動車的故障，司機會匯報調度，根據調度的建議進行緊急操作，傳統模式不能掌握司機故障恢復進度、當前旁路操作，如果司機操作不當地面無法及時干預。

根據不同影響動車故障場景的司機處置步驟，轉化成網絡IO及司機操作旁路。當某應急場景觸發時，系統監聽IO/旁路狀態，自動識別當前應急所處步驟、當前哪一個IO或者旁路和應急不符合，待操作處理。當司機操作系統提示報警，調度DCC反饋司機進行相關操作，系統自動記錄并識別司機的操作是否有問題，如果存在異常系統進行報警提前干預[3]（表5）。

2.5" 故障快速分析

針對正線未恢復的故障，需要技術人員快速給出故障初步調查報告，傳統模式下需要等車輛回庫，如果是輕微故障，甚至要等到車輛回庫才能下載數據。

基于部件設計、檢修、部件廠家經驗，將每一個故障同列車信號形成關聯，包括故障設計的判斷邏輯、跨系統分析所需數據的排查、縮小部件排查范圍的采集數據、故障伴隨情況，最終形成基于實時數據的故障快速分析專家系統，同時支持基于時間、空間故障前后5 min的專家經驗參數趨勢變化，第一時間快速輔助技術分析故障，解決60%～70% 正線故障可以快速定位，短時間給出分析報告（表6）。

2.6" 故障詳細分析

針對部分復雜的故障，基于實時故障分析無法確切給出分析報告，需要更高頻率的采樣數據深入分析，車載采集故障前后3～5 min的相關高頻信號，打包發給車載無線傳輸設備，傳輸設備監聽收到的故障采樣數據，將傳輸故障采樣數據優先級升至最高，優先傳輸該類數據，保障故障深度分析的數據10 min內自動下載。相關故障文件及數據通過集成在平臺的各專業故障分析工具，實現故障相關信號趨勢分析，輔助技術人員決策。

3" 技術設計

軟件設計包括車載軟件設計、地面軟件設計。車載軟件主要用于收集車輛故障、狀態相關數據，傳輸至地面系統；地面軟件主要利用車載數據進行監控、分析、故障處置等。

3.1" 車載設計

車輛一般配置無線傳輸設備，接入列車MVB網、維護以太網、PIDS網絡。無線傳輸設備通過MVB網和維護以太網獲取列車數據，通過PIDS通道傳輸至地面服務器。

無線傳輸設備支持TCP、FTP傳輸協議，TCP協議用于實時列車數據、故障傳輸，FTP協議用于列車信號高頻率采樣數據傳輸。

3.2" 軟件架構設計

車輛智能運維系統整體分為數據采集、數據存儲、數據計算和數據應用模塊[4]。

數據采集負責收集車載實時數據、車載文件數據、其他第三方數據；數據存儲將采集與加工、處理后的數據按業務劃分存儲，為上層業務調取提供支持；數據計算模塊利用存儲的數據，經過解析、整合運算，為數據應用提供服務；數據應用模塊主要包括可視化應用與數據服務，為用戶與第三方提供界面與數據能力。

3.2.1" 列車數據采集

系統采用Flume作為采集工具，實現車輛數據實時與離線的采集。實時數據采集采用TCP作為傳輸協議，實現車載數據實時數據傳輸，數據清洗后以數據流形式發送Kafka存儲，并共享提供第三方進行訂閱消費。離線數據采用FTP協議，實現列車相關傳感器、故障高頻文件采集接收。

3.2.2" 車輛數據存儲

為存儲列車所有數據平臺采用多種混合存儲技術，主要針對實時業務、顯示數據業務、離線分析業務和大批量原始數據。①實時原始數據存儲。實時數據存儲在Kafka數據池，用于提供平臺實時計算數據源。Kafka主要提供數據共享通道，包括整車信號數據、關鍵系統監控數據、車載子系統數據。第三方可以通過kafka數據池獲取實時數據。②實時業務數據存儲。計算資源從kafka獲取原始數據，針對列車實時數據展示的業務，平臺將數據轉換成鍵值對數據形式，存放內存數據庫Redis，Redis支持大量、快速的實時業務調取，同時會周期性地把更新的數據寫入磁盤存儲。內存數據監測到車輛數據變化時，比如速度、溫度、故障的變化時，及時推送至前端系統顯示。③列車部件明細數據存儲。車輛詳細數據包括牽引、制動、空調、車門、走行部和網絡等關鍵部件信息，每個系統有大量自身設備監測信息，包括狀態、故障、傳感器采集用于預測的數據，這類數據主要用于故障回朔、數據分析、專家診斷和預警，針對這類非實時業務，需要大量明細數據分析、匯總平臺采用大數據數據庫HBase存儲，HBase主要存儲了車輛原始數據，車輛業務所需數據，列車主要系統數據。④業務結果存儲。經過平臺大數據運算后的結果，比如應急相關分析結果，故障/預警分析、故障的統計相關結果，使用結構化數據庫MySQL存儲，避免業務調用數據時平臺重新進行大數據運算。同時支持前端顯示系統所需數據調取。

3.2.3" 數據計算

①實時數據計算。實時數據計算利用SPARK-STREAMING計算引擎[5]進行數據計算、整合，解析列車網絡中實時監測的數據，包括整車、關鍵部件的傳感器采樣數據、故障數據等，處理完將運算結果推送到數據庫存儲，用于后續的數據呈現。②離線計算。針對大量列車跨時間、跨空間的離線分析，比如系統趨勢分析、可靠性分析等，需要通過歷史數據處理，利用Hive工具進行離線數據處理。Hive主要將非結構化數據轉化成結構化數據，進行邏輯處理，并提供完整的數據查詢功能，同時將用戶的查詢語句轉換為大數據離線處理MapReduce離線任務進行運算。

4" 結束語

文章分析了地鐵運營的對于正線故障處理傳統模式的缺陷，車輛智能運維運用與地鐵運營關于故障處理流程的契合點，設計了服務于地鐵運營的車輛智能運維系統，很大程度提高了正線故障處置、分析效率。實際車輛智能運維系統建設過程中，比較受限于車地傳輸通道質量，當車地通信質量不理想時，車輛實時工況、故障的快速分析功能會受限，可以根據線路通信具體情況，考慮車輛智能運維優化運營的具體方面。

參考文獻：

[1] 吉敏.基于大數據的專家系統在地鐵智能運維方面的應用研究[J].計算機產品與流通，2017（11）：74.

[2] 杜永蘋，岳凡，馮曉容，等.軌道交通在線監測專用無線傳輸系統研究[J].無線通信技術，2020，29（4）：35-40.

[3] 劉陽學.城市軌道交通線網應急處置協調系統研究[J].都市快軌交通，2016，29（5）：55-59.

[4] 董楠楠，單曉歡，牟有靜.基于Hadoop和MapReduce的大數據處理系統設計與實現[J].信息通信，2020（6）：29-31.

[5] 封富君，姚俊萍，李新社，等.大數據環境下的數據清洗框架研究[J].軟件，2017，38（12）：193-196.