2. 基于运营场景库的CBTC安全测试场景选取

场景选取的输入与输出

本案例的任务不是设计新场景，而是从既有运营场景库中“挑出”与CBTC安全功能相关的条目，并让每条被选中的场景都能追溯到具体的安全需求。选取的输入是场景库条目（含运营动作、设备状态、环境条件）与安全需求清单；输出是一张场景—需求追溯矩阵，以及每条场景的选取理由与排除理由。

选取准则的核心是三条硬性判据：安全相关性（场景失效是否可能导致危险侧后果）、CBTC功能覆盖性（场景是否触发ATP/ATO/联锁/车地通信等安全功能）、可追溯性（能否映射到至少一条已定义的安全需求）。三条同时满足才入选；只满足部分则进入“待补充需求”或“非安全场景”分支。

选取准则的落地判定

把三条判据变成可操作的判定，需要为每条判据给出明确的“通过/不通过”证据，而不是凭经验感觉。下表给出本案例使用的判定口径，可直接作为场景筛选的检查依据。

追溯关系的建立方法

追溯矩阵的每一行是一条“场景—需求”映射，建立时按以下顺序操作：

1. 提取场景的安全触发点：从场景库条目中找出会改变列车运行安全状态的动作或条件，例如“扣车解除”“限速命令下发”“道岔请求转换”。
2. 匹配安全功能：判断该触发点由哪个CBTC安全功能负责防护，形成“场景→功能”的中间映射。
3. 落到需求编号：在安全需求清单中查找描述该功能危险侧防护要求的SR条目，确认需求中的防护条件与场景触发点一致后建立映射。
4. 标注选取结论与理由：入选场景写明危险侧后果；待补充场景写明缺失的需求方向；排除场景写明排除依据。

选取结果的自检

完成矩阵后，用以下三个问题自检选取质量：

• 覆盖检查：安全需求清单中每条SR是否至少被一条入选场景覆盖？未覆盖的SR说明场景库存在缺口，需要补充运营场景。
• 冗余检查：是否存在多条场景映射到同一SR且触发点完全相同？若有，保留危险侧后果最直接的一条，其余标注为冗余候选。
• 边界检查：被排除的场景是否确实不涉及任何安全功能？对“疑似安全相关但判据不足”的场景，应记录为待复核，而不是直接排除。