王天鳴
(國家鐵路局裝備技術(shù)中心,北京 100891)
無線閉塞中心(RBC)是基于故障安全計算機(jī)平臺的信號控制系統(tǒng),屬于CTCS-3級列控系統(tǒng)的地面核心設(shè)備。RBC根據(jù)所控制列車的狀態(tài),其控制范圍內(nèi)的軌道占用、列車進(jìn)路狀態(tài)、臨時限速命令、災(zāi)害防護(hù)和線路參數(shù)等信息,產(chǎn)生針對所控列車的移動授權(quán)(MA)信息,并通過GSM-R無線通信系統(tǒng)傳輸給車載子系統(tǒng),保證其管轄范圍內(nèi)列車的運行安全[1]。RBC發(fā)生故障會導(dǎo)致車地通信超時或中斷,使列車由CTCS-3降為CTCS-2,還可能會觸發(fā)制動、緊急停車,給其運營帶來很大影響。
RBC故障分為RBC本身系統(tǒng)故障,如RBC重啟、RBC內(nèi)部交換機(jī)死機(jī)、鏈接線纜松動等;以及RBC在與其他設(shè)備通信時發(fā)生的故障,如RBC與聯(lián)鎖通信中斷、RBC與列車通信故障、RBC與臨時限速服務(wù)器(TSRS)通信故障等。其中,RBC在與其他設(shè)備方面故障占大部分。通過對RBC日志的分析,能深入了解RBC故障的成因,提高分析質(zhì)量、優(yōu)化列控系統(tǒng),快速定位故障原因[2]。
在正常移交通信過程中,列車從RBC1駛?cè)隦BC2管轄范圍,在列車移動授權(quán)(MA)到達(dá)切換應(yīng)答器時,RBC1會向RBC2發(fā)移交預(yù)告信息(M201),申請進(jìn)路信息。RBC2接收到RBC1發(fā)出的M201后,發(fā)送確認(rèn)信息(M205)對信息進(jìn)行確認(rèn)。RBC1根據(jù)從RBC2接收到的進(jìn)路信息,發(fā)送移動授權(quán)請求信息(M202),RBC2接收到M202后根據(jù)范圍內(nèi)的進(jìn)路狀態(tài),發(fā)送移動授權(quán)信息(M221),RBC1發(fā)送M205對M221進(jìn)行確認(rèn)(見圖1)。
圖1 RBC正常移交通信場景
當(dāng)列車距移交邊界小于一定距離(根據(jù)線路配置),向列車發(fā)送RBC移交命令(P131),列車給RBC1發(fā)送確認(rèn)信息(M146)和位置報告(M136),列車2電臺與RBC2建立通信會話,RBC2給列車發(fā)送移動授權(quán),在列車到達(dá)移交邊界前,車載設(shè)備繼續(xù)使用RBC1提供的行車許可(MA)。
當(dāng)列車達(dá)最大安全前端通過切換應(yīng)答器,列車分別向兩個RBC發(fā)送M136,當(dāng)RBC1收到M136后若之前未收到RBC2發(fā)來的列車接管信息(M222),則RBC1向RBC2發(fā)送移交通告信息,停止向RBC2請求進(jìn)路信息。
若RBC1先收到RBC2發(fā)來的列車接管信息,則移交結(jié)束。RBC2接管列車后,RBC1向車發(fā)送消息終止會話通信(P42),列車回復(fù)通信會話結(jié)束(M156),RBC1發(fā)送會話結(jié)束確認(rèn)(M39),至此完成RBC1到RBC2的移交[3-4]。
舉例說明:16:30左右,列車10030291運行至K2214+ 248處未收到來自RBC的消息,后轉(zhuǎn)C2,RBC發(fā)送斷開命令,與車斷開鏈接。
打開日志相應(yīng)時間段的RBC日志,選擇類型“alarmgroupil_ad_crsc_a”“iladcrscsam”“stpdatatotrain”和“stpdatafromtrain”,過濾日志,選擇車載標(biāo)識10030291,同時選擇查看“alarmgroupil_ad_crsc_a”類型。
進(jìn)入Alarms信息,導(dǎo)入報警日志信息,可以看到16:29:21時RBC的報警信息:
The session to ILOCKGZN is terminated,consequence=No data have been received from ILOCKQY in 3500 milliseconds.The session to ILOCKQY is terminated,consequence=No data have been received from ILOCKQY in 3500 milliseconds.
通過報警告信息可知16:29:21,RBC8與聯(lián)鎖斷開連接。此時,列車10030291的位置報告顯示:
NID_MESSAGE=136,L_MESSAGE=24,T_TRAIN=1521067,NID_ENGINE=10030291,NID_PACKET=0,L_PACKET=114,Q_SCALE=1,NID_LRBG=9385759,D_LRBG=601,Q_DIRLRBG=1,Q_DLRBG=1,L_DOUBTOVER=30,L_DOUBTUNDER=29,Q_LENGTH=0,V_TRAIN=69,Q_DIRTRAIN=1,M_MODE=0,M_LEVEL=3
可知,列車的位置為K2214+823,速度為69×5=345km/h,在清遠(yuǎn)管轄范圍內(nèi),此時RBC回復(fù)一條M24后不再給列車發(fā)送任何信息。
列車20s之內(nèi)沒收到RBC的消息,認(rèn)為無線超時,執(zhí)行常用制動,于16:30:08速度降到300km/h以下,模式為C2。
16:30:12,報警信息顯示,清遠(yuǎn)和廣州北聯(lián)鎖與RBC重新建立連接:
The connection to ILOCKQY is established.
The connection to ILOCKGZN is established.
16:30:20,RBC恢復(fù)工作,向已處于C2的列車發(fā)送斷開命令,列車與RBC正常斷開。
RBC和聯(lián)鎖通信中斷,使RBC無法獲得其管轄范圍內(nèi)各進(jìn)路狀態(tài)信息,RBC立即停止與行車許可(MA)已涉及該聯(lián)鎖控制區(qū)的列車通信,不向列車發(fā)送任何消息。
時間15:32,列車10030172上行過RBC6/5移交點,此后由于列車故障停車后重啟,目視轉(zhuǎn)完全后收到一條很短的MA,行駛至衡山接近MA終點處,關(guān)機(jī)轉(zhuǎn)C2(見圖2)。
圖2 列車與RBC通信錯誤導(dǎo)致行車許可縮短
列車已過RBC6/5移交點,重新啟機(jī)轉(zhuǎn)完全監(jiān)控模式收到很短的MA,查看RBC5所發(fā)的MA是否準(zhǔn)確。
查找15:00:00至16:00:00時的RBC5日志。從RBC5所解析的數(shù)據(jù)看到,10030172與RBC5在15:30:46建立連接(M155,RBC6/5移交預(yù)告點),15:33:48斷開連接(列車故障點),而15:33:48之后列車與RBC5無任何消息。由于列車處在RBC5和RBC6的套袖區(qū)內(nèi),而列車能收到MA,則有可能是RBC6所發(fā)。因此,還要查看RBC6的數(shù)據(jù),列車10030172與RBC6于15:32:19斷開連接(RBC6/5移交執(zhí)行點),15:43:37重新建立連接,如下所示:
15:47:50,SR(目視)模式過9381138(9490,K1737+843),報告有效位置。
15:48:08,RBC6給車發(fā)送MA,NID_LRBG=9381138(9490,K1737+843),EOA為K1725+219,該點RBC6上行所管轄的終點。
15:54:11,列車停于K1725+416處。
因此,可以判斷列車故障重啟后本應(yīng)呼叫RBC5,卻錯誤地輸入了RBC6的ID和電話號碼,由于已接近RBC6邊界,導(dǎo)致列車收到的MA短。
利用RBC日志分析列車的問題,下載數(shù)據(jù)量小、診斷效率高、方便易操作、隨時都可在司法記錄單元下載數(shù)據(jù)進(jìn)行分析,但因列車通信傳輸問題處理涉及通信、地面、車載3個業(yè)務(wù)口,部分問題需要跨鐵路局協(xié)調(diào)解決,分析處理還需要相關(guān)單位密切配合。RBC的日志分析可以初步確定問題部門,好為下一步處理指明方向,使部門間提高處理效率,降低對列車運行的影響。