郭媛忠

郭媛忠:北京鐵路局北京電務段 高級工程師 100054 北京

無線超時是CTCS-3級列車運行控制系統(tǒng)常見故障。所謂無線超時是指車-地連接通信中斷時間(T_NCVONTACT=20 s)大于20 s，就會導致列車常用制動。當列車運行速度降至CTCS-2級系統(tǒng)允許運行速度時，提示司機確認后，系統(tǒng)將自動轉(zhuǎn)換為CTCS-2級進行控車。

導致無線超時故障的原因有很多，大致可以包含3個方面，即車載設(shè)備故障、地面設(shè)備故障和GSM-R無線通信故障。本文將分析導致無線超時故障的地面設(shè)備原因和故障發(fā)生后列車的運行狀況。

1 無線超時故障地面設(shè)備原因

導致車-地通信無線超時故障的信號系統(tǒng)地面設(shè)備原因有2種，即聯(lián)鎖系統(tǒng)與RBC系統(tǒng)通信中斷或RBC設(shè)備故障。

1．聯(lián)鎖系統(tǒng)與RBC系統(tǒng)通信中斷。當聯(lián)鎖系統(tǒng)通信機故障或安全數(shù)據(jù)網(wǎng)故障時，RBC將無法獲得該聯(lián)鎖管轄范圍內(nèi)各進路狀態(tài)信息。聯(lián)鎖與RBC通信時間超過3 s(TRBCtimeout=3 s)，RBC判斷應用超時后，立即停止與行車許可已涉及該聯(lián)鎖控制區(qū)的列車通信，工作在CTCS-3級狀態(tài)的列車將使用原有的行車許可繼續(xù)運行。當車-地通信中斷時間超過20 s時，工作在CTCS-3級狀態(tài)的列車實施最大常用制動，速度降到CTCS-2級允許的運行速度后，自動轉(zhuǎn)換到CTCS-2級系統(tǒng)繼續(xù)工作。

2．RBC故障。RBC采用雙套冗余設(shè)備，如果2套設(shè)備均故障，則受其控制的列車中斷與RBC之間的通信連接，工作在CTCS-3級狀態(tài)的列車將使用原有的行車許可繼續(xù)運行。當車-地通信中斷時間超過20 s時，CTCS-3級狀態(tài)的列車實施最大常用制動，自動轉(zhuǎn)換到CTCS-2級系統(tǒng)繼續(xù)工作。

2 無線超時故障案例分析

無線超時故障發(fā)生后，針對不同型號列車、故障發(fā)生時列車所處位置、列車運行速度的不同，故障現(xiàn)象也不同。

2.1 300S型動車組無線超時后停車

1．過程分析。ATP 600721在18:07無限超時之后停在某分相區(qū)內(nèi)。通過回放再現(xiàn)故障時刻列車運行情況，可看出RBC2重啟導致該RBC管轄范圍內(nèi)的列車無線超時，一些列車降CTCS-2級運行，而G527次停車。

2．停車原因。ATP 600721裝配300S型車載設(shè)備，出站后不久18:07:34，列車由CTCS-2級轉(zhuǎn)為CTCS-3級，車速70 km/h，此時列車的移動授權(quán)已經(jīng)到了RBC1—RBC2邊界，但由于RBC2正在重啟，導致移交啟動失敗，RBC1不向列車發(fā)送消息，導致列車降級運行。實際上直到18:08:30，RBC1收到列車發(fā)送的最后一條位置信息時，顯示列車仍為CTCS-3等級，速度為10 km/h。18:08:51，列車發(fā)送M156結(jié)束通信會話，列車從RBC1中注銷。

ATP 600721次之所以停車，是由于剛出站列車速度低，在無線超時過程中制動時間過長導致。300S型動車組在20 s無線超時后，將繼續(xù)試圖連接RBC，并重復3次，約需40 s。這樣處理的好處是當40 s內(nèi)如果再次呼叫成功，列車可不降級，繼續(xù)以CTCS-3級運行。但由于此時ATP 600721列車運行速度較低，在60 s內(nèi)ATP持續(xù)輸出常用制動，并保持CTCS-3級運行，導致列車停車，并正好停在分相區(qū)內(nèi)。

300T型動車組在無線超時后，可經(jīng)過司機確認立即降為CTCS-2級運行。所以，裝載300T型車載設(shè)備的動車組都順利降為CTCS-2級后不停車通過了該分相區(qū)。可見，雖然同為無線超時故障，故障現(xiàn)象卻是因車而不同。

3．解決方案。導致RBC重啟的原因是由于RBC的軟件缺陷，需要通過修改軟件完成。在解決此缺陷前，若要解決300S因無線超時停在分相區(qū)內(nèi)的故障，可將出站后地面無源應答器組內(nèi)的P42【呼叫信息包】取消，使列車以CTCS-2級運行，至下一等級轉(zhuǎn)換點再進行等級轉(zhuǎn)換。

2.2 前車無線超時導致后車降速運行

1．過程分析。ATP 600251在RBC5管轄范圍內(nèi)，由于無法收到MA(行車許可)，于10:16:19開始減速，在10:20:55重新獲取 MA。從RBC的eventlog中可以看到如下過程。

1)對于前車 603031來說:10:15:12，RBC5收到前車 603031的 M136，NID_LRBG=9105951，D_LRBG=26，列車位于進路05549→05569。(NID_LRBG為列車最近通過的應答器編號，即最近相關(guān)應答器組編號，利用日志解析工具可換算出對應應答器的編號;D_LRBG為列車距LRBG的距離，據(jù)此可判斷出列車的位置)。

10:15:12，RBC5回復M24;之后RBC5再沒收到列車任何消息。由于列車通信異常中斷，RBC5將列車通信異常時所在進路05549→05569保留5 min再釋放。若在5 min之內(nèi)列車再次呼叫成功，則立即釋放進路。

2)對于后車 600251來說:10:15:05，RBC5收到列車 M136，NID_LRBG=9105689，D_LRBG=516;10:15:05，RBC5給列車發(fā)送MA，長度為17656 m，MA延伸至05549信號機處，如圖1所示。

圖1 后車600251MA示意圖

10:15:37，進路 05549→05569狀態(tài)變?yōu)門rain route(聯(lián)鎖送給RBC的進路狀態(tài)，即列車進路)，但是由于RBC5將此進路給前車603031保留5 min，所以MA無法延伸;直到10:20:53，前車603031從RBC5中徹底刪除，之前保留的進路被釋放。10:20:55，列車運行至進路05529→05549，由于 MA不能延伸，列車速度降至40 km/h，發(fā)送 M136，NID_LRBG=9105945，D_LRBG=427;10:20:55，RBC5給列車發(fā)送MA，長度為3162 m，延伸至RBC5—RBC6邊界，RBC5啟動移交;RBC5與RBC6的邊界在K556+918處，在移交之前，MA只能延伸至邊界。10:20:58，RBC5給列車正常延伸MA，長度為18517 m;之后列車正常運行。

2．故障特點。列車在CTCS-3級模式下因MA不能延伸降速運行，其原因卻是由前車無線通信超時引起。經(jīng)過車載、地面、通信等專業(yè)的聯(lián)合分析后，前車無線超時的原因為車載電臺故障。由此體現(xiàn)出無線超時所引起的故障現(xiàn)象是多么不同。

2.3 RBC與聯(lián)鎖通信中斷導致通信超時

1．過程分析。ATP 200631在某站進入1G時無線超時，列車輸出常用制動，降CTCS-2級運行。從RBC的eventlog中可以看到如下過程。

3:00:21通信會話開始，RBC接受列車正常注冊，正常執(zhí)行;

3:03:31報警:The session to ILOCK＊＊ is terminated;(＊＊代表某個站的名稱，比如北京南站，就表示為BJS等);

RBC系統(tǒng)與聯(lián)鎖的通信會話中斷后，停止向位于該聯(lián)鎖控制區(qū)域內(nèi)所有列車發(fā)送消息;停止向MA已經(jīng)延伸到該聯(lián)鎖控制區(qū)域內(nèi)所有列車發(fā)送消息。然后將所有來自該聯(lián)鎖的輸入置為安全狀態(tài)。

3:03:33，RBC向列車發(fā)送M24(地到車的通常消息);此時，列車前方信號機為＊＊＊＊%XI@＊＊＊＊;

3:03:34，列車向RBC發(fā)送M136(車載設(shè)備發(fā)送給RBC的列車位置報告)，RBC未回復;

3:03:39，列車向RBC發(fā)送M136，RBC未回復;

3:03:45，列車再次向 RBC發(fā)送 M136，RBC未回復;

3:03:51，列車向RBC發(fā)送M132(車載設(shè)備向RBC請求MA，當司機按壓啟動按鈕或者ATP中剩余的行車許可長度不足導致列車降速時，ATP應發(fā)送M132)，RBC未回復;

3:03:52，列車向RBC發(fā)送M136，RBC未回復;

3:03:53，的無線通信狀態(tài)變?yōu)閠imeout，列車前方信號機為＊＊＊＊%XI@＊＊＊＊;

3:04:11，列車向 RBC發(fā)送 M136，報告CTCS-2等級位置報告，無線超時。

2．故障特點。①MA覆蓋該聯(lián)鎖管轄范圍內(nèi)所有車次降為CTCS-2級運行;②RBC側(cè)接收到了來自車載的多條數(shù)據(jù)，但RBC在一段時間內(nèi)未向車載發(fā)送任何數(shù)據(jù)。

3．解決方案。從RBC的報警信息中，可看出RBC與聯(lián)鎖系統(tǒng)的通信中斷。聯(lián)鎖與RBC通過安全數(shù)據(jù)網(wǎng)相連，故應檢查安全數(shù)據(jù)網(wǎng)連接狀態(tài)?？赏ㄟ^安全數(shù)據(jù)網(wǎng)網(wǎng)管終端查看連接狀態(tài)，研究連接斷開的原因，盡快修復故障。若安全數(shù)據(jù)網(wǎng)工作正常，則檢查聯(lián)鎖機前置通信機的工作狀態(tài)，不良盡快處理。

3 總結(jié)

從以上案例的分析可以看出，分析人員只有具備一定的知識、技術(shù)能力，才能勝任日志分析工作?；疽蟀?①應有一定的英語翻譯和理解能力，通過日志文件讀懂故障提示信息;②應熟練掌握車-地無線通信中，各種消息、信息包及變量的含義;③應掌握車-地通信周期等技術(shù)指標。

日志分析過程中，還應掌握一些技巧:

1．日志下載完成后，應首先通過維護終端的回放功能，查看故障發(fā)生時刻，故障車次所在區(qū)域列車的運行情況。檢查受影響的是一列車還是多列車。

2．必要時，還需分析相鄰運行列車的日志。

3．查看在故障發(fā)生時刻，RBC邊界處是否正有列車在進行移交。

4．學會利用日志分析軟件中的快捷工具，提高分析質(zhì)量，快速定位故障原因。

5．JRU的日志可隨時下載，但eventlog只有在“天窗”點內(nèi)才可下載。

6．充分利用DMS等監(jiān)測工具，全面查看相關(guān)設(shè)備的工作狀況。

［1］中華人民共和國鐵道部.鐵科技［2008］127號．CTCS-3 級列控系統(tǒng)需求規(guī)范(SRS)(V1．0)［J］．2008.

［2］中華人民共和國鐵道部.CTCS-3級列控系統(tǒng)總體技術(shù)方案［M］．北京:中國鐵道出版社，2011.