兩起時間戳引起的RBC移交典型案例分析

趙紅霞，馮 飛

（中國鐵路上海局鐵路集團有限公司徐州電務段，江蘇徐州 221000）

無線閉塞中心（RBC）是CTCS-3 級（簡稱C3）列控地面的核心設備，為列車提供行車許可。其中RBC 的移交是CTCS-3 級中非常重要的一個運行場景，移交過程中會牽涉到移交RBC、接受RBC 和列車三者的信息交互，過程復雜。過程中出現問題經常會引起列車常用制動，造成無線超時降級，甚至停車。所以分析清楚移交過程，找到列車降級原因，做好防范措施，對于維護人員具有重要意義。

1 RBC移交概況

根據C3 級列控總體技術方案[1]，RBC 移交目前有兩種方式。一種是采用通過聯鎖間接聯系，武廣高鐵就是采用的這種方式，移交場景如圖1 所示。聯鎖與RBC 之間通信采用單點連接方式，當一個RBC 需要兩個聯鎖信息時，另一個聯鎖信息通過車站TCC 傳輸至該聯鎖。該種方式是特殊情況下需要主管部門批準。

另外一種是RBC 之間通過信號安全數據網絡通信，如圖2 所示。每套RBC 均采用兩套獨立的安全數據網交換機，通過光電模塊轉換成光纖信號進入安全數據網絡，與TSRS、相鄰RBC 和CBI 通信，目前主要是采用這種直接通信方式。

圖1 RBC間間接移交示意圖Fig.1 Schematic diagram of indirect handover among RBC

圖2 RBC間直接通信示意圖Fig.2 Schematic diagram of direct communication among RBC

2 RBC移交場景過程分析

2.1 雙電臺正常的移交過程

列車以C3 等級在RBC1 范圍內運行時，當MA終點達到RBC 移交邊界時，RBC1 向RBC2 發送M201。RBC1 收到RBC2 的回復信息M205 后，申請進路信息M202，同樣也需要接受RBC 確認。

RBC2 接收到M202 后，則根據控制范圍內進路信息向RBC1 發送M221。

RBC1 收到M221 后，便可以將MA 延伸到RBC2 的范圍。

期間兩個RBC 之間保持通信，M202、M205、M221 3 個消息周期性的循環。如果RBC2 內進路有變化，要及時的發送給移交RBC1。

RBC1 判斷列車距離向列車發送P131。

列車根據RBC1 提供的電話號碼，啟動電臺2開始呼叫RBC2 并建立通信會話。列車與RBC2 建立連接后，要向RBC2 發送列車位置報告，在RBC2能夠對列車準確定位后，可以向列車發送MA。

列車繼續前行，在到達移交邊界前，均受RBC1 控制。

當列車最大安全前端通過切換應答器，車載設備向兩個RBC 發送基于該應答器的位置報告，同時車載設備應開始僅接受RBC2 控制。

如果RBC1 先收到位置報告，則向RBC2 發送移交通告信息，并停止向RBC2 請求進路信息，也丟棄RBC2 發送的進路信息；如果RBC1先收到RBC2 列車接管信息，則認為移交結束。

當列車最小安全末端通過切換應答器，車載設備向RBC1 發送位置報告，RBC1 將向車載設備發送消息終止通信會話（信息包42）[2-3]。

2.2 單電臺正常的移交過程

此前移交過程和雙電臺一致，直到列車最大安全前端通過切換應答器，車載設備只會向RBC1 發送基于該應答器的位置報告[4-6]。

RBC1 收到位置報告后，向RBC2 發送移交通告信息。

列車尾部通過移交應答器組后，處于休眠模式的車載設備記錄RBC2 的呼叫信息。

當列車最小安全末端通過切換應答器，車載設備向RBC1 發送基于該應答器的位置報告。

當RBC1 接收到位置報告后，將向車載設備發送消息終止通信會話（信息包42）。

根據RBC1 提供的電話號碼，車載設備開始呼叫RBC2 并建立通信會話。

RBC2 發送MA 并監控列車運行，至此完成RBC1 到RBC2 的移交。

2.3 雙電臺和單電臺過程對比

通過上述雙電臺移交和單電臺移交的過程分析，可以發現這兩個場景的RBC 移交過程的共同點是都需要經過3 個過程[7-8]：開始移交并獲得跨越RBC 移交點的MA，注冊到GSM-R 網絡，脫離移交RBC 控制和接受接管RBC 控制。

第一個移交都是從MA 達到RBC 分界點開始，移交RBC 和接管RBC 開始啟動移交程序。包括移交預告、應答、移交請求信息和授權相關信息，這樣 MA 就可以延伸跨越分界點。

第二個都需要與接收RBC 建立連接并開始通話，建立連接首先需要注冊到GSM-R 網絡，由于在中國CTCS-3 級線路上所有無線閉塞中心（RBC）都連接到相同的GSM-R 無線網絡上（同一個GSM-R 運營商網絡），RBC 移交正常情況不需要考慮任何新的GSM-R 無線網絡注冊。然后都是根據RBC1 提供的P131 包中的信息獲取RBC2 電話號碼。

第三個都是需要有一個斷開與移交RBC 的連接和與接管RBC 建立連接的過程。

不同點是雙電臺的移交過程中，當收到移交RBC 發來的P131 包以后，是有兩個電臺同時工作，一個與移交RBC 通信的同時，另一個與接管RBC通信。而單電臺的移交過程中，由于只有一個電臺，需要先與移交RBC 斷開通話，再通過該電臺建立與接收RBC 通話。并且雙電臺移交過程中當列車經過移交點后，就應該僅接受RBC2 的控制。而單電臺移交是過了移交點后列車還是繼續使用RBC1之前給的MA，直至與RBC1 斷開連接。通過分析可以看出，雙電臺移交是可以保證列車一直與RBC通信通過移交點。但是單電臺必然會在移交區出現列車降級現象，而且通過DMS 上可以看到該列車每次經過移交區都會出現降級現象。

3 典型案例分析

3.1 時間戳溢出導致移交超時

3.1.1 故障概況

2019 年在鄭徐線路中，發生列車由CTCS-3 級降到CTCS-2 級現象。通過DMS 查看回放記錄，發現降級點在K199-200 之間，處于鄭徐RBC3 和京滬RBC7 的移交范圍內。

3.1.2 故障分析

下載鄭徐RBC3 的EVENTLOG 日志，對日志進行解析和篩選，篩選出所有移交日志，在日志類型中選中M201、M202、M203、M204、M205、M221、M222、M223 和stpdatatotrain、stpdatafromtrain，總共包含所有車地之間交互信息和RBC 移交的全部信息日志。根據降級時間查看相應時間段的日志可發現 ：

12:18:04 JHRBC7 向 ZXRBC3 發送 M201，啟動 G1807 列車的移交信息，說明京滬RBC7 是移交RBC，向接管鄭徐RBC3 發送了移交預告，標志著移交的啟動開始；

之后JHRBC7 收到ZXRBC3 發送的M205確認，又向ZXRBC3 發送M202 進路申請信息，ZXRBC3 向JHRBC7 發送M221 信息，期間一直是M205,M221 循環發送，確保RBC 之間移交通信正常，也可以確保接管鄭徐RBC 內如果進路信息發生變化可以及時傳給移交京滬RBC。

12:23:44 JHRBC7 發 送M205 至ZXRBC3，nT_RBC = 4294967295；

12:23:44 JHRBC7 發 送M221 至ZXRBC3，nT_RBC = 0；

12:23:44 查看C 類報警，12:23:46 鄭徐RBC3中出現alarmgrouprim_a 報警信息，顯示Message discarded，表示鄭徐RBC3 接受到信息校驗不合格，進行丟棄；

12:23:49 ZXRBC3 通信計時器超時（RBC間通信時間超過5 s），導致列車由 JHRBC7 向ZXRBC3 移交失敗，移交RBC 不在向列車發送任何消息，然后列車由于無線超時降級C2 運行。

3.1.3 故障原因

按照RBC-RBC 接口規范，RBC 移交連續消息中的時間戳應保持遞增，時間戳不一定是真實時間，單位是10 ms，最大值是4 294 967 295。此次移交過程中京滬RBC 的nT_RBC=0，出現了時間戳溢出的現象，導致發給相鄰 RBC 信息的時間戳跳變，相鄰鄭徐RBC 認為該消息不合法，丟棄該信息，引起正在移交的列車移交失敗，無線超時轉 C2運行。

3.1.4 解決措施

目前這個現象無法解決，需要更新RBC 版本才可以，但是為了避免以后再次出現這類現象，維護人員可以在大概497 天之內對雙系RBC 進行重啟，因為RBC 雙系重啟會清除所有的動態數據。

3.2 時間戳誤判導致移交超時

3.2.1 故障概況

2019 年在鄭徐線K203，處于鄭徐RBC 向徐鹽RBC 移交范圍，11:56 鄭徐RBC3（通號產品）與徐鹽RBC1（鐵科產品）移交超時，導致MA 縮短。

3.2.2 故障分析

由于該移交超時牽涉到兩種廠家的RBC，所以需要分別下載通號和鐵科日志進行分析。

11:52:44 鐵科RBC 收到M201，說明移交開始啟動，網絡通信正常。

11:53:50 至11:55:50，鄭徐RBC 和徐鹽RBC都進行正常的時鐘偏移更新，徐鹽RBC 也做了應答。移交鄭徐RBC3 已經把MA 延伸到徐鹽RBC1管轄范圍內。

11:56:04 鄭徐RBC3 在安全連接斷開前收到徐鹽RBC1 發來的M221 消息，同時并回復M205 消息。

11:56:05，鄭徐RBC3 向徐鹽RBC1 發起斷開連接信息stpdisconnectreq，同時徐鹽RBC1 收到DI 斷開連接消息。

11:56:06 在RBC 維護終端數據上查看NRBC連接狀態是0x00，表明徐鹽RBC 與鄭徐RBC 斷開連接。

11:56:07 徐鹽RBC1 收到連接斷開后，立即斷開TCP 連接并重新建立TCP 重連，并三步握手成功。

11:56:08 徐鹽RBC1 作為交權接收方，日志中取消原因是0x04,表明在一定時間內未收到NRBC消息，判斷通信異常，取消3552 車的移交。

11:56:11 徐 鹽RBC1 向 鄭 徐RBC3 發 送 了AU1，建立安全連接，回復通信數據，并向鄭徐RBC3 發送M204 消息。

11:56:13 重新連接成功后，鄭徐RBC3 收到徐鹽RBC1 的第一條信息是M204，即整個中斷過程是9 s，超過RBC 間移交超時規定值，導致移交超時。

3.2.3 故障原因

這次導致MA 縮短的故障原因從日志角度分析是鄭徐RBC 和徐鹽RBC 移交超時，徐鹽RBC1 向鄭徐RBC3 斷開連接后重連并發送M204 取消移交。深層次原因通過安全數據網抓包才發現的。目前中國鐵路通信信號股份有限公司的RBC 和中國鐵道科學研究院集團有限公司的RBC 都是采用RSSPII 協議中的TTS 通信方式，需要雙方進行時鐘偏移機制。通過抓包發現，徐鹽RBC1 向鄭徐RBC3 發送3 包應用數據（序號是22816,22824,22834），徐鹽RBC1 發送的時鐘偏移更新請求（序號22860），這四個包時間戳均為0x1c3919a9，在徐鹽發出時鐘偏移更新請求22860 的同時，鄭徐RBC3 發送時鐘偏移更新請求22874，由于在此之前已經收到需要RBC1 時間戳0x1c3919a9 的應用數據，22874中上一次接收方時間戳設置為0x1c3919a9，導致徐鹽RBC1 誤認為是鄭徐RBC3 發送的22874 是對22860 的時鐘偏移更新應答。而鄭徐RBC3 發送的真正時鐘偏移應答22877 又被徐鹽RBC1 誤認為是下一次時鐘偏移請求，導致無法通過鄭徐RBC3 的安全校驗，經過多次這種請求信息和應答信息的誤判，雙方均不停的發送請求信息，而不處理應答信息，鄭徐RBC 無法完成時鐘偏移更新，最終導致鄭徐RBC3 向徐鹽RBC1 發送斷開連接通知，兩個RBC 間安全連接中斷。但是時鐘偏移引起的RBC間安全連接斷開，如果安全連接斷開后重新建立連接的時間小于RBC 判斷應用超時的時間，該中斷不會影響RBC 間通信，所以此時鄭徐RBC 給列車的MA 不會縮短至移交邊界，直到鄭徐RBC3 收到徐鹽RBC 發送的M204，鄭徐RBC3 將MA 縮短至邊界，造成列車ATP 緊急制動停車。

3.2.4 解決措施

針對以上問題，設備維護單位組織相關設備廠家進行分析討論，提出以下兩點解決措施。

一個是在故障分析中可以得知，11:56:07 徐鹽RBC1 三步握手成功，但是11:56:11 徐鹽RBC1 才向鄭徐RBC3 發送了AU1 建立安全連接，中間過了4.1 s，如果在握手成功后立即發送AU1，則安全連接中斷時間可以壓縮到5 s。所以建議徐鹽RBC 修改應用層判斷超時時間，由原來的5 s 改為7 s，這樣應用層不會判斷異常，造成超時。

另一個是修改判斷應用層連接超時后不發送M204 消息，這樣即使發生RBC 通信中斷的情況，列車會無線超時降至C2 級運行，不會觸發緊急制動停車。

4 結束語

通過對RBC 移交過程的分析，總結出移交過程中關鍵點，并對雙電臺和單電臺進行了對比。同時結合現場RBC 移交超時日志分析，對時間戳以及由于時間戳引起的故障進行說明分析，并提出解決措施，對此后維護人員分析移交中出現的降級現象提供借鑒。