宋鵬飛
(1.中國鐵道科學(xué)研究院通信信號研究所,北京 100080; 2.國家鐵路智能運輸系統(tǒng)工程技術(shù)研究中心,北京 100081)
計算機聯(lián)鎖系統(tǒng)(簡稱為“聯(lián)鎖”)是我國鐵路系統(tǒng)關(guān)鍵的車站基礎(chǔ)信號設(shè)備,調(diào)度集中系統(tǒng)(Centralized Train Control,簡稱為CTC)是高速鐵路列車調(diào)度指揮、集中控制的重要技術(shù)裝備。目前聯(lián)鎖系統(tǒng)與CTC系統(tǒng)之間的標準接口規(guī)范遵循的是《調(diào)度集中車站自律機與計算機聯(lián)鎖接口通信協(xié)議(V1.1)》(運基信號[2006]312號)[1]。兩大信號系統(tǒng)接口通信的安全可靠性直接影響到列車調(diào)度指揮的安全及效率[2-3]。
隨著高速鐵路線路的廣泛開通運營,二者之間的通信過程逐步暴露出部分問題[4]。本文主要探討目前聯(lián)鎖與CTC系統(tǒng)的標準接口規(guī)范缺陷,分析二者之間的標準通信流程及交互信息流,對雙方之間基于安全通信協(xié)議進行通信的可行性進行了設(shè)計研究。
既有的接口規(guī)范為《調(diào)度集中車站自律機與計算機聯(lián)鎖接口通信協(xié)議(V1.1)》,該規(guī)范于2005年由原鐵道部組織聯(lián)鎖、CTC廠家統(tǒng)一討論編制并試用,2006年正式發(fā)布,主要的傳輸邏輯包括以下5個方面。
(1)聯(lián)鎖與CTC之間通過串口建立通信。
(2)CTC作為通信的發(fā)起方,主動建立連接;聯(lián)鎖系統(tǒng)作為通信的應(yīng)答方,被動響應(yīng)連接請求。
(3)雙方傳輸數(shù)據(jù)時,通過對數(shù)據(jù)幀的發(fā)送序號、接收確認序號進行邏輯檢查,以判斷是否丟幀重幀;通過信息中的循環(huán)冗余校驗碼(CRC)確定信息是否被篡改訛傳。
(4)通信雙方定時向?qū)Ψ桨l(fā)送心跳以維持通信鏈路的穩(wěn)定。
(5)雙方傳輸?shù)闹饕獞?yīng)用數(shù)據(jù)主要包括:聯(lián)鎖向CTC發(fā)送站場表示、站場變化表示、自律請求、狀態(tài)報告、時鐘同步請求信息;CTC向聯(lián)鎖發(fā)送控制命令、自律同意、請求站場表示、時鐘同步數(shù)據(jù)。
既有接口規(guī)范制定的年代較早,在編制時單純考慮了聯(lián)鎖與CTC如何以一個簡單有效的邏輯進行交互應(yīng)用數(shù)據(jù),經(jīng)過十多年的現(xiàn)場應(yīng)用,遇到部分問題如下。
(1)既有接口協(xié)議不滿足當前EN50159及GB/T 24339的要求。
聯(lián)鎖系統(tǒng)為SIL4級安全型設(shè)備,CTC系統(tǒng)為低等級的非安全信號設(shè)備。按照鐵路信號系統(tǒng)的安全通信標準要求,安全相關(guān)設(shè)備的數(shù)據(jù)通信必須建立安全通信功能[3]。
隨著我國鐵路的高速發(fā)展,2009年國家正式頒布GB/T24339標準[5-7],明確軌道交通領(lǐng)域通信信號的安全相關(guān)通信內(nèi)容。此標準是源于歐洲鐵路信號安全標準系列的安全通信標準EN50159,條款內(nèi)容完全一致,可視為等價標準[8-10]。按照GB/T 24339要求,安全相關(guān)設(shè)備(聯(lián)鎖)與非安全相關(guān)設(shè)備(CTC)之間的通信,需要在安全相關(guān)報文(message)中增加安全編碼(transmission code),使安全相關(guān)和非安全相關(guān)的報文具有不同的結(jié)構(gòu),安全編碼應(yīng)能夠保護系統(tǒng)達到要求的安全完整性等級(SIL 4級)。而目前聯(lián)鎖與CTC的標準接口規(guī)范協(xié)議不具備安全層的防護。
(2)接口規(guī)范對高鐵線路的需求考慮不足。
既有接口規(guī)范原是為了普速線路及最初的客專線路制定,高鐵線路大面積開通運營后接口規(guī)范并沒有進行專門修訂,只在既有基礎(chǔ)上進行打補丁擴充,比如高鐵線路中的“點燈”“滅燈”的顯示及控制、“尖軌”“心軌”的操作等新需求均是聯(lián)鎖和CTC雙方在應(yīng)用中協(xié)商擴充,這導(dǎo)致了不同廠家在擴充時信息幀格式不盡相同。這也側(cè)面表明原有規(guī)范在制訂時對技術(shù)的適應(yīng)性、前瞻性考慮不夠,有損標準規(guī)范的權(quán)威性[11-12]。
(3)既有規(guī)范對聯(lián)鎖與CTC通信的安全校驗及安全防護部分較為薄弱。
當前協(xié)議規(guī)范中,聯(lián)鎖與CTC通信雙方根據(jù)發(fā)送序號(1字節(jié))、接收確認序號(1字節(jié))、CRC(2字節(jié))對信息進行簡單的安全確認,安全性卡控不足。分析協(xié)議可以得出接口規(guī)范的風險防御矩陣如表1所示。
表1 既有接口規(guī)范防御矩陣
注:√表示防御措施與威脅的應(yīng)對關(guān)系
可以看出,風險防御的手段略有單薄[13-14],基本全依靠一個字節(jié)的序號及2個字節(jié)的CRC校驗進行防御。當前接口協(xié)議使用的是CRC16生成多項式,即G(x)=x16+x15+x2+1。CRC16的漏檢率可以通過算法計算,按照當前16位CRC通過漏檢率分析算法[15],仍存在收到干擾數(shù)據(jù)的可能。
案例:2016年9月某鐵路局現(xiàn)場運行過程中發(fā)生了CTC端站場顯示異常,經(jīng)分析CTC端收到的信息流如圖1所示。
圖1 異常信息流
現(xiàn)場數(shù)據(jù)流中出現(xiàn)了“斷尾幀”的異常情況,串口接收器工作異常導(dǎo)致接收到的信息為半截,之后新的一幀數(shù)據(jù)與斷尾幀進行了拼接,如圖1所示,信息流1與信息流2的CRC校驗值完全相同,均為0x1b 0x22。此次極端情況下發(fā)生CRC碰撞校驗值相同,引起CTC端處理邏輯異常,從而導(dǎo)致了站場表示顯示錯誤。
(4)接口規(guī)范在雙方通信連接的維持上存在瑕疵,部分核心信息沒有定時發(fā)送。
當前接口規(guī)范的邏輯下,雙方通道沒有主動釋放的過程,只能被動的依賴超時。聯(lián)鎖與CTC雙方在連接成功建立之后,任何一方的中斷或退出,對方均無從悉知,只能被動等待超時。
在通信建立后沒有應(yīng)用數(shù)據(jù)時,雙方僅發(fā)送心跳信息,而核心的狀態(tài)信息沒有定時發(fā)送,比如主備狀態(tài)、是否允許轉(zhuǎn)自律、當前控制狀態(tài)等。
(5)既有規(guī)范對列車調(diào)度指揮系統(tǒng)(TDCS)系統(tǒng)與聯(lián)鎖接口適用性不足,無法做到單向數(shù)據(jù)傳輸。在聯(lián)鎖與TDCS等系統(tǒng)通信時,一般要求TDCS端不向聯(lián)鎖發(fā)送應(yīng)用數(shù)據(jù),只接收聯(lián)鎖端的應(yīng)用數(shù)據(jù),既有規(guī)范不支持此種場景。
(6)既有規(guī)范對工程實施時要求不嚴謹。通信接口時無法體現(xiàn)本機是A機還是B機,對方是I系還是II系,只能依靠工程實施布線時,強制指定。
目前我國針對鐵路信號安全設(shè)備之間安全相關(guān)信息的交互流程,制定了鐵路信號安全通信協(xié)議(RSSP)[7],其中RSSP-I適用于封閉式傳輸系統(tǒng),RSSP-II適用于開放式傳輸系統(tǒng)。對照協(xié)議,聯(lián)鎖與CTC之間可歸類為典型的封閉式信號傳輸,即“連接的設(shè)備數(shù)量固定或最大數(shù)量固定,有已知且固定的特性的傳輸系統(tǒng),對于此系統(tǒng)可以忽略非法訪問的風險”。為此可分析考慮RSSP-I型安全通信協(xié)議是否適用,并進行可行性驗證。
RSSP-I安全通信協(xié)議是從接收端角度設(shè)計的保護算法[16-17],能夠解決封閉環(huán)境下的信息安全傳輸。對封閉式傳輸系統(tǒng)而言,可存在的威脅包括:數(shù)據(jù)幀重復(fù)、數(shù)據(jù)幀丟失、數(shù)據(jù)幀插入、數(shù)據(jù)幀次序混亂、數(shù)據(jù)幀錯誤、數(shù)據(jù)幀傳輸超時。RSSP-I協(xié)議要求通信雙方必須基于周期性交互,主要存在3種幀類型。
(1)實時安全數(shù)據(jù)幀RSD,通信雙方將應(yīng)用層的數(shù)據(jù)均封裝在此RSD數(shù)據(jù)幀中,定時周期性發(fā)送。
(2)時序校正請求SSE,通信的任何一方在接收數(shù)據(jù)后檢查到數(shù)據(jù)幀的時序錯誤時,觸發(fā)式的向發(fā)送端發(fā)起時序校正請求。
(3)時序校正答復(fù)SSR,通信的一方收到對方的時序校正請求后,即時反饋時序校正應(yīng)答。
RSSP-I的威脅防御矩陣如表2所示。
表2 RSSP-I協(xié)議防御矩陣
注:√表示防御措施與威脅的應(yīng)對關(guān)系
基于RSSP-I安全通信協(xié)議開發(fā)聯(lián)鎖與CTC的通信接口規(guī)范[18-20],需在3方面考慮可行性:安全性、工程性、業(yè)務(wù)性。
分析RSSP-I協(xié)議,可以得出在威脅防御方面RSSP-I能夠滿足GB24339和歐標EN 50159的要求,可解決既有接口規(guī)范遇到的安全性、工程性問題,主要包括:(1)雙方通信接口能夠?qū)崿F(xiàn)安全數(shù)據(jù)通信,保證了數(shù)據(jù)報文的安全傳輸,異常情況下也可做到數(shù)據(jù)的安全卡控;(2)協(xié)議框架支持單向數(shù)據(jù)傳輸,聯(lián)鎖單向?qū)DCS傳輸數(shù)據(jù)可適配;(3)協(xié)議框架具有嚴謹?shù)腁機、B機區(qū)分,更符合工程實施規(guī)范。為此,需重點考慮基于RSSP-I協(xié)議框架對聯(lián)鎖與CTC之間數(shù)據(jù)業(yè)務(wù)的可行性,分析安全通信協(xié)議是否適配聯(lián)鎖與CTC之間當前傳輸?shù)膽?yīng)用層數(shù)據(jù)要求[21]。
既有規(guī)范中聯(lián)鎖與CTC傳輸?shù)臄?shù)據(jù)分為2類:通信控制幀和數(shù)據(jù)傳送幀。其中通信控制幀主要包括通信建立、維持的信息;數(shù)據(jù)傳送幀主要包括應(yīng)用層業(yè)務(wù)數(shù)據(jù)信息,如表3所示。
表3 幀類型及用途
通過表3可以看出,雙方交互的信息幀類型繁多復(fù)雜,部分幀類型在現(xiàn)場應(yīng)用時也是多余無用的(比如版本號錯誤幀、故障報告幀等)。雙方連接建立是由CTC方主動發(fā)起連接,聯(lián)鎖被動響應(yīng);應(yīng)用層的信息主動發(fā)送,并等待對方確認應(yīng)答;部分與業(yè)務(wù)應(yīng)用無關(guān)的數(shù)據(jù)比如時鐘信息、請求信息、狀態(tài)信息等,也通過幀類型進行交互。
為此需要分類處理,對業(yè)務(wù)數(shù)據(jù)和非業(yè)務(wù)數(shù)據(jù)進行差異化的分析。
3.2.1 通信建立相關(guān)幀
基于RSSP-I安全通信協(xié)議下,原有的通訊控制幀涉及的部分信息類型可以廢棄,RSSP-I中的SSE、SSR數(shù)據(jù)幀完全替代原有的通信建立過程,另外,RSSP-I協(xié)議在傳輸中增加了身份源標識符SID來保證信息源頭的真實性,SID與時間戳偽隨機數(shù)經(jīng)過異或運算結(jié)合在一起傳輸,能夠?qū)鬏數(shù)膱笪倪M行安全的防護。
3.2.2 時鐘數(shù)據(jù)相關(guān)幀
既有接口規(guī)范要求聯(lián)鎖系統(tǒng)定時(每天6:00、18:00整點)向CTC申請時鐘,CTC反饋應(yīng)答當前時鐘。這種申請-應(yīng)答的方式增加了雙方通信的復(fù)雜度,可以通過CTC方在RSD封裝的應(yīng)用層消息的頭部插入時鐘信息塊代替,CTC每一個周期性RSD消息均自帶當前時鐘信息,從而大幅簡化交互流程。
3.2.3 狀態(tài)報告幀
既有聯(lián)鎖與CTC的狀態(tài)報告幀(RSR)包含2個字段,除了各自包括本端主備狀態(tài)外,聯(lián)鎖發(fā)出的RSR幀包含“當前聯(lián)鎖的自律/站控工作模式”,CTC發(fā)出的RSR幀則包含“是否允許聯(lián)鎖轉(zhuǎn)為自律模式”字段。既有規(guī)范對此信息要求有變化時主動發(fā)送,而此信息屬于關(guān)鍵信息,一旦出現(xiàn)丟失則會引起中斷甚至邏輯錯誤,在現(xiàn)場實施時聯(lián)鎖與CTC雙方為了避免異常情況,一般均人為設(shè)定定時發(fā)送。為此,使用RSSP-I協(xié)議時雙方可在RSD數(shù)據(jù)包中插入對應(yīng)的RSR狀態(tài),周期性地發(fā)送。
3.2.4 控制命令幀及自律申請、自律同意幀
這一部分作為雙方交互的核心信息非常重要,其中控制命令幀為CTC向聯(lián)鎖發(fā)送排路等控制命令;自律申請幀為聯(lián)鎖系統(tǒng)由站控申請切換為分散自律模式;自律同意幀為CTC收到申請后確認可以轉(zhuǎn)為分散自律模式。這3類信息是雙方傳輸?shù)年P(guān)鍵信息,既有協(xié)議中將此3類信息與其他普通信息類型同等對待不做特殊區(qū)分,在實際應(yīng)用中頗受詬病。為此可對這部分信息增加命令I(lǐng)D(4字節(jié))字段,信息的發(fā)送方在發(fā)送時填寫唯一的命令I(lǐng)D,接收方收到此信息后以原ID反饋,確認收到此命令。
3.2.5 聯(lián)鎖站場表示相關(guān)信息
當現(xiàn)場車站信號設(shè)備狀態(tài)發(fā)生變化時,由聯(lián)鎖系統(tǒng)主動觸發(fā)發(fā)送站場表示信息及站場變化信息。RSSP-I協(xié)議框架下完整的一包RSD可容納的應(yīng)用層數(shù)據(jù)域最大長度為524字節(jié),匯總當前幾個聯(lián)鎖廠家對外接口數(shù)據(jù),對一個標準站型的車站所有信號設(shè)備狀態(tài)進行評估,得出如下結(jié)果:(1)對類似“4組股道、10組道岔”站型的車站,聯(lián)鎖全體站場表示信息一般為60字節(jié)左右;(2)迄今為止,最大站場下聯(lián)鎖的全體站場表示信息少于700字節(jié);(3)既有接口規(guī)范中全體站場表示信息最大為1 013字節(jié)。綜上,對任何一個車站的站場表示信息,均可由RSD數(shù)據(jù)幀封裝發(fā)送;站型較大的車站可通過2包RSD覆蓋。既有接口規(guī)范對雙方通信時串口波特率選擇的是19 200 bps,可粗略的視為1秒鐘最快可傳輸2400字節(jié)數(shù)據(jù);鑒于RSSP-I協(xié)議500 ms的周期性傳輸要求,而聯(lián)鎖與CTC機柜之間距離較短,可更改雙方傳輸波特率為38 400 bps,更快的傳輸數(shù)據(jù)以節(jié)省雙方串口通信耗時。
基于RSSP-I安全通信協(xié)議,聯(lián)鎖發(fā)往CTC的信息體格式可定義為表4協(xié)議藍本。
表4 RSPP-I框架下聯(lián)鎖發(fā)送數(shù)據(jù)協(xié)議藍本
CTC向聯(lián)鎖發(fā)送的數(shù)據(jù)流協(xié)議可以按照表5格式。
表5 RSPP-I框架下CTC發(fā)送數(shù)據(jù)協(xié)議藍本
按照上述的協(xié)議藍本,在RSSP-I協(xié)議框架下,聯(lián)鎖和CTC構(gòu)建安全通信連接,以此協(xié)議傳輸業(yè)務(wù)數(shù)據(jù)。
為了驗證協(xié)議的適用性及穩(wěn)定性[22],選擇一個標準站型、最大規(guī)模的2個車站進行測試,以北京鐵路局津秦高鐵唐山津秦場站(25組道岔、6組股道、17架進站及出站信號機)、北京鐵路局樞紐區(qū)段動車段站(259組道岔、100組股道、405架進站出站調(diào)車信號機)為例進行仿真測試。聯(lián)鎖仿真與CTC自律機軟件按照串口連接,波特率為38 400 bps。其中,唐山津秦場聯(lián)鎖的全體碼位接口數(shù)據(jù)約180字節(jié);動車段的全體碼位接口數(shù)據(jù)約為690字節(jié)的數(shù)據(jù),驗證結(jié)果見表6。
表6 新舊接口協(xié)議耗時對比 ms
基于RSSP-I安全通信協(xié)議下,通信指標與既有接口規(guī)范均滿足技術(shù)條件的要求,幾大測試項差別不大,同時對協(xié)議進行預(yù)留擴充,滿足后續(xù)新需求的擴充。測試發(fā)現(xiàn),只有超大型車站站型下相比既有的接口規(guī)范略有延時,這是因為設(shè)計的RSSP-I協(xié)議藍本每一次都發(fā)送了全站信息,且大型車站站場碼位需要分2包依次發(fā)送,從而產(chǎn)生了部分耗時,而既有接口規(guī)范默認只發(fā)送變化的站場信息。后期可以優(yōu)化調(diào)整接口協(xié)議藍本,對標準站和大型站分別處理。
隨著高速鐵路的走出去策略,我國鐵路信號產(chǎn)品按照歐洲鐵路信號安全標準進行認證并獲取獨立第三方資格認證,已成為必然趨勢。本文根據(jù)我國GB體系、歐洲EN50159標準,對CTC與聯(lián)鎖系統(tǒng)之間的既有接口通信規(guī)范進行了分析,對接口協(xié)議升級為RSSP-I協(xié)議框架進行了設(shè)計研究,并在實驗室仿真環(huán)境系下進行了測試驗證,明確了雙方之間可以按照RSSP-I協(xié)議升級,為進一步提高兩大鐵路信號系統(tǒng)之間的安全通信提供了一個方案。