基于通信的列车控制系统（CBTC）测试方法研究与设计

孙晓光 侯 磊（北京全路通信信号研究设计院有限公司，北京 100073）

孙晓光，男，硕士毕业于清华大学，助理工程师。主要研究方向包括软件开发、系统测试，曾参与CBTC项目。

随着城市轨道交通的飞速发展，基于通信的列车控制系统（CBTC）由于其安全高效和易于维护，已经成为现今城轨交通领域占主导地位的城轨列车控制系统。CBTC系统融合先进的通信技术、列控技术、计算机技术，进行行车控制、指挥和管理，基于高精度高冗余的车地双向通信实现移动闭塞的列控机制。CBTC列控系统遵循故障导向安全的设计理念，系统安全相关功能须具备SIL4安全完整性等级，因此在系统全生命周期，需进行包括软件单元测试、子系统测试、系统集成测试、工程测试等多层级全面严格的验证测试工作，其中，系统集成测试是系统验证的最直接有效手段，系统集成测试质量决定了系统的研发效果，进而影响工程产品的质量安全水平。

本文重点研究CBTC系统仿真测试的特点，分析仿真测试环境的针对性需求和方案特色，提出CBTC系统集成测试理论体系。结合实际CBTC测试项目，具体介绍测试案例的设计策略。

1 CBTC系统简介

CBTC系统利用无线设备进行双向车地通信，实现列车的移动闭塞控制，具有追踪间隔小、列车控制精确、安全性高、易维护等特点。CBTC系统主要由列车自动防护系统（ATP）、区域控制器（ZC）、计算机联锁（CBI）、列车自动运行系统（ATO）、列车自动监控系统（ATS）、数据通信网络组成，其典型系统结构如图1所示。

ATP、ZC、CBI主要用于列车运行安全防护，防护与撞车、侧冲、超速及其他危险源相关的安全事件。ATO在ATP的防护之下，提供自动控车功能。ATS主要用于列车运营调度，并提供系统状态信息，监控各子系统功能。数据通信网络用于设备间双向通信。

2 CBTC系统测试环境

CBTC系统最好的测试验证环境是理想化的现场环境，但是现实中现场测试存在如下问题：1）现场测试人工、费用成本很高，且时间周期长；2）现场测试不可知因素较多，容易出现事故；3）现场测试不利于监测设备间通信数据和故障模拟；4）现场往往不具备系统功能全面测试所需的所有场景。因此采用实物与仿真相结合的半实物测试环境尤为重要。通过仿真与实物相结合的方式，既在一定程度上模拟了实际场景，又兼顾了系统测试的可行性、全面性。

CBTC系统测试环境主要由半实物仿真测试运行系统、综合监控系统、综合测评系统3部分组成。CBTC系统测试环境总体结构如图2所示。

半实物仿真测试运行系统，通过实物接口平台将实物设备接入仿真系统，通过数据协议的解析和转换，实现模型和实物系统的无差异接入，以及虚实互换和虚实互控功能。

综合监控系统，利用半实物仿真运行系统提供的监控接口实现对系统运行设备及接口的状态和数据监测，以及操作控制命令的下达。

综合测评系统，是面向集成测试和故障诊断等实际应用的系统，实时动态显示实物设备与实物设备、实物设备与仿真系统的连接情况。

结合CBTC系统车地双向通信量大、移动闭塞、追踪间隔小、列车控制精确、实时性要求高的特点，CBTC系统测试环境添加较多的数据监测机制和故障注入方式。

数据监测主要包括ATP与ZC通信监测、ZC与CBI通信监测、ZC维护监测、ATP维护监测、ATO维护监测，无线通信监测、安全通信维护监测。数据监测为CBTC系统测试提供了除实物设备动作以外的观测点。通过数据监测，可以直观的观测实物设备间的交互数据。

1）ATP与ZC通信监测用于观察记录ATP与ZC之间的通信数据，如ZC向ATP发送的移动授权数据、列车回库注销时ATP与ZC的交互数据。

2）ZC与CBI通信监测用于观察记录ZC与CBI之间的通信数据，如CBI向ZC发送的计轴区段状态、ZC向CBI发送的逻辑区段状态。

3）ZC维护监测用于观察记录ZC设备接收发送的所有信息，可通过回放的方式重现测试场景。

4）ATP维护监测、ATO维护监测用于观察记录ATP、ATO动作信息及接收发送的数据。

5）安全通信维护监测用于观察记录ZC与ATP通信中安全层的连接信息，如列车通信中断后重新连接ZC时安全连接建立情况。

6）无线通信监测用于观察记录无线通信情况，如无线信号强度。

为了便于系统故障模拟，营造故障场景测试条件，CBTC系统仿真测试环境集成了多种故障注入机制。故障注入主要包括故障数据注入、通信故障注入和接口不稳定性故障注入。

1）故障数据注入主要体现在模型的数据输入不符合设备预期，数据的完整性和准确性出现异常，如应答器数据错误。

2）通信故障注入主要体现在各设备模型之间通信连接和通信传输的故障，如车-地无线通信故障、设备接口故障等。

3）接口不稳定性故障注入主要体现在设备模型间通信的接口的不稳定给模型功能执行的故障，如ATP速度传感器断线等。

故障注入主要通过仿真平台、无线加扰、设备实物连接等方式实现。仿真平台，可以模拟部分在现场试验中无法进行的故障场景，提高系统测试的全面性和可靠性，如列车溜逸、计轴设备故障等。无线加扰可以在实验室模拟真实线路无线信号强弱变化的特点，根据实际测量的线路信号强弱变化，对无线信号进行了加扰，模拟真实线路的实际无线情况。设备实物连接可以在实验室模拟实物设备故障、设备间通信中断等场景，如CBI设备故障、ZC与CBI通信中断、ATP速度传感器断线等。

3 CBTC系统测试理论体系

测试案例生成是系统测试的关键问题，本章主要研究了适用于CBTC系统测试的测试案例生成方法，并且给出了应用此方法生成测试案例的实例。

在进行系统测试案例编写之前，首先需要分析系统需求规范中需求条目的可测性，结合室内仿真测试条件，确认可以通过系统仿真测试进行验证的系统需求子集，作为后续工作的输入。

然后，根据CBTC系统需求规范划分功能实体，提取具体的功能特征点，针对各功能特征点结合CBTC系统测试特点进行细化生成案例描述，进而生成每个功能特征点对应的测试案例。

最后，结合线路数据串联测试序列，作为系统集成测试执行的依据。

在功能点、测试案例、测试序列的编写过程中，需进行多级文档之间的追溯工作，维护多级工作对系统需求规范的追溯，以及彼此的追溯关系，保证所有具备可测性的需求条目真正被测试案例和测试序列覆盖，并在后续的测试执行中被验证。

各模块间追溯关系如图3所示。

功能特征列表需建立每个功能特征点对需求条目的链接追溯关系。每个功能特征中包含的需求条目是其包含的测试案例追溯需求条目的集合，即每个功能特征追溯的需求条目必然被其包含的一个或多个测试案例追溯。

交叉引用表统计需求条目和功能特征列表之间的交叉引用关系（通过功能特征列表到需求条目的链接关系得到），用于证明功能特征列表对可测需求子集的完全覆盖。

测试案例需建立其对系统需求条目的链接追溯关系，以及与功能特征列表的追溯归属关系。

测试序列需建立其对测试案例的链接追溯关系，保证每个测试案例至少被一个测试序列覆盖，如出现部分测试案例无法被追溯的情况，必须清楚说明该情况，如由于线路数据限制，部分案例可能暂不能进行测试。

3.1 功能特征点

CBTC系统测试立足于系统需求规范，由于需求数量众多，且部分需求条目较为细致，针对具体功能的描述存在重叠和重复的现象。若针对每条系统需求编写测试案例，测试案例数量较为庞大，且存在重复工作的可能。另外，部分需求较为概括，需要划分至具体的功能进行测试。为了解决上述问题，通过功能特征点归纳系统功能，对已筛选确定可测的需求条目进行重新划分，保证每一条需求至少在一个功能特征点中得到反映。每个功能特征点是一组需求的集合，追溯一条或者多条系统需求条目。

在功能特征点提取过程中，根据CBTC系统结构划分功能实体，分割各子系统的功能点，逐步细化，形成相对独立、基础的功能特征点。CBTC系统测试功能点按照子系统进行归纳，分为车载ATP子系统、ZC子系统、CBI子系统、ATS子系统、ATO子系统，然后根据系统需求逐步细分。

在功能特征点的归纳总结中，还需注意以下几个地方：1）需为每条功能点均分配一个唯一的功能点编号，方便后续对功能点的追溯统计；2）需明确每条功能点适用的车载设备运行等级和模式；3）需建立对系统需求条目的追溯。

CBTC系统测试功能点的列表格式如表1所示。

表1 CBTC系统测试功能点示例

3.2 测试案例

测试案例根据功能特征点进行编写。通过分析功能特征点的可能场景，将功能特征点拆分为若干分支流程，然后通过用例图、状态图等辅助措施，从不同角度描述功能特征点对应功能的整个过程，最终结合CBTC系统测试中用于验证和观测的可见接口，如ZC-ATP通信等监测数据、CBI控显、ATS控显等，形成案例描述。案例描述是对测试案例中测试内容的概括，通过对案例描述进行扩展，可以生成测试案例。生成测试案例的详细步骤如下：

步骤1：根据功能特征点，分析可能的场景，形成用例图等；

步骤2：根据可能场景，确定相关设备；

步骤3：根据相关设备，确定可测性及观测接口；

步骤4：根据可能场景和可测性，形成案例描述；

步骤5：根据案例描述，确定测试案例的详细步骤、观测接口、预期结果等。

选取ATP的功能点“ATP接收移动授权”为例，分析ATP接收移动授权的可能场景，可确定该功能点主要与ZC设备有交互。通过ATP与ZC的接口监测数据可以观测ATP接收移动授权的情况，形成案例描述，部分案例描述如表2所示。

表2 CBTC系统案例描述示例

最后，根据活动图将案例描述的场景进行细化，按照测试案例模板形成测试案例。测试案例主要包括以下内容：

1）被测对象：本案例测试目的涉及的对象设备（车载或地面子系统）。

2）所属的功能特征：每一个测试案例都是针对某一个功能特征设计出来的，用于测试其所属的功能特征。

3）测试的系统需求：每一个测试案例都测试了系统需求规范中的某条需求，必须标明。4）测试方法：包括测试步骤、如何检验测试结果。5）易于理解的测试环境：测试包括测试所处的模式等级，各接口的状态条件。

6）测试执行的结束标准：测试案例执行结束时所处的状态，产生的影响。

3.3 测试序列

CBTC系统主要包括车载ATP子系统、ATO子系统、ZC子系统、CBI子系统和ATS子系统。测试序列的组织采用先焦点后全面的顺序进行。首先依次以车载ATP子系统和ATO子系统为焦点，组织测试序列，并对测试案例进行追踪统计，此过程将覆盖所有车载ATP子系统和ATO子系统相关测试案例集，以及大部分ZC、CBI、ATS子系统相关测试案例；接下来，依次针对ZC、CBI、ATS子系统未被覆盖的测试案例，组织测试序列，对测试案例进行链接统计，保证测试序列全面覆盖测试案例集。

车载ATP子系统和ATO子系统可采用内部状态串联方法，组织测试序列。内部状态串联方法的要点在于定义子系统内部状态集，内部状态集覆盖所有可能的等级/模式组合。两个内部状态之间的转移称为一个状态转移路线。一旦定义好状态转移路线后，通过将模式与（或）等级状态转移路线中指定的或者相关的测试案例进行串接，从而形成状态转移路线中的测试子序列集。

对测试案例进行串接时，需同时参照测试案例起始和结束的外部接口状态和其他子系统状态描述，防止出现CBTC系统设计无法实现的状态转移。

内部状态串联方法的序列串接过程，需确保所有测试子序列被至少使用一次并且使测试子序列的使用数量达到最少。

完成车载ATP或ATO子系统序列串联之后，需使用ZC、CBI、ATS子系统等相关子系统的测试案例，对序列测试案例中子系统相关接口测试步骤进行替代，并追踪链接对应测试案例和需求。

针对ZC、CBI、ATS子系统未被覆盖的测试案例，采用枚举方式，串联测试案例，组织测试序列，保证对测试案例和需求集的完全覆盖追踪。

此外，串联测试序列时需考虑线路数据的实际情况，分析确定线路中的特殊位置，如建立定位点、完成头筛点、列车升级点、站台区段、折返区段等。

4 结束语

CBTC系统测试对系统的安全运行提供必要的保证。在CBTC系统开发与研制项目中，基于CBTC系统仿真环境和相关测试案例、测试序列，可行性得到验证，测试效果显著。

[1] A.Gohler, Eh.Frerichs,E.Fernandez,et al.ERTMS/ETCS SUBSET-076-0 2.2.3, ERTMS/ETCS Class 1 Test Plan[S].2005.

[2] Meyer zu Hoerste,Stefanie schwartz,Jorge lglesias,et al.ERTMS/ETCS SUBSET-076-4-1 1.0.0, ERTMS/ETCS Class 1 Test Sequences Generation：Methodology and Rules[S].2003.