CBI與RBC接口規范中的特殊點解析

趙曉東

(北京全路通信信號研究設計院有限公司，北京 100073)

CBI與RBC接口規范中的特殊點解析

趙曉東

(北京全路通信信號研究設計院有限公司，北京 100073)

針對CTCS-3級列控系統中計算機聯鎖設備與無線閉塞中心設備在接口適配過程中，針對接口規范中幾項具有代表性的問題進行探討分析，給出相應的解析說明。

接口規范；計算機聯鎖；無線閉塞中心

1 研究背景

在從CTCS-2(以下簡稱C2)級列控系統邁入CTCS-3(以下簡稱C3)級列控系統時,增加了一種全新的設備——無線閉塞中心(RBC), RBC用于實時計算列車移動授權并通過無線指揮行車,其所需基礎線路信號授權信息來自于核心地面信號控制設備——計算機聯鎖(CBI),因此CBIRBC這兩套設備間接口在C3級列控系統中起著極其重要的作用。鐵道部為此發布了兩部暫行標準規范:《CBI-RBC接口規范(V1.0)》和《RSSP-II鐵路信號安全通信協議(V1.0)》,這兩部規范分別從CBI-RBC接口的應用協議和安全協議兩個角度制定,本文結合CBI-RBC接口適配過程中規范應用方面的部分問題進行研究。

2 規范中的部分特殊點解析

1) 通用應用層

由于RBC的制式不同,《CBI-RBC接口規范(V1.0)》中應用協議規范實際為兩個協議,目前,應用協議一在國內客運專線中使用較多,如武廣、京滬、滬寧、滬杭、哈大等高鐵線路均使用此協議,應用協議二在鄭西、廣深港高鐵線路中使用。從協議內容層面上看,應用協議一與應用協議二看似差別很大,但實際僅僅是對線路信息描述方式與格式不同,其所傳達的本質信息是相同的。應用協議一與協議二相比,其最大的差別是多出一個協議層,稱為通用應用層(GAL層)。GAL層需要將對象數據包(OP)按一定長度限制分為若干條消息(Message),然后將同一執行周期生成的所有消息合成一個消息組(Batch),如圖1所示。

圖1 GAL層分包示意圖

通用應用層在規范中是明確提出的,但是很多人不理解為什么要在應用層之上增加一個GAL層,也不清楚在具體工程實施中如何將應用層數據限制為不超過480 Byte。

因此有必要在此解釋說明一下,由于CBIRBC通信是建立在TCP/IP協議基礎上的安全協議,因此它需要受TCP/IP協議的制約,IP鏈路層具有最大傳輸單元MTU的限制特性,它限制了數據幀的最大長度,不同的網絡類型都有一個上限值,局域網的MTU最大限制為1 500 Byte。如果IP層數據包傳送的請求長度超過了MTU上限,那么IP層就要對數據包進行分片(fragmentation)操作,使每一片的長度都小于或等于MTU。假設要傳輸一個數據包,一般IP首部為20 Byte,TCP首部為20 Byte,數據的凈荷(payload)部分預留是1 500-40=1 460 Byte。當用戶數據長度大于1 460 Byte,IP協議就會出現自動分片行為。

針對這一特點可知,當傳輸的用戶數據太長時必然被分割成若干片傳送,接收端則需要將所有片聚齊以后才可以接收解析。一旦傳輸過程中某一分片出現錯誤或丟失,則依照TCP/IP協議,整個協議數據單元必須全部重傳,這樣一來存在兩個風險:一是大量數據重傳可能會加重網絡擁堵幾率,另一方面會加大信息延時。鐵路信號控制領域信息的時效性是很重要的一項指標,也就是說,即使重傳成功,數據可能已經過時失效了。總之,基于TCP/IP構建安全通信協議的要求是避免TCP/IP協議帶來的影響,數據拆分合并的功能應該由應用業務實現,而不要被底層進行過度干預,從而達到安全可控。

為了實現這個目標,我們需要為應用層預留出充足的安全層附加信息余量后,限制用戶數據最大長度,其原理實質是依靠人為的應用層分包來避免IP底層分包動作,這樣做的好處就是即使傳輸過程中丟了一小包,則TCP/IP協議處理只會重傳這一小包的內容,不至于重傳分組后的其他子包。所以當用戶數據超過此限制時,必須在應用層用戶數據交付安全層處理之前預處理分包,這就需要加入一個中間子層——GAL層。

按照《RSSP-II鐵路信號安全通信協議(V1.0)》安全協議來說,各協議層幀頭(包括幀尾)附加長度為56 Byte,即應用層的長度為不大于1 460-56=1 404 Byte即不會引起IP分片, 但《RSSP-II鐵路信號安全通信協議(V1.0)》安全協議規范為了擴展預留了足夠的幀頭幀尾附加域尺寸,規定了應用數據包最長不超過1 000 Byte。

在實際工程使用中,考慮到RBC可能連接無線廣域網,其鏈路MTU最大限制為576 Byte,去掉TCP/IP首部后為536 Byte,因此在使用《RSSP-II鐵路信號安全通信協議(V1.0)》安全協議去掉各協議層幀頭(包括幀尾)附加長度56字節后,應用數據最大長度限制為480 Byte。CBIRBC接口雖不屬于無線廣域網鏈路,但為了軟件處理一致性,因此應用層提交安全層處理之前,統一規定每包數據不超過480 Byte。

2) “進路狀態”與“降級狀態”

接口開發之初,在信號授權信息(SA信息)幀中,其中有兩項概念內容不容易區分,即“進路狀態RouteStatus”與“降級狀態DegradedStatus”,其中“進路狀態”取值有“降級”狀態一項,而同時規范中說明,當“進路狀態”為“降級”狀態時,將“降級狀態”也置為“設置降級”,否則為無降級。

這個表述方法給人的直觀感覺就是“降級狀態”中的設置降級完全取決于“進路狀態”,也就是說“降級狀態”看不出任何意義,“進路狀態”已經完全涵蓋了它的信息。這樣理解是沒有錯誤的。但問題就在于既然“降級狀態”字段沒有用處,為什么SA幀結構中還要單獨設“降級狀態”一項,在此做一下解釋說明。

C3級列控系統的RBC技術引進于歐洲的ETCS-2列控技術(以下簡稱E2)。在原始的E2技術中存在“聯合縮短移動授權”的功能,該功能可以大大縮減聯鎖系統的解鎖時間,進而提高系統的執行效率。具體來講,該功能是指CBI在進路降級(即對已給出信號授權的進路取消或人解)時需要征得RBC的許可,方可執行降級動作,完成進路解鎖。因此,比如值班員取消或人解進路時,CBI先會將“降級狀態”一項置為“設置降級”,以表示向RBC提交降級申請,假如該進路SA已經被RBC分配給列車,則RBC還會將CBI降級請求轉給列車,在確定列車可以在解鎖進路信號機前停車后, RBC會告知CBI準予降級;否則,列車仍有可能闖入需要解鎖的進路,所以RBC不予降級。綜上, CBI提出申請,并經RBC許可后方可將進路狀態置為“降級”狀態。

在E2技術引進時,由于我國鐵路運輸的復雜性,要求C3制式線路要后備兼容C2甚至C0技術,對CBI子系統的功能獨立性要求非常高,盡可能的不用其他子系統的功能去約束國內成熟的CBI控制技術,因此目前CBI不使用RBC的任何應用信息,在CBI進行取消進路等操作時,不會等待RBC回應,直接將“進路狀態”與“降級狀態”置為“降級”。但協議為了保留其成熟格式以及預留日后技術的更新擴展,在信息幀中還是做了保留。

3) 保護區段狀態

“保護區段狀態”在幀結構中的位置是替代了E2規范中“危險點(danger point)”字段,用于股道長度較短導致列車無法全部進入股道的場合。在我國C3級列控系統中,“危險點”的概念尚無實際意義,因此將其替換為“保護區段狀態”,但對RBC、CBI來說,“保護區段”設置原則、使用規則等相關細則尚未制定,所以目前僅作為預留功能在幀結構中保留其位置,實際工程中暫不啟用。

4)主備系網絡發送問題

對于二乘二取二系統平臺來說,分主備二重系,在《CBI-RBC接口規范(V1.0)》中4.1.1.6條規定:“CBI主備系均向RBC發送應用層消息,RBC僅主系向CBI發送應用層消息。”針對該條款的疑問,筆者認為該條款表述不準確。

實際情況是目前國內所有客專線路中不管哪種平臺制式的RBC、CBI,接口中通信雙方均為僅主系發送應用層消息,主備系均接收對方應用層信息。

對于此條款形成的原因,有其特殊背景,在使用從龐巴迪引進的RBC平臺中發現,雖然開發引進之初規定僅主系發送應用層消息,但后來發現RBC平臺的雙系以太網通道均有應用層信息送出,看似RBC主備系均向CBI發送應用層信息,然而實際情況是,RBC主系為了最大限度實現冗余網絡的優勢,不僅使用自身的網絡通道,也使用了備系的網絡通道,即發送時看似備系通道發出來的數據,實質是主系生成的數據經由備系通道也送出去,并非備系生成的數據發送了出去。同理,在接收方面, RBC主系也會同時利用備系通道收回數據,即使主系與某個設備的雙通道均中斷,仍可以利用備系通道收到對方主系信息。

因此為了消除歧義,可能原文想表達成RBC主備系均向CBI發送應用層消息,CBI僅主系向RBC發送應用層消息,結果由于筆誤造成諸多誤會。此處筆者只想說明一下實際情況是通信雙方均只有主系發送應用數據,這一點是不容置疑的。

5)EC與TTS

在《RSSP-II鐵路信號安全通信協議(V1.0)》規范中,描述了兩種時延防護手段,即3倍時間戳(TTS)方式與執行周期計數(EC)方式。

TTS防護技術不需要設定固定通信周期,通過時鐘偏移估算而達到信息時效性的判定,適用范圍廣,既可用在非周期性通信的系統上,又可用于周期性通信的系統上。其計時分辨率為10 ms,在實踐中多用于非周期性通信,如事件觸發式通信時使用。另外,該技術方案與IEEE1588的符合性很高,可以看作是IEEE1588在鐵路通信技術中的一個應用實例。

EC防護技術顧名思義是以執行周期來計數的,因此其計數值非絕對時間計數,是按照通信周期時長來累加的,對周期性通信的系統,執行周期計數是一種便捷有效的時延防護方式。

《RSSP-II鐵路信號安全通信協議(V1.0)》最初源于RBC-RBC之間通信協議,RBC之間僅存在列車跨區切換時才需要交互信息,所以信息發送方式采用事件觸發式,并非周期性交互信息,設計TTS防護技術,即在于不需要設定固定通信周期,因此在對信息時效性的判定上《RSSP-II鐵路信號安全通信協議(V1.0)》提出兩種方式可選,但互相排斥,即不可同時使用。

3倍時間戳的計數值是以10 ms為精度的,雖然適用范圍廣,但防護運算方式復雜,對系統平臺特性依賴性強,要求較高。而EC則是按照系統運行周期計數的,延遲威脅的檢測通過對接收到的消息中的EC計數值和本地計算的EC計數期望值進行比較實現。因此在CBI-RBC接口中,由于采用周期性通信方式,故選擇了更加便捷的EC防護技術。

有一點特別需要注意的是,規范中規定,使用EC后,幀結構中TTS域仍然保留,對應的TTS3個時間戳位置均填0。這是對發送方規定的,但不少開發人員對此誤讀,在接收端對對方的此信息域是否為0進行校驗。如不是,則認為是非法數據。

實際上,這是一種誤讀,TTS技術是防護時效性的,既然不使用此技術,則不應該對此域進行校驗,TTS域填0只是覺得既然保留了位置,就需要有個值填進去,對開發人員來說,給出了一個常規缺省處理方法,但并不要求接收方檢查此域。實際上發送方將此處填寫其他任意值,接收方都不能認為是非法信息。這在《RSSP-II鐵路信號安全通信協議(V1.0)》規范中是有明確規定的,只是不容易引起開發人員注意,在此強調一下。

本文結合CBI-RBC接口適配工程實際開發過程中反映較多的幾項問題進行分析,希望能與同行共同探討、共同進步,如有不當之處敬請指正。

In the process of interface adaptation between computer-based interlocking (CBI) equipment and radio block center (RBC) in CTCS-3 System, there are several typical problems in the interface specification. And the paper analyzes and discusses these problems and gives the corresponding explanation.

interface specification; CBI; RBC

10.3969/j.issn.1673-4440.2014.04.031

2014-06-13）