陳靜梅

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

1 CBTC 信號系統(tǒng)的故障處理方式

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

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

圖1 CBTC 系統(tǒng)總體結(jié)構(gòu)Fig. 1 CBTC system overall structure

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

2 信號設備狀態(tài)感知層的采集能力

2.1 環(huán)境情況監(jiān)控

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

2.2 狀態(tài)感知層監(jiān)控

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

2.3 信號設備監(jiān)控

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

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

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

3.1 日志的時間特征

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

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

3.2 日志的密度和種類特征

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

3.3 日志的嚴重等級

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

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

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

3.4.1 典型故障案例1

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

圖2 案例1 的故障現(xiàn)象Fig. 2 Failure in case 1

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

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

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

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

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

3.4.2 典型故障案例2

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

圖3 案例2 的故障現(xiàn)象Fig. 3 Failure phenomenon in case 2

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

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

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

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

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

4 信號智能化維護系統(tǒng)模型的建立

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

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

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

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

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

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

5 結(jié)語

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