C2级列控中心仿真测试平台设计与应用

尹 青， 上官伟， 张军政， 胡妙春， 臧一佩

(1.中国铁道科学研究院集团有限公司，北京 100044； 2.北京交通大学 电子信息工程学院，北京 100044)

随着我国高铁线路的大规模发展，对铁路运输安全提出了更高的要求，列控中心(Train Control Center,TCC)系统作为高铁技术核心之一，在保障高铁安全运行方面起着重要作用。列控中心系统由安全主机子系统、驱采子系统、通信接口子系统、维护子系统和电源子系统5个部分组成。该系统根据管辖范围内各列车位置、联锁进路和线路临时限速状态等信息，控制轨道电路编码和有源应答器信息，向列车提供运行许可。

现有的C2级列控中心仿真工程测试主要依靠人工完成，即按照测试案例逐条进行手动测试，包括案例的编写也主要依靠人工，带有较大的盲目性和不确定性，同时测试人员的行为倾向使得他们选择的测试用例往往仅能测出所熟悉或印象较深的错误，且在工程项目较多、工期较为紧张的情况下，测试人员对系统的熟悉程度和自身疲劳程度对测试质量和效率都有较大影响。因此需要开发更为高效智能的自动化测试产品以减少对人工的依赖，提高测试质量和效率。

针对以上问题，在数据配置及软件功能测试方面，笔者探讨了将机器学习应用在C2列控中心室内仿真测试案例的生成中，实现通过智能分析站场数据，生成有针对性的测试案例，结合分析以往的测试数据，优化测试结构，并研究自动测试框架，自动执行并对被测对象的输出进行验证和评判，能够减少大量重复烦琐的人工测试工作，从而降低人为因素造成的错误率，提高测试效率。

1 列控中心仿真测试平台架构

1.1 室内仿真测试需求

在C2级系统中，列控中心软件主要完成以下功能：

① 根据列车进路和轨道区段状态等信息，实现站内和区间轨道电路的编码；

② 通过安全数据网接收临时限速信息，实现应答器报文的实时组帧、编码并发送给地面电子单元(Lineside Electronic Unit,LEU);

③ 实现区间运行方向与闭塞的控制；

④ 实现信号机的点灯控制；

⑤ 实现TCC间、联锁系统(Computer Based Interlocking,CBI)、调度集中系统(Centralized Traffic Control,CTC)信息的传输；

⑥ 实现区间闭塞分区的占用逻辑检查等。

针对以上功能，测试内容主要包括站内、区间载频校验；站内进路编码测试；区间编码及点灯测试；改方测试；异物防护配置测试；无限速报文测试；大号码道岔应答器报文发送测试；进路限速及信号降级测试；正线及区间限速测试；接口配置测试[1]；长短链限速测试等[2]。

测试环境由TCC真机、仿真邻站TCC、仿真CBI、仿真临时限速服务器(Temporary Speed Restriction Server,TSRS)、仿真CTC、仿真LEU、仿真继电器驱采(IO)、仿真轨道电路和维护终端组成。TCC室内仿真测试设备连接如图1所示。

图1 TCC室内仿真测试设备连接图

现有TCC仿真测试主要由人工进行，在验证轨道电路编码正确性时需要人工排列进路，根据码序图和信号显示关系图等资料数据验证编码、边界和改方等信息。在测试报文时需要人工验证有源应答器的所有场景报文[3]，包括无限速时和有限速时、接车报文、发车报文、预告报文等，工作量较大。

1.2 系统架构设计

C2级智能列控中心仿真测试平台架构如图2所示，主要包括3个模块：通信接口模块、验证服务模块、AI案例生成及执行模块。通过AI驱动的案例选择引擎生成有针对性的测试案例，再对外部输入驱动数据进行解析，对数据进行关键字特征提取，自动执行测试案例序列，并通过通信接口模块接收被测TCC系统的输出数据，将输出数据交由验证服务模块进行评判验证，同时给出测试结果。

图2 C2级智能列控中心仿真测试平台架构图

1.2.1 基于vSphere的通信接口模块

试验开始前，首先需要人工创建测试环境，目前主要是在多个物理设备上进行人工部署，传统物理结构如图3所示。

图3 传统物理结构

本测试平台的一个创新点在于整合管理多台物理服务器的计算、网络和存储，形成集中的资源库，在资源库中为不同的测试环境分配虚拟机和划分虚拟局域网(Virtual Local Area Network,VLAN)，为仿真CTC、仿真TCC、仿真TSRS、仿真CBI和接口仿真等提供基础运行环境，在很大程度上减少了物理接口，提高了运行的稳定性，并可以将部署时间大幅缩短。通过多个操作系统的整合，只需采用一台高性能服务器，即可构建资源集中和共享的新服务器模式，满足日益扩大的应用需求。

创建方法是在物理服务器中分布式安装vSphere，完成ESXi服务器配置，然后通过安装vCenter，将ESXi服务器连入vCenter服务器进行集中管理[4]。同时，将存储接入ESXi服务器，并按网卡分配规则，将网卡指定给不同的虚拟交换机，并配置不同的端口组，同时指定不同的VLAN，安装相应虚拟机后，配置不同的端口组，从而实现虚拟机间网络互联。不同于传统的测试环境，vSphere虚拟化环境实现了物理资源的池化和计算资源的共享，省去了互联机器间的线缆，提高了机器之间可靠性和可管理性[5]。串口通信设备均为仿真时，可采用虚拟串口工具实现。

在配置完vSphere和vCenter的整体环境后，该平台可提供虚拟机生成和网络服务，其中，网络服务主要由虚拟化环境中的虚拟交换机和虚拟端口组提供，基本满足了列控设备的集成测试环境需求。

根据实际通信需求将通信接口设计为3种通信方式。以太网通信模块主要实现集成测试平台中集成封装的仿真CBI、仿真TSRS、仿真邻站TCC、仿真LEU(以太网)与被测TCC系统之间的数据交互。

RS422串口通信模块主要实现集成测试平台中集成封装的仿真CTC、仿真LEU(串口)与被测TCC系统之间的数据交互。

CAN总线通信模块主要实现集成测试平台中集成封装的仿真IO与被测TCC系统之间的数据交互。

1.2.2 案例生成及执行模块

案例生成模块主要包含数据解析、案例生成和案例执行3个部分。首先应对输入源文件进行数据解析、信息提取和结构重组。案例生成工具根据重组后的数据预测生成车站所需测试案例，再通过Robot Framework 测试框架自动遍历执行测试案例。输入源文件包括与其他系统的接口文件、设计数据、LEU端口表、TSRS管辖范围表等。

1.2.3 验证服务模块

验证服务模块采用Robot Framework测试驱动框架，解析不同测试案例对应脚本的指令，根据脚本信息向仿真测试系统下发相应的指令，并实时获取列控中心所反馈的状态信息，从而对结果做出判断。

① 报文验证。测试平台下发报文测试序列后，接收由TCC回传的报文数据并进行验证。标准站场示意图如图4所示，其中BX即X发车口的进站应答器，以此类推。

图4 标准站场示意图

例如X→XI这条进路，由测试平台下发联锁进路命令，列控中心执行后，回传该进路所需要核对的有源应答器报文，平台接收后，对该应答器报文数据进行解析验证，并生成报告，若不一致通过红色高亮显示，再由人工进行确认。

② 码序验证。码序验证测试流程如图5所示。码序验证模块根据设计提供的码序表、编码规范、联锁进路排列和信号开放情况，生成预期码序输出表，将其与被测TCC输出的码序进行验证评判。测试平台自动执行码序测试案例，判断实际值与预期值是否一致。

图5 码序验证测试流程

③ 限速验证。限速验证模块包括2个部分：验证信号机限速降级信息、验证边界和进站应答器配置。主要验证包括平台下发给被测TCC的限速命令，被测TCC系统是否正确执行，限速线路号、起始公里标、终点公里标以及应答器限速报文是否正确。

2 关键技术

2.1 决策树算法驱动的案例选择器

仿真测试的一个关键点是测试案例的生成，针对不同站型，重点研究如何生成适合的测试案例。案例选择器根据决策树算法，学习以往的案例生成方式，结合历史数据和问题库，通过大数据加上机器学习，针对不同站型选择出该车站的适用案例。目标测试案例为工程测试案例，软件的功能测试案例不作为本次研究的重点。

案例选择器基于决策树算法设计，决策树算法是一种非常有效的数据分类技术，有着与流程图相似的树结构[6]。特定站型和所有案例有直接相关性，例如标准站都有A类案例，非标站没有B类案例，C类案例只在某种站型中出现等。前述相关性不太好描述，所以根据历史积累的数据，基于决策树算法进行训练，最终实现了AI驱动的案例选择器。决策树有多种算法，例如ID3算法、C4.5算法和CART算法[7]等。 ID3中根据属性值分割数据，之后该特征不再起作用，这种快速切割的方式会影响算法的准确率。而CART是一棵二叉树，采用二元切分法，每次把数据切成2份，分别进入左子树和右子树，叶子节点比非叶子多1。相比ID3和C4.5，CART应用要多一些，既可以用于分类也可以用于回归。CART分类时，使用基尼(Gini)指数来选择最好的数据分割的特征，Gini指数描述的是纯度，与信息熵的含义相似。CART中每一次迭代都会降低Gini指数。因此本研究选取CART算法。

以一个标准车站为例，从数据中获取最终案例生成所需要的各个特征点，包括股道数量、发车口类型、轨道电路制式、站内及区间编码方式、区间信号控制方式、异物侵限配置、大号码道岔配置、站台门配置和区间占用逻辑检查配置等。通过决策树算法，根据特征点与数据的匹配一致性来判断出是否生成该特征点对应的测试案例。案例选择器决策树结构如图6所示。

图6 案例选择器决策树结构

实际工作中，测试人员对报错的报告进行检查，确认该错误。对于正确的报告，考虑到AI引擎可能漏选，故需进行有针对性的补充测试。将每次的结果再次输入给选择器进行训练，不断地提高准确性，并丰富测试案例库。

测试案例库的管理使用SQL数据库进行。模型服务流程如图7所示。把数据引入到系统后，先用 SQL算子对数据做了拼接，然后清洗一些无效数据； 再把数据拆分为训练集和测试集，分别对2个数据集做特征抽取；之后训练集传递给机器学习算法进行训练，训练后使用测试集来测试模型的效果。由近年来已测工程车站的数据训练结果可知，该模型是有效的。

图7 模型服务流程

通过历史测试案例训练出决策树模型后，发布一个预测服务，然后输入新的数据后可根据模型算出一个预测值，即针对该站的测试案例。当然，拥有的数据越多、越丰富、越真实，训练出的模型效果越好。

2.2 关键字驱动测试模型

Robot Framework是基于Python 语言编写开发的，是支持关键字驱动的自动化测试框架，多个测试案例可以通过同一关键字的调用实现测试的功能，脚本复用度较高。Robot Framework内置全局日志管理模块，包含多种案例库管理与测试报告生成工具[8-10]，支持多设备通信，包括Telnet、SSH、XML-RPC等。

以关键字驱动的自动化测试由关键字构成测试案例对应的脚本[11]，通过改变关键字来驱动自动化测试的执行，最终引起测试结果的变化。关键字即对测试操作的抽象与封装，其执行顺序代表着系统的业务逻辑[12]。在关键字驱动模式下，测试数据存储于数据文件中，与关键字相独立，通过Robot Framework的开源图形界面开发工具RIDE实现测试案例的管理和执行，如图8所示。采用基于Internet过程调用实现的XML-RPC通信协议，将执行模块作为客户端，TCC接口适配仿真作为服务端，完成测试指令的解析和执行，从而实现非侵入式闭环的黑盒自动测试。

图8 基于RIDE开发工具的测试案例管理界面图

码序测试或报文测试都是在排列进路的基础上完成的，TCC与联锁、相邻TCC等系统的交互会影响轨道电路码序的改变以及有源应答器报文的选择[13]。因此本测试平台将测试案例中的进路相关操作封装于关键字中，将进路的始端与终端信号按钮写入数据文件。执行测试案例时，Robot Framework根据测试案例中的步骤，加载相应的数据文件并调用关键字对应的底层代码，完成对联锁进路的操作，以便进行之后的测试。

3 仿真平台测试结果验证

以连镇线宝应站数据为测试输入来验证笔者提出的测试方法的可行性。宝应站为4股道标准车站，将该站数据引入AI驱动的案例选择器后，生成目标测试案例种类包括站内区间编码测试、改方测试、报文测试、限速及区间逻辑占用检查测试和站台门测试案例，站场部分特征筛选如表1所示。将案例选择器生成结果与手动编写案例进行对比，结果如表2所示。由表2可知，案例选择器生成的案例种类等于手动编写案例，而数量则等于或多于手动编写案例。应用于多个车站后，结果表明基于决策树算法驱动的案例选择器生成的案例覆盖率更高。

表1 站场部分特征筛选表

表2 宝应站两种案例生成方式生成种类及数量对比

以发码自动化测试为例，选择X→X1→SF发码测试案例，码序测试的测试案例大致步骤如表3所示。单击“运行”按钮，执行该测试案例，能够生成简单易读的测试报告和码序验证结果，测试报告中案例测试若执行失败，背景显示红色，反之则显示绿色，如图9所示。

表3 测试案例步骤一览表

图9 码序验证结果

测试报告记录了本次案例自动执行的结果，包括场景执行的成功与失败的次数以及执行完该案例的耗时,测试执行结果报告如图10所示。该进路的码序遍历测试在 5 s 内完成，扩展到全站时不超过10 min，用时远小于人工测试，结果表明采用所提出的自动测试方案在案例生成和测试用时方面均远小于人工测试，测试效率有显著提高，验证了该方案的可行性和有效性。

图10 测试执行结果报告

4 结束语

本文提出了一种列控系统室内仿真自动测试平台的设计方法，该仿真测试平台实现列控中心系统数据配置的自动化测试，并提供直观的测试结果，缩短了项目工程周期，通过计算机的自动计算代替人工计算，有效减少了人为失误并节省了人力资源的投入，提高了效率。同时，积累了测试经验数据，通过逐步优化测试案例算法，可挖掘测试盲区，保证测试质量，有较高的工程应用价值，减少了人工成本，提高了生产率。