列控系統通信中斷問題的分析與思考

王先帥 中國鐵路上海局集團有限公司電務部

目前，采用CTCS-3 級列控系統構建的錯綜復雜的高速鐵路網已實現互聯互通。但隨著新線路的陸續開通，線路上不同廠家設備并存的現象越來越普遍，設備間的接口也越來越多，越來越復雜。我國高速鐵路交叉成網、運輸密度高、運營場景復雜，在某些特定的場景下，設備之間通信不匹配的問題偶有發生。筆者結合管內設備運行情況，對兩起設備間通信中斷問題進行分析與探討。

1 故障一：相鄰RBC 間通信中斷

1.1 概況

徐鹽鐵路引入徐州東樞紐時，對徐州東樞紐地區的RBC管轄范圍做過適應性調整，調整后的RBC 管轄情況見圖1。

圖1 徐州東樞紐RBC 管轄范圍示意圖

其中，徐鹽RBC1 為鐵科院產品，首次在管內運用。鄭徐RBC3 為通號院產品，2015 年開通運用至今。兩個RBC 的切換點位于徐蘭高速徐州東線路所至銅山線路所之間。

徐鹽RBC1 開通后，動車組在徐蘭高速上行線運行，會偶發以下故障：當運行至鄭徐RBC3（移交RBC）與徐鹽RBC1（接收RBC）移交區時，由于兩個RBC 之間通信中斷，導致ATP 車載接收的MA 突然縮短，造成列車緊急制動停車。

1.2 原因分析

為切實找準故障原因，對安全層數據和應用層邏輯進行分析，以2019 年10 月24 日發生的故障為例進行探討。

（1）安全層數據分析情況：雙方RBC 采用RSSP-II 協議，使用TTS 通信方式。在TTS 通信方式下，相鄰RBC 通過定期互相發送時鐘偏移信息實現握手，其中時鐘偏移請求和時鐘偏移應答信息格式完全相同。

對故障時刻安全數據網的數據抓包見圖2。

圖2 安全數據網抓包數據

根據抓包數據，徐鹽RBC1 發送3 包應用數據（抓包序號22816、22824 和 22834）后，隨即發送了時鐘偏移更新請求（抓包序號22860），經調閱分析，這四包數據的時戳均為0xlc3919a9。

在徐鹽RBC1 發出時鐘偏移更新請求（22860）的同時，鄭徐RBC3 發送了時鐘偏移更新請求（22874）。由于在此前已收到徐鹽RBC1 時間戳為0xlc3919a9 的應用數據（22816、22824和 22834），（22874） 中“上一次接收方時間戳”設置為0xlc3919a9，導致徐鹽 RBC1 誤認為鄭徐 RBC3 發送的（22874）是對（22860）的時鐘偏移更新應答，徐鹽RBC1 判斷時鐘偏移更新流程完成。而鄭徐RBC3 發送的真正時鐘偏移更新應答（22877）又被徐鹽RBC1 認為是下一次時鐘偏移請求，徐鹽RBC1 針對誤認的請求信息（22877）發送新的時鐘偏移應答數據。由于存在這種錯位誤判，在后續的信息交互中，兩RBC 均把對方RBC 發送的“應答信息”誤判成“請求信息”，均認為對方RBC 不停的發送“請求信息”而不處理本RBC 發送出去的“應答信息”，鄭徐RBC3 無法完成時鐘偏移更新，直至鄭徐RBC3 第五次發送“請求信息”超時后，向徐鹽RBC1 發送中斷通知（DI），兩 RBC 通信中斷。

（2）應用層邏輯分析情況：鄭徐RBC3 與徐鹽RBC1 通信中斷后，鄭徐RBC3 啟動C3 降C2 流程；10S 后，徐鹽RBC1發送AU1，重新建立安全連接，與鄭徐RBC3 通信連接恢復正常，并向鄭徐RBC3 發送“取消移交”指令；鄭徐RBC3 采用“取消移交”指令，將MA 縮短至RBC 邊界，造成ATP 車載設備接收的MA 突然縮短。

通過上述分析，可以看出問題的根本原因在于雙方RBC均不能準確區分對方發送來的時鐘偏移請求和時鐘偏移應答信息。

實際上，為準確區分時鐘偏移請求、時鐘偏移應答信息，通號院RBC 和鐵科院RBC 也均采取了相應措施。通號院RBC 通過優化協議棧的方式，區分同一周期內不同消息的時間戳；鐵科院RBC 增加了對時鐘偏移信息的防護機制。因此同型設備之間互相通信時，不會發生類似問題。但在互聯互通場景中，兩家設備間互相通信時，由于采取的措施不同，則無法準確區分對方發來的時鐘偏移信息。

1.3 解決方案

鑒于平臺原因及修改底層數據的難度，經通號院、鐵科院通號所共同研究，雙方RBC 在以下方面進行優化，以解決該問題。

（1）安全層方面，優化修改通號院RBC。目前通號RBC 與鐵科RBC 配置的時鐘偏移請求間隔均為2 min，通過調整通號RBC 發送時鐘偏移請求間隔（如改為2 min30 s），將雙方更新時鐘偏移的周期錯開，最大程度降低觸發該場景的概率。

（2）應用層方面，優化修改鐵科院RBC。一是修改重連時間參數和應用層超時時間，RBC 建立TCP 連接后立即啟動安全連接建立，同時修改應用層判斷超時時間，由5 s 修改為7 s；二是修改判斷應用層連接超時后不發送“取消移交”M#204 消息，這樣即使發生RBC 通信中斷的情況，列車會無線超時降級C2 運行，不會觸發緊急制動停車，增加了可用性。

2 故障二：RBC 與聯鎖通信中斷

2.1 概況

滬杭高鐵線，RBC 為通號院設備，計算機聯鎖為卡斯柯設備，自2010 年開通以來運用至今。2019 年下半年，滬杭RBC 2 與嘉興南聯鎖偶發通信中斷故障。

2.2 原因分析

以2019 年12 月10 日發生的故障為例，對相關數據及邏輯進行分析。

（1）聯鎖數據分析

2019 年 12 月 10 日，19：34：56.690，CBI（172.74.21.53）3.5秒內沒有收到RBC 發送的應用層數據，因此向RBC（172.74.21.155/156）發送 DI（請求中斷）數據包，RBC 收到后將通信中斷，并進行重連，重連后恢復正常，聯鎖數據見圖3。

圖3 嘉興南站聯鎖抓包數據截圖1

進一步對聯鎖數據進行分析，發現RBC 向CBI 發送的數據包進行了拆包處理（見圖4）。

圖4 嘉興南站聯鎖抓包數據截圖2

（2）邏輯分析

滬杭高鐵線于2010 年開通運營，RBC 與CBI 通信協議參照《鐵路信號安全通信協議技術規范》（運基信號〔2010〕267號）執行，規范中明確“用戶數據長度不超過1 000 字節”，因此當RBC 向CBI 發送的數據超過一定字節數時，需進行拆包處理。

其中通號院RBC 拆包邏輯為：當RBC 向CBI 發送的數據包字節數超過480 字節時，即進行拆包處理。

卡斯柯CBI 對RBC 發送來的拆包數據處理邏輯為：CBI默認RBC 只有在發送的數據包字節數超過1 000 字節時才會拆包，而對通號院RBC 發送的480 字節的拆包數據不識別，認為數據異常，CBI 應用層判斷沒有收到來自RBC 的有效信息。

《列控系統 RBC 接口規范》（運基信號〔2010〕533 號）第5.1.1.2 規定：如果CBI 在規定時間內未收到來自RBC 的有效信息，則認為與RBC 的通信中斷。因此當RBC 拆包發送持續時間超過3.5 s 的情況時，CBI 應用層判斷超時，發送DI 數據包，主動切斷通信嘗試重連。

通過上述分析，可以看出問題的根本原因是：在特殊場景下，當RBC 在同一周期內向CBI 發送的字節數較大時（大于480 字節），由于RBC、CBI 對拆包數據的處理方式不同，導致CBI 無法正確識別RBC 數據。

2.3 解決方案

解決該問題，可從兩個方面考慮：（1）修改RBC 拆包邏輯，即當RBC 向CBI 發送的數據包字節數超過1000 字節時，再進行拆包處理；（2）修改CBI 對RBC 發送來的拆包數據的處理邏輯，即能夠有效識別通號院RBC 發送的480 字節的拆包數據。

鑒于RBC 平臺問題及參數修改難度，經通號院、卡斯柯共同研究，對CBI 的處理邏輯進行適應性修改。

3 兩起故障的共性分析

3.1 兩起故障的共同點

（1）相關設備供應商編制的軟件都在標準體系框架內，沒有突破規范，但由于各家對標準的理解不同，在執行時同一條款時，處理方式不盡相同，軟件存在差異化，兼容性上并非完全匹配。

（2）上述問題都不是設備上道后立即出現，而是在設備運用一段時間甚至相當一段時間后，在某種特殊場景下出現。故障雖不是普遍發生，但十分典型。

3.2 反映的問題

（1）設備供應商在編制軟件時，各自為戰，缺少必要、全方位的溝通，對軟件處理上的差異性相互之間沒有做到全面交底，機器語言傳送時，不能準確識別，設備上道后不能適應錯綜復雜的現場運用場景。

（2）設備上道前互聯互通試驗不充分，測試案例不全面，測試序列不詳細，沒有對軟件的差異化處理進行全面的梳理與驗證。

4 建議

（1）細化標準。主要是指CTCS-3 級列控系統標準體系中，通信語言中的消息類型、消息中各字段的含義和取值范圍進行明確的定義，避免引起歧義、多義，杜絕不同設備供應商存在不同的理解。

（2）加強溝通與對接。主要是指在軟件編制前，相關設備供應商之間對軟件處理方式進行全面的技術交底，特別是接口間傳遞的消息和報文格式須具有統一的布局，統一的報文定義。

（3）全覆蓋測試。主要是指設備上道之前進行的軟件互聯互通試驗應嚴謹周詳，編制全覆蓋測試案例，再量化成詳細的測試序列來驗證預設測試案例的正確性。需要指出的是，建議不同設備供應商將軟件存在的差異化處理進行列表，逐條確認測試序列是否覆蓋，滿足互聯互通要求。

5 總結語

隨著后續大批線路的開通和新型設備的上道使用，設備間通信不匹配的問題還會出現。通過細化標準、規范軟件編制與測試可大大降低問題出現的概率。即便在運用中出現類似問題，積極對底層數據和處理邏輯進行分析，也會很快找到癥結所在，制定出切實可行的解決方案。