CBTC 信號(hào)系統(tǒng)智能化故障分析

陳靜梅

（鄭州地鐵集團(tuán)有限公司運(yùn)營分公司，鄭州 450000）

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

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

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

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

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

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

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

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

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

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

2.3 信號(hào)設(shè)備監(jiān)控

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

3 信號(hào)設(shè)備智能診斷的可行性分析

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

3.1 日志的時(shí)間特征

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

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

3.2 日志的密度和種類特征

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

3.3 日志的嚴(yán)重等級(jí)

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

3.4 日志的空間維度和時(shí)序特征

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

3.4.1 典型故障案例1

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

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

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

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

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

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

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

3.4.2 典型故障案例2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)語

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