基于场景的方法在自动驾驶系统研究和工程中受到了极大的关注。由于驾驶环境的复杂性和不确定性，以及驾驶任务本身的复杂性，自动驾驶系统（ADS）或高级驾驶辅助系统（ADAS）可能遇到的驾驶场景数量几乎是无限的。因此，必须做场景识别，特别是那些不考虑则有无法接受风险的关键场景。

关键场景对于设计、确认和验证（V&V，verification and validation）工作以及安全基础等尤为重要。本文对此做了一个文献综述，主要包括：(i) 一个关键场景识别方法的分类； (ii) 基于分类法的最新研究，2017 年至 2020 年的 86 篇论文； (iii) 确定未解决的问题和进一步研究的方向。该分类法的三个主要观点，是问题定义（原因）、解决方案（派生场景的方法）以及已建立场景的评估。此外，讨论一些开放研究问题，即覆盖范围、实用性和场景空间探索等。

这里安全作为特定的操作设计域 (ODD) 、功能安全 (FuSa) 和预期功能安全 (SOTIF) 的组合。

如图所示是潜在危害之源：

功能不足会导致该功能在某种触发条件（例如眩光）下出现意外行为（例如对前方车辆的错误检测）。 如果下游功能（例如目标跟踪和传感器融合）的容错不能解决这种意外行为，则可能会传播到车辆级危险（例如未能检测到行人造成未及时启动制动 ）。

对场景和景象做定义：

“场景（scenario）描述了一系列场景中几个景象之间的时间发展。 每个场景都从一个初始景象开始。 可以指定行动和事件以及目标和价值来表征场景的这种时间发展。 不是一个景象，一个场景跨越一定的时间。” 如上图所示，可以通过一组影响因素来描述场景。

“景象（scene）描述了环境的快照，包括景色（scenery）和可移动目标，以及所有行动者和观察者的自我表现，以及这些实体之间的关系。 只有模拟世界中的景象表示才能包罗万象（客观景象、真值）。 现实世界中这是不完整不正确不确定的，是从一个或多个观察者的角度来看（主观景象）。”

所有符合相同描述的相关场景，组成一个场景空间。 一个重要场景空间，是操作设计域（ODD），其中要求自车应该安全行驶。

ODD定义：

“给定驾驶自动化系统或其功能，专门用于运行的操作条件，包括但不限于环境、地理和时间限制，和/或某些必要的存在或不存在的交通或道路特征”。

ODD 本质上定义了操作环境，而ADS 就是针对该环境设计的。

德国Pegasus项目定义一个6-层场景描述模型，如下表所示：

场景表示包含三层抽象，即功能场景、逻辑场景和具体场景。 功能场景和逻辑场景在两个不同的抽象层次上描述场景空间，而具体场景描述特定场景。

根据一个具体场景，采用OpenX（OpenDRIVE, OpenSCENARIO），可以构建一个可执行的场景。可以是仿真模型，也可以是真实的测试。 可执行场景是指来自相机的图像或来自 LiDAR 的点云。

如图描绘了三个抽象层次之间的转换：支持功能场景形式化的是逻辑 ODD，即一个参数化的ODD描述；来自 ODD 定义的输入，功能场景被形式化和参数化为有所有参数定义及值范围的逻辑场景；即使形式化的逻辑场景比功能场景包含更多的信息，其代表的场景空间更小一些，因为并非所有影响因素都可能被识别和考虑。

很多情况下，极端场景（corner case ）和边缘场景（edge case）是相关的术语，通常用作同义词。 发生的概率是二者之间最显着的差异。 corner case是正常操作参数和罕见/异常情况的组合。 并非所有edge case都是corner case，反之亦然。 只有罕见和新的条件下特殊组合的corner case才被视为edge case。

关键场景（Critical scenario）定义为系统设计、安全分析、验证或确认的相关场景，具有潜在的危害风险。

触发条件和安全-紧要操作情况是 ODD 中关键场景的两个主要组成部分。 因此，未知的关键场景可能源于这两个部分，如图所示：

标准ISO/PAS 21448的一个主要目标是识别未知的关键场景，然后使其安全。此外，标准ISO/PAS 21448的附录 B2 进一步假设场景条件/情况可以建模为几个有影响情景因素的组合（例如，大雨、眩光、路面湿滑、另一辆车突然切入、等等）。在这个假设下，未知的关键情景可以归因于未知的场景因素或已知场景因素的未知组合。

为此，关键场景识别 (CSI，Critical Scenario Identification) 方法被定义为查找触发条件、安全-紧要操作情况或将导致伤害的两者组合方法。 ODD 定义被认为是 CSI 方法的输入来划定场景空间。

一个保证预功能安全的迭代过程如图所示：识别出的关键场景将支持自动驾驶功能的细化，使ADS 更安全。

它们还可能有助于ODD 定义的完整，尤其当确定的关键场景指向 ODD 定义中未考虑的方面。 同时，功能细化也可能导致 ODD 变化，在下一次迭代中启动新的 CSI 过程。

如图是关键场景识别（CSI）方法分级的类别结构：

采用以下三个基本类来构建CSI 方法：下面的子类见上图（左、中、右）

问题定义：识别什么样的场景？ 为什么这些场景很重要？

解决方案：应用哪些技术来识别关键场景？ 需要什么外部信息/数据？

评估：如何评估方法和关键场景的有效性？

开发中V-模型每个阶段的关键场景如图所示： 图中的灰色框列出了识别出的关键场景在相应开发阶段可以支持的内容。

需求分析：

在 ISO 26262 中，危害分析和风险评估 (HARA，Hazard Analysis and Risk Assessment ) 是识别所有潜在危害事件的重要步骤。 如图所示，每个危险事件都是危险和操作条件的组合。 确定的撞前功能场景可以用作HARA 的所有操作条件集。

系统设计：

决定系统配置和分解车辆级别需求到组件级别。

组件设计：

由于不同的自动驾驶功能可能对不同的环境因素敏感，因此通常在组件层而非车辆层分析影响因素。

组件和系统验证：

生成的测试用例用于验证整个自动驾驶系统或特定的功能。

系统确认：

一种常见的验证（validation）方法是通过蒙特卡罗模拟来估计事故率或故障率。 由于关键场景相对较少，小样本量的蒙特卡罗模拟可能会导致关键场景的覆盖率较差，增加估计误差。 作为蒙特卡罗模拟的一种变型，重要采样（IS）为关键但相对罕见的场景分配更多样本来减少估计误差。 因此，重要抽样（IS）方法意味着识别的关键场景或关键区域作为输入。

根据问题定义和解决方案，CSI方法分成5个类群（clusters）：

C1 探索没有参数轨迹的逻辑场景；

C2 探索有参数轨迹的逻辑场景；

C3 归纳推理；

C4 演绎推理；

C5 基于计算机视觉（CV）的函数找到关键景象。

下面先说C1群。

一个逻辑场景的参数分类如图所示：

假设参数对于所有实例（即具体场景）具有固定值，例如场景中的车辆数量和车道数量；感兴趣的参数构建要探索的场景空间，这些参数包括随时间恒定的参数（例如天气状况或道路上静止障碍物的位置）和随时间变化的参数（例如周围车辆的速度或感知误差）。 如果参数随时间变化，则可以将其表示为参数轨迹。 参数值可以是分类的（例如天气、颜色和车辆模型）或数字的。 数值可以是连续的（例如速度、航向和传感器噪声）或离散的（例如其他车辆的数量、车道数量和速度限制）。

在C1类，具体关键具体场景的确认看成是设计空间探索（DSE）或基于搜索的测试（SBT）问题，其流程图如图所示：

给定一个逻辑场景，用参数空间探索方法生成一组具体场景。在这些生成的具体场景中，用预定义的关键性评估方法识别关键场景。 关键性评估可以看作是将场景空间一个点映射到评分空间中一个点的函数。 评分空间是对具体场景的关键性定量评估。评估是通过替代测量来实现的，因为关键性很难直接测量。

如图列出C1类中关键场景识别（CSI）中所有场景空间探索方法：可以分为两种类型，即（1）天真型搜索（即采样和组合测试）和（2）指导型搜索（即基于优化和学习的测试）。

场景探索的一种天真方法是在场景空间中随机或系统地搜索。换句话说，样本是相互独立的。因此，这些方法可以并行实施以减少探索时间。然而，如果关键场景很少见，这些方法可能效率低下，因为采样到关键场景的概率很低。另一方面，指导搜索方法具有更高效的潜力，因为每次迭代的搜索方向根据前一次迭代的搜索结果进行调整，将探索收敛到关键区域。

采样方法在逻辑场景空间随机分配每个参数值来实例化具体场景。 根据参数的概率分布统计抽取预定数的样本，其抽样大小由模拟所需的覆盖范围和计算时间决定。

使用的采样方法总结如图所示：根据逻辑场景的参数描述，根据是否考虑参数分布，对采样方法进行分类；如果没有提到参数分布，假设采用均匀分布。

组合测试（CT）是一种常用的软件测试方法，专注于识别仅由特定输入组合触发的故障。 CT 的核心是生成满足 N-wise 覆盖（注：给定一个感兴趣系统模型，包含参数列表、取值和约束来定义参数交互，那么N-wise 覆盖表明所有参数值的 N 元组必须至少测试一次）的最小测试用例集（即覆盖数组）。 在 自动驾驶的CSI 的背景下，CT 可用于发现可能使自动驾驶或特定 自动驾驶功能失效的影响因素未知组合。

CSI 方法也可表述为优化问题，通常包含四个部分，即设计变量、约束、目标函数和优化器（即求解器）。

基于学习的测试方法旨在将模型检查算法与有效的模型推理算法相结合，并将两者与感兴趣系统集成在一个迭代循环中，自动生成大量高质量的测试用例。 它会训练代理模型在优化过程中学习系统的属性。 可以通过最大化场景空间或评分空间中样本之间距离来优化多样性。

从上述 CSI 方法获得具体场景后，基于测试的方法可以验证派生场景的关键性，如图所示：

在关键性评估阶段，大多数研究利用 X-in-loop仿真来估计具体场景的关键性，其中 X 将系统 的模型、软件或硬件表示为黑盒。 也可以不在X-in-loop模拟的情况下评估关键性。 验证可以通过现实世界的测试来实现，以分析探索方法的性能。

对于安全论证，在探索逻辑场景时必须考虑覆盖范围。 然而，并非所有主要研究都明确讨论了覆盖范围。 对覆盖范围的考虑，以及增加该类方法群已识别关键场景多样性的机制，总结如图所示：

C1群没有考虑运动轨迹，会有不少限制。在C2群，这个参数轨迹会作为场景参数来探索。

如图是C2群中各种逻辑场景实例方法一览：

场景模型包括一组参数。 其中一些具有预定义值（假设的参数），而其他（感兴趣的参数）应优化以找到关键具体场景，如图所示。假设参数的例子比如，其他参与者的数量（运动交通参与者）、车道数和人行横道的位置等。

探索的方法基本分成优化、路径规划和强化学习等。

关键性评估定义系统是否能满足其要求。 该评估可以根据确定故障的替代措施以及分析故障的避免性进行分类。比如：基于碰撞、基于规定、考虑避障和不考虑避障等。

在C3群（归纳推理）中主要数据来源归纳为两种类型：

1) 仅基于事故场景，

2）基于各种类型的数据和场景。

前者依赖于事故数据库，包括原始事故数据、事故报告或记录，后者是指现有的逻辑或具体场景、自然驾驶数据、交通数据或传感器数据。 C3群的 CSI 方法总结如图所示：

C4群（演绎推理）基于各种知识源寻找功能或者逻辑场景。

这里列出的是方法，通过系统考虑一组预定义假设下的所有可能性来寻找碰撞前场景。 确定的预碰撞场景可用作安全-紧要的操作情况。

最后，C5群（基于计算机视觉功能）的方法总结如图所示：

C5分成景象表征和关键景象生成或者探索两个主要思路。在C5群的评估图像关键性方法，大多数将被评估的图像提供给系统（即被验证的函数）作为评估性能的输入。 因此，评估的关键性针对实现而言。

评估方法的分类：

C1: 几乎所有研究都将案例研究作为评估方法来验证方法和关键场景。 大多数案例研究都是通过模拟实现的。

C2: 类似C1

C3：最常用的评估方法是将识别场景与法规场景进行比较。 通过来自真实数据的聚类生成功能或逻辑预碰撞场景，直接与法规或测试组织的测试场景进行比较，例如 Euro NCAP。

C4：不是都做评估。

C5：几乎都使用案例研究作为评估方法。 与 C1 和 C2 类似，也没有进行验证确定模拟识别的关键场景对于计算机视觉系统在现实世界是否也很关键。 覆盖率主要取决于使用的数据集，但对覆盖结果没有验证。

相关研究方向有：

在线风险评估

基于场景的功能评估

基于场景的系统设计

故障注入

ontology设计和影响因子分析

形式方法

计算机视觉中未知的未知物检测

数据增强

几个讨论点：

覆盖范围：覆盖范围可以通过 3 种方式定义（类型）： 1) 针对给定场景空间探索的覆盖范围； 2) 给定场景空间内所有关键场景的覆盖率（即在给定场景空间内所有关键场景中识别关键场景的比例）； 3) 在给定的功能场景或 ODD 下，所有关键功能不足及其触发条件的覆盖范围。

ALARP (”As Low As Reasonably Practicable”)原理：确保伤害风险最小。

场景空间探索：场景空间分成两个角度，一是分解ODD成各种应用用例，二是分成不同的感兴趣系统。要进行完整的安全分析，需要明确分析系统的容错（即识别上游功能意外行为所无法解决的场景），特别是分析目标跟踪和传感器融合的容错。此外，还需要一个系统的观点来确保划分到感兴趣系统中以及随后的“证据”组成是完整的，例如关于共同原因故障。

讨论了一些研究空白，例如覆盖度量、关键性度量、影响因素的识别和分类，以及缺乏一个方法框架将不同 CSI 方法组合起来并把它们与其他安全分析过程相结合。