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

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

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

1.1 概況

徐鹽鐵路引入徐州東樞紐時，對徐州東樞紐地區(qū)的RBC管轄范圍做過適應(yīng)性調(diào)整，調(diào)整后的RBC 管轄情況見圖1。

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

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

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

1.2 原因分析

為切實找準故障原因，對安全層數(shù)據(jù)和應(yīng)用層邏輯進行分析，以2019 年10 月24 日發(fā)生的故障為例進行探討。

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

對故障時刻安全數(shù)據(jù)網(wǎng)的數(shù)據(jù)抓包見圖2。

圖2 安全數(shù)據(jù)網(wǎng)抓包數(shù)據(jù)

根據(jù)抓包數(shù)據(jù)，徐鹽RBC1 發(fā)送3 包應(yīng)用數(shù)據(jù)（抓包序號22816、22824 和 22834）后，隨即發(fā)送了時鐘偏移更新請求（抓包序號22860），經(jīng)調(diào)閱分析，這四包數(shù)據(jù)的時戳均為0xlc3919a9。

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

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

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

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

1.3 解決方案

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

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

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

2 故障二：RBC 與聯(lián)鎖通信中斷

2.1 概況

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

2.2 原因分析

以2019 年12 月10 日發(fā)生的故障為例，對相關(guān)數(shù)據(jù)及邏輯進行分析。

（1）聯(lián)鎖數(shù)據(jù)分析

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

圖3 嘉興南站聯(lián)鎖抓包數(shù)據(jù)截圖1

進一步對聯(lián)鎖數(shù)據(jù)進行分析，發(fā)現(xiàn)RBC 向CBI 發(fā)送的數(shù)據(jù)包進行了拆包處理（見圖4）。

圖4 嘉興南站聯(lián)鎖抓包數(shù)據(jù)截圖2

（2）邏輯分析

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

其中通號院RBC 拆包邏輯為：當RBC 向CBI 發(fā)送的數(shù)據(jù)包字節(jié)數(shù)超過480 字節(jié)時，即進行拆包處理。

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

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

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

2.3 解決方案

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

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

3 兩起故障的共性分析

3.1 兩起故障的共同點

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

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

3.2 反映的問題

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

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

4 建議

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

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

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

5 總結(jié)語

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