基于真实世界故障记录的自动驾驶系统测试场景生成

# 基于真实世界故障记录的自动驾驶系统测试场景生成
来源: https://arxiv.org/html/2606.31131
\\coltauthor\\Name

Anjali Parashar\\Email anjalip@mit\.edu \\NameChuchu Fan\\Email chuchu@mit\.edu \\addr 麻省理工学院，剑桥，马萨诸塞州

###### 摘要

为了确保自动驾驶系统（ADS）在道路上的安全行为，部署前的测试和故障发现至关重要。目前，基于模拟的测试方法主要侧重于利用数学模型高效搜索最优场景，并假设场景表示是固定的。另一方面，真实世界的测试需要大量人工来设计用于测试的场景模板。这些模板代表不同的故障场景，包括部署前的车辆运动、地图类型等。ADS的历史故障记录是真实世界故障条件的可靠来源，可用于场景生成。在本工作中，我们提出了一种利用历史记录中以自然语言格式提供的分类和上下文信息进行场景生成的流程。我们的方法包括基于模块化LLM的合成场景生成，与给定系统的测试约束兼容。我们成功地将该方法应用于在Metadrive模拟器上使用NHTSA ADS碰撞记录测试自主导航，生成了多样化的场景集合。我们的方法结合了4种道路类型、3种非自车运动类型（包括施工区域等道路异常），生成了准确且多样化的场景。生成的场景与提供的测试条件一致，并在有限的20个场景测试预算内揭示了系统有趣的功能失效。代码可在 \url{https://github.com/anjaliParashar/crash2scenario} 获取。

###### 关键词:

场景生成，自动驾驶系统故障，历史故障记录。

## 1 引言

自动驾驶系统（ADS）故障发现（或称反证）是确保车辆乘员及道路上其他实体安全的关键步骤 (najm2007pre; 10.1007/978-981-96-7956-0\_7; szenasi2021analysis)。当前用于真实世界ADS反证的方法侧重于在一套手动设计的场景上测试系统性能 (berger2015large)。测试套件设计的目标是覆盖广泛的系统功能和真实世界故障场景。这里，时间和成本限制了可测试场景的数量。因此，大量的手动工作被投入到设计一组场景模板上，例如车对车后方制动（CCRb）、成人横穿马路等，这些模板代表了真实世界故障的一系列设置 (euroncap\_website)。每个场景模板进一步由少量场景参数（如车辆速度）参数化，这些参数在一个统一范围内变化，以生成组合场景用于测试车辆性能。

场景模板和参数由专家根据历史故障数据选择，以重现故障相关条件，并在各种操作设置下测试车辆性能。这也被称为组合测试，是监管测试机构（如Euro NCAP、NHTSA等）遵循的结构 (hackney1995new)。由此产生的测试套件与实时测试要求（时间和成本）兼容，并为车辆在道路上的性能提供了以用户为中心的基准。

随着工程创新带来的传感器能力和ADS功能的进步，这些手动设计的静态测试套件需要定期修订 (EuroNCAP\_2026\_Protocols)。此外，生成的测试套件难以轻易调整以对特定车辆或系统进行压力测试。因此，车辆可能因测试中已验证的故障而在实时中发生碰撞，因为潜在故障可能仍未被发现 (teambhp\_ncap\_overoptimisation)。

作为静态测试套件的替代方案，基于模拟的测试中出现了一些自适应场景生成框架 (klampfl2024testing; zhu2022review; dawson2023a; koren2018adaptive; koren2021finding; ghaiGeneratingAdversarialDisturbances2021; hanselmannKINGGeneratingSafetyCritical2022a; wong2018provable; karve2026optimizing)。然而，这些方法假设可以访问预定义的场景模板，主要侧重于利用数学工具对固定场景模板和参数集相关的数字场景参数进行高效搜索。

历史ADS碰撞记录捕捉了固定场景模板可能遗漏的常见和非平凡的真实世界故障 (NHTSA\_ADAS\_Crash\_Report\_SGO)。例如，CCRb模板只改变自车和目标速度，忽略了像施工区域这类显著增加故障可能性的上下文因素。这在测试实践中留下了空白，因为没有原则性的方法从碰撞数据中提取场景定义并将其用于系统特定测试。虽然基于模拟的测试方法鼓励探索数值场景参数 (delecki2022we; dawson2023a)，但覆盖所有类型的故障场景对于全面测试也很重要。

在本工作中，我们提出一个场景生成框架，以原则性的方式使用现有碰撞记录中的数据，同时整合系统特定的测试约束。我们构建了一个场景模板测试套件，使用碰撞记录中现有的分类特征（如碰撞前车辆运动、道路类型等）进行参数化。碰撞记录还提供了事件的自然语言描述，称为叙述，提供了关于故障条件的详细、细粒度的洞察。最近，leung2025road 成功展示了使用LLM在自动驾驶中进行场景合成。我们采用这一概念，利用LLM辅助场景生成流程，将碰撞叙述转化为系统特定场景。我们提出的方法可轻松用于初始场景生成，在此基础上，可以部署如贝叶斯优化 (parashar2024failure)、MCMC采样 (parashar2024learning; delecki2022we) 和基于梯度的优化 (dawson2023a) 等低级测试方法，以进一步迭代和优化数值参数。

我们通过使用NHTSA ADS碰撞记录 (NHTSA\_SGO\_2021) 设计场景，验证了我们端到端的场景生成流程。这些场景是为在Metadrive模拟器 (li2022metadrive) 上测试IDM策略用于自动驾驶导航和避障而设计的。如第6节 (https://arxiv.org/html/2606.31131#S6) 所述，我们的方法成功地将自然语言描述的故障场景转化并生成为模拟场景。使用历史记录，我们在常见和不常见的故障条件下测试系统。我们的主要贡献如下：

- • 我们提出了一种自动化的场景生成程序，该程序利用了基于分类特征的场景模板设计，以及从真实世界ADS碰撞中获取的特定事件叙述。
- • 我们提出了一种方法，利用基于LLM的场景生成流程，将可用记录适配为系统特定的测试场景。
- • 我们使用Metadrive模拟器，从NHTSA碰撞记录中提取的碰撞进行系统特定测试，验证了我们的方法。

## 2 相关工作

自主系统测试的关键方法可根据测试成本分为三类，各自使用不同的数学工具，我们讨论如下。

### 2.1 基于采样的模拟测试

这些方法假设可以访问廉价的模拟模型，并将故障发现构建为针对特定动态系统的成本引导搜索，使用基于采样的方法 (delecki2022we; okellyScalableEndtoEndAutonomous2018a; sinha2020neural; dawson2023a; koren2018adaptive) 和优化技术 (wong2018provable; hanselmannKINGGeneratingSafetyCritical2022a)。这些方法不考虑测试用例生成的成本，因此它们侧重于利用样本密集的数学框架，如MCMC采样 (dawson2023a; delecki2022we)、MCTS (koren2018adaptive)，以实现高效的搜索空间覆盖、罕见故障发现以及平均系统验证。通常，场景参数化是用户定义的选择，并不像受监管的真实世界测试那样直接由现有碰撞记录提供信息。

### 2.2 使用历史记录的真实世界测试

真实世界测试的组合测试实践利用从重现历史碰撞记录中获得的信息 (EuroNCAP\_2026\_Protocols)。Euro NCAP协议评估多个标准的安全指标，大致可分为三类：关注车辆乘员（成人和儿童）免受碰撞影响、弱势道路使用者（VRU，行人和自行车骑行者）以及非自车实体（汽车）。对于每一类自车和非自车主体，都使用一组场景参数（如车辆速度、非自车主体的相对位置和运动、碰撞时间TTC）定义各种场景模板。这些场景覆盖的测试条件广度旨在提供丰富的场景覆盖。虽然这些方法提供了不同车辆之间的比较基准，但它们并未对给定车辆进行压力测试以暴露系统特定故障。此外，它们假设设计场景模板的刚性结构，使得整个流程无法迁移到模拟测试。

### 2.3 使用多保真度的模拟与真实联合测试

最近，一些工作考虑了使用基于贝叶斯实验设计（BED）的公式、代理模型和顺序场景采样的成本感知自适应测试 (parashar2025cost; sinha2024rate; parashar2024failure)。其中一些工作还扩展到使用模拟和真实世界系统的联合测试，通过使用多保真度场景生成并引入与每个保真度相关的成本 (parashar2024failure)。这些方法使用主动学习/BED和基于采样的方法的混合，并且也对场景参数化的预定义访问做出基本假设。

我们的工作与上述每种方法互补，因为我们从根本上侧重于使用历史碰撞记录作为场景模板设计和参数化的现实来源，进行原则性的场景设计。使用我们的方法提取的场景模板集可以嵌入到上述任何方法中，因为我们系统特定的适配视为流程的模块化组件。

## 3 问题定义

##### 定义。

考虑一个ADS，定义为 \\dot{x}=f(x,\\pi(o,z\_\{s\}))，状态 x \\in \\mathcal{X}，系统观测 o \\in \\mathcal{O}，场景参数 z\_s \\in \\mathcal{Z}，该ADS基于某策略 \\pi: \\mathcal{O} \\times \\mathcal{Z} \\to \\mathcal{A} 执行动作 a \\in \\mathcal{A}。我们假设可以访问具有预定义策略 \\pi 的系统，该策略可以输入 z\_s 并生成轨迹展开，并使用指标 y \\in \\mathcal{Y} 评估系统性能。这些指标假定是用户定义的，例如TTC、最小间隙等。下标 s \\in \\mathcal{S} 表示一个场景模板，它包含足够的上下文信息来唯一定义一组场景，这些场景可以通过 M 个元变量 [s\_i]\_{i=1}^{M} 与其他场景区分开来。例如，道路类型、自车和非自车轨迹类型以及天气都是元变量。每个元变量的唯一组合可用于定义一个场景模板。对于每个 s \\in \\mathcal{S}，我们使用数值变量（如自车速度、车辆之间的初始间隙等）定义一个场景 z\_s \\in \\mathcal{Z}。例如，一条直路，自车左转且非自车直行是一个场景模板 s，其规范包括道路长度、主体速度和轨迹参数化 z\_s。

本工作的目标是提出一种原则性的场景设计范式，该范式使用历史故障记录作为参考，并充分地对给定系统进行压力测试。我们以原则性的方式使用这些记录，作为减少场景设计中手动工作的方法。生成的场景可以适配用于系统特定测试，从而缓解静态测试方法的常见问题。在本工作中，我们使用NHTSA记录中可用的ADS碰撞报告格式来构建场景模板。我们的场景设计流程包括三步基于LLM的模板生成，以使用碰撞数据为系统特定测试设计场景模板。随后，这可用于以成本感知的方式采样场景，同时确保生成测试用例的多样性，如第6节 (https://arxiv.org/html/2606.31131#S6) 所示。

## 4 使用历史故障数据的场景设计

我们的场景设计方法包括两个主要步骤：(1) 使用碰撞记录设计元变量，以及 (2) 以碰撞记录为输入的基于LLM的场景设计。第一步提供了一个示例，说明如何使用历史故障记录进行高效场景表示。第二步是模块化的，也可用于其他故障数据库。

### 4.1 从历史故障数据中提取信息

NHTSA ADS碰撞记录中每次碰撞的信息可分为两类：

- **元变量**：表示感兴趣数量的分类变量，例如“碰撞伙伴（CP）碰撞前运动”、“自车（SV）碰撞前运动”、“道路类型”等。模拟器/系统支持的一组离散变量用于定义元变量。
- **叙述**：与场景相关的上下文信息，以叙述形式记录，描述了自车和非自车轨迹的定性方面，以及它们在用道路类型表示的全局参考系中的相对位置。

表1 (https://arxiv.org/html/2606.31131#S4.T1) 展示了从NHTSA ADS记录中提取的元变量。所选元变量集必须与系统/模拟器的场景生成能力兼容。这些元变量可通过多种方式定义场景模板。这里的最低要求是，每个元变量组合必须提供高级可解释分类，以区分不同的故障场景。为此，我们直接使用碰撞记录中的分类特征。这些变量也已用于文献中AV测试的本体场景模型设计 (schuldt2017beitrag; bagschik2018ontology)。例如，一辆在高速公路上直行 (s\_1) 的车辆与另一辆左转 (s\_3) 的车辆碰撞，定义了一个场景模板。这里，对应的元变量分别是自车碰撞前运动、道路类型和碰撞伙伴碰撞前运动。图1 (https://arxiv.org/html/2606.31131#S4.F1) 展示了根据元变量（道路类型：交叉口、自车运动：直行、CP运动：左转、施工区域：假）构成的场景模板的叙述。碰撞报告通常记录自车在碰撞前短时间内的场景描述，因此涉及两个主体：自车和碰撞伙伴。这可以演变为构建包含长期信息的场景模板。