1. 列控联调联试问题分类与定位流程建立
为什么先建流程，而不是先查设备
联调联试现场最常见的低效不是"查不出问题"，而是"查错了对象"。同一现象可能来自车载、地面应答器、RBC、联锁、通信网络或测试操作本身。若没有统一的分类与定位流程，各专业会各自采集、各自判断，导致重复上车、重复抓包、结论互相矛盾。本案例的任务是建立一条可复用的定位主线：现象记录 → 分类归口 → 数据采集 → 根因判定 → 闭环归档，并明确每一步的输入、输出与责任边界。
问题分类：先按"失效表现"归口，再按"责任域"分流
分类的目的不是贴标签，而是决定"下一步该采什么数据、找谁确认"。建议采用两级分类：第一级看失效表现（停车、降级、接口中断、超时、显示异常、测试操作异常），第二级看责任域（车载ATP、地面应答器/LEU、RBC、联锁/CBI、通信网络、测试组织）。两级交叉后，采集对象和责任人就基本确定了。
| 失效表现 | 典型责任域 | 首要采集对象 | 责任边界提示 |
|---|---|---|---|
| 区间停车/紧急制动 | 车载ATP、应答器 | ATP车载日志、应答器报文、BTM接收记录 | 车载负责解析与制动逻辑，地面负责报文与链接关系 |
| 模式降级（如部分监控转目视） | 车载ATP、RBC | 车载日志、RBC移交/注册记录 | 移交边界由RBC与车载共同确认 |
| 接口通信中断/超时 | RBC、联锁、网络 | 接口日志、抓包、安全连接状态 | 网络层与安全层分开判定 |
| 进路/信号显示不一致 | 联锁、RBC | 联锁状态记录、RBC进路信息 | 以联锁为进路状态基准 |
| 测试操作引发的异常 | 测试组织 | 测试脚本、操作时序记录 | 先排除操作因素再进入设备排查 |
定位流程与各环节输入输出
流程的关键约束是"上一环节的输出必须是下一环节的输入"，否则定位会断链。现象记录必须带时间戳、车次、位置（公里标/应答器编号）、现象描述和初步截图；分类归口必须给出责任域和采集清单；数据采集必须保证多源数据时间对齐；根因判定必须能回答"证据是否支持该结论"；闭环归档必须留下可复用的判据。
关键环节的实操要点
现象记录要避免"停车了"这类无信息描述。可用的记录格式是：时间 | 车次 | 公里标/应答器编号 | 运行模式 | 现象 | 初步截图。例如"14:32:07 | Gxxxx | K125+300 应答器 0123 后 | 部分监控 | 触发常用制动停车 | 车载DMI截图"。位置信息决定了后续该调哪一段应答器报文和哪一段RBC管辖数据。
分类归口时，先问三个问题：现象是否可复现？是否与特定位置/特定设备相关？是否在测试操作后立即出现？三个问题的答案能快速把问题分流到"设备缺陷""接口配置""测试操作"三类，避免一上来就全员上车。
数据采集的核心是时间对齐。车载日志、RBC日志、联锁记录、抓包的时间基准可能不同，采集时必须记录各设备的时钟偏差，并在分析时统一到同一时间轴。否则"谁先谁后"判断错误，根因就会指向错误设备。
根因判定要求结论可被证据反驳。一个合格的结论应写成"因为A时刻B设备发出了C，而D设备在E时刻未响应，故判定为D侧接口处理异常"，而不是"可能是通信问题"。若证据不足，应回到采集环节补充，而不是勉强下结论。
可直接使用的定位记录单示例
| 字段 | 示例填写 | 填写要求 |
|---|---|---|
| 问题编号 | LT-001 | 全流程唯一，便于追溯 |
| 发现时间/位置 | 14:32:07 / K125+300 | 精确到秒，位置到应答器或公里标 |
| 失效表现 | 常用制动停车 | 用可观察现象描述，不写推测原因 |
| 分类/责任域 | 停车类 / 车载ATP+应答器 | 两级分类，明确牵头专业 |
| 采集清单 | ATP日志、0123应答器报文、BTM记录 | 列明对象、时间窗、采集人 |
| 根因结论 | 应答器链接关系缺失导致制动 | 须有证据支撑，可被复核 |
| 回归结果 | 修正链接后同位置通过 | 记录复测条件与结果 |
这张记录单的价值在于：它把"现象—分类—采集—判定—回归"串成一条可审计的链。后续案例中无论排查应答器报文、RBC接口还是联锁进路，都可以复用同一张单子的字段结构，只是采集对象和判据不同。