城市轨道交通TACS 系统测试探讨

欧阳玲萍 熊坤鹏 朱程辉 夏芸

（卡斯柯信号有限公司 上海市 200072）

2019 年，发改委将基于车-车通信的列车自主运行系统（Train Autonomous Control System, TACS）投入《产业结构调整指导目录》鼓励类清单，2020 年，中国城市轨道交通协会发布《中国城市轨道交通智慧城轨发展纲要》并将青岛6 号线列车自主运行系统作为示范工程，为车-车通信技术在列车全自动运行系统中的发展和应用提供了政策指导。

基于车-车通信的TACS 系统代表了当今铁路信号的发展趋势，其遵循故障导向安全的设计原理，系统安全相关功能必须具备SIL4 安全完整性等级。因此在系统全生命周期中，需要进行软件单元、软件集成、软件确认、子系统集成、子系统确认、系统集成、系统确认测试 等多层级全面完整严格的测试及验证工作。

1 TACS系统介绍

1.1 系统原理

TACS 系统和传统的CBTC 系统一样，都是以移动闭塞的方式运行，移动闭塞是基于控制列车在线路上的安全间隔。但两者的区别在于：

CBTC 信号系统是以轨旁设备为中心的列车控制系统，轨旁资源管理和间隔防护是以地面轨旁设备为核心的，系统关键数据流汇集到轨旁的区域控制器（ZC），区域控制器（ZC）根据从计算机联锁（CI）获取当前线路上信号机、道岔 等轨旁资源情况并结合从所有通信车的车载控制器（CC）获取每辆车的实时位置信息，从而实时为每辆通信车计算移动授权，并将移动授权发给各辆车，每辆车的车载控制器（CC）根据从区域控制器（ZC）收到的移动授权信息来计算列车安全运行曲线，从而控制列车的安全运行。

而TACS 信号系统是以车载设备为中心的列车控制系统，由车载控制器（CC）根据从列车自动监控系统（ATS）收到的运行任务计划进行路线规划，根据列车当前实际位置，自主计算对轨旁资源的需求，并择机向轨旁资源管理器（WRC）申请轨旁资源，轨旁资源管理器（WRC）对轨旁资源进行分配后并告知车载控制器（CC），车载控制器（CC）自主计算移动授权。同时车载控制器（CC）与相邻列车直接进行通信，获取相邻列车的实时位置信息，并根据交互信息自主更新移动授权和列车安全运行曲线，从而控制列车的安全运行，实现主动间隔防护。

CBTC 信号系统中资源的管理和实际使用并不是同一个设备，车载设备和轨旁设备之间交互的信息量非常大，且交互信息链路复杂，影响信息传递的效率。而与传统的CBTC 系统相比，TACS 系统中车载控制器（CC）能自主管理资源，自主与相邻车辆进行直接通信，自主计算移动授权，资源的管理和实际使用都是车载控制器（CC），故相比传统的CBTC 系统，TACS 系统具有更简单、更高效、更灵活的特点。

1.2 系统结构

典型的基于车-车通信的列车自主控制系统（TACS）信号系统主要由车载控制器（CC）、轨旁资源管理器（WRC）、轨旁列车控制器（WTC）、目标控制器（OC）、列车自动监控系统（ATS）、数据传输系统（DCS）以及智能运维系统（IOM）子系统组成，并根据项目需求配置用于后备列车定位的BLS（Backup Location System）子系统。

典型的TACS 系统结构图如图1 所示。

图1：TACS 系统架构

1.3 系统功能

各子系统主要功能如下：

车载控制器（CC）主要负责根据计划进行线路资源申请及释放，自主计算移动授权并进行列车自动控制；

轨旁资源管理器（WRC）主要负责线路资源分配和回收；

轨旁列车控制器（WTC）主要负责管理及跟踪故障列车，接管故障列车进行资源申请及释放，并与相邻列车进行信息交互；

目标控制器（OC）主要负责实现轨旁基础设备的状态采集及驱动；

列车自动监控系统（ATS）主要负责监督和控制列车的运营；

数据传输系统（DCS）主要负责各子系统提供透明传输通道；

智能运维系统（IOM）主要负责设备运行状态及故障信息监视，并进行智能分析，提供故障处理建议。

2 测试准备

2.1 组建测试团队

在启动测试之前，组建一支优秀的测试团队是非常重要的。需要包含白盒、黑盒以及系统级测试人员，从而满足软件单元、软件集成、软件确认、子系统集成、子系统确认、系统集成、系统确认测试各阶段的测试需要。

测试人员在上岗前，需经过培训并必须上岗考核合格，证明测试人员具有相应的资质及能力才能正式从事相关测试工作，这也是安全认证中人员考核的内容之一。

2.2 搭建测试平台

信号系统最好的测试环境是理想的现场环境，但现实中现场测试存在各种各样的难点：

（1）现场测试人工、费用成本很高，耗时长；

（2）现场都是真实的设备，不支持故障模拟，不便于开展一些异常测试，有些测试场景在现场环境下无法开展；

（3）现场测试无法预料的因素很多，容易发生事故，存在安全隐患；所以需要采用真实和仿真相结合的测试环境下进行测试，被测对象务必是真实设备，非被测的辅助设备可以通过模拟仿真的方式实现相应的功能，将真实设备接入仿真系统，通过数据协议的解析和转换，实现半实物半仿真的测试环境。这样的测试环境能支持完整的系统测试要求，同时测试环境要具备易操作性、可执行性 等特点。详细的测试平台架构如图2 所示。

图2：TACS 系统测试平台架构图

3 TACS系统测试

当各子系统均已完成一系列的软件单元测试、软件集成测试、软件确认测试、子系统集成测试及子系统确认测试，证明各子系统符合各自子系统需求和接口规格说明书的要求后，需要将各子系统组合在一起做系统级测试，包括系统集成测试和系统确认测试。用于验证各子系统之间（车、地、中心等）的一致性、各子系统接口之间的配合及系统各项功能是否达到设计要求。

3.1 系统集成测试

系统集成测试的重点在于测试各子系统之间的接口是否满足接口定义文件所规定的协议和消息传递的要求，以及集成后的系统功能的正确性。

当执行某两个子系统之间的集成测试时，被测的这两个子系统必须是真实子系统，其他用于支撑整个信号系统正常工作的子系统可以是真实子系统也可以是仿真模拟的子系统。

图3 给出了TACS 信号系统内部子系统的逻辑接口关系。

图3：TACS 系统接口

TACS 系统接口测试需要覆盖各子系统之间的接口，包括以下内部接口测试，见表1。

表1：系统集成测试范围

3.2 系统确认测试

系统确认测试的重点在于将所有子系统集成在一起后的系统功能是否符合系统需求规格说明书的要求。

常见的测试场景有：驾驶室激活和门控管理。

3.2.1 驾驶室激活

驾驶室激活的判断，涉及CC 跟车辆之间的继电器接口，详见表2。

表2：驾驶室激活相关继电器定义及说明

驾驶室激活状态（COR）主要用来表示列车哪端车头由司机在驾驶室激活钥匙（KSON），或者DTO 模式下由CC 输出驾驶室激活命令(CSR)来决定。详细的测试项见表3。

表3：驾驶室激活测试项

3.2.2 门控管理

在本项目中，门模式的选择是通过一个旋钮实现的，有3 个挡位，分别是全自动、半自动和手动档。涉及CC 跟车辆之间的继电器接口，详见表4。

表4：门控管理相关继电器定义

如表5 所示，开关门的管理方式有3 种方式：全自动（自动开自动关）、半自动（自动开手动关）、手动（手动开手动关）。对于手动开自动关这种非法方式司机是无法选择上的，但也存在，比如司机选择自动开自动关的方式，但DM11 和DM12 线路故障，CC 只能从继电器采集到手动开门的信号，从而出现了非法的门控状态，这种非法的门控状态系统需要检测到后需要提供相应的报警。

表5：门控管理说明

在本项目中：

（1）DTO/AM 驾驶模式下，支持全自动、半自动、手动开关门方式；

（2）CM 驾驶模式下，不管DM 输入选择什么方式，最终仅支持手动开关门方式；

（3）RMF/RMR/ATC BYPASS 驾驶模式下，仅支持手动开关门方式，并且由司机负责而不是CC。

详细的测试项见表6。

表6：开关门管理测试项

4 结语

本文介绍了TACS 系统原理、结构以及功能，并从测试角度如何进行测试准备，针对系统级测试范围进行介绍，最后针对2 个常见的测试场景进行详细的分析，设计完整的测试项以实现对该场景详细的功能测试。

鉴于笔者对系统的了解程度及水平有限，疏漏难免，愿与大家共同探讨。