动车段(所)控制集中系统关键接口数据自动测试平台研究

付紫彪

随着越来越多高铁线路的规划建设和投入使用，与之配套的动车段（所）数量也在不断攀升。为提高作业效率、保证作业安全，全路已近40个动车段（所）运用了控制集中系统（Control Centralized System， CCS）。CCS 具备作业计划管理、调度命令管理、动车组位置追踪、作业过程控制等功能，可实现动车段（所）内的调度指挥和行车作业自动化，有效保障了站场内动车组的高效检修、安全运营和合理调度［1-3］。

动车段（所）站场一般规模庞大、信号设备多，仅站场存车线就普遍高达二三十条。为了充分实现CCS 功能，需要配置大量的接口数据，如站场表示信息等。作为CCS 安全可靠运行的保障，其数据测试质量直接影响系统的运行效果及现场作业安全。

当前，CCS 接口数据测试完全依赖于外部厂商提供的仿真环境。在实际测试中，经常遇到仿真环境不能及时搭建、不易维护，以及无法提供部分数据验证等问题，造成数据测试不及时、不全面，并且主要通过人工进行数据校验，容易产生漏测或误测风险。遇到工期紧张时，测试人员压力大，若数据错误又需修改配置重新提交测试，则耗时长，影响工期节点［4］。

因此，本文从实现接口数据自动测试，减少对仿真环境依赖的角度出发，开展CCS 关键接口数据自动测试平台（简称“测试平台”）的研究，分别从测试平台构成、软件设计和平台应用等方面进行重点介绍。

1 平台构成

测试平台由内部CCS 和外部测试系统两部分组成，平台架构见图1。一方面模拟计算机联锁和CTC，通过网线与CCS连接，采用既有通信协议，实现信息自动发送；另一方面模拟CCS 自动发送内部信息。测试平台提供界面显示测试进度和测试结果，通过比对内外部信息数据的一致性，判断CCS接口配置的准确性［5-6］。

图1 测试平台架构

1）CCS 侧采用单机单网的方式，组成一套内部交互的独立局域网，按照与现场相同的应用软件和配置进行部署。除设置一套接口服务器外，还配备其他与接口相关的值班员终端、信号员终端和应用服务器。其中，值班员终端显示采集表示和车次窗信息；信号员终端显示本站联锁码位、采集表示和车次窗信息，并执行控制命令和车次窗相关操作；应用服务器进行车次窗逻辑处理。

2）外部测试系统设置一套接口仿真测试终端，开发关键接口测试软件（简称“测试软件”）。采用与实际相同的网络接口和CCS 实现外部格式信息的交互。此外，增加一路网络接口与CCS 局域网连接（图1 中红线），实现测试平台内部格式信息的交互。外部测试系统获取所有信息和数据，为比对内外部数据信息奠定基础。

在终端上部署测试软件，模拟不同设备厂商、外部系统（“实际系统”）的交互内容、数据格式及交互特点，具备双方规定的传输控制协议（Transmission Control Protocol，TCP）通信要求。根据接口标准规范及CCS 交互协议要求，借助内网实现CCS 的用户数据报协议（User Datagram Protocol， UDP）通信。通过自动加载内外部数据，触发执行接口数据配置测试，即可无需借助外部厂商的仿真环境，达到对CCS 关键接口数据的自动化遍历测试的目的［7-8］。

1.1 交互协议

CCS与CTC接口进行信息交互主要依据《列车调度指挥系统（TDCS）数据通信规程》、各接口厂商的补充协议和规定数据格式等［9］。由于CCS早期与TDCS接口，后续站场虽均升级为CTC设备，但与各厂商的系统交互仍然继续沿用此协议。

CCS 借助CTC 实现与计算机联锁的信息交互，交互协议依据《调度集中车站自律机与计算机联锁接口通信协议（V1.1）》，数据格式遵照不同厂商的具体规定要求［10-11］。

1.2 测试内容

对接发车、调车进路的控制是整个CCS 的关键，有4 类接口信息在其中发挥了重要作用，分别为：与CTC 交互的车次窗、采集表示信息；与计算机联锁交互的站场码位、控制命令信息。为实现这些信息的有效交互，CCS 需要实际系统厂商提供接口数据进行内部编制，具体数据如下。

1）码位数据：本站联锁码位信息中的码序映射数据。

2）按钮数据：控制命令信息中的按钮映射数据。

3）车次窗数据：本站、相邻车站CTC 车次窗信息中，区间和股道的车次窗编码映射数据。

4）表示数据：本站、相邻车站CTC 表示信息中的设备类型及码序映射数据。

在各工程项目中，上述这些数据编制及待测数量高达几千条，工作量极其繁重。

1.3 测试逻辑

CCS 通过搭建局域网的方式实现内部信息互联互通，通过接口服务器与实际系统进行互联。由CCS 接口及其他服务器、终端共同进行内外部协议和数据转换，实现信息隔离。局域网中包含内部交互信息，实际系统包含外部信息及数据内容。

对于从外部测试系统侧主动发送的信息，如本站联锁码位信息等，外部测试系统自动发送外部格式及数据信息，并从局域网中获取经过CCS 转换后的数据，将内外部信息进行比对，判断接口数据配置的准确性；对于在CCS 侧操作发送的信息，如本站车次窗信息等，则由外部测试系统模拟CCS 行为，加载内部车次窗数据后，自动按照内部格式，借助局域网转译后再返回外部测试系统，将收到的内外部信息进行比对判断，反馈具体配置项的测试结果，从而达到自动测试的目的。测试平台测试逻辑见图2。

图2 测试平台测试逻辑

2 测试软件设计

2.1 软件架构

软件架构分为数据访问层、业务逻辑层和界面层3层，见图3。

图3 软件架构示意

1）数据访问层，主要包括磁盘文件读写和通信数据收发，如接口文件读取、日志写入、内外部通信数据的接收和发送等。

2）业务逻辑层，作为测试软件的核心，该层包括计算机联锁业务、CTC 业务、CCS 业务及日志管理等，如模拟联锁、CTC、CCS 行为，通过信息自动发送和比对，实现数据自动测试的要求。

3）界面层，包括操作指令下发，以及通信链接状态、测试实时进度和测试结果的展示等。

2.2 模块划分

按照各层实现的功能不同，测试软件划分为7 个模块。依据实际外部接口情况，各模块能够独立实现特定功能和需求。

1）计算机联锁仿真模块，是实现自动测试计算机联锁相关接口数据的核心。通过加载联锁厂商提供的码位表、按钮表文件等，模拟接口交互要求，自动比对内外部信息。

2）CTC 仿真模块，负责自动测试CTC 相关接口数据。通过加载CTC 厂商提供的设备编码、车次窗等文件，模拟接口交互要求，自动比对内外部信息。

3）人机交互模块实现信息展示和指令下发。

4）CCS 仿真模块是自动测试实际系统接口数据的辅助模块，通过加载内部数据，按照内部协议提供接口有关信息，将CCS 处理转为外部协议后，辅助实现需由内部下发的部分接口数据的自动测试。

5）通信模块提供TCP 和UDP 两种通信方式，满足各类系统通信要求。

6）配置文件管理模块在程序中最先开启运行，是程序全局变量数据的来源。

7）日志管理模块实现测试软件对测试进度和测试结果的记录和运行中日志的管理。

2.3 测试流程

测试平台需要实现2 个方向的数据流接口信息自动测试：①外部测试系统侧发送的信息流，如联锁码位、站透采集表示和车次窗信息等；②CCS 侧发送的信息流，如本站的车次窗和控制命令信息。每个数据流的自动测试过程基本一致，下面以码位数据测试为例介绍测试流程，见图4。

图4 码位数据自动测试流程

根据联锁厂家提供的码位表内容，每次更改一个码位值，按照联锁协议组成一包完整的站场表示信息；调用通信模块依次发给CCS，监测2 s 内（参数可配置）是否能收到CCS 码位信息，且对应的设备内外部码位值是否一致。在界面上显示每个码位数据的测试结果，并记录日志。如此循环，直至所有码位数据测试完毕。

3 测试平台应用

测试软件采用C#编译环境作为开发平台，基于.Net2.0，采用面向对象分析方法和模块化程序设计相结合的方式进行软件开发。将测试软件部署在接口仿真测试终端上，软件界面见图5。以列表的形式展示被测数据和测试结果，并进行日志记录，将测试未通过的配置项清晰地记录在问题反馈列表中，方便人工查看及后续的数据复核。

图5 测试软件界面

目前，测试平台采用已开通的动车段（所）接口数据进行了测试验证。以当前正在工程化实施过程中的某动车所为实例，基于以往人工测试经验，需要2 名人员花费2~3 个工作日（8 h/工作日）才能完成关键接口数据的测试工作，采用测试平台后可在任意时间进行测试，测试完毕后由1 名人员用1 个工作日左右完成数据的复核和复测，整体测试效率提升3~5倍。同时，帮助测试人员发现了2处人工数据配置错误和漏配问题，测试效率明显提升，试用效果良好。

4 结束语

通过研发CCS 系统关键接口数据自动测试平台，实现机器代替人工完成大量机械性、重复性的数据遍历测试目标，辅以人工校核测试结果，可为测试人员找出接口配置问题，快速定位错误配置项，有效减少因接口数据问题造成一系列不必要的重复流程；减轻测试人员的工作压力，减少人为原因的疏漏，压缩了CCS 软件出厂时间，保证关键接口数据的准确性，显著加快工程实施进度，实现降本增效［12］。