多線網通用地鐵運維系統研究

楊 博，劉 琪，張哲瑞，李康樂，閆莉瑩

(1.西安中車永電捷通電氣有限公司，陜西 西安 710018；2.大連機車車輛有限公司，遼寧 大連 116021)

0 引言

隨著城市地鐵線網的增多，原有低效的維保方式已無法滿足地鐵公司日益增長的業務需求，亟需尋求新的解決方案。通過物聯網等技術實現車輛狀態的實時監控，建立車輛運維系統，將傳統的車輛變得更加智能，對于實現地鐵公司的數字化轉型意義重大[1]。然而地鐵不同線路的車輛大多由不同的廠商生產，且車上設備種類眾多，如果都采用各設備供應商的專用監控方案，由每個設備提供自己的數據采集和落地服務，則會導致成本上升和布線冗雜[2]，因此實現能夠將不同廠家、多種設備的數據進行綜合采集、集中發送和監控的運維系統是解決問題的核心。

本文提出了一種基于車載運維主機和地面數據中心的多線網通用地鐵運維系統，該系統包含車載的運維主機和地面的數據中心，運維主機通過MVB、485、以太網等接口獲取車載設備的運行狀態信息，然后通過LTE/WLAN傳輸到地面的數據中心，數據中心再負責將數據進行整合、分析和呈現。

1 運維系統總體架構

目前車輛上裝備的監控系統多為煙筒式架構(見圖1)，弓網監控、乘務監控等有監控需求的系統都配置有各自的通信模塊、天線和地面服務器，各系統間服務與數據不共享，形成數據和服務孤島，導致車輛運維成本升高，由于車頂空間有限，為保證通信質量，避免信號間相互干擾，各天線間需要保持合理的間距，導致布線困難。為解決上述問題，可采用共享式架構，將各系統功能相似部分進行抽象，由運維主機替代各系統原有的通信模塊和外置天線，由數據中心替代各系統原有的地面服務器。

圖1 煙筒式架構圖

系統總體架構如圖2所示：在每列車上安裝一臺運維主機，運維主機具備485、MVB和M12以太網等接口，可通過多種接口采集車上設備的狀態數據；將設備數據收集組包后，通過LTE/WLAN傳輸至地面數據中心，考慮到網絡安全，須加裝防火墻。數據中心包含接收運維主機數據的數據采集服務器、將數據存儲的數據存儲服務器和解析數據的應用服務器；采用微服務的架構，一套硬件通過容器技術劃分出多個虛擬空間，提供Docker給各車載設備部署數據模型和應用，通過Kafka或Rest API進行數據的交互，避免了服務器硬件的重復投入。

圖2 系統總體架構圖

2 運維主機硬件設計

運維主機替代了車上各系統原有的通信模塊和天線，因此需要采集各設備的應用數據，然后進行存儲和發送。需要采集的信息可分為兩種：一種是列車各設備運行狀態數據，如速度、網壓、制動空壓機壓力等信號，這類信息實時性要求高，但數據量不大，可通過MVB接口進行采集；另一種是用于設備健康管理的數據，如接觸器動作次數、電容充放電時間、弓網監測的視頻等信息，這類信息由于數據量較大且實時性要求不高，需要通過以太網接口進行采集。

由于隧道內LTE網絡不穩定，而進行設備的健康管理對數據的連續性要求又比較高，因此運維主機需要將采集到的數據進行緩存，并和地面數據中心實現斷點續傳的功能。運維主機還須具備集成數據記錄儀功能，將通過MVB和以太網接口采集的列車運行數據存儲在內置的固態硬盤中。數據發送包含LTE和WLAN兩種方式：LTE通道用于實時時間的發送；WLAN通道用于音視頻、硬盤數據等大數據的發送。

根據運維主機的上述需求，設計的控制器硬件包括核心控制板、通信板、電源板、接口板等模塊；核心控制板用于運行Linux操作系統，進行數據處理及存儲、協議轉換。選用Toradex公司的Apalis iMX6D，搭載恩智浦MCIMX6D7CVT08 SoC，具備雙核800 MHz處理能力，自帶1 G DDR3和4 G eMMC NAND Flash，能滿足應用需求。

通信板用于數據的無線傳輸，外接天線通過LTE/WLAN等無線方式將數據發送至地面數據中心，選用華為ME909s-821模塊，上行速率50 Mbps，下行速率150 Mbps，具備Mini PCIe接口和核心板連接。

為兼容列車上的多種接口協議，接口板設計了2路CAN接口、2路以太網接口、2路MVB接口、1路485接口和3路外部天線接口(4G、Wi-Fi、GPS及北斗)。

3 無線傳輸與數據同步

車輛與地面的無線傳輸通道由4G網絡和段內無線局域網組成，其中4G通道提供實時傳輸，即使車輛在線上提供運營服務，也能實時將數據傳回到位于車輛段內的服務器中；段內無線局域網用于離線的數據傳輸，當車輛回到車輛段，車輛將通過車載設備自動連接地面無線網絡，從而實現將車輛數據通過WLAN傳輸到地面服務器。

為提高無線局域網的網絡性能、網絡管理和安全管理能力，采用“AC無線控制器+AP”模式構建無線局域網，保證無線網絡的高性能，易于管理和安全性。為了避免AC單點故障的問題，采取AC 1+1熱備份，增加網絡的可靠性。核心交換機也采用1+1熱備份，保證傳輸的可靠性與安全性。根據網絡管理特點，網管平臺采用B/S架構，瘦客戶端的方式，可通過遠程方式登錄管理，網管平臺的WLAN功能模塊可組件化解耦，按需拆卸，便于在網絡不同場景下靈活組合使用。

由于列車通常在上行段和下行段都設有停車場，數據庫將同時部署在2個停車場，其中一個停車場的服務器定義為主服務器，同時接收4G和無線網絡傳回的數據；另一個停車場的服務器定義為從服務器，只接收無線網絡傳回的數據。當位于輔助停車場的從服務器接收到數據后，將通過2個車庫間的VPN網絡把數據發送到主停車場的主服務器。

4 數據中心設計

數據中心作為整個運維系統的處理核心，接收并存儲車輛的海量運行數據，并基于大數據分析和挖掘技術，通過分析列車運行狀態變化趨勢，輔助車輛人員進行智能決策。系統實時與車載運維主機進行數據交互，采集和處理傳感器數據，實現車輛在線故障診斷、故障預測以及亞健康預判等功能，實現車載故障預測和健康管理，指導維保人員維修決策，并可實現與地鐵公司的EAM系統對接，當運維系統識別到列車發生故障后，實現維修工單自動生成和派發。

系統主要模塊包括數據處理、在線監控、事件管理、工單管理、數據分析、健康管理和系統管理。數據處理模塊包含數據接收、數據解析和數據存儲。實時數據通過實時流式數據接收方式接收車載數據，數據以Socket數據流形式發送，Kafka將數據流整理為數據流序列，并有序地提供給后端實時數據處理程序。針對大數據量的離線數據，待列車回庫后，以FTP方式實現數據接收。

在線監控模塊按使用需求可實現線路級、列車級和部件級監控，線路級監控可宏觀顯示當前線路正常和故障狀態的車輛數目。列車級監控可顯示列車位置、列車號、網壓、速度、運行模式、站點、故障狀態等信息，部件級監控可顯示單個設備的電壓電流、接觸器開斷等詳細狀態信息，并實現了將列車HMI界面1:1無差別復制到運維系統的功能，方便維保人員對車輛狀態的遠程診斷。

事件管理模塊用于對列車已發生的故障進行管理，包括事件監控、事件管理和事件查詢，可對列車發生的故障實時報警，并可實現類似應急預案的功能，預定義故障可能的原因、故障相關變量和給出建議的解決措施。為減少誤發，提高預警的準確性，支持事件信息的人工更新和修正，根據歷史故障和模型預警情況，構建并不斷完善知識庫。

根據列車故障狀況和維修建議，系統自動生成維修工單，工單管理模塊包括工單生成、結果回填和評價。根據列車健康情況，構建維修工單，并自動推送到地鐵公司EAM系統，實現工單自動生成和派發，待工單關閉后將執行結果及相關信息推送回運維系統，進行結果回填和評價。

數據分析模塊包括歷史數據查詢和運營信息分析2個功能。針對故障調查等特定的數據需求，可通過列車號和時間查詢列車運行歷史數據，再現故障發生時的列車運行狀態，為調查分析提供數據支撐。該模塊還支持將牽引能耗、再生電量和里程等運營信息生成報表，供決策分析使用。

5 設備健康管理和評估

傳統的列車維保按運營里程進行分級檢修，在設備達到使用壽命時提前進行預防性更換。為降低列車維修成本和正線故障率，實現車輛預防修到狀態修的轉換，亟需對設備健康狀況進行管理，實現設備狀態數據、故障數據、預警數據的管理和分析。首先對管理對象按功能結構進行拆解，以逆變器為例，可拆解為接觸器、電容、IGBT、傳感器等具體部件，然后根據部件特性搭建故障預警模型，具體界面如圖3所示。

圖3 設備健康管理和評估界面

以IGBT為例，IGBT模塊的失效多為其內部疲勞逐漸積累，并與外部運行環境多種因素相互作用的綜合結果。主要故障模式可分為芯片失效與熱疲勞失效，其中芯片失效為內部高溫和過電應力導致，瞬時發生，很難通過狀態檢測；熱疲勞失效是指IGBT內部結溫引起的熱應力所致，包括斷裂、焊料層裂紋等。因此可通過檢測實時電流、電機頻率結合IGBT 的損耗模型和變流器熱模型計算出IGBT 模塊的芯片溫度和殼溫，通過實時雨流算法計算出IGBT 的溫度波動幅度及頻次，最后結合IGBT的壽命模型對IGBT健康度進行實時評估，給出合理的維修建議。

6 結語

本文針對地鐵監控領域所面臨的通用性問題，開發了基于車載運維主機和地面數據中心的地鐵運維系統。設計了運維主機硬件，實現了列車數據的采集和轉發；搭建了地面數據中心，完成了地鐵設備的在線監控與管理，并實現了設備健康管理和評估，與硬件模塊一起提供了適用于地鐵設備的軟硬件一體化運維解決方案。