本发明涉及轨道交通技术领域，尤其涉及一种基于外部真实设备的故障插入系统。
背景技术：
列车运行控制系统是保障高速铁路行车安全、提高运输效率的核心，是高速铁路的“神经中枢”。我国制定了CTCS技术规范，它是以分级形式满足不同线路运输需求的技术规范。我国300km/h以上的高速铁路已确定采用以车载速度信号显示为主的高可靠、高安全的CTCS-3级列车运行控制系统作为统一技术平台。为了保证列车能够安全、可靠的运行，必须保证CTCS-3级列车运行控制系统的可靠性。因此，高速铁路列车控制系统装机前的动态测试试验是比不可少的。
高可靠性的列控系统的仿真测试平台是提高列控系统安全性的基本保障。
在仿真测试系统搭建完成后，系统可能存在潜在的危险。RBC、TCC、GSM-R通信设备等都有可能成为危险源。为了保证列车运行的安全，使系统符合安全技术要求，需要对系统进行安全分析。一般来说，通过分析信号系统中存在的潜在危险和薄弱环节、发生事故的概率和可能的严重程度，确定系统能否满足安全要求并达到设定的安全目标。
CTCS-3级列车运行控制系统作为一个安全相关系统，要做到系统的安全能够得到接受和论证，必须经过质量管理、安全管理、功能和技术安全措施等步骤。
在对CTCS-3级列控系统的安全性分析工作中，将CTCS-3级列控系统功能需求规范作为顶级设计的基础。根据系统功能规范，对系统中可能存在的危险源进行详实、全面的分析，找出系统可能存在的所有安全隐患和危险源。包括轨旁与TCC通信故障、TCC与临时限速服务器通信故障、RBC故障、RBC与车站联锁设备通信故障、GSM-R通信中断、车载设备故障等。
在CTCS-3级列控系统仿真测试系统中故障注入方法选择是提高仿真系统的可靠性提高的重要保障。
故障注入技术(Fault Injection)是系统测试性、安全性以及功能验证研究的重要方面，是验证工作得以实现的基础。故障注入技术按照事先选定的故障模型，采取某种策略认为的、有意识的将故障注入目标系统，用以加速该系统错误和失效的发生，同时观测反馈系统对所注入故障的相应信息，通过分析，对系统进行验证和评价的过程。
故障注入的位置与故障注入的类型有关，对于处于物理层的软件故障注入和硬件故障注入并不是故障注入的重点，为了测试设备失效对安全性的影响，故障注入的位置以设备为基本单位，从而构成设备及、单系统级、多系统级的故障注入方案。
故障注入方法是一种测评容错机制有效的试验方法，他通过有意识地向系统中引入故障来加速测评容错机制的试验过程。
目前故障注入方法主要是通过系统内设备的仿真软件，将故障注入实现系统的测试验证。以CTCS-3级列控系统RBC设备系统的测试为例，RBC作为测试对象时，测试车地、相邻RBC消息交互的功能，车载ATP和相邻RBC作为陪测设备。按照测试需求，需要很多故障场景，如果车载ATP和相邻RBC作为采用纯仿真设备或者基于真实逻辑的程序进行修改，由于故障场景需要复杂的消息交互，仿真程序一个是很难模拟，而是即使模拟出了也很难保证正确性。
技术实现要素：
本发明的目的是提供一种基于外部真实设备的故障插入系统，保证了通信交互数据与真实情况的近似性，也达到了故障插入测试的目的。
本发明的目的是通过以下技术方案实现的：
一种基于外部真实设备的故障插入系统，包括：
测试自动执行框架，用于获取测试案例管理系统下发的测试脚本，并下发给自动执行适配单元，以及将执行结果反馈给测试案例管理系统；
修改执行模块，用于捕获真实陪测设备的逻辑处理单元产生的通信数据，并按照测试脚本中的执行命令对通信数据做相应的故障插入处理后再通过真实陪测设备的安全通信单元发送给被测设备。
该故障插入系统还包括：
消息修改模块，用于执行测试脚本中的命令，解析被测系统与相关安全通信单元之间的通信协议，并将相应的故障插入处理方式及相关参数传输至修改执行模块。
该故障插入系统还包括：
自动执行适配单元，用于对测试脚本的语言适配为消息修改模块所能识别的语言。
该故障插入系统还包括：第一与第二消息解析组包模块；其中：
第一消息解析组包模块，用于将逻辑处理单元产生的二进制的通信数据解析为系统内部可处理的结构化数据，并传输至修改执行模块；
第二消息解析组包模块，用于将修改执行模块输出的故障插入处理后的通信数据组包为二进制数据，再传输给真实陪测设备的安全通信单元。
故障插入处理方式包括：
丢弃消息、修改消息中变量、增加消息中信息包、延迟消息发送中的一种或多种。
由上述本发明提供的技术方案可以看出，外部陪测设备为真实设备，通过修改外部真实设备与被测对象的通信数据，保证了通信交互数据逻辑与数据的可信性，也达到了故障插入测试的目的。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。
图1为本发明实施例提供的一种基于外部真实设备的故障插入系统的示意图。
具体实施方式
下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。
CTCS-3列车运行控制系统是一个相对特殊的复杂系统，许多安全攸关的故障测试不能在真实环境中验证，只能在实验室中创建相应的故障注入测试场景进行测试。一般来说，对于被测设备与外部设备间交互信息的故障注入，普遍采用基于仿真的故障注入方法，即采用仿真的外部陪测设备创造各种故障数据。但是由于CTCS-3系统的复杂性，尤其是RBC-ATP交互消息、RBC-RBC交互消息，交互信息量大，涉及到很多系统逻辑与数据，仿真的外部设备在编制过程中一般不会像安全攸关软件那样进行严格的设计编码、单元测试、子系统测试，仿真的外部设备尚不能保证自身逻辑与数据的正确性，更无法保证用来测试被测设备的正确性。
本发明提出了一种基于外部真实设备的故障插入系统。将外部陪测设备为真实设备，通过修改外部真实设备与被测对象的通信数据，保证了通信交互数据逻辑与数据的可信性，也达到了故障插入测试的目的。
本故障插入系统中，捕获的是真实陪测设备(ATP、相邻RBC)逻辑处理单元发往安全通信单元的通信数据，根据测试脚本中的执行命令进行相应的处理，如丢弃消息、修改消息中变量、增加消息中信息包、延迟消息发送等操作，之后再通过安全通信单元发往被测设备。通过对被测设备的维护单元中的数据进行监测来判断本次测试的执行结果与预期结果是否一致。通过测试自动执行框架与测试管理系统的结合，可将测试案例、测试脚本、测试执行单元、测试人员、被测结果各部分有机结合起来。
如图1所示，为基于外部真实设备的故障插入系统的示意图，其主要包括：
1、测试自动执行框架，用于获取测试案例管理系统下发的测试脚本，并下发给自动执行适配单元，以及将执行结果反馈给测试案例管理系统。可以采用python编写的功能自动化测试框架。具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口，可以进行分布式测试执行。
2、修改执行模块，用于捕获真实陪测设备的逻辑处理单元产生的通信数据，并按照测试脚本中的执行命令对通信数据做相应的故障插入处理后再通过真实陪测设备的安全通信单元发送给被测设备。
3、测试案例管理系统，用于管理测试脚本形式的测试案例，提供测试人员操作的界面。是测试脚本、测试人员、自动测试执行、测试结果各个模块的连接单元。收到执行结果后，会判断是否与预期结果一致，从而输出测试结果。
其中，测试脚本是测试案例的体现，以关键字驱动的形式包含了各种操作，如对消息的丢弃，还包括测试预期结果。测试脚本中的内容，主要为通过消息编辑工具对已有的车地、相邻RBC原始消息进行修改，生成的相关内容。
4、消息修改模块，用于执行测试脚本中的命令，解析被测系统与相关安全通信单元之间的通信协议，并将相应的故障插入处理方式及相关参数传输至修改执行模块。
修改过程是通过修改执行模块来执行，消息修改模块主要是确定相应的处理方式。例如，对于一些实时性相关的变量进行自动处理，如T_Train、T_RBC等。
5、自动执行适配单元，用于对测试脚本的语言适配为消息修改模块所能识别的语言。
举例来说，因测试脚本为Python语言、消息修改模块为.Net语言，所以有自动执行适配单元来进行协议转换。
6、第一与第二消息解析组包模块。
其中，第一消息解析组包模块，用于将逻辑处理单元产生的二进制的通信数据解析为系统内部可处理的结构化数据，并传输至修改执行模块；
第二消息解析组包模块，用于将修改执行模块输出的故障插入处理后的通信数据组包为二进制数据，再传输给真实陪测设备的安全通信单元。
本发明实施例中，故障插入处理方式包括：丢弃消息、修改消息中变量、增加消息中信息包、延迟消息发送中的一种或多种。
本发明实施例上述方案，外部陪测设备为真实设备，通过修改外部真实设备与被测对象的通信数据，保证了通信交互数据逻辑与数据的可信性，也达到了故障插入测试的目的。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。