鐵路聯鎖與調度集中標準接口規范缺陷分析及升級研究

宋鵬飛

(1.中國鐵道科學研究院通信信號研究所,北京 100080； 2.國家鐵路智能運輸系統工程技術研究中心,北京 100081)

計算機聯鎖系統(簡稱為“聯鎖”)是我國鐵路系統關鍵的車站基礎信號設備，調度集中系統(Centralized Train Control，簡稱為CTC)是高速鐵路列車調度指揮、集中控制的重要技術裝備。目前聯鎖系統與CTC系統之間的標準接口規范遵循的是《調度集中車站自律機與計算機聯鎖接口通信協議(V1.1)》(運基信號[2006]312號)[1]。兩大信號系統接口通信的安全可靠性直接影響到列車調度指揮的安全及效率[2-3]。

隨著高速鐵路線路的廣泛開通運營，二者之間的通信過程逐步暴露出部分問題[4]。本文主要探討目前聯鎖與CTC系統的標準接口規范缺陷，分析二者之間的標準通信流程及交互信息流，對雙方之間基于安全通信協議進行通信的可行性進行了設計研究。

1 既有接口協議介紹

既有的接口規范為《調度集中車站自律機與計算機聯鎖接口通信協議(V1.1)》，該規范于2005年由原鐵道部組織聯鎖、CTC廠家統一討論編制并試用，2006年正式發布，主要的傳輸邏輯包括以下5個方面。

(1)聯鎖與CTC之間通過串口建立通信。

(2)CTC作為通信的發起方，主動建立連接；聯鎖系統作為通信的應答方，被動響應連接請求。

(3)雙方傳輸數據時，通過對數據幀的發送序號、接收確認序號進行邏輯檢查，以判斷是否丟幀重幀；通過信息中的循環冗余校驗碼(CRC)確定信息是否被篡改訛傳。

(4)通信雙方定時向對方發送心跳以維持通信鏈路的穩定。

(5)雙方傳輸的主要應用數據主要包括：聯鎖向CTC發送站場表示、站場變化表示、自律請求、狀態報告、時鐘同步請求信息；CTC向聯鎖發送控制命令、自律同意、請求站場表示、時鐘同步數據。

2 既有接口規范遇到問題及分析

既有接口規范制定的年代較早，在編制時單純考慮了聯鎖與CTC如何以一個簡單有效的邏輯進行交互應用數據，經過十多年的現場應用，遇到部分問題如下。

(1)既有接口協議不滿足當前EN50159及GB/T 24339的要求。

聯鎖系統為SIL4級安全型設備，CTC系統為低等級的非安全信號設備。按照鐵路信號系統的安全通信標準要求，安全相關設備的數據通信必須建立安全通信功能[3]。

隨著我國鐵路的高速發展，2009年國家正式頒布GB/T24339標準[5-7]，明確軌道交通領域通信信號的安全相關通信內容。此標準是源于歐洲鐵路信號安全標準系列的安全通信標準EN50159，條款內容完全一致，可視為等價標準[8-10]。按照GB/T 24339要求，安全相關設備(聯鎖)與非安全相關設備(CTC)之間的通信，需要在安全相關報文(message)中增加安全編碼(transmission code)，使安全相關和非安全相關的報文具有不同的結構，安全編碼應能夠保護系統達到要求的安全完整性等級(SIL 4級)。而目前聯鎖與CTC的標準接口規范協議不具備安全層的防護。

(2)接口規范對高鐵線路的需求考慮不足。

既有接口規范原是為了普速線路及最初的客專線路制定，高鐵線路大面積開通運營后接口規范并沒有進行專門修訂，只在既有基礎上進行打補丁擴充，比如高鐵線路中的“點燈”“滅燈”的顯示及控制、“尖軌”“心軌”的操作等新需求均是聯鎖和CTC雙方在應用中協商擴充，這導致了不同廠家在擴充時信息幀格式不盡相同。這也側面表明原有規范在制訂時對技術的適應性、前瞻性考慮不夠，有損標準規范的權威性[11-12]。

(3)既有規范對聯鎖與CTC通信的安全校驗及安全防護部分較為薄弱。

當前協議規范中，聯鎖與CTC通信雙方根據發送序號(1字節)、接收確認序號(1字節)、CRC(2字節)對信息進行簡單的安全確認，安全性卡控不足。分析協議可以得出接口規范的風險防御矩陣如表1所示。

表1 既有接口規范防御矩陣

注：√表示防御措施與威脅的應對關系

可以看出，風險防御的手段略有單薄[13-14]，基本全依靠一個字節的序號及2個字節的CRC校驗進行防御。當前接口協議使用的是CRC16生成多項式，即G(x)=x16+x15+x2+1。CRC16的漏檢率可以通過算法計算，按照當前16位CRC通過漏檢率分析算法[15]，仍存在收到干擾數據的可能。

案例：2016年9月某鐵路局現場運行過程中發生了CTC端站場顯示異常，經分析CTC端收到的信息流如圖1所示。

圖1 異常信息流

現場數據流中出現了“斷尾幀”的異常情況，串口接收器工作異常導致接收到的信息為半截，之后新的一幀數據與斷尾幀進行了拼接，如圖1所示，信息流1與信息流2的CRC校驗值完全相同，均為0x1b 0x22。此次極端情況下發生CRC碰撞校驗值相同，引起CTC端處理邏輯異常，從而導致了站場表示顯示錯誤。

(4)接口規范在雙方通信連接的維持上存在瑕疵，部分核心信息沒有定時發送。

當前接口規范的邏輯下，雙方通道沒有主動釋放的過程，只能被動的依賴超時。聯鎖與CTC雙方在連接成功建立之后，任何一方的中斷或退出，對方均無從悉知，只能被動等待超時。

在通信建立后沒有應用數據時，雙方僅發送心跳信息，而核心的狀態信息沒有定時發送，比如主備狀態、是否允許轉自律、當前控制狀態等。

(5)既有規范對列車調度指揮系統(TDCS)系統與聯鎖接口適用性不足，無法做到單向數據傳輸。在聯鎖與TDCS等系統通信時，一般要求TDCS端不向聯鎖發送應用數據，只接收聯鎖端的應用數據，既有規范不支持此種場景。

(6)既有規范對工程實施時要求不嚴謹。通信接口時無法體現本機是A機還是B機，對方是I系還是II系，只能依靠工程實施布線時，強制指定。

3 安全通信協議研究及驗證

目前我國針對鐵路信號安全設備之間安全相關信息的交互流程，制定了鐵路信號安全通信協議(RSSP)[7]，其中RSSP-I適用于封閉式傳輸系統，RSSP-II適用于開放式傳輸系統。對照協議，聯鎖與CTC之間可歸類為典型的封閉式信號傳輸，即“連接的設備數量固定或最大數量固定，有已知且固定的特性的傳輸系統，對于此系統可以忽略非法訪問的風險”。為此可分析考慮RSSP-I型安全通信協議是否適用，并進行可行性驗證。

3.1 RSSP-I協議介紹

RSSP-I安全通信協議是從接收端角度設計的保護算法[16-17]，能夠解決封閉環境下的信息安全傳輸。對封閉式傳輸系統而言，可存在的威脅包括：數據幀重復、數據幀丟失、數據幀插入、數據幀次序混亂、數據幀錯誤、數據幀傳輸超時。RSSP-I協議要求通信雙方必須基于周期性交互，主要存在3種幀類型。

(1)實時安全數據幀RSD，通信雙方將應用層的數據均封裝在此RSD數據幀中，定時周期性發送。

(2)時序校正請求SSE，通信的任何一方在接收數據后檢查到數據幀的時序錯誤時，觸發式的向發送端發起時序校正請求。

(3)時序校正答復SSR，通信的一方收到對方的時序校正請求后，即時反饋時序校正應答。

RSSP-I的威脅防御矩陣如表2所示。

表2 RSSP-I協議防御矩陣

注：√表示防御措施與威脅的應對關系

基于RSSP-I安全通信協議開發聯鎖與CTC的通信接口規范[18-20]，需在3方面考慮可行性：安全性、工程性、業務性。

分析RSSP-I協議，可以得出在威脅防御方面RSSP-I能夠滿足GB24339和歐標EN 50159的要求，可解決既有接口規范遇到的安全性、工程性問題，主要包括：(1)雙方通信接口能夠實現安全數據通信，保證了數據報文的安全傳輸，異常情況下也可做到數據的安全卡控；(2)協議框架支持單向數據傳輸，聯鎖單向對TDCS傳輸數據可適配；(3)協議框架具有嚴謹的A機、B機區分，更符合工程實施規范。為此，需重點考慮基于RSSP-I協議框架對聯鎖與CTC之間數據業務的可行性，分析安全通信協議是否適配聯鎖與CTC之間當前傳輸的應用層數據要求[21]。

3.2 既有應用數據幀的安全協議適用分析

既有規范中聯鎖與CTC傳輸的數據分為2類：通信控制幀和數據傳送幀。其中通信控制幀主要包括通信建立、維持的信息；數據傳送幀主要包括應用層業務數據信息，如表3所示。

表3 幀類型及用途

通過表3可以看出，雙方交互的信息幀類型繁多復雜，部分幀類型在現場應用時也是多余無用的(比如版本號錯誤幀、故障報告幀等)。雙方連接建立是由CTC方主動發起連接，聯鎖被動響應；應用層的信息主動發送，并等待對方確認應答；部分與業務應用無關的數據比如時鐘信息、請求信息、狀態信息等，也通過幀類型進行交互。

為此需要分類處理，對業務數據和非業務數據進行差異化的分析。

3.2.1 通信建立相關幀

基于RSSP-I安全通信協議下，原有的通訊控制幀涉及的部分信息類型可以廢棄，RSSP-I中的SSE、SSR數據幀完全替代原有的通信建立過程，另外，RSSP-I協議在傳輸中增加了身份源標識符SID來保證信息源頭的真實性，SID與時間戳偽隨機數經過異或運算結合在一起傳輸，能夠對傳輸的報文進行安全的防護。

3.2.2 時鐘數據相關幀

既有接口規范要求聯鎖系統定時(每天6：00、18：00整點)向CTC申請時鐘，CTC反饋應答當前時鐘。這種申請-應答的方式增加了雙方通信的復雜度，可以通過CTC方在RSD封裝的應用層消息的頭部插入時鐘信息塊代替，CTC每一個周期性RSD消息均自帶當前時鐘信息，從而大幅簡化交互流程。

3.2.3 狀態報告幀

既有聯鎖與CTC的狀態報告幀(RSR)包含2個字段，除了各自包括本端主備狀態外，聯鎖發出的RSR幀包含“當前聯鎖的自律/站控工作模式”，CTC發出的RSR幀則包含“是否允許聯鎖轉為自律模式”字段。既有規范對此信息要求有變化時主動發送，而此信息屬于關鍵信息，一旦出現丟失則會引起中斷甚至邏輯錯誤，在現場實施時聯鎖與CTC雙方為了避免異常情況，一般均人為設定定時發送。為此，使用RSSP-I協議時雙方可在RSD數據包中插入對應的RSR狀態，周期性地發送。

3.2.4 控制命令幀及自律申請、自律同意幀

這一部分作為雙方交互的核心信息非常重要，其中控制命令幀為CTC向聯鎖發送排路等控制命令；自律申請幀為聯鎖系統由站控申請切換為分散自律模式；自律同意幀為CTC收到申請后確認可以轉為分散自律模式。這3類信息是雙方傳輸的關鍵信息，既有協議中將此3類信息與其他普通信息類型同等對待不做特殊區分，在實際應用中頗受詬病。為此可對這部分信息增加命令ID(4字節)字段，信息的發送方在發送時填寫唯一的命令ID，接收方收到此信息后以原ID反饋，確認收到此命令。

3.2.5 聯鎖站場表示相關信息

當現場車站信號設備狀態發生變化時，由聯鎖系統主動觸發發送站場表示信息及站場變化信息。RSSP-I協議框架下完整的一包RSD可容納的應用層數據域最大長度為524字節，匯總當前幾個聯鎖廠家對外接口數據，對一個標準站型的車站所有信號設備狀態進行評估，得出如下結果：(1)對類似“4組股道、10組道岔”站型的車站，聯鎖全體站場表示信息一般為60字節左右；(2)迄今為止，最大站場下聯鎖的全體站場表示信息少于700字節；(3)既有接口規范中全體站場表示信息最大為1 013字節。綜上，對任何一個車站的站場表示信息，均可由RSD數據幀封裝發送；站型較大的車站可通過2包RSD覆蓋。既有接口規范對雙方通信時串口波特率選擇的是19 200 bps，可粗略的視為1秒鐘最快可傳輸2400字節數據；鑒于RSSP-I協議500 ms的周期性傳輸要求，而聯鎖與CTC機柜之間距離較短，可更改雙方傳輸波特率為38 400 bps，更快的傳輸數據以節省雙方串口通信耗時。

3.3 RSSP-I協議下接口協議設計

基于RSSP-I安全通信協議，聯鎖發往CTC的信息體格式可定義為表4協議藍本。

表4 RSPP-I框架下聯鎖發送數據協議藍本

CTC向聯鎖發送的數據流協議可以按照表5格式。

表5 RSPP-I框架下CTC發送數據協議藍本

按照上述的協議藍本，在RSSP-I協議框架下，聯鎖和CTC構建安全通信連接，以此協議傳輸業務數據。

4 基于RSSP-I協議測試驗證

為了驗證協議的適用性及穩定性[22]，選擇一個標準站型、最大規模的2個車站進行測試，以北京鐵路局津秦高鐵唐山津秦場站(25組道岔、6組股道、17架進站及出站信號機)、北京鐵路局樞紐區段動車段站(259組道岔、100組股道、405架進站出站調車信號機)為例進行仿真測試。聯鎖仿真與CTC自律機軟件按照串口連接，波特率為38 400 bps。其中，唐山津秦場聯鎖的全體碼位接口數據約180字節；動車段的全體碼位接口數據約為690字節的數據，驗證結果見表6。

表6 新舊接口協議耗時對比 ms

基于RSSP-I安全通信協議下，通信指標與既有接口規范均滿足技術條件的要求，幾大測試項差別不大，同時對協議進行預留擴充，滿足后續新需求的擴充。測試發現，只有超大型車站站型下相比既有的接口規范略有延時，這是因為設計的RSSP-I協議藍本每一次都發送了全站信息，且大型車站站場碼位需要分2包依次發送，從而產生了部分耗時，而既有接口規范默認只發送變化的站場信息。后期可以優化調整接口協議藍本，對標準站和大型站分別處理。

5 結語

隨著高速鐵路的走出去策略，我國鐵路信號產品按照歐洲鐵路信號安全標準進行認證并獲取獨立第三方資格認證，已成為必然趨勢。本文根據我國GB體系、歐洲EN50159標準，對CTC與聯鎖系統之間的既有接口通信規范進行了分析，對接口協議升級為RSSP-I協議框架進行了設計研究，并在實驗室仿真環境系下進行了測試驗證，明確了雙方之間可以按照RSSP-I協議升級，為進一步提高兩大鐵路信號系統之間的安全通信提供了一個方案。