適用于既有城市軌道交通線路的車輛在線監(jiān)測系統(tǒng)

劉克偉 高利華 王伊多 裴加富

(北京市地鐵運營有限公司運營二分公司,100043,北京∥第一作者,高級工程師)

0 引言

隨著城市的快速發(fā)展,城市軌道交通面臨的運營壓力越來越大,因此對設備的安全性、穩(wěn)定性要求越來越高。車輛為城市軌道交通的核心裝備之一,傳統(tǒng)的列車回庫檢查模式已無法滿足高效、安全運營對車輛的需求。近幾年開通的全自動無人駕駛線路,已分別在場段基地和控制中心配置了完善的車輛智能運維系統(tǒng)和車輛調(diào)度系統(tǒng),能夠很好地滿足全自動運行車輛的日常檢修維護和高效運營調(diào)度的要求。但對于開通較早且沒有配置車輛在線監(jiān)測系統(tǒng)或車輛智能運維系統(tǒng)的線路,車輛的維護和故障信息主要是在車輛司機室的顯示屏上顯示的,車輛檢修人員無法對車輛運行和運營情況進行實時監(jiān)測,也無法有效地進行車輛的預防維修。車輛出現(xiàn)故障時,只能等列車回庫后由檢修人員登車查看報警記錄或手動拷取車輛運行日志進行人工分析,故障診斷和修復時間都比較長。而對于控制中心的運營指揮人員,也無法實時掌握車輛設備的運行情況,只能被動接收司機的故障上報,當車輛出現(xiàn)故障時,無法準確高效地進行應急指揮和運營調(diào)整決策。顯然,這種情況已無法滿足城市軌道交通車輛高效維護和高效運營調(diào)度的需求。因此,針對既有線路車輛,有必要研究和實施針對車輛關(guān)鍵信息的在線監(jiān)測和智能維護方案,為城市軌道交通運營單位的維護決策和運營指揮等提供更科學、更有效的支持。

車輛在線監(jiān)測和智能運維的實現(xiàn),必須建立在穩(wěn)定可靠的車地通信網(wǎng)絡基礎之上。目前常規(guī)的做法是使用民用公網(wǎng)或搭建新的傳輸網(wǎng)絡。但使用民用公網(wǎng)存在著數(shù)據(jù)安全性差、無線網(wǎng)絡信號覆蓋不穩(wěn)定等問題;而搭建全新的傳輸網(wǎng)絡則存在著成本過大、需要在運營線路上大量施工等問題,實施難度較大。

本文提出一種基于DCS(數(shù)據(jù)通信系統(tǒng))專用網(wǎng)絡的車輛數(shù)據(jù)實時傳輸落地方案,實現(xiàn)運營車輛關(guān)鍵設備和運行信息的實時在線監(jiān)測,并在此基礎上采用智能化分析和智能維護決策相關(guān)技術(shù)實現(xiàn)車輛智能維護功能,能夠有效滿足既有線路車輛在線監(jiān)測和智能維護的要求。

1 車輛在線監(jiān)測系統(tǒng)設計及其影響分析

基于上述現(xiàn)狀和需求,設計的車輛在線監(jiān)測系統(tǒng)利用車輛-ATC(列車自動控制)-ATS(列車自動監(jiān)控)的既有數(shù)據(jù)傳輸通道進行數(shù)據(jù)擴容和落地,同時在地面設置獨立的車輛在線監(jiān)測及智能分析相關(guān)設備,實現(xiàn)車輛在線監(jiān)測及智能維護相關(guān)功能。

1.1 系統(tǒng)結(jié)構(gòu)

設置一套主備冗余的車輛在線監(jiān)測服務器,一方面負責與ATS子系統(tǒng)接口,實時獲取車輛數(shù)據(jù)并進行數(shù)據(jù)處理,另一方面負責車輛數(shù)據(jù)智能分析并提供智能維護相關(guān)功能。同時,根據(jù)需要設置車輛監(jiān)控終端,為調(diào)度人員和維護人員提供調(diào)度和維護決策支持;與ATS子系統(tǒng)有接口時,需設置防火墻,以保證數(shù)據(jù)接口的安全可靠性,避免對既有系統(tǒng)產(chǎn)生影響。車輛在線監(jiān)測系統(tǒng)架構(gòu)如圖1所示。

圖1 車輛在線監(jiān)測系統(tǒng)架構(gòu)

1.2 功能架構(gòu)

由于車輛落地的數(shù)據(jù)量大且部分線路車輛數(shù)量較多,因此車輛在線監(jiān)測系統(tǒng)采用了支持大規(guī)模實時數(shù)據(jù)的綜合監(jiān)控軟件平臺,可滿足高實時性、高可靠性和穩(wěn)定性要求,該軟件平臺由數(shù)據(jù)采集層、后臺服務層和前端顯示層組成,如圖2所示。

圖2 車輛在線監(jiān)測系統(tǒng)功能架構(gòu)

數(shù)據(jù)采集層提供接口采集框架,包括主備冗余機制、協(xié)議驅(qū)動、數(shù)據(jù)解析、主備數(shù)據(jù)同步等,支持多種標準協(xié)議的接入和擴展。由于車輛維護數(shù)據(jù)量大,且實時性要求也較高,因此數(shù)據(jù)接口采集層框架采用負載均衡策略:主模塊收到數(shù)據(jù)后,將數(shù)據(jù)處理分發(fā)到不同的處理模塊,從而確保數(shù)據(jù)處理的實時性。后臺服務層引入綜合監(jiān)控實時庫及其成熟的雙機熱備、數(shù)據(jù)訂閱、數(shù)據(jù)存儲等核心功能模塊。同時引入高并發(fā)計算引擎、故障智能分析服務,實現(xiàn)車輛智能維護的相關(guān)功能。前端顯示層主要提供面向運營和維護人員的車輛狀態(tài)監(jiān)測及智能維護相關(guān)功能,包括狀態(tài)實時監(jiān)測、報警管理、趨勢及報表、智能維護指導、運營輔助決等[1]。

1.3 車輛數(shù)據(jù)傳輸方式

車輛TCMS與信號車載子系統(tǒng)存在實時數(shù)據(jù)通道,而信號車載子系統(tǒng)與地面ATS子系統(tǒng)也存在實時數(shù)據(jù)通道。經(jīng)充分測試和評估,在確保對既有系統(tǒng)不產(chǎn)生影響的情況下,采用在這兩個既有數(shù)據(jù)傳輸通道的基礎上進行傳輸數(shù)據(jù)擴容,將更多的車輛實時運行和關(guān)鍵故障數(shù)據(jù)發(fā)送給地面的ATS子系統(tǒng),再由地面ATS子系統(tǒng)將數(shù)據(jù)實時轉(zhuǎn)發(fā)給車輛在線監(jiān)測系統(tǒng),從而實現(xiàn)了車輛數(shù)據(jù)實時、安全、可靠落地[2]。

1) 車輛TCMS數(shù)據(jù)采集:通過與車輛其他設備間的接口以及自身的采集點位,采集匯總車輛工況信息,根據(jù)在線監(jiān)測及智能維護需求調(diào)整需要監(jiān)控的信息,以確保滿足用戶日常維護以及后續(xù)故障預警的功能需求。

2) 車輛TCMS與車載信號子系統(tǒng)間數(shù)據(jù)交互:車輛TCMS與車載信號子系統(tǒng)間通過RS485總線或MVB(多功能車輛總線)接口進行數(shù)據(jù)交互。根據(jù)用戶需求可對既有的接口協(xié)議進行調(diào)整,將用戶需要增加的車輛工況信息擴展補充到協(xié)議內(nèi),由車輛TCMS按照協(xié)議要求將信息發(fā)送給車載信號系統(tǒng)[3]。

3) 信號系統(tǒng)內(nèi)部數(shù)據(jù)交互:車載信號子系統(tǒng)將車輛TCMS發(fā)過來的實時數(shù)據(jù)信息發(fā)送至ATS子系統(tǒng),再由ATS子系統(tǒng)將信息發(fā)送到車輛在線監(jiān)測系統(tǒng)服務器。另外,為了更好地對列車運行進行實時監(jiān)控,同時對運行故障進行智能化判斷,也建議ATS子系統(tǒng)將車載CC數(shù)據(jù)以及ATS子系統(tǒng)掌握的列車運行信息一并發(fā)送給車輛在線監(jiān)測系統(tǒng)服務器。

1.4 對既有系統(tǒng)的影響分析

通過對多條既有線路的應用分析評估發(fā)現(xiàn),目前通過車載信號子系統(tǒng)落地的車輛狀態(tài)數(shù)據(jù)一般在200 B左右,每3 s發(fā)送一次數(shù)據(jù),發(fā)送數(shù)據(jù)量非常小,存在較大的擴容空間。

車地無線鏈路的理論帶寬為6 Mibit/s,信號系統(tǒng)車地無線實際數(shù)據(jù)量為25～30 Kibit/s。按照全自動無人駕駛項目車輛智能運維建設的標準,要實現(xiàn)相對比較完整的車輛在線監(jiān)測和智能維護,預計需要的數(shù)據(jù)為2 048 B。按這個數(shù)據(jù)傳輸?shù)脑?車地無線流量占用峰值會增加16 Kibit/s。加上既有信號系統(tǒng)占用的帶寬,也遠小于理論帶寬6 Mibit/s,因此對既有業(yè)務的數(shù)據(jù)傳輸不會產(chǎn)生影響。

所設計的車輛在線監(jiān)測系統(tǒng)也在北京某線路進行了實際測試驗證,測試結(jié)果表明:車地無線通信在增加車輛數(shù)據(jù)落地的情況下,其吞吐率、時延、丟包等參數(shù)都滿足要求,不影響既有車地業(yè)務功能。

2 車輛在線監(jiān)測系統(tǒng)關(guān)鍵技術(shù)

2.1 前端邏輯分析技術(shù)

該系統(tǒng)在顯示設計上采用了由粗到細的展示方案,首先是全線車輛監(jiān)測概覽界面,然后是單獨一輛車的監(jiān)測概覽界面,最后是具體的專業(yè)系統(tǒng)界面。對于概覽界面的顯示,需要做大量的匯總計算,如實時統(tǒng)計該車當前有幾個牽引逆變器出現(xiàn)故障、當前車輛是否存在嚴重故障等。這些指標的計算具有一定的特殊性,而且不同線路顯示要求也有所區(qū)別。所以在界面顯示邏輯實現(xiàn)時,一方面需要考慮計算的規(guī)模,另外一方面需要考慮可配置的能力。

研發(fā)了基于MapReduce編程模型原理的分布式計算引擎服務,每輛車上運行一個獨立的計算引擎服務。對于每個統(tǒng)計指標,采用邏輯計算表達式進行統(tǒng)計指標建模,使用加減乘除以及邏輯與或非等運算符建立數(shù)據(jù)間的計算關(guān)系。

該系統(tǒng)實際運行時,根據(jù)車輛數(shù)量啟動相應數(shù)量的計算引擎,每個計算引擎獨立加載一輛車的邏輯計算表達式并根據(jù)邏輯表達式參數(shù)的變化驅(qū)動實時計算,計算后輸出結(jié)果至實時庫供監(jiān)控終端訂閱。分布式計算引擎服務驅(qū)動邏輯如圖3所示。

2.2 智能故障定位技術(shù)

由于車輛本身結(jié)構(gòu)復雜、組成部件繁多、發(fā)生故障的類型也很多,各種突發(fā)故障、交叉故障、組合故障占了很大比例。同一故障引發(fā)的原因也多種多樣,人工定位故障難度很大。該系統(tǒng)采用了基于多叉樹結(jié)構(gòu)的智能故障定位技術(shù),提高了故障的診斷和定位效率。該技術(shù)的故障定位流程如圖4所示。

1) 構(gòu)建故障案例庫。對故障案例進行歸納總結(jié),把內(nèi)容相似、業(yè)務邏輯相近的案例歸納到同一類故障案例庫中。該系統(tǒng)通過初始化故障案例庫接口、計算故障執(zhí)行接口、車輛數(shù)據(jù)訂閱接口、注冊若干組件接口和若干故障狀態(tài)回調(diào)接口等調(diào)用不同類的故障案例庫。

2) 構(gòu)建并解析故障狀態(tài)表達式。①定義參與計算的節(jié)點。每一個節(jié)點對應一個點名稱,并配置節(jié)點類型,節(jié)點共有3種類型:運算符、常數(shù)和需要參與計算的內(nèi)存點。②解析故障狀態(tài)表達式。利用遞歸的方式和多叉樹結(jié)構(gòu)算法,將表達式劃分為多叉樹的頂節(jié)點、左子樹和右子樹。③根據(jù)解析得到的頂節(jié)點、左子樹和右子樹,得出故障狀態(tài)表達式。當故障狀態(tài)表達式計算結(jié)果為1時,說明故障信號出現(xiàn);當故障狀態(tài)表達式計算結(jié)果為0時,說明故障信號未出現(xiàn)或設備已由故障轉(zhuǎn)為正常。

3) 定位故障。①確認故障狀態(tài)。在一定時間內(nèi)(可配置),如果故障狀態(tài)表達式計算結(jié)果一直為1,則說明該故障確切不是由信號擾動產(chǎn)生的,該系統(tǒng)開始觸發(fā)故障定位分析;在這段時間內(nèi),如果故障狀態(tài)表達式計算結(jié)果為0,則說明該故障可能是由信號擾動產(chǎn)生的,該系統(tǒng)不觸發(fā)故障定位分析。②利用遞歸式定位故障。如果節(jié)點包含子節(jié)點,則對其中子節(jié)點表示的故障進行定位;如果節(jié)點不包含子節(jié)點,該節(jié)點則為故障定位點,從節(jié)點對應的點名稱可以分析出故障原因[4-5]。

3 結(jié)語

車輛在線監(jiān)測系統(tǒng)已通過功能驗證,并開始現(xiàn)場運行。該系統(tǒng)的優(yōu)勢主要體現(xiàn)在以下幾個方面:

1) 實時性:從車輛數(shù)據(jù)采集、數(shù)據(jù)預處理、數(shù)據(jù)發(fā)送、數(shù)據(jù)接收到故障分析結(jié)果顯示可在3 s內(nèi)完成,使車輛維護人員能在第一時間掌握車輛實時狀態(tài)信息及故障情況。

2) 經(jīng)濟性:該系統(tǒng)可對線路上所有車輛進行遠程實時監(jiān)測,提高了車輛維護和故障處理的效率,能夠?qū)崿F(xiàn)較好的經(jīng)濟效益。

3) 故障定位及處置效率:該系統(tǒng)實現(xiàn)了故障智能定位功能,可為車輛維護人員最終確認故障點位及處置方式提供判斷依據(jù),能夠有效壓縮故障定位和處置延時。

4) 輔助調(diào)度決策:該系統(tǒng)實現(xiàn)了故障情況的實時分析和統(tǒng)計,可為調(diào)度決策提供有力的數(shù)據(jù)支持,能更好地輔助調(diào)度的運營調(diào)整決策。

車輛在線監(jiān)測系統(tǒng)總體上提升了車輛維護及運營指揮效率。目前該系統(tǒng)運行穩(wěn)定且信息準確,解決了既有線路車輛系統(tǒng)維護困難的問題。