临时限速服务器(TSRS)仿真测试平台研究与实现

林 鹏 徐中伟 丰文胜

（1.同济大学 电子与信息工程学院，上海 201804；2.上海申通地铁集团有限公司，上海 200122）

列车速度控制是列车控制系统核心功能之一，通过对线路上运行列车进行有计划的速度控制能够在保障运行效率的同时，提高列车运行的安全性。列车在运行时，铁路线路上可能存在临时的人为施工情况，也可能出现天气突变、自然灾害等突发状况，这就要求列控系统不仅能够做到大范围、定时的速度控制，还要能够做到局部、即时的速度控制。

临时限速服务器(Temporary Speed Restriction Server，TSRS) 是第三代中国列车控制系统(Chinese Train Contral System，CTCS-3) 系 统中重要的组成部分，为列车安全运行提供了必要的限速管理控制能力。依托TSRS，列车调度员能够更加轻松、灵活、集中地进行列车的限速管理，做到精细及时的控制，并兼顾行车效率和安全性。

CTCS-3 系统由许多计算机子系统组成，除了TSRS，还包括调度集中系统(CTC)、无线闭塞中心(RBC)、列车控制中心(TCC)、计算机联锁(CBI)等设备。由于TSRS 在现场运行中需要与多数其他子系统协同工作，而这些子系统又大多昂贵且复杂，因此TSRS 设备在调试检测过程中，就需要一套仿真测试平台，能模拟其他子系统的功能，构造仿真的测试环境，实现高效简便低成本的TSRS 设备测试。

1 TSRS介绍

TSRS 是一个临时限速的统一管理平台，能够对来自CTC 的临时限速命令(简称TSR 命令)进行储存、校验、删除、拆分、设置、下发以及取消等。

在线路现场，TSRS 系统需要与其他系统设备相互通信，相互协作，以完成对临时限速正常执行。相关的系统设备包括相邻的TSRS、CTC、RBC、TCC 等。通过关注各个系统之间逻辑通信链路并忽略与TSRS 无关的设备，可以抽象出系统结构图，如图1 所示。

图1 临时限速相关系统组成Fig.1 Composition of temporary speed limit related systems

调度人员通过CTC 下发TSR 命令到TSRS 服务器，TSRS 服务器分析处理TSR 命令后，下发命令至RBC、TCC，RBC 和TCC 对 限 速 命 令 进 行 验证与执行。由于相邻的TSRS 服务器管辖范围有重叠，因此位于两个TSRS 管理区域边界处的临时限速，需要相邻的TSRS 协助执行。衔接站TCC 位于既有线与客运专线的分界处，由于既有线没有TSRS 服务器，因此分界处的限速命令需要衔接站与TSRS 服务器配合处理。

2 仿真测试平台的设计与实现

2.1 测试平台的系统设计和仿真器设计

要搭建TSRS 服务器仿真测试平台，首先需要搭建一个TSRS 服务器能够正常运行的环境。根据图1 所示的各个子系统间的关系，需要实现CTC、RBC、TCC、相邻TSRS、衔接站TCC 这几个设备的仿真。出于简便低成本考虑，通过开发桌面软件模拟这些设备，并只关注这些设备与临时限速相关的功能。整个测试平台需要一个测试引擎进行统筹管理并提供自动化测试功能，需要数据库保存限速信息和测试结果信息。

CTC 具有站场信息管理、列车计划管理、车次追踪、危险报警、临时限速管理等功能。CTC 仿真器着重关注临时限速相关的功能，提供了手动设置限速命令窗口，能够人为输入限速命令类型、限速原因、限速值、限速时间、限速位置等限速命令必要信息，根据操作向临时限速服务器下达临时限速的拟定、验证、执行、删除、取消等命令。同时CTC 仿真器还提供了初始化命令下发、限速命令记录、连接状态显示、报文信息查看以及线路图显示等功能。为了满足自动化测试的需求，提供通信接口以供测试引擎控制CTC 仿真器。

RBC 通过GSM-R 与车载设备进行无线通信，具有行车许可、列车注册以及临时限速等功能。由于只关注TSRS 的测试，因此RBC 仿真器无需实现无线通信环境与车载设备仿真，只需实现对TSR命令的逻辑处理功能即可。考虑到一个TSRS 服务器的管辖范围内往往有多个RBC 站点，采用站点信息与功能分离的设计，RBC 仿真器通过读取对应站点的配置信息，运行对应的RBC 仿真站点。RBC 仿真器将接收到的各种限速命令信息保存在数据库中。为了验证TSRS 的可靠性，RBC 仿真器引用故障注入功能，对正常的限速命令处理逻辑和设备通信逻辑进行修改打断，测试TSRS 设备是否要求的故障处理能力。RBC 仿真器同样提供了供测试引擎控制的接口。

TCC 具有控制轨道电路发码、控制区间运行方向、控制车站信号机以及临时限速执行等功能。如果忽略轨道电路、LEU 以及应答器等线路设备对TCC 的影响，只考虑TCC 与TSRS 通信的接口规范，就会发现对于临时限速TCC 具有与RBC 相似的处理逻辑，因此实现了一个外观和功能与RBC仿真器相似的TCC 仿真器，并实现其他的TCC 独有的功能。衔接站TCC (也称边界转换站TCC)位于客运专线与既有线交界处，既有线侧，由于既有线没有设置TSRS 服务器，因此衔接站TCC 需要既能够接收客专侧的TSRS 服务器的TSR 命令，又能够处理直接来自CTC 的限速命令。除了以上特点，衔接站TCC 与客专线TCC 具有相同的功能，因此TCC 仿真器囊括了衔接站TCC 的功能。

相邻TSRS 服务器的管辖范围存在重叠区域，当需要在重叠处执行TSR 命令时，需要相邻的TSRS 相互协作。开发相邻TSRS 仿真器用于测试TSRS 服务器对于跨界TSR 命令的处理能力以及与相邻的TSRS 的协作能力。TSRS 服务器对于跨界临时限速的拟定、验证、执行、取消、删除都要通知相邻的TSRS，并需要等待相邻TSRS 的回复后综合判断当前临时限速的执行状态。相邻TSRS 仿真器对来自被测TSRS 的命令提供了处理、显示、存储、故障响应等功能，同时相邻TSRS 仿真器还提供了简要的TSR 命令操作界面，模拟上述TSRS服务器对跨界TSR 命令的操作，以验证被测TSRS对非其拟定的TSR 命令的处理能力。

测试引擎提供了系统初始化、仿真器管理、系统状态监控、自动化测试以及数据记录等功能。测试引擎能够读取配置信息初始化所有的仿真器。测试引擎通过运行测试脚本运行自动测试，能够按照测试脚本的命令并通过各个仿真器提供的通信接口向仿真器发送操控命令控制仿真器运行测试，同时仿真器返回测试结果信息也能够被记录分析。测试引擎能够精细地控制脚本运行，能够通过启动、暂停、停止、重启等操作控制脚本的运行。各个仿真器周期性的向测试引擎发送自身运行状态信息，以便测试引擎监控系统状态。测试引擎会按照测试脚本命令的运行顺序分析并记录测试结果和仿真器状态信息，生成最初的测试报告，如图2 所示。

图2 测试引擎运行流程Fig.2 Test engine running process

2.2 测试平台的实现与环境搭建

2.2.1 仿真器的实现

对于所有的仿真软件和测试引擎，使用C#语言在Windows 系统上进行开发，开发工具为Visual Studio。数据库系统使用的是SQL Server。系统的配置文件使用后缀名为.ini 的文件进行保存，并使用kernel32.dll 提供接口函数读取配置文件。

采用模块化的设计进行仿真器的开发，分别根据功能设计如通信模块、TSR 处理模块、数据库访问模块，日志记录模块等模块，以期望减少重复开发，提高测试平台灵活性。这些模块以封装的类或者编译后的动态链接库表示。

不同的仿真器会根据自身的功能需求组合不同的模块，例如RBC、TCC 仿真器需要所有的模块才能正常的工作，而CTC 仿真器则不需要TSR 处理模块。所有模块间关系如图3 所示。

图3 模块化设计Fig.3 Modular design

在真实的线路现场中，TCC 设备多位于封闭式网络中，而其他设备可能位于开放式的网络中。封闭式网络存在的安全威胁多为数据帧的传输错误问题，而开放式的网络还需面对非法入侵的问题，所以针对这两种网络，中国铁路总公司制定两种铁路信号安全协议(Railway Signal Safety Protocal，RSSP)：RSSP-I、RSSP-II。针对两种通信协议分别开发了对应通信模块，并应用于对应的仿真器中。RSSP-I 基于UDP 通信，RSSP-II 基于TCP 通信，所以利用.NET 平台中System.Net.Sockets 命名空间中的UdpClient、TcpClient 开发对应的通信模块。TSR 处理模块是TCC、RBC 仿真器中用于处理TSR 命令的组成模块。由于TCC、RBC 处理TSR 命令的机制如报文封装、TSR 验证执行命令处理、刷新请求命令处理、初始化命令处理等有许多相似之处，所以把这些相似之处进行封装，形成一个通用的模块。对于数据库访问模块，使用.NET平台的Entity Framework6 框架结合语言集成技术(LinQ)实现对数据库的访问。Entity Framework6是微软开发的一种对象关系映射(ORM)框架，能够使开发人员不通过sql 访问数据库，提高编程的效率，增加系统稳定性。日志记录模块提供日志记录功能，能够接受仿真器主体提供的日志数据，并进行格式化处理后保存到后缀名为.log 的文件中。利用System.IO 命名空间中Directory 类创建日志目录，利用File 类创建日志文件，并写入数据。

2.2.2 仿真测试平台搭建

在真实现场中各个子系统之间的通信是通过安全以太网进行，安全以太网通常包含两个互为冗余备份的网络，分别称为A 网和B 网。在系统运行时其中一个网络被设置为主网，另一个网被设置为备网，全部的数据通信都在主网完成，备网只发送心跳信息以确认连接正常。当主网出现故障无法通信的时候，系统会自动切换网络，保证通信连接的安全。使用两台交换机构造两个小型的局域网模拟安全以太网，同时另使用一台交换机构建一个测试网用于仿真器、测试引擎以及数据库之间的通信。所有的仿真器和测试引擎都运行在windows 系统的PC 总线工控机上，通过RJ45 接口网线连接到对应的交换机上。PC 总线工控机具有普通PC 计算机的功能，但不同于普通PC 的是工控机具有高稳定性、高可靠性、丰富的I/O 接口等特点，将其应用在测试平台上，满足平台对I/O 接口需求，并保障了系统运行稳定性和测试数据安全性。测试平台的搭建如图4 所示。

3 平台仿真测试

图4 测试平台搭建Fig.4 Test platform construction

《客运专线列控系统临时限速技术规范》(简称TSRS 技术规范)是TSRS 服务器以及相关的限速设备在设计生产测试时要严格遵守的技术规范，所以测试平台的主要工作就是测试TSRS 服务器的功能、安全性是否全部满足TSRS 技术规范的要求。测试大纲、测试平台全都围绕着这些规范的要求而设计。结合测试大纲地编写过程、测试平台搭建过程，归纳出整个测试流程，如图5 所示。

测试平台正常运行的一个前提是需要合适的线路数据，所以在测试开始前需要设计测试线路数据。设计线路数据需要兼顾临时限速的各种场景，以便全面地测试TSRS 服务器的功能。整个测试线路以被测TSRS 服务器的管辖区域为主，包含多个TCC区域和RBC 区域，同时也包含与相邻的TSRS 的重叠区域以及与既有线交界区域。

测试大纲依据TSRS 技术规范和线路数据进行测试案例的编写。TSRS 技术规范中对TSRS 服务器、CTC、TCC、RBC、各系统间接口、网络搭建、跨界临时限速、边界临时限速等都提出了具体的要求。根据规范中每条要求编写对应的测试条例，并结合设计的测试线路，设计出具体的测试案例。测试脚本依据大纲中测试案例信息进行编写。

按照测试大纲中的要求，并按照测试线路数据中设备分布需求仿真搭建测试平台。在系统初始化完成、通信建立后，测试引擎运行测试脚本进行自动化测试。在自动化测试完成后，测试者需要检查是否因系统异常而无法测试的案例。对于出现异常的条例，可以与其它一些无法进行自动测试的案例一起进行手动测试。对于所有的测试结果进行汇总分析校验后，编写出正式的测试报告。

图5 测试流程Fig.5 Test process

4 结束语

本文对列控系统的TSRS 服务器的测试平台进行研究与实现。主要关注与TSRS 服务器的协作系统以及运行环境，并忽略一些与临时限速无关的功能和设备，设计并实现了TCC、RBC、CTC、相邻TSRS 仿真器。同时为了管理上的便利和测试的效率，设计测试引擎进行综合管理和自动化测试。测试平台依据TSRS 技术规范设计与搭建，能够全面的测试TSRS 的功能与安全性，为TSRS 系统测试提供了便利、全面、高效、低成本的测试能力。