CBTC 信號系統智能化故障分析

陳靜梅

（鄭州地鐵集團有限公司運營分公司，鄭州 450000）

1 CBTC 信號系統的故障處理方式

基于通信的列車運行控制系統(communication based train control system，CBTC)作為城市軌道交通的“大腦”和“中樞神經”，目前已成為列車控制的主流制式，CBTC 從大的方面來看，可以分為列車控制和信息傳輸兩大部分。筆者調查了目前主流的設備廠商得知，列車控制部分主要由ZC(zone controller，區域控制器)、LC (line controller，線路控制器)、聯鎖子系統、車載CC(carborne controller，車載控制器)子系統、ATS (automatic train supervision，列車自動監控)子系統構成，信息傳輸部分采用無線通信系統，常見的系統架構如圖1 所示。

列車在正常運行過程中，控制各子系統各司其職，按照分工進行信息流的交互及處置，共同確保列車的安全穩定運行。但是，各子系統自身有獨立的處理邏輯，同時相互之間又具備極強的關聯性，運行過程中一旦發生因信息處理沖突等導致的故障，在各子系統上可能會出現不同的故障顯示，很難在短時間內確定為哪個子系統導致，故障定位難度大，需對各子系統

圖1 CBTC 系統總體結構Fig. 1 CBTC system overall structure

均精通的人員進行處理；再加上調度、站務、司機等設備使用人員對故障信息獲取較少，上報存在片面，而信號集中監測系統(MSS)主要監測硬件類的設備報警，各子系統日志較少，故障處理人員更擅長處理硬件故障，信息來源少且片面，導致故障處理效率低下。因此，亟需從CBTC 層面研究，按照各子系統的功能和信息流走向，通過軟件判斷設備或者軟件故障發生的根本原因，并快速排除。

2 信號設備狀態感知層的采集能力

2.1 環境情況監控

目前，針對監控設備的溫濕度、漏水、燈光控制、玻爆、煙霧粉塵等的監測能力已經具備，后續可將設備室的環境情況通過串口服務器或信號采集器傳送至監測系統中作為底層數據[1]。

2.2 狀態感知層監控

硬件管理方面，目前在行業內是利用傳感器、監測設備、攝像掃描、溫度感知等技術，將道岔、信號機、計軸/軌道電路、電源設備、ZC、LC、車載CC 等設備硬件的電壓、電流、燈位顯示、溫度變化、開關量/模擬量變化等進行綜合采集，后續也可通過網絡傳送至智能化維護系統中作為底層數據，為后續綜合分析并給出報警信息、處理建議和行車影響預警打下基礎[2]。

2.3 信號設備監控

信號設備中有大量的設備工作站、交換機、服務器等，目前行業內已具備對工作站、交換機的CPU、內存、磁盤占用率、網絡端口流量、包錯誤率、包丟失率、溫度、風扇轉速、各模塊工作狀態等的監控能力，后續對操作記錄、事件、日志等運行情況進行監控，形成大數據后作為信號設備的底層數據。

3 信號設備智能診斷的可行性分析

隨著云儲存、大數據的高速發展，已具備對狀態感知層每天采集的數萬億數據元的信息傳輸及存儲處理的能力。信號各子系統在設計階段和功能描述中，系統日志詳細記錄了設備運行中硬件、軟件的各種狀態信息，因信號系統網絡的封閉性和高安全性，為發生設備故障后快速通過IP 地址和MAC 地址追溯故障原因創造了條件。信號各子系統在信息傳遞時具備明顯的邏輯時序，可通過各子系統信息流之間的橫向對比，快速實現日志在空間維度中的異常檢測；通過對單個子系統日志中的數據信息與歷史數據的對比，能快速實現日志中時間維度的異常檢測功能。

3.1 日志的時間特征

舉個典型故障案例：某線路信號ATS 子系統在執行計劃下發、調取運行圖、報表信息等命令時，頻繁出現卡死現象，其他功能均正常；而該線路運行圖、報表信息的存儲和調閱，以及用戶權限的核對等功能，由數據庫服務器負責。通過對其A、B 機oraagent.log日志進行查看，發現故障的發生時段均會出現故障語句 ([ora.LISTENER_SCAN2.lsnr][8000]{1:56041:268}[check] clsnUtils::error Exception type=2 string=CRS-5014:代理在啟動進程"D:app11.2.0gridinlsnrctl.exe"以執行操作"check"時超時)。因故障出現的隨機性，維護人員很難及時發現故障代碼并處理故障。

設備日志信息具備明顯的時間維度特征，故障前后記錄的日志數據均大致相同，只是在故障時段會出現異常數據。因此，通過已發生事件的時間間隔變化，可以快速獲取事件的變化模式。通過日志信息中提取的多種特征信息進行相似性檢測、回歸分析和機器學習，建立檢測模型，可快速實現異常檢測。

3.2 日志的密度和種類特征

通常，設備在正常狀態下可能不定期地產生少量的日志記錄。當設備異常時，設備可能會打破記錄的模式，產生大量的日志記錄，即故障時段設備日志的密度明顯增加。例如，某線路信號系統試運營階段，某ZC 控制區域內正在運行的列車全部觸發EB 停車，且CBTC 模式不可用，后對該時段ZC 日志進行分析發現，此時某列車進入該ZC 區域，在與ZC 通信時出現了大量的延時報文(cc_zc_synchro_obsolete)，ZC自鎖，從而導致列車全部觸發EB 停車。

3.3 日志的嚴重等級

信號各子系統異常日志具備明顯的等級劃分，如根據嚴重程度，將報警分為了一級報警、二級報警和三級報警，并針對不同報警，使用了如聲光報警、彈出式報警、紅色顯示報警等方式。維護人員可通過不同報警信息，快速實現故障定位和判斷。

3.4 日志的空間維度和時序特征

各子系統之間雖相互獨立，但具備明顯的關聯關系和邏輯時序，此種故障用如下案例加以說明。

3.4.1 典型故障案例1

ATS 折返進路與聯鎖防護區段overlap 觸發沖突[3]：如圖2 所示，在正常運營過程中，DG5110 區段突發白光帶。

圖2 案例1 的故障現象Fig. 2 Failure in case 1

1) ATS 日志分析：列車占用小交路折返站折返軌時，ATS 自動觸發S5115-X5106、S5104-X5102 進路，進路按照從遠端至近端開放的原則，聯鎖先正常辦理了S5104-X5102 進路，接著辦理S5115-X5106 進路，對DG5110 區段進行了鎖閉(此時P5110 道岔反位)。此時開往上行方向的大交路車因開放S5302-S5108 進路觸發了O_S5108，需將P5110 道岔放置在定位，P5110 道岔向定位轉換，導致已鎖閉的DG5110 區段故障，顯示白光帶。

2) 聯鎖日志分析：按照聯鎖系統的處理邏輯，進路辦理可簡化為選擇組電路確保道岔在正確的位置、執行組電路進路鎖閉、執行組電路信號開放三個部分。查看聯鎖日志可知，因P5110 道岔本身在反位，聯鎖不發送驅動道岔動作命令，只驅動P5106-P5108 道岔向反位動作；而此時O_S5108 發送命令，聯鎖驅動P5110 道岔向定位動作，因命令剛剛發出，此時P5110道岔第一啟動繼電器尚未勵磁，P5110 道岔仍處在反位表示狀態。ATS 開始預排列進路S5115-X5106，將相關區段鎖閉。此時P5110 道岔繼續按照聯鎖命令轉換至定位，導致已鎖閉的區段出現白光帶。

兩種命令處理沖突的過程如表1 所示。

表1 兩種命令處理沖突的過程Tab. 1 Conflict resolving process by two commands

由上述分析可知，按照ATS 和聯鎖子系統空間維度的日志對比和聯鎖子系統時序特征，可快速判斷故障原因為 ATS 折返進路與聯鎖防護區段overlap 觸發沖突所致。因此，后續ATS 觸發時可增加兩條命令的沖突判斷處理機制，從源頭避免故障的發生。

3.4.2 典型故障案例2

列車以ATP模式在小交路站使用站前P5101 道岔折返時，產生緊急制動，行調組織司機以RM 模式動車后恢復ATP 模式運行，如圖3 所示。

圖3 案例2 的故障現象Fig. 3 Failure phenomenon in case 2

1) 車載日志分析：故障發生時，列車車頭所在區段為B_67，即X5105 信號機至P5101 道岔，列車車頭進入X5105 信號機內方后，列車移動授權丟失，發生緊急制動。

2) ATS 日志分析：501 次工程車一直停留在車站下行站臺，ATS 正常開放X5105 信號機黃燈后，列車進入X5105 信號機內方，ATS 未發現異常，司機反饋列車緊急制動停車。

3) ZC 日志分析：501 為非通信車，其NIAP(非識別自動防護)區域為WG5119 處。為確保行車安全，系統在NIAP 與AP 之間會設計一個出清的區域(buffer zone)，其區段為B_68，即P5101 道岔至S5107 處。因B_67、B_68、B_225 均為同一軌道區段DG5101，當車頭一進入X5105 信號機內方時，DG5101 被占用，ZC 處于安全考慮，將buffer zone 擴延至B_67 區域，導致列車產生緊急制動，故非信號設備故障。

4) 故障處理難度：因X5105 信號可正常開放，所以列車運行過程中突發緊急制動很難立即鎖定故障原因，列車回庫后下載車載日志再分析會浪費大量時間，且車載日志分析也并未發現異常；而ZC 日志分析，因各設備廠商之間不同設計理念的差異，想要打破技術壁壘、弄懂設計人員的初衷難度很大，維護人員很難在短時間內通過大量數據判斷出故障原因，需設備廠商的專業技術人員提供技術支持。

5) 智能化分析探索：因信號可正常開放，能判斷出ATS 子系統、聯鎖子系統均功能正常。ZC 系統通過CC 發送的列車移動的相關信息，可迅速判斷出緊急制動是否因空轉、打滑、定位丟失等原因造成；在排除車載故障原因后，ZC 可迅速判斷無法給出移動授權的原因，給行車指揮人員提供正確的組織行車建議。

4 信號智能化維護系統模型的建立

分析狀態層數據和信號各子系統的日志特征可知，CBTC 信號系統具備智能化維護的可行性，而信號設備故障影響大、故障定位困難，信號專業人員培養周期長、難度大，已成為各地鐵公司安全、穩定運行的制約因素，所以亟需由人工傳統的狀態修、故障診斷向智能化轉變。經過上述可行性分析與案例論證，智能化發展可從3 個方面入手：

1) 全面、準確地收集原始數據，因信號設備受風霜雨雪等惡劣天氣和溫度、濕度影響較大，所以建議源數據包含環境狀態和氣象信息等數據。此外，監測狀態感知層在數據采集時標準應統一，因道岔、信號機等信號設備繼電器電路均采用同樣的定型組合，為確保分析的可靠性，新增的電流、電壓采集點應在定型組合的統一位置，建議提前編制技術標準，確保監測內容、監測點、監測量程、監測精度、采樣速率等一致，確保后續數據剝離、加工后的報警方式等一致[4]。

2) 數據預處理階段，因監測數據量大、雜亂且來源復雜，針對數萬億的數據元，可通過重復值、缺失值、異常值等形式進行數據質量的檢查，并通過數據抽取、轉換、檢查、數據調度等方式，對數據進行預處理，篩選出關鍵數據[5]。

3) 機器學習建模階段，一是結合不同的數據特性研發不同的分析方法，實現數據的全量智能分析，如針對各子系統連續的數據日志記錄進行波形分析，針對道岔、信號機等使用事件型曲線進行特征分析，針對綜合型多數據及多接口數據，利用專家知識庫進行綜合分析推理，利用故障樹、事故樹等推理故障影響或故障原因，確保數據挖掘的深度和有效性[6]；二是通過各子系統的日志解析軟件，對區域控制器(ZC)、線路控制器(LC)、聯鎖子系統、車載CC 子系統、ATS子系統的運行過程進行全程監控，并診斷分析行車運行過程中存在的問題，針對歷史故障開展機器語言學習，自動更新故障庫[7]；三是通過各子系統的邏輯關系，分析CBTC 信號系統運行過程中存在的軟硬件問題，最終構建集設備監測、維護、診斷、管理、預警及應急處置指導于一體的智能化維護系統[8]。

4) 模型發布和模型應用階段，因各地鐵公司應急預案、行車組織規則、故障處理細則均有自身特點，數據模型發布應用時，可結合各公司運營管理的要求進行使用，給出設備故障、大雪天氣時智能行車組織、故障處理、健康度評價、應急指揮處理、啟動預案的建議。譬如，小交路站道岔故障后立即全部智能改開大交路行車，若確定為室內故障，立即要求維護人員更換故障元器件，啟動信號故障應急預案等[9]。智能化維護系統模型如圖4 所示。

5) 信號智能化系統宜采用自動分析、智能判斷、智慧信號逐步推進，按照站機、線網、全網化逐步建設，通過大數據分析人員行為特征，AI 預測人員行為動向，虛擬現實培訓，基于BIM 的設備全生命周期管理，AI 預測維修及施工，最終實現信號智能運維體系的建設[10]。

5 結語

計算機軟件開發、機器語言學習、人工智能等技術的飛速發展，為信號智能化維護系統的發展創造了有力的條件；信號各子系統的日志和明確的邏輯處理關系，為故障定位及行車影響判斷打下了基礎。為確保行車設備安全穩定運行，急需各設備廠商及信號維護人員共同開展研究，攻克難關，共同出臺信號智能化維護系統標準，開發出安全可靠的智能化維護系統，提高信號故障處理的速度和準確性[11]。