列車運行控制系統故障注入測試方法研究

郝 建,張 浩,盧佩玲

(1.中國鐵道科學研究院研究生部,北京 100081； 2.中國鐵道科學研究院集團有限公司通信信號研究所,北京 100081)

列車運行控制系統是保證動車組列車安全運行的核心關鍵系統之一，其設備組成及設備間接口復雜多樣。2019年全路電務專業工作重點中強調“‘八橫八縱’建設必然涉及大量高鐵樞紐接入改造工作，各鐵路局要重視樞紐驗收試驗和現場施工方案，重視系統間接口和結合部，重視仿真試驗、模擬試驗、集成試驗等工作，重視特殊場景的安全風險分析研判，增加測試案例，減少安全風險。”[1]因此，作為對安全性要求極高的信號控制系統，必須深入研究列控系統各關鍵設備的安全防護機制，在運用之前及時發現設計缺陷以避免釀成事故。

故障注入是一種重要的安全測試技術，是對系統功能、安全性進行測試驗證的重要手段。通過故障注入測試可以實現對列控系統故障的模擬，分析核心設備對故障-安全的響應行為，以此評價系統的功能設計水平[2]。

對于列控關鍵設備邏輯功能的故障注入測試應通過可編輯腳本或程序，從通信應用層入手，向被測設備發送可以觸發故障模式的通信數據，達到將故障引入被測設備的目的[3]。目前在針對列控系統的故障注入測試中，被測設備為真實設備而與之接口的陪測設備多為具有故障模擬功能的仿真設備，其模型如圖1所示[4-8]。這類測試環境即使在一定程度上保證了系統交互數據的真實性，但是仿真設備的運用使其可信度在設備驗收測試時常受到質疑；而且在涉及邏輯處理復雜的接口(例如RBC-RBC接口)時，設計仿真接口設備的難度較高、通信數據正確性難以保證。此外，這種故障注入測試方法需針對特定接口設計專用仿真程序，仿真程序之間通用性差，降低了開發與測試效率。

圖1 現有故障注入測試方法模型

從列控設備接口間的通信數據入手，根據列控系統的通信機制設計了一種基于WinPcap的列控系統故障注入測試方法：被測設備和與之接口的陪測設備均采用真實設備，在2臺真實列控設備通信通道間插入一個故障注入模塊，完成設備間正常通信數據轉發的同時，利用安全通信機制對通信數據進行修改，使其滿足故障數據的要求，實現對故障場景的模擬。

1 列控系統的安全通信機制

列控系統通信數據的安全傳輸是保證列車安全運行的關鍵，鐵路信號安全通信協議(RSSP)是應用于我國鐵路信號安全設備之間的安全通信協議規范，該協議由RSSP-I與RSSP-II兩部分組成。其中RSSP-I規定了信號安全設備之間使用封閉式傳輸系統進行安全相關信息交互的功能結構和協議，該協議采用32位的CRC編碼、序列號和時間戳校驗機制等數據安全防御措施；RSSP-II規定了信號安全設備之間使用開放式網絡進行安全相關信息交互的功能結構和協議，該協議采取了序列號、時間戳、計數器、消息驗證碼等防御機制以抵御傳輸系統中的相關威脅和風險[9]。相對于封閉式傳輸系統而言，開放式傳輸系統需要采用更多的安全防護措施來防御開放環境中信息交互的風險[10]，因此將重點研究采用RSSP-II安全通信協議的列控設備的故障注入測試方法。RSSP-II規定的鐵路信號安全設備間的通信系統結構如圖2所示。

圖2 RSSP-Ⅱ協議規定的通信系統結構

要使故障注入測試方法盡可能滿足測試需求，必須對故障類型進行總結概括。根據EN50159標準，列控系統安全設備間的通信數據在傳輸過程中發生的錯誤主要有：重復、刪除、插入、重排序、損壞、延遲、偽裝[11]。通過分析系統測試案例，結合等價類劃分的思想可將數據錯誤概括為3種類型：①數據丟失；②數據篡改；③數據異常增加。因此在設計故障注入測試方法時需完成對以上3種數據錯誤類型的模擬。

2 WinPcap機制

為實現列控系統通信數據的捕獲、編輯與發送，在本方法中引入了WinPcap機制。WinPcap是一種在Windows平臺上對網絡數據包的捕獲機制，它允許應用程序繞開操作系統協議棧來實現對數據包的捕獲和網絡分析，用于用戶層次的數據包捕獲與傳遞。WinPcap主要提供以下4種功能的實現：

(1)捕獲流經網卡的所有原始數據包，包括在共享網絡上各主機發送/接收的數據包；

(2)可以基于用戶定義的規則，在數據包發往應用程序之前，利用WinPcap提供的函數對應用程序不關心的數據包進行過濾；

(3)構造并發送數據包至網絡；

(4)對網絡中流通的信息傳輸流量進行監控等[12-13]。

WinPcap的基本框架如圖3所示。NPF(Netgroup Packet Filter)即數據包過濾器，它既能捕獲、過濾底層網卡的原始網絡數據包，又能將額外的信息(包長和時間戳)加入到數據包中并進行存儲和發送。Packet.dll是一個低級動態鏈接庫，它將應用程序和數據包監聽設備程序隔離開來，使得程序可以兼容不同的Windows系統。Wpcap.dll與應用程序鏈接在一起，并向應用程序提供完善的監聽接口以及功能強大并且便于用戶調用的函數。[14]

圖3 WinPcap的基本框架

WinPcap提供了一種真實網絡環境下對通信數據轉發的方式，可以實現對列控系統真實設備間通信數據的捕獲與轉發，并在轉發過程中對通信數據進行解析與編輯。

3 基于WinPcap的列控系統故障注入測試方法設計

在對通信數據錯誤類型的總結以及利用WinPcap能夠轉發底層網絡數據的基礎上，設計出一種基于WinPcap的列控系統故障注入測試方法，其工作流程如圖4所示。設備A、B是列控系統中進行數據交互的2臺真實設備，在A、B的通信通道間插入故障注入模塊，該模塊工作在具有一對網絡適配器的計算機中并通過網絡1、2與設備A、B相連。故障注入模塊底層功能由WinPcap完成，實現對網絡1、2上特定數據的捕獲、過濾與發送；同時模塊還可完成對A、B間通信數據的篩選、解析、編輯、重組等功能。

圖4 基于WinPcap的列控系統故障注入測試方法流程

3.1 網絡數據包獲取與篩選

網絡數據包的獲取與篩選過程如圖5所示。為捕獲到流經網絡適配器的所有數據包，首先要對網絡適配器的工作模式進行設置。計算機中每個網絡適配器的物理地址是唯一的，物理地址可以用來確認由數據鏈路層發送的數據幀的源地址與目的地址。網絡適配器的常用工作模式包括正常模式與混雜模式，當其工作在正常模式時，對接收到的數據幀的目的地址進行判斷，若目的地址非該網絡適配器的物理地址或非廣播地址，則不響應該數據幀；而工作在混雜模式下的網絡適配器會響應接收到的每個數據幀，使操作系統產生硬件中斷，并向上層系統傳送數據幀中的數據，進而對其進行更深層次的處理[13-14]。

網絡適配器1若要捕獲到由設備A向設備B發送的數據幀，必須設置自身工作模式為混雜模式，此時網絡適配器1便可以捕獲到局域網內傳輸的所有數據包。但并非所有的數據包均需要轉發，以采用以太網通信方式的列控設備為例，只需過濾出符合以太網協議的并且目的地址為設備A或者B的數據幀即可。

圖5 網絡數據包的獲取與篩選過程

3.2 數據包解析與編輯

由網絡適配器捕獲到的通信數據包是以字節流的形式存在的，如要對該形式的數據包進行編輯，現有方法多是按照具體的通信協議計算出某字段在字節流中的偏移量，對特定位置的數值進行修改。這種數據編輯方式算法繁瑣、容易出錯且受限于具體的通信協議。考慮到設備間通信協議的層次化，利用C#編程語言中面向對象的設計思想，將通信數據包依據協議并借助序列化手段解析為層次清晰的數據包對象[15]，其解析過程如圖6所示。

通信協議庫是對具體通信協議的程序語言描述，包括協議規定的變量名稱、變量位置與長度、取值范圍以及變量之間的關系等。在對通信數據包解析時，可根據特定變量值選擇需要參照的通信協議，提高數據解析過程的通用性。序列化庫提供序列化方法，用以實現數據包對象的序列化與數據字節流的反序列化。序列化庫與通信協議庫相輔相成，共同完成數據包對象與數據字節流兩種形式之間的轉化。

圖6 數據包解析過程

在數據包對象中可容易地實現對需要編輯的字段的定位，按照協議規定的格式添加應用消息包或丟棄某些數據。一套測試案例庫對應于一個消息編輯函數集，更換故障注入的接口時只需修改消息編輯函數即可，這樣使得該故障注入測試方法在不同設備接口間具有較高的通用性。

3.3 基于RSSP-Ⅱ協議的安全數據重組

RSSP-Ⅱ安全通信協議在通信系統中加入安全功能模塊來實現對通信通道上傳輸威脅的防御，安全功能模塊分為安全應用中間子層和消息鑒定安全層兩個子模塊，每個子模塊分別用于防御不同的安全威脅，通過兩個模塊共同作用來保護消息的真實性、完整性、時效性和有序性。

圖8 安全連接建立及數據傳輸流程

RSSP-Ⅱ安全通信協議經過分層設計，將來自應用層的消息層層封裝、校驗，最終實現消息的安全傳輸[16]。當應用層消息經過編輯后，需要根據安全功能模塊中的防御機制進行安全層數據的更新，其更新流程如圖7所示。

安全應用中間子層(SAI層)通過給應用層數據封裝SAI層幀頭，提供消息時效性和有序性保護。應用層數據的丟棄、篡改與異常增加等錯誤并不涉及SAI層防御機制的更改。

圖7 應用消息編輯后安全層數據更新流程

消息鑒定安全層(MASL層)在SAI層基礎上添加MASL幀頭和消息驗證碼(MAC)，MASL幀頭中的連接標識符用于防止數據的插入威脅，消息驗證碼用于防護數據的偽裝與損壞威脅，整個過程通過發送方消息源驗證來確保消息的真實性與完整性[17]。故障注入模塊在完成對通信數據的修改后，需要按照發送方消息源認證過程重新計算消息驗證碼。處理過程如下。

(1)獲取發送方消息源認證的參數。參數包括驗證密鑰(KMAC)、消息實體m、發送方ETCS ID(SA)、接收方ETCS ID(DA)、隨機數RA與RB、消息類型標識符(MTI)和方向標志(DF)等。

(2)通過改進的數據加密算法(DES)計算會話密鑰(KSMAC)。

(3)構建字符串S="l|DA|m|p"；

(4)使用會話密鑰KS和CBC-MAC函數計算字符串S的MAC值：

MAC(m)=CBC-MAC(KS，S)。

在建立安全連接過程中獲取消息源認證所需的參數。安全服務用戶通過安全服務原語的方式請求安全層提供安全連接服務，安全連接建立與數據傳輸流程如圖8所示[18]。

從安全層服務原語AU1 SaPDU與AU2 SaPDU中分別獲取隨機數RB、RA、發送方與接收方ETCS ID，從DT SaPDU中獲取消息實體m、MTI和DF。以通信雙方之間共享的驗證密鑰KMAC(K1，K2，K3)和隨機數RA、RB為參數，通過改進的DES算法，生成一個192位的會話密鑰KSMAC(KS1，KS2，KS3)，方法如下。

計算3個64位密鑰KS1，KS2，KS3

將KS1，KS2，KS3連接起來即是所求的會話密鑰KSMAC。

消息實體m='000'|MTI|DF|SaDU由指示DTSaPDU的消息類型標識符(MTI)、方向標志(DF)和安全用戶數據SaDU組成，并與長度l、接收方地址DA和填充數據p組成字符串S="l|DA|m|p"。

將字符串S分為64位塊結構S1、S2、…、Sq，F(KSn，Q)為通過會話密鑰KSn(n=1，2，3)對數據串Q進行加密的函數，加密結果為R；F-1(KSn，Q)為解密函數，⊕為異或運算符，通過以下迭代過程定義字符串S的MAC計算函數CBC-MAC(KS，S)

R0=0

Ri=F(KS1，Ri-1⊕Si)i=1，2，…,q-1

Rq=F(KS3，F-1(KS2，F(KS1，Rq-1⊕Sq)))

Rq即為所計算的字符串S的MAC值[19]，并將其更新到編輯后的數據中。

ALE層幀頭中包含ALE層數據的長度與校驗和，對應用消息的編輯可能會造成ALE層數據長度變化，此時需要更新ALE層數據長度，生成CRC16-CCITT多項式x16+x12+x5+1,并按照FCS-16重新計算校驗和，完成安全層數據重組。

3.4 傳輸層欺騙與數據包發送

TCP協議是一種可靠的、面向連接的數據流協議，其對于可靠傳輸的實現得益于本身的序號與確認號機制。將一個TCP連接中傳送的字節流中的每個字節都按順序編號，TCP報文段首部中的序號(Seq)指的是本報文段所發送數據的第一個字節的編號，確認號(Ack)是指期望收到通信對方下一個報文段的第一個數據字節的編號[20]。對于發送方發送的數據，接收方在接收到數據之后必須在規定時間內予以確認，若未確認則意味著接收方沒有接收到數據，發送方需對數據進行重傳。如果在故障注入過程中應用層數據長度發生變化，則接收方所能確認的數據長度同樣發生變化，若對接收方回復發送方的確認號不做處理，會使發送方認為在傳輸過程中存在數據丟失或假確認的情況，造成重傳或偽重傳過程。

在故障注入測試過程中，接收方收到長度異常的數據包時，存在與數據發送方繼續保持通信連接的情況。故障注入模塊在模擬該場景時需對傳輸層進行“欺騙”，修改TCP報文段的序號、確認號及校驗和，以維持通信雙方的正常連接狀態。數據包發送流程如圖9所示。

圖9 數據包發送流程

實現傳輸層“欺騙”，故障注入模塊根據報文段長度的增減需要有不同的處理機制。報文段長度增加時的處理流程如圖10所示，客戶端向服務器發送序號Seq=1、長度Len=20的報文段，故障注入模塊向報文段中添加50個字節的數據，使其長度Len變為70。服務器在確認收到編號為1～70的數據后，向客戶端請求編號為71及以后的數據。若故障注入模塊不采取TCP欺騙措施，會導致客戶端認為編號為21～70的數據得到“假確認”，產生這部分數據的“偽重傳”。因此故障注入模塊需要對服務器回復客戶端的報文段中的確認號Ack修改為21，繼續向客戶端請求編號為21及之后的數據，保持數據流交互的正確性。

圖10 對報文段長度異常增加時的處理流程

故障注入模塊對報文段長度變短時的處理流程如圖11所示。與對數據長度增加的處理流程不同的是，故障注入模塊產生數據丟棄操作后，需要對后續通信流程中報文段的序號與確認號均作修改。

應用消息的改動同樣會影響TCP報文段首部與IP層幀頭的長度與校驗和，需要按照相應算法對其進行重新計算。

故障注入模塊通過網絡適配器1接收到來自設備A的數據后，需要將數據鏈路層中的源物理地址修改為網絡適配器2的物理地址，并通過網絡適配器2發送給設備B，實現通信數據從設備A到設備B的轉發。

4 故障注入測試方法實現與驗證

在實驗室環境中，以真實的無線閉塞中心(RBC)與臨時限速服務器(TSRS)間的故障注入測試為例，將故障注入模塊分別接入RBC-2-YH型無線閉塞中心的IFC-T接口轉換器與TSRS-YH型臨時限速服務器的通信機中，如圖12所示。針對3種通信數據錯誤場景對設計的故障注入測試方法進行逐一驗證。

圖12 故障注入測試方法驗證模型

4.1 通信數據篡改場景驗證

通過CTC擬定一條限速值為45km/h的臨時限速驗證命令，經TSRS下發至RBC的過程中，利用故障注入模塊將限速值修改為40km/h，借助Wireshark抓包工具捕獲流經兩個網絡適配器的數據，對修改前后的數據包進行對比，同時在RBC維護終端上觀察報警信息的變化。

利用故障注入模塊對數據包修改前后所捕獲到的數據包分別如圖13(a)與圖13(b)所示。參照RBC與TSRS的接口規范可分析出該臨時限速驗證命令中的限速值已由0x09修改為0x08[21]，同時RBC接收到該命令并判斷臨時限速值無效，由維護終端給出報警信息，如圖14所示。

圖13 修改前后所捕獲到的數據包

圖14 RBC維護終端對于臨時限速值無效的報警

4.2 通信數據異常增加場景驗證

在RBC與TSRS正常通信過程中，通過故障注入模塊編輯臨時限速驗證命令信息包并插入到某一通信周期的數據中，借助Wireshark對捕獲到的數據包進行對比，同時在RBC維護終端上觀察輸入輸出信息的變化。

利用故障注入模塊進行插入數據操作前后所捕獲到的數據包分別如圖15(a)與圖15(b)所示。參照RBC與TSRS的接口規范可分析出該通信周期中增加了臨時限速驗證命令的信息；同時RBC接收到該命令，判斷該臨時限速驗證信息有效，由維護終端給出該命令的解析與執行情況，如圖16所示。

圖15 插入數據操作前后所捕獲到的數據包

圖16 RBC維護終端對于臨時限速驗證命令的解析

4.3 通信數據丟失場景驗證

通過CTC擬定一條正確的臨時限速驗證命令，經RBC檢驗該命令驗證成功，在向TSRS回送該臨時限速狀態信息的過程中，利用故障注入模塊丟棄相應數據包中與驗證命令有關的數據，借助Wireshark對捕獲到的數據包進行對比，判斷目標數據是否成功丟棄。

利用故障注入模塊進行數據丟棄操作前后所捕獲到的數據包分別如圖17(a)與圖17(b)所示。參照RBC與TSRS的接口規范可分析出該通信周期中臨時限速驗證成功的信息被成功丟棄。

圖17 丟棄操作前后所捕獲到的數據包

對以上3種通信數據錯誤場景的模擬，成功驗證了這種基于WinPcap的故障注入測試方法的可行性，可以滿足列控系統故障注入測試的需求。

5 結語

列車運行控制系統是一個復雜的安全性系統，對該系統的安全功能驗證尤其重要。相比于目前廣泛采用仿真設備實現故障注入的方法，基于WinPcap的列控系統故障注入測試方法無論在第三方認證測試或驗收測試中均具有更高的可信度；由于該方法設計過程不依賴于具體的通信協議，使得該方法在列控系統不同的設備接口間具有更好的通用性。在此基礎上，還可進一步研究總結測試案例庫的相似點，設計通用的消息編輯模塊，實現消息編輯的自動化。