TRACE：面向自动驾驶评测的拓扑感知事故重建

论文：Nahian Salsabil, Sebastian Elbaum, TRACE: Topology-aware Reconstruction of Accidents in CARLA for AV Evaluation 论文链接：https://arxiv.org/abs/2604.22068 项目与数据：GitHub / Zenodo

概述

自动驾驶系统需要在低频但高风险的交通事故场景中进行测试。然而，常规驾驶数据中真实碰撞事件很少，而现有场景生成方法通常采用合成道路、标准路口模板或抽象几何结构，难以保留真实事故发生地点的道路拓扑，也不能准确还原碰撞前的车辆状态和异常驾驶行为。

论文提出 TRACE，一个将美国国家公路交通安全管理局（NHTSA）的真实事故报告自动转换为 CARLA 可执行仿真场景的流水线。其核心思路是：

• 从事故报告中提取位置、碰撞类型、车辆状态和碰撞前行为；
• 根据事故经纬度从 OpenStreetMap 获取真实道路网络；
• 将道路转换为 CARLA 使用的 OpenDRIVE 格式；
• 使用大语言模型推断报告中缺失的车辆初始位置和方向；
• 根据事故类型生成允许逆行、跨实线等异常行为的车辆轨迹；
• 在 CARLA 中执行事故，并根据碰撞位置、撞击点和运动方向进行验证。

作者最终从 100 份随机抽取的事故报告中构建出一个包含 52 个已验证事故场景的开源基准，覆盖多种碰撞形式、道路拓扑和车辆运动关系。

1. 介绍

自动驾驶评测通常面临一个典型的"长尾问题"：日常采集的数据大部分是正常驾驶行为，而真正影响系统安全性的碰撞、逆行、异常转向等事件非常少。依靠自然驾驶数据进行训练和测试，很难保证系统充分接触这些高风险情况。

一种解决方案是人工或自动生成危险场景，但合成场景往往存在以下问题：

• 道路通常是直路、标准十字路口等简单布局；
• 场景只复现碰撞结果，没有还原碰撞前的完整轨迹；
• 车辆行为受到正常交通规则和仿真器路径规划器的限制；
• 事故文本与地图、车辆状态之间缺乏准确对应；
• 生成的场景缺少公开代码和数据，难以复现。

TRACE 的目标不是生成"可能发生"的危险事件，而是将已经真实发生过的事故重新构造成可执行仿真场景。它重点保留三类信息：

• 事故现场的道路拓扑与交通标志；
• 涉事车辆的初始位置、方向和速度；
• 导致碰撞的车辆轨迹和事件顺序。

论文将 TRACE 的应用场景归纳为三类：

1. 测试自动驾驶系统的碰撞规避能力：替换场景中某辆车的控制系统，观察被测系统能否避免原事故。
2. 压力测试感知与轨迹预测模块：研究复杂路口、弯道和视觉遮挡是否会导致感知或预测失败。
3. 自动生成安全关键测试用例：利用真实事故扩充长尾场景，服务于测试或模型训练。

2. 背景

论文将自动驾驶场景生成方法分为三类。

2.1 对抗式场景生成

这类方法通过优化或搜索其他交通参与者的行为，有意制造能够使自动驾驶系统失败的场景。

其优点是能够针对特定系统发现薄弱点，但也可能存在计算成本较高、场景多样性有限，以及生成行为缺乏现实依据等问题。

2.2 基于知识的场景生成

这类方法使用预定义规则、知识图谱、本体或约束描述场景。它具有较强的可解释性，但规则构建成本较高，而且难以覆盖现实事故中的违规行为和复杂事件序列。

2.3 数据驱动的场景生成

这类方法从真实驾驶数据中学习交通参与者的行为分布，因此场景通常更加自然。但是，常规驾驶数据中的安全关键事件数量有限，仍然受到长尾问题的影响。

TRACE 也属于数据驱动方法，但它不依赖普通驾驶轨迹，而是直接从 NHTSA 的真实事故报告中提取已经发生的碰撞事件。

2.4 与事故报告重建方法的区别

已有方法也尝试从事故报告生成仿真场景，例如 AC3R、SoVAR、CrashAgent、AccidentSim 和 SAFE。论文认为这些方法主要存在以下局限：

TRACE 的主要区别是把真实地理位置、真实道路网络、事故报告和可执行车辆轨迹整合到同一条流水线中。

3. 模型框架

严格来说，TRACE 不是单一的神经网络模型，而是一个由事故数据解析、地图转换、LLM 状态推断、轨迹生成和仿真验证组成的系统。

整体流程可概括为：

3.1 事故数据提取

输入是 NHTSA 数据库中的事故报告。原始数据来自警方事故报告，之后由 FARS 分析人员进行标准化处理。每份报告是包含约 1,000～1,500 个字段的半结构化 XML 文档。

Extractor 主要提取三类信息：

• 地理坐标：纬度、经度，用于定位事故现场。
• 事故信息：碰撞类型、环境条件、道路拓扑、导致碰撞的事件序列。
• 车辆信息：车辆速度与车型、撞击位置和损伤部位、碰撞前行为（例如直行、左转和右转）。

由于事故报告可能不完整或相互矛盾，TRACE 会检查报告是否至少包含：

• 可用的事故坐标；
• 道路拓扑；
• 碰撞前轨迹类别。

不满足完整性要求的报告会被过滤。为了构建论文中的基准，作者还将场景限制为仅包含两辆车的事故。

3.2 地图重建

地图重建的目标是把事故发生地点的真实道路网络转换为 CARLA 可以加载的地图。

具体过程如下：

1. 根据事故经纬度查询 OpenStreetMap；
2. 使用 Osmium 裁剪地图，减少地图范围；
3. 将地理坐标转换到 CARLA 的平面坐标系；
4. 使用 CARLA 的 osm2odr() 将 OSM 道路转换为 OpenDRIVE；
5. 加载到 CARLA 中形成可行驶地图。

与使用标准十字路口模板相比，这种方式可以保留现场道路的：

• 车道宽度；
• 道路曲率；
• 交叉口形状；
• 道路连接关系；
• 部分交通标志。

不过，osm2odr() 会将道路网络平面化，无法保留垂直几何，因此当前版本不支持立交桥和隧道。

为了检查转换后的几何一致性，TRACE 在地图上选取 5 个位置，将其转换为 CARLA 坐标，并比较转换前后的相对距离。如果距离关系不一致，地图会被排除。此外，如果报告中的事故点位于道路范围之外，对应场景也会被过滤。

3.3 道路结构调整

CARLA 会把道路表示为多个独立路段，并依据交通规则限制部分动作。例如，标准路径规划可能不允许车辆：

• 跨越实线；
• 逆向行驶；
• 在不允许的位置横向穿越车道。

但这些行为恰恰可能是正面碰撞、逆向刮擦等真实事故的必要组成部分。因此，TRACE 会修改转换后的道路结构，将分离的车道片段整合为允许横向切换的多车道路段，从而为重建异常行为提供条件。

这种设计反映了事故重建与常规自动驾驶仿真的区别：常规仿真强调车辆遵守规则，事故重建则必须允许车辆执行导致事故的违规或异常动作。

3.4 基于 LLM 的车辆状态估计

事故报告通常会描述车辆碰撞时的速度、方向和撞击部位，但不一定给出碰撞前某一时刻的精确位置和朝向。因此，TRACE 使用 LLM 补全缺失状态。

State Estimator 的输入包括：

• 事故报告中提取的车辆信息；
• 碰撞位置；
• 道路和车道布局；
• 候选道路片段；
• 路口边界；
• 碰撞速度、角度和事件顺序。

论文构建基准时使用的是 gemini-3-flash-preview，但系统架构不依赖某个特定模型，其他支持结构化推理的 LLM 也可以替换。

提示词要求模型从碰撞状态反向推理车辆轨迹，并满足以下约束：

• 初始位置必须位于有效道路范围内；
• 车辆方向应与事故报告一致；
• 车道分配通常遵守右侧通行规则；
• 推断结果需要能够从初始状态到达报告中的碰撞点。

模型输出后，系统进行分析性检查：

• 车辆位置是否落在道路边界内；
• 车辆朝向是否与报告描述一致；
• 车辆是否位于合理的道路或车道上。

如果检查失败，TRACE 会将具体错误反馈给 LLM，要求其重新估计，直到通过校验或达到最大重试次数。最终结果以结构化 JSON 保存，包括碰撞位置、车辆初始坐标及其对应的 OpenDRIVE 道路编号。

3.5 轨迹生成与场景执行

Launcher 根据估计的初始状态生成 CARLA 车辆轨迹：

• 初始位置作为起点；
• 报告中的事故位置作为终点；
• 车辆速度采用报告中的速度；
• 轨迹由一系列 CARLA Waypoint 表示。

TRACE 没有直接使用 CARLA 的 GlobalRoutePlanner，因为标准规划器依赖合法道路连接关系，无法生成逆行、跨实线等轨迹。作者为此设计了针对事故类型的轨迹生成机制。

场景执行后，系统会保存：

• 车辆位置；
• 车辆方向；
• 行驶速度；
• 轨迹航点；
• 碰撞传感器输出；
• 实际碰撞位置和撞击部位。

这些数据使事故可以在后续实验中重复回放。

3.6 场景验证

一个生成场景需要同时满足三项条件：

1. 碰撞位置误差不超过 5 米；
2. 车辆撞击部位与报告基本一致，允许相差 ±2 个钟点方向；
3. 车辆轨迹类别一致，即左转、右转或直行与报告相符。

撞击部位使用钟点位置描述，例如 12 点代表车头，6 点代表车尾。作者没有要求精确匹配，是因为事故报告通常不会记录最后一刻的避让、急转等动作，这些动作可能改变车辆最终朝向和撞击角度。

4. 实验

4.1 实验目标

论文的实验重点不是比较不同自动驾驶算法的性能，而是回答两个问题：

1. TRACE 能否从真实事故报告中生成可执行且通过验证的 CARLA 场景？
2. 最终构建的事故基准是否覆盖多种碰撞类型、道路拓扑和车辆轨迹？

因此，这部分更接近流水线可行性验证与数据集覆盖分析，而不是传统意义上的模型精度对比实验。

4.2 数据筛选过程

作者从 NHTSA CrashView 数据库中随机抽取了 100 份事故报告，处理结果如下：

地图重建阶段过滤的 35 个案例包括：

• 17 个包含当前不支持的垂直道路结构，例如立交桥或隧道；
• 10 个事故信息不完整；
• 8 个事故位置存在不一致。

因此，TRACE 在这批样本上的最终场景构建成功率为：

如果只考虑已经成功生成地图的 65 个案例，则仿真碰撞复现率为：

需要注意的是，这两个比例只反映该批随机样本和当前实现的处理能力，不能直接视为系统在所有 NHTSA 报告上的总体准确率。

4.3 碰撞类型覆盖

52 个场景的碰撞类型分布如下：

总体覆盖了 FARS 分类中的 5 类碰撞，其中正面碰撞和角度碰撞占大多数：

这说明基准主要集中在方向冲突比较明显的严重碰撞上，对同向刮擦、车尾相撞等场景的覆盖仍然不足。

4.4 道路拓扑覆盖

多数事故发生在非交叉口道路上，包括普通直路和弯道。交叉口场景共 16 个，其中 T 形路口与十字路口各占 8 个。

基准虽然保留了真实道路曲率和车道结构，但拓扑类型仍不完整，尚未包括环岛、Y 形路口和多岔路口等更复杂结构。

4.5 车辆轨迹覆盖

其中，对向行驶场景最多，与数据集中正面碰撞数量较高的特点一致。转向和路径交叉场景则主要体现交叉口中的复杂交通冲突。

4.6 实验结论

实验说明 TRACE 能够将部分真实事故报告转换为：

• 保留事故地点道路拓扑的 CARLA 地图；
• 包含车辆初始位置、速度、方向和轨迹的可执行场景；
• 能够实际发生碰撞并通过位置、撞击点和轨迹验证的测试用例；
• 可重复回放、修改车辆控制器并用于自动驾驶测试的场景包。

TRACE 最终生成的 52 个场景覆盖了不同碰撞类型、道路结构和运动关系，说明其方法具有一定通用性。但覆盖分布并不均衡，部分事故类型和复杂道路拓扑仍然缺失。

5. 总结与思考

TRACE 的核心贡献是打通了：

真实事故报告 → 真实道路地图 → 缺失状态推断 → 异常轨迹生成
→ CARLA 场景执行 → 碰撞一致性验证

相比只生成危险交通冲突的方法，TRACE 的优势在于场景有真实事故作为依据，并尽可能保留事故现场的道路结构。相比直接从事故文本生成抽象场景的方法，它进一步使用 OpenStreetMap 还原具体道路，并通过校验机制约束 LLM 的推断结果。

不过，论文目前仍有几个明显限制：

1. 不支持垂直道路结构：osm2odr() 会将地图平面化，因此立交桥和隧道无法正确重建。

2. 只处理双车事故：多车连环碰撞、行人和骑行者事故尚未纳入当前基准。

3. LLM 推断不等于真实状态恢复：事故报告缺少精确轨迹时，模型只能给出满足道路与碰撞约束的合理估计，不能证明该轨迹就是事故发生时的真实轨迹。

4. 验证条件相对宽松：5 米的位置误差和 ±2 个钟点的撞击方向误差有利于提高重建成功率，但也意味着"验证通过"不等于物理过程被精确复现。

5. 实验缺少下游自动驾驶系统评测：论文证明了场景可以生成和复现，但没有进一步测试不同自动驾驶系统在这些场景中的碰撞率，也没有展示 TRACE 是否比现有基准更容易发现系统缺陷。

6. 基准规模和类别覆盖有限：当前只有 52 个场景，并且主要集中在正面和角度碰撞，环岛、复杂多岔路口及部分碰撞类型尚未覆盖。

总体来看，TRACE 更像是一个面向自动驾驶安全测试的真实事故场景基础设施，而不是新的驾驶算法。它最有价值的地方，是把静态、半结构化的事故报告转化成可以被自动驾驶系统实际运行和测试的仿真场景，为碰撞规避、感知预测压力测试以及长尾测试用例生成提供了基础。