郝 建,張 浩,盧佩玲

(1.中國(guó)鐵道科學(xué)研究院研究生部,北京 100081； 2.中國(guó)鐵道科學(xué)研究院集團(tuán)有限公司通信信號(hào)研究所,北京 100081)

列車(chē)運(yùn)行控制系統(tǒng)是保證動(dòng)車(chē)組列車(chē)安全運(yùn)行的核心關(guān)鍵系統(tǒng)之一，其設(shè)備組成及設(shè)備間接口復(fù)雜多樣。2019年全路電務(wù)專(zhuān)業(yè)工作重點(diǎn)中強(qiáng)調(diào)“‘八橫八縱’建設(shè)必然涉及大量高鐵樞紐接入改造工作，各鐵路局要重視樞紐驗(yàn)收試驗(yàn)和現(xiàn)場(chǎng)施工方案，重視系統(tǒng)間接口和結(jié)合部，重視仿真試驗(yàn)、模擬試驗(yàn)、集成試驗(yàn)等工作，重視特殊場(chǎng)景的安全風(fēng)險(xiǎn)分析研判，增加測(cè)試案例，減少安全風(fēng)險(xiǎn)?！盵1]因此，作為對(duì)安全性要求極高的信號(hào)控制系統(tǒng)，必須深入研究列控系統(tǒng)各關(guān)鍵設(shè)備的安全防護(hù)機(jī)制，在運(yùn)用之前及時(shí)發(fā)現(xiàn)設(shè)計(jì)缺陷以避免釀成事故。

故障注入是一種重要的安全測(cè)試技術(shù)，是對(duì)系統(tǒng)功能、安全性進(jìn)行測(cè)試驗(yàn)證的重要手段。通過(guò)故障注入測(cè)試可以實(shí)現(xiàn)對(duì)列控系統(tǒng)故障的模擬，分析核心設(shè)備對(duì)故障-安全的響應(yīng)行為，以此評(píng)價(jià)系統(tǒng)的功能設(shè)計(jì)水平[2]。

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

圖1 現(xiàn)有故障注入測(cè)試方法模型

從列控設(shè)備接口間的通信數(shù)據(jù)入手，根據(jù)列控系統(tǒng)的通信機(jī)制設(shè)計(jì)了一種基于WinPcap的列控系統(tǒng)故障注入測(cè)試方法：被測(cè)設(shè)備和與之接口的陪測(cè)設(shè)備均采用真實(shí)設(shè)備，在2臺(tái)真實(shí)列控設(shè)備通信通道間插入一個(gè)故障注入模塊，完成設(shè)備間正常通信數(shù)據(jù)轉(zhuǎn)發(fā)的同時(shí)，利用安全通信機(jī)制對(duì)通信數(shù)據(jù)進(jìn)行修改，使其滿(mǎn)足故障數(shù)據(jù)的要求，實(shí)現(xiàn)對(duì)故障場(chǎng)景的模擬。

1 列控系統(tǒng)的安全通信機(jī)制

列控系統(tǒng)通信數(shù)據(jù)的安全傳輸是保證列車(chē)安全運(yùn)行的關(guān)鍵，鐵路信號(hào)安全通信協(xié)議(RSSP)是應(yīng)用于我國(guó)鐵路信號(hào)安全設(shè)備之間的安全通信協(xié)議規(guī)范，該協(xié)議由RSSP-I與RSSP-II兩部分組成。其中RSSP-I規(guī)定了信號(hào)安全設(shè)備之間使用封閉式傳輸系統(tǒng)進(jìn)行安全相關(guān)信息交互的功能結(jié)構(gòu)和協(xié)議，該協(xié)議采用32位的CRC編碼、序列號(hào)和時(shí)間戳校驗(yàn)機(jī)制等數(shù)據(jù)安全防御措施；RSSP-II規(guī)定了信號(hào)安全設(shè)備之間使用開(kāi)放式網(wǎng)絡(luò)進(jìn)行安全相關(guān)信息交互的功能結(jié)構(gòu)和協(xié)議，該協(xié)議采取了序列號(hào)、時(shí)間戳、計(jì)數(shù)器、消息驗(yàn)證碼等防御機(jī)制以抵御傳輸系統(tǒng)中的相關(guān)威脅和風(fēng)險(xiǎn)[9]。相對(duì)于封閉式傳輸系統(tǒng)而言，開(kāi)放式傳輸系統(tǒng)需要采用更多的安全防護(hù)措施來(lái)防御開(kāi)放環(huán)境中信息交互的風(fēng)險(xiǎn)[10]，因此將重點(diǎn)研究采用RSSP-II安全通信協(xié)議的列控設(shè)備的故障注入測(cè)試方法。RSSP-II規(guī)定的鐵路信號(hào)安全設(shè)備間的通信系統(tǒng)結(jié)構(gòu)如圖2所示。

圖2 RSSP-Ⅱ協(xié)議規(guī)定的通信系統(tǒng)結(jié)構(gòu)

要使故障注入測(cè)試方法盡可能滿(mǎn)足測(cè)試需求，必須對(duì)故障類(lèi)型進(jìn)行總結(jié)概括。根據(jù)EN50159標(biāo)準(zhǔn)，列控系統(tǒng)安全設(shè)備間的通信數(shù)據(jù)在傳輸過(guò)程中發(fā)生的錯(cuò)誤主要有：重復(fù)、刪除、插入、重排序、損壞、延遲、偽裝[11]。通過(guò)分析系統(tǒng)測(cè)試案例，結(jié)合等價(jià)類(lèi)劃分的思想可將數(shù)據(jù)錯(cuò)誤概括為3種類(lèi)型：①數(shù)據(jù)丟失；②數(shù)據(jù)篡改；③數(shù)據(jù)異常增加。因此在設(shè)計(jì)故障注入測(cè)試方法時(shí)需完成對(duì)以上3種數(shù)據(jù)錯(cuò)誤類(lèi)型的模擬。

2 WinPcap機(jī)制

為實(shí)現(xiàn)列控系統(tǒng)通信數(shù)據(jù)的捕獲、編輯與發(fā)送，在本方法中引入了WinPcap機(jī)制。WinPcap是一種在Windows平臺(tái)上對(duì)網(wǎng)絡(luò)數(shù)據(jù)包的捕獲機(jī)制，它允許應(yīng)用程序繞開(kāi)操作系統(tǒng)協(xié)議棧來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)包的捕獲和網(wǎng)絡(luò)分析，用于用戶(hù)層次的數(shù)據(jù)包捕獲與傳遞。WinPcap主要提供以下4種功能的實(shí)現(xiàn)：

(1)捕獲流經(jīng)網(wǎng)卡的所有原始數(shù)據(jù)包，包括在共享網(wǎng)絡(luò)上各主機(jī)發(fā)送/接收的數(shù)據(jù)包；

(2)可以基于用戶(hù)定義的規(guī)則，在數(shù)據(jù)包發(fā)往應(yīng)用程序之前，利用WinPcap提供的函數(shù)對(duì)應(yīng)用程序不關(guān)心的數(shù)據(jù)包進(jìn)行過(guò)濾；

(3)構(gòu)造并發(fā)送數(shù)據(jù)包至網(wǎng)絡(luò)；

(4)對(duì)網(wǎng)絡(luò)中流通的信息傳輸流量進(jìn)行監(jiān)控等[12-13]。

WinPcap的基本框架如圖3所示。NPF(Netgroup Packet Filter)即數(shù)據(jù)包過(guò)濾器，它既能捕獲、過(guò)濾底層網(wǎng)卡的原始網(wǎng)絡(luò)數(shù)據(jù)包，又能將額外的信息(包長(zhǎng)和時(shí)間戳)加入到數(shù)據(jù)包中并進(jìn)行存儲(chǔ)和發(fā)送。Packet.dll是一個(gè)低級(jí)動(dòng)態(tài)鏈接庫(kù)，它將應(yīng)用程序和數(shù)據(jù)包監(jiān)聽(tīng)設(shè)備程序隔離開(kāi)來(lái)，使得程序可以兼容不同的Windows系統(tǒng)。Wpcap.dll與應(yīng)用程序鏈接在一起，并向應(yīng)用程序提供完善的監(jiān)聽(tīng)接口以及功能強(qiáng)大并且便于用戶(hù)調(diào)用的函數(shù)。[14]

圖3 WinPcap的基本框架

WinPcap提供了一種真實(shí)網(wǎng)絡(luò)環(huán)境下對(duì)通信數(shù)據(jù)轉(zhuǎn)發(fā)的方式，可以實(shí)現(xiàn)對(duì)列控系統(tǒng)真實(shí)設(shè)備間通信數(shù)據(jù)的捕獲與轉(zhuǎn)發(fā)，并在轉(zhuǎn)發(fā)過(guò)程中對(duì)通信數(shù)據(jù)進(jìn)行解析與編輯。

3 基于WinPcap的列控系統(tǒng)故障注入測(cè)試方法設(shè)計(jì)

在對(duì)通信數(shù)據(jù)錯(cuò)誤類(lèi)型的總結(jié)以及利用WinPcap能夠轉(zhuǎn)發(fā)底層網(wǎng)絡(luò)數(shù)據(jù)的基礎(chǔ)上，設(shè)計(jì)出一種基于WinPcap的列控系統(tǒng)故障注入測(cè)試方法，其工作流程如圖4所示。設(shè)備A、B是列控系統(tǒng)中進(jìn)行數(shù)據(jù)交互的2臺(tái)真實(shí)設(shè)備，在A、B的通信通道間插入故障注入模塊，該模塊工作在具有一對(duì)網(wǎng)絡(luò)適配器的計(jì)算機(jī)中并通過(guò)網(wǎng)絡(luò)1、2與設(shè)備A、B相連。故障注入模塊底層功能由WinPcap完成，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)1、2上特定數(shù)據(jù)的捕獲、過(guò)濾與發(fā)送；同時(shí)模塊還可完成對(duì)A、B間通信數(shù)據(jù)的篩選、解析、編輯、重組等功能。

圖4 基于WinPcap的列控系統(tǒng)故障注入測(cè)試方法流程

3.1 網(wǎng)絡(luò)數(shù)據(jù)包獲取與篩選

網(wǎng)絡(luò)數(shù)據(jù)包的獲取與篩選過(guò)程如圖5所示。為捕獲到流經(jīng)網(wǎng)絡(luò)適配器的所有數(shù)據(jù)包，首先要對(duì)網(wǎng)絡(luò)適配器的工作模式進(jìn)行設(shè)置。計(jì)算機(jī)中每個(gè)網(wǎng)絡(luò)適配器的物理地址是唯一的，物理地址可以用來(lái)確認(rèn)由數(shù)據(jù)鏈路層發(fā)送的數(shù)據(jù)幀的源地址與目的地址。網(wǎng)絡(luò)適配器的常用工作模式包括正常模式與混雜模式，當(dāng)其工作在正常模式時(shí)，對(duì)接收到的數(shù)據(jù)幀的目的地址進(jìn)行判斷，若目的地址非該網(wǎng)絡(luò)適配器的物理地址或非廣播地址，則不響應(yīng)該數(shù)據(jù)幀；而工作在混雜模式下的網(wǎng)絡(luò)適配器會(huì)響應(yīng)接收到的每個(gè)數(shù)據(jù)幀，使操作系統(tǒng)產(chǎn)生硬件中斷，并向上層系統(tǒng)傳送數(shù)據(jù)幀中的數(shù)據(jù)，進(jìn)而對(duì)其進(jìn)行更深層次的處理[13-14]。

網(wǎng)絡(luò)適配器1若要捕獲到由設(shè)備A向設(shè)備B發(fā)送的數(shù)據(jù)幀，必須設(shè)置自身工作模式為混雜模式，此時(shí)網(wǎng)絡(luò)適配器1便可以捕獲到局域網(wǎng)內(nèi)傳輸?shù)乃袛?shù)據(jù)包。但并非所有的數(shù)據(jù)包均需要轉(zhuǎn)發(fā)，以采用以太網(wǎng)通信方式的列控設(shè)備為例，只需過(guò)濾出符合以太網(wǎng)協(xié)議的并且目的地址為設(shè)備A或者B的數(shù)據(jù)幀即可。

圖5 網(wǎng)絡(luò)數(shù)據(jù)包的獲取與篩選過(guò)程

3.2 數(shù)據(jù)包解析與編輯

由網(wǎng)絡(luò)適配器捕獲到的通信數(shù)據(jù)包是以字節(jié)流的形式存在的，如要對(duì)該形式的數(shù)據(jù)包進(jìn)行編輯，現(xiàn)有方法多是按照具體的通信協(xié)議計(jì)算出某字段在字節(jié)流中的偏移量，對(duì)特定位置的數(shù)值進(jìn)行修改。這種數(shù)據(jù)編輯方式算法繁瑣、容易出錯(cuò)且受限于具體的通信協(xié)議?？紤]到設(shè)備間通信協(xié)議的層次化，利用C#編程語(yǔ)言中面向?qū)ο蟮脑O(shè)計(jì)思想，將通信數(shù)據(jù)包依據(jù)協(xié)議并借助序列化手段解析為層次清晰的數(shù)據(jù)包對(duì)象[15]，其解析過(guò)程如圖6所示。

通信協(xié)議庫(kù)是對(duì)具體通信協(xié)議的程序語(yǔ)言描述，包括協(xié)議規(guī)定的變量名稱(chēng)、變量位置與長(zhǎng)度、取值范圍以及變量之間的關(guān)系等。在對(duì)通信數(shù)據(jù)包解析時(shí)，可根據(jù)特定變量值選擇需要參照的通信協(xié)議，提高數(shù)據(jù)解析過(guò)程的通用性。序列化庫(kù)提供序列化方法，用以實(shí)現(xiàn)數(shù)據(jù)包對(duì)象的序列化與數(shù)據(jù)字節(jié)流的反序列化。序列化庫(kù)與通信協(xié)議庫(kù)相輔相成，共同完成數(shù)據(jù)包對(duì)象與數(shù)據(jù)字節(jié)流兩種形式之間的轉(zhuǎn)化。

圖6 數(shù)據(jù)包解析過(guò)程

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

3.3 基于RSSP-Ⅱ協(xié)議的安全數(shù)據(jù)重組

RSSP-Ⅱ安全通信協(xié)議在通信系統(tǒng)中加入安全功能模塊來(lái)實(shí)現(xiàn)對(duì)通信通道上傳輸威脅的防御，安全功能模塊分為安全應(yīng)用中間子層和消息鑒定安全層兩個(gè)子模塊，每個(gè)子模塊分別用于防御不同的安全威脅，通過(guò)兩個(gè)模塊共同作用來(lái)保護(hù)消息的真實(shí)性、完整性、時(shí)效性和有序性。

圖8 安全連接建立及數(shù)據(jù)傳輸流程

RSSP-Ⅱ安全通信協(xié)議經(jīng)過(guò)分層設(shè)計(jì)，將來(lái)自應(yīng)用層的消息層層封裝、校驗(yàn)，最終實(shí)現(xiàn)消息的安全傳輸[16]。當(dāng)應(yīng)用層消息經(jīng)過(guò)編輯后，需要根據(jù)安全功能模塊中的防御機(jī)制進(jìn)行安全層數(shù)據(jù)的更新，其更新流程如圖7所示。

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

圖7 應(yīng)用消息編輯后安全層數(shù)據(jù)更新流程

消息鑒定安全層(MASL層)在SAI層基礎(chǔ)上添加MASL幀頭和消息驗(yàn)證碼(MAC)，MASL幀頭中的連接標(biāo)識(shí)符用于防止數(shù)據(jù)的插入威脅，消息驗(yàn)證碼用于防護(hù)數(shù)據(jù)的偽裝與損壞威脅，整個(gè)過(guò)程通過(guò)發(fā)送方消息源驗(yàn)證來(lái)確保消息的真實(shí)性與完整性[17]。故障注入模塊在完成對(duì)通信數(shù)據(jù)的修改后，需要按照發(fā)送方消息源認(rèn)證過(guò)程重新計(jì)算消息驗(yàn)證碼。處理過(guò)程如下。

(1)獲取發(fā)送方消息源認(rèn)證的參數(shù)。參數(shù)包括驗(yàn)證密鑰(KMAC)、消息實(shí)體m、發(fā)送方ETCS ID(SA)、接收方ETCS ID(DA)、隨機(jī)數(shù)RA與RB、消息類(lèi)型標(biāo)識(shí)符(MTI)和方向標(biāo)志(DF)等。

(2)通過(guò)改進(jìn)的數(shù)據(jù)加密算法(DES)計(jì)算會(huì)話(huà)密鑰(KSMAC)。

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

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

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

在建立安全連接過(guò)程中獲取消息源認(rèn)證所需的參數(shù)。安全服務(wù)用戶(hù)通過(guò)安全服務(wù)原語(yǔ)的方式請(qǐng)求安全層提供安全連接服務(wù)，安全連接建立與數(shù)據(jù)傳輸流程如圖8所示[18]。

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

計(jì)算3個(gè)64位密鑰KS1，KS2，KS3

將KS1，KS2，KS3連接起來(lái)即是所求的會(huì)話(huà)密鑰KSMAC。

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

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

R0=0

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

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

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

ALE層幀頭中包含ALE層數(shù)據(jù)的長(zhǎng)度與校驗(yàn)和，對(duì)應(yīng)用消息的編輯可能會(huì)造成ALE層數(shù)據(jù)長(zhǎng)度變化，此時(shí)需要更新ALE層數(shù)據(jù)長(zhǎng)度，生成CRC16-CCITT多項(xiàng)式x16+x12+x5+1,并按照FCS-16重新計(jì)算校驗(yàn)和，完成安全層數(shù)據(jù)重組。

3.4 傳輸層欺騙與數(shù)據(jù)包發(fā)送

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

在故障注入測(cè)試過(guò)程中，接收方收到長(zhǎng)度異常的數(shù)據(jù)包時(shí)，存在與數(shù)據(jù)發(fā)送方繼續(xù)保持通信連接的情況。故障注入模塊在模擬該場(chǎng)景時(shí)需對(duì)傳輸層進(jìn)行“欺騙”，修改TCP報(bào)文段的序號(hào)、確認(rèn)號(hào)及校驗(yàn)和，以維持通信雙方的正常連接狀態(tài)。數(shù)據(jù)包發(fā)送流程如圖9所示。

圖9 數(shù)據(jù)包發(fā)送流程

實(shí)現(xiàn)傳輸層“欺騙”，故障注入模塊根據(jù)報(bào)文段長(zhǎng)度的增減需要有不同的處理機(jī)制。報(bào)文段長(zhǎng)度增加時(shí)的處理流程如圖10所示，客戶(hù)端向服務(wù)器發(fā)送序號(hào)Seq=1、長(zhǎng)度Len=20的報(bào)文段，故障注入模塊向報(bào)文段中添加50個(gè)字節(jié)的數(shù)據(jù)，使其長(zhǎng)度Len變?yōu)?0。服務(wù)器在確認(rèn)收到編號(hào)為1～70的數(shù)據(jù)后，向客戶(hù)端請(qǐng)求編號(hào)為71及以后的數(shù)據(jù)。若故障注入模塊不采取TCP欺騙措施，會(huì)導(dǎo)致客戶(hù)端認(rèn)為編號(hào)為21～70的數(shù)據(jù)得到“假確認(rèn)”，產(chǎn)生這部分?jǐn)?shù)據(jù)的“偽重傳”。因此故障注入模塊需要對(duì)服務(wù)器回復(fù)客戶(hù)端的報(bào)文段中的確認(rèn)號(hào)Ack修改為21，繼續(xù)向客戶(hù)端請(qǐng)求編號(hào)為21及之后的數(shù)據(jù)，保持?jǐn)?shù)據(jù)流交互的正確性。

圖10 對(duì)報(bào)文段長(zhǎng)度異常增加時(shí)的處理流程

故障注入模塊對(duì)報(bào)文段長(zhǎng)度變短時(shí)的處理流程如圖11所示。與對(duì)數(shù)據(jù)長(zhǎng)度增加的處理流程不同的是，故障注入模塊產(chǎn)生數(shù)據(jù)丟棄操作后，需要對(duì)后續(xù)通信流程中報(bào)文段的序號(hào)與確認(rèn)號(hào)均作修改。

應(yīng)用消息的改動(dòng)同樣會(huì)影響TCP報(bào)文段首部與IP層幀頭的長(zhǎng)度與校驗(yàn)和，需要按照相應(yīng)算法對(duì)其進(jìn)行重新計(jì)算。

故障注入模塊通過(guò)網(wǎng)絡(luò)適配器1接收到來(lái)自設(shè)備A的數(shù)據(jù)后，需要將數(shù)據(jù)鏈路層中的源物理地址修改為網(wǎng)絡(luò)適配器2的物理地址，并通過(guò)網(wǎng)絡(luò)適配器2發(fā)送給設(shè)備B，實(shí)現(xiàn)通信數(shù)據(jù)從設(shè)備A到設(shè)備B的轉(zhuǎn)發(fā)。

4 故障注入測(cè)試方法實(shí)現(xiàn)與驗(yàn)證

在實(shí)驗(yàn)室環(huán)境中，以真實(shí)的無(wú)線(xiàn)閉塞中心(RBC)與臨時(shí)限速服務(wù)器(TSRS)間的故障注入測(cè)試為例，將故障注入模塊分別接入RBC-2-YH型無(wú)線(xiàn)閉塞中心的IFC-T接口轉(zhuǎn)換器與TSRS-YH型臨時(shí)限速服務(wù)器的通信機(jī)中，如圖12所示。針對(duì)3種通信數(shù)據(jù)錯(cuò)誤場(chǎng)景對(duì)設(shè)計(jì)的故障注入測(cè)試方法進(jìn)行逐一驗(yàn)證。

圖12 故障注入測(cè)試方法驗(yàn)證模型

4.1 通信數(shù)據(jù)篡改場(chǎng)景驗(yàn)證

通過(guò)CTC擬定一條限速值為45km/h的臨時(shí)限速驗(yàn)證命令，經(jīng)TSRS下發(fā)至RBC的過(guò)程中，利用故障注入模塊將限速值修改為40km/h，借助Wireshark抓包工具捕獲流經(jīng)兩個(gè)網(wǎng)絡(luò)適配器的數(shù)據(jù)，對(duì)修改前后的數(shù)據(jù)包進(jìn)行對(duì)比，同時(shí)在RBC維護(hù)終端上觀察報(bào)警信息的變化。

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

圖13 修改前后所捕獲到的數(shù)據(jù)包

圖14 RBC維護(hù)終端對(duì)于臨時(shí)限速值無(wú)效的報(bào)警

4.2 通信數(shù)據(jù)異常增加場(chǎng)景驗(yàn)證

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

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

圖15 插入數(shù)據(jù)操作前后所捕獲到的數(shù)據(jù)包

圖16 RBC維護(hù)終端對(duì)于臨時(shí)限速驗(yàn)證命令的解析

4.3 通信數(shù)據(jù)丟失場(chǎng)景驗(yàn)證

通過(guò)CTC擬定一條正確的臨時(shí)限速驗(yàn)證命令，經(jīng)RBC檢驗(yàn)該命令驗(yàn)證成功，在向TSRS回送該臨時(shí)限速狀態(tài)信息的過(guò)程中，利用故障注入模塊丟棄相應(yīng)數(shù)據(jù)包中與驗(yàn)證命令有關(guān)的數(shù)據(jù)，借助Wireshark對(duì)捕獲到的數(shù)據(jù)包進(jìn)行對(duì)比，判斷目標(biāo)數(shù)據(jù)是否成功丟棄。

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

圖17 丟棄操作前后所捕獲到的數(shù)據(jù)包

對(duì)以上3種通信數(shù)據(jù)錯(cuò)誤場(chǎng)景的模擬，成功驗(yàn)證了這種基于WinPcap的故障注入測(cè)試方法的可行性，可以滿(mǎn)足列控系統(tǒng)故障注入測(cè)試的需求。

5 結(jié)語(yǔ)

列車(chē)運(yùn)行控制系統(tǒng)是一個(gè)復(fù)雜的安全性系統(tǒng)，對(duì)該系統(tǒng)的安全功能驗(yàn)證尤其重要。相比于目前廣泛采用仿真設(shè)備實(shí)現(xiàn)故障注入的方法，基于WinPcap的列控系統(tǒng)故障注入測(cè)試方法無(wú)論在第三方認(rèn)證測(cè)試或驗(yàn)收測(cè)試中均具有更高的可信度；由于該方法設(shè)計(jì)過(guò)程不依賴(lài)于具體的通信協(xié)議，使得該方法在列控系統(tǒng)不同的設(shè)備接口間具有更好的通用性。在此基礎(chǔ)上，還可進(jìn)一步研究總結(jié)測(cè)試案例庫(kù)的相似點(diǎn)，設(shè)計(jì)通用的消息編輯模塊，實(shí)現(xiàn)消息編輯的自動(dòng)化。