3. 问题复现工程核心概念
在 Bosch ADAS 数据闭环体系中，路测发现问题只是起点，真正决定工程效率的是“问题能否被稳定复现、能否被准确定位、修复后能否被证明有效”。这四个动作——问题定义、复现等级、根因分析、闭环验证——构成了问题复现工程的主干。它们不是四个独立环节，而是一条从“现象”到“证据”再到“结论”的收敛链：定义决定复现目标，复现等级决定投入强度，根因分析决定修复方向，闭环验证决定问题是否真正关闭。
问题定义：把“感觉不对”变成可判定的命题
路测中常见的原始描述是“AEB 在某个路口误触发”“LKA 在弯道画龙”“ACC 跟车距离忽远忽近”。这类描述无法直接进入复现流程，因为它缺少判定条件。问题定义的任务，是把模糊现象转成一条可判定的命题，至少包含五个要素：触发场景、期望行为、实际行为、判定依据、影响等级。
以“AEB 误触发”为例，可定义为：在城区直道、前方无有效目标、自车车速 30 km/h 的条件下，AEB 在 t=12.4 s 输出减速度请求 a_req ≥ 3 m/s²，而感知层未输出任何置信度 ≥ 0.5 的障碍物目标，判定为误触发，影响等级 S2（非安全关键但影响舒适性与信任度）。这里“30 km/h”“a_req ≥ 3 m/s²”“置信度 ≥ 0.5”都是可回放、可计算的量，而不是主观感受。
问题定义还要明确参照系与坐标约定。ADAS 中常用 ISO 8855 车辆坐标系：x 轴指向车辆前方，y 轴指向左侧，z 轴向上；横摆角速度以逆时针为正。若问题涉及横向控制，必须说明使用的是车辆坐标系还是图像坐标系，否则“向左偏”在不同模块中含义不同，复现时会产生歧义。
复现等级：用分级控制复现成本
并非所有问题都值得投入完整的数据回灌与实车复现。Bosch 工程实践中通常按复现等级划分投入：
- L0 不可复现：仅有一次路测记录，无同步数据，无法回放。此时只能归档并等待同类问题再次出现。
- L1 数据回放复现：用路测录制的传感器数据（摄像头、雷达、CAN、IMU）在离线回灌平台上重放，能重现问题现象。这是最经济的复现方式。
- L2 场景仿真复现：在仿真环境中重建场景（如 CarMaker、IPG、自研场景工具），可参数化调整目标距离、速度、光照，用于验证边界条件。
- L3 实车复现：在封闭场地或指定路段用实车按定义条件重跑，用于确认仿真与回灌无法覆盖的实车效应（如执行器延迟、标定偏差）。
分级的意义在于：L1 能复现的问题不应直接跳到 L3；L1 无法复现但 L2 可复现的问题，说明问题与感知输入的具体数值强相关，而非实车动力学。复现等级的选择本身就是一个工程判断，需要在问题定义中写明“目标复现等级”和“已达成等级”。
根因分析：沿信号链逐层收敛
根因分析不是“猜哪个模块有问题”，而是沿 ADAS 信号链从现象反向追踪到最小可归因单元。典型信号链为：传感器原始数据 → 感知（检测/跟踪/融合）→ 预测 → 规划 → 控制 → 执行器 → 车辆运动。每一层都有可观测的中间量，根因分析就是找到“第一个出现异常偏差的层”。
以 AEB 误触发为例，回放数据后可按以下顺序检查：
- 感知层：在 t=12.4 s 前后，摄像头是否输出了虚假目标？检查目标置信度、目标距离、目标速度的时间序列。
- 融合层：雷达与摄像头是否产生了不一致的关联？检查融合后的目标列表与各传感器原始目标列表的差异。
- 决策层：AEB 触发逻辑的输入条件是否被满足？检查 TTC 计算值、目标类型过滤、驾驶员操作状态。
- 执行层：a_req 是否被正确下发？检查 CAN 报文与执行器响应。
若发现摄像头在 t=12.3 s 输出一个距离 18 m、置信度 0.62 的虚假目标，而雷达无对应目标，则根因可定位为“摄像头感知在特定光照/纹理条件下产生虚假检测，且融合层未有效抑制单传感器虚假目标”。此时根因不是“AEB 太敏感”，而是感知与融合的联合缺陷。
闭环验证：用同一判定条件证明问题关闭
修复完成后，闭环验证必须回到问题定义中的判定条件，而不是“感觉好了”。验证至少包含三部分：原场景复现验证、边界场景回归、无回归确认。
原场景复现验证：用同一段回灌数据重跑，确认 a_req 不再满足误触发条件，且感知层不再输出该虚假目标。边界场景回归：在仿真中扫描光照、目标距离、车道线曲率等参数，确认修复未引入新的漏检或延迟。无回归确认：在标准回归集（如 AEB 法规场景、LKA 标准弯道）上跑通，确认其他功能未受影响。
闭环验证的结论应写成可追溯的记录：问题编号、复现等级、根因层级、修复版本、验证数据包、判定结果。只有判定结果与问题定义中的判定依据一致，问题才允许关闭。
端到端流程与角色分工
从路测问题到数据闭环，完整链路涉及多个角色。路测工程师负责记录现象并触发问题单；数据工程师负责数据回传、时间对齐与回灌平台准备；感知/融合/规划控制算法工程师负责根因分析与修复；测试工程师负责复现等级判定与闭环验证；系统工程师负责判定条件与影响等级的一致性。各角色之间的交接物不是口头描述，而是问题单、数据包、回放配置、验证报告。
这张图把四个核心概念与信号链、角色分工放在同一张视图中：上半部分是问题定义、复现等级、根因分析、闭环验证的推进关系；中间是根因分析所依赖的 ADAS 信号链，虚线表示从异常现象反向追踪；下半部分是各角色的交接物。实际工程中，问题单在角色之间流转时，最容易丢失的是“判定依据”和“时间对齐信息”，因此这两项应作为问题单的必填字段。
把四个概念串起来看，问题复现工程的本质是用可判定的证据替代主观判断。问题定义给出判定条件，复现等级给出证据强度，根因分析给出证据链，闭环验证给出关闭依据。四者缺一，问题就会在“已修复”和“又出现”之间反复摇摆，数据闭环也就无法真正收敛。