列车运行控制系统故障注入测试方法研究

郝 建,张 浩,卢佩玲

(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的列控系统故障注入测试方法无论在第三方认证测试或验收测试中均具有更高的可信度；由于该方法设计过程不依赖于具体的通信协议，使得该方法在列控系统不同的设备接口间具有更好的通用性。在此基础上，还可进一步研究总结测试案例库的相似点，设计通用的消息编辑模块，实现消息编辑的自动化。