特殊場景下RBC移交過程中導致MA無法延伸問題的優化

李 礫 中國鐵路上海局集團有限公司電務處

眾所周知，我國高速鐵路營業里程在不斷增長，高速鐵路在我國進入了黃金發展階段，CTCS-3級列控系統在我國高速鐵路上廣泛運用，其主要特點是基于GSM-R無線通信實現車-地信息雙向傳輸，無線閉塞中心（RBC）生成行車許可（MA），軌道電路實現列車占用檢查，應答器實現列車定位，并具備CTCS-2級功能的列車運行控制。

RBC是CTCS-3級列控系統地面核心設備，根據聯鎖、臨時限速服務器、其他地面設備和車載設備提供的信息，生成列車行車許可，并通過無線通信方式發送給車載設備，以控制列車的安全追蹤運行。由于單個RBC處理能力有規定限度，因此按照高速鐵路運營里程的不同，每條線設置的RBC數量也不同，RBC與RBC之間需要進行信息移交，但是RBC之間在進行移交過程中，由于運營場景的特殊性，偶爾會發生在RBC移交過程中，其發給車載設備的MA會無法延伸，從而導致動車組列車停車。現以合福高鐵RBC1（通號RBC-TH型）與合蚌高鐵RBC2（通號RBC-TH型）之間移交過程中，特殊場景下兩個RBC之間移交時MA無法延伸問題為例，來分析問題的優化解決方案。

1 問題描述

2017年6月12日,G272次 (合肥南-北京南，CRH380B-3721動車組00端擔當,300T型ATP車載設備)在合肥南合福場始發后，18∶30因ATP顯示運行速度為零，停在合肥西合福場至合肥北城站間上行線K980+070處，司機改目視行車后，18∶37開車，運行一個閉塞分區后恢復正常。

經對RBC記錄日志并結合ATP車載設備JRU記錄數據綜合分析發現，CRH380B-3721動車組00端擔當G7418次運營交路17∶11∶59抵達合肥南站后，計劃接開G272次自合肥南站開往北京南站。此時ATP一直保持開機狀態，且處于C3等級完全監控模式。17∶57∶41司機進行列車數據的輸入，此時輸入車長為210 m，17∶58∶00司機再次進行列車數據的輸入，此時輸入車長為420 m，至信號開放（出站信號于18：11：56開放）前，司機未再次對ATP進行操作。18∶11∶56出站信號開放，根據RBC邏輯，G272次列車MA達到RBC移交啟動條件，此時開始啟動合福RBC1向合蚌RBC2移交過程。但是，18∶15∶25司機第三次進行列車數據的輸入，此時輸入車長為210 m。18∶17∶06 發車，運行至 18∶29∶39 停車。

圖1 場景示意圖

如圖1所示，列車停于站內，當發車信號機開放后，列車的MA延伸致RBC邊界（K979+886處），移交RBC（合福RBC1）從而啟動與接收RBC（合蚌RBC2）的移交。

從RBC日志中看，18∶12∶45，列車的行車許可延伸至移交邊界，MA長度為19.541 km。

NID_MESSAGE=3, L_MESSAGE=202,T_TRAIN=1117136,M_ACK=1,NID_LRBG=5786966,NID_PACKET=15,Q_DIR=1,L_PACKET=88,Q_SCALE=1,V_LOA=0,T_LOA=1023,N_ITER=0,L_ENDSECTION=19541,Q_SECTIONTIMER=0,Q_ENDTIMER=0, Q_DANGERPOINT=1, D_DP=0,V_RELEASEDP=127,Q_OVERLAP=0,…

由于在RBC軟件配置的MA最大長度參數為20 km，因此，移交啟動后，合蚌RBC2向合福RBC1發送的授權相關信息請求（M202）的長度為459 m（即請求的長度=MA最大長度-移交RBC范圍內的MA長度=20000-19541=459）；

nid_message= Route Related Information Request,nRbcNID_C=597,nNID_RBC=1,nNID_ENGINE=337212,nBg－NID_C=698,nNID_BG=2820,nT_RBC=1311025156,nM_ACK=1,nD_REMAINDISTANCE=459,nN_REMAINEOAINTERVALS=31,…

合蚌RBC2收到該授權相關信息請求后，判斷請求的長度小于其管轄范圍內第一個閉塞分區（即RBC邊界順著列車運行方向前方第一個閉塞分區，長度為1 949 m）的長度，因此，發送長度為0 m的授權相關信息（M221），列車的行車許可終點仍然為移交邊界。

此后，18∶15∶25司機第三次進行列車數據的輸入，修改列車車長為210 m，列車向移交RBC重新發送列車數據消息（M129），合福RBC1向列車發送確認列車數數據消息M8。

2 原理分析

RBC-TH型RBC之間取消與重新啟動移交的設計邏輯和接口規范如下∶

（1）待移交RBC收到M8消息的確認后，應向列車發送SMA，終點縮短到邊界;

（2）待收到SMA的確認后，移交RBC向接收RBC發送M204取消移交。

（3）移交取消后，移交RBC收到列車的位置報告后，重新啟動移交，并向接收RBC發送新的移交預告消息（M201），該消息中將最新的列車數據告知接收RBC；（注：列車數據（P11包）只能隨M201消息發送給接收RBC，且只在移交啟動時發送一次）。

此時，合福RBC1收到車載發送M8確認消息后，應向列車發送SMA，將MA終點縮短到RBC邊界，但是實際上合福RBC1未發送SMA，根據上述 RBC設計邏輯和接口規范第1、2條，合福RBC1就無法向合蚌RBC2發送M204取消移交消息，最終導致列車的MA一直停留在RBC移交邊界。

正常情況下，移交RBC與ATP、接收RBC之間的消息交互流程如圖2所示。

圖2 RBC與ATP、接收RBC之間的消息交互流程圖

但此時由于列車行車許可的終點恰好是移交邊界，即與待發的SMA的終點相同，合福RBC1沒有向列車發送SMA。而按照當前RBC的設計邏輯，在列車運行模式、等級未發生變化的情況下，只有收到列車對SMA的確認的情況下，才會取消移交。而在上述場景中，由于未發送SMA，也因此無法觸發發送M204的機制，移交無法取消。

6月12日，合福高鐵RBC1與合蚌高鐵RBC2實際之間的消息交互流程如圖3所示。

圖3 本特殊場景下RBC與ATP、接收RBC之間的消息交互流程圖

移交無法取消，導致新的列車數據無法告知接收RBC，而列車長度又是一個涉及安全的參數，因此，移交RBC不向接收RBC發送新的授權相關信息請求消息（M202），接收RBC仍然按照之前收到的M202消息中的參數發送RRI，即長度一直為0。

3 原因分析

因此，通過上述分析，不難得出上述特殊場景下RBC移交過程中導致MA無法延伸問題的原因：

（1）技術層面（直接原因）：一是合福RBC1收到車載M8消息的確認后，未向列車發送SMA，后續RBC之間的移交流程無法取消，導致新一輪重新移交流程無法啟動。二是RBC軟件配置的MA最大長度參數為20 km，當MA正好跨一個閉塞分區且RBC邊界點正好在該閉塞分區入口處時，導致MA終點與RBC邊界點重合。

（2）操作層面（間接原因）：在合肥南站24道出站信號開放前后，司機在ATP設備DMI上頻繁修改列車長度數據，尤其在信號開放后仍在修改列車長度數據引發了上述RBC技術層面的問題。

4 處置措施

在原因清楚的基礎上，制定解決該問題的措施就十分清晰了：

（1）修改RBC邏輯，即當合福RBC1收到車載M8消息的確認后，不論列車行車許可的終點是否在移交邊界，都應向ATP車載設備發送SMA消息，從而可以啟動后續重新移交的流程。

（2）修改RBC配置的MA最大長度，及將20 km的MA長度適當延長或縮短，使其能夠覆蓋RBC移交邊界點前后一個閉塞分區長度。

（3）明確司機在ATP設備DMI上修改列車數據的時機，在C3完全模式下，盡量不要修改列車數據，如果需修改列車數據，應重啟ATP設備后再進行修改。

綜合評估對比上述三條措施：雖然第3 條措施不涉及設備修改工作，只是通過司機操作來避免問題的發生，但是由于設備問題給司機操作帶來了不必要的多余操作，站在機務專業角度看，不具備可實施性；第1 條措施涉及到RBC 軟件邏輯功能的修改，軟件變動內容較大，帶來的不可預知風險會增；第2 條僅修改RBC 的MA 最大長度參數，參數修改工作量小，實施便捷，風險小。因此，上述第2條措施為最佳措施。

5 總結

隨著我國高速鐵路的不斷建設并投入運營，高速鐵路融匯貫通、交叉互織已成為新常態，復雜的線路條件勢必會產生各種特殊場景，特殊場景下的新問題也會不斷涌現，通過問題表象去綜合分析并挖掘引發問題的本質是各級高鐵電務維護管理人員必須具備的意識和素質，只有把握住了問題的本質，問題的解決也就迎刃而解了。