自动驾驶合规宝典10～如何搭建完整的交通场景库

1.什么是交通场景

2.确保足够的交通场景覆盖

3.交通场景分类

4.交通场景的应用

5.交通场景模板

1.什么是交通场景

此外，仅通过现实世界测试进行验证的时间和成本是令人望而却步的，这可能需要ADS在没有事故的情况下行驶数十亿公里，以证明其安全性能明显优于人类驾驶员。如果系统发生变化（软硬件变更、升级、优化）则需要重新验证，复制重现这种测试也是不可行的。

考虑到这些因素，需要使用基于交通场景的方法以高效、客观、可重复和可扩展的方式系统地组织安全验证活动。

基于交通场景的验证包括挑战ADS车辆安全运行的特定场景的重现。

交通场景（Traffic Scenario）：交通场景是在给定旅行期间可能发生的一个或多个驾驶情况的描述（旅行是车辆从起点到目的地穿越整个旅行路径）。交通场景会涉及许多元素，例如DDT的部分或全部、不同的道路布局、不同类型的道路使用者、静态或多样化动态的物体、不同的环境条件以及许多其他因素。

2. 确保足够的场景覆盖

在验证ADS的安全性时，选择的每个场景应准确反映ADS的ODD特定条件（例如，道路配置、给定车道的交通方向等）。场景应与正在验证的ADS功能的ODD相关。例如，一个只供高速公路使用的ADS将不受涉及交叉口转弯的情况的影响，这在其ODD之外。

由于ADS需要对其他道路使用者的行为做出反应，而其他道路使用者的行为可能会导致碰撞不可避免，因此要确保场景不限于ADS认为可以预防的场景。其他道路使用者的不安全行为（例如，车辆逆向行驶、突然无转向灯变道、超速等）——如果在适当的ODD范围内可以合理预见——应作为验证测试的一部分。

可用于识别安全验证场景的许多方法，包括但不限于：

场景目录不一定是详尽无遗的，监管当局可能需要考虑其他必要的场景，以支持ADS功能的安全验证。

3. 交通场景分类

因此，建立描述场景的标准化和结构化语言至关重要，以便ADS利益相关者理解场景的意图、彼此的目标和ADS的能力。建议使用统一的语言（模版）来描述场景，以确保所包含的信息是一致的，并最大限度地减少翻译解释过程中混淆的可能性。

一般场景分为正常场景、关键场景、故障场景、复杂场景四类。

“正常场景Nominal scenario”：是指代表通常和/或预期对象、对象行为和/或道路状况的交通场景。

“紧急场景Critical scenario”：是指代表异常和/或意外对象、对象行为和/或道路状况的交通场景。

“故障场景Failure scenario”：是指代表系统故障的交通场景，该故障会损害ADS执行整个DDT的能力。

“复杂场景Complex scenario”：是指包含一个或多个涉及大量其他道路使用者、不太可能的道路基础设施或异常地理/环境条件的情况的交通场景。

可以通过不同的抽象级别来描述场景，抽象提供了将场景描述集中在特定方面的能力，同时根据需要留下其他细节以进一步处理。一些行业和研究正在提出3或4层的场景抽象：功能、抽象、逻辑和具体。这些层次的本质如下所述，3或4个层次并不意味着也不强制要求从一个层次到另一个层次的任何具体实现或翻译流程。

（a）功能场景Functional Scenario：在概念层面上用自然语言描述的场景，一般没有具体的物理值。这些是具有最高抽象级别的场景，概述了场景的核心概念，例如自动驾驶车辆动作的基本描述；自动驾驶车辆与其他道路使用者和物体的交互；以及构成场景的其他元素（例如环境条件等）。这种方法使用可理解的语言来描述情况及其相应的元素。

（b）抽象场景Abstract Scenario：对功能场景的形式化、声明性描述（声明性描述可以包括结构化的自然语言、编程语言或满足所需标准（形式化和声明性）的其他形式的语言）。抽象级别的规范可以突出场景的相关方面，同时专注于关系（因果关系）的有效描述。

（c）逻辑场景Logical Scenario：包含参数的场景，其中一些参数的值被定义为范围。例如，基于功能场景中确定的元素，开发人员通过为场景中的每个元素选择范围或概率分布（例如，以米为单位的车道可能宽度）来生成逻辑场景。

（d）具体场景Concrete Scenario：用明确的参数值描述物理属性的场景。通过为每个元素选择特定的值来建立具体场景。此步骤确保特定的测试场景是可复现的。此外，对于每个具有连续范围的逻辑场景，可以开发任意数量的具体场景，有助于确保车辆暴露于各种可能情况下。

功能场景、抽象场景、逻辑场景、具体场景关系举例（ISO34501）

4. 交通场景的应用

在选择用于为特定ADS及其ODD创建ADS验证的逻辑和具体场景的参数时使用抽样技术，以避免ADS针对一组已知测试用例进行优化。从可信度的角度来看，使用最大数量的随机样本显然是更可取的，但这可能会给制造商和相关机构（例如技术服务）带来更大的负担，在使用随机抽样确定测试量时，应考虑这一点。对于仿真测试，随机抽样带来的负担较小，因此最大化测试随机样本数量更可行。

5. 交通场景模板

交通场景目录应遵循一个共同模板，以便于比较不同的交通场景，并帮助监管当局确定哪些交通场景适合测试特定ADS。

场景名称：描述场景的标题。

场景ID：唯一标识号

贡献者：哪个组织贡献了该场景。

场景来源：此场景的来源是什么（例如，ISMR、综合场景、其他法规、事故数据库等）？这包括原始事件的地理位置（如果适用）

版本：用于跟踪更新的方案版本，包含提交日期。

图形：描述场景的图形，运动也可以用箭头或其他图形方式表示。该图形可以是2D或3D。

功能场景描述：包含场景文本描述的部分。这可能包括一些特定的测试和安全评估目标。此描述可以是结构化或非结构化的自然语言。

ODD 标签：场景元素（道路细节、建筑物等）、环境条件、动态元素（运动中的元素）

（有许多用于ODD和行为的标签标准，它们可用于创建要在目录中使用的常见标签列表。场景模板中的ODD标签不应被解释为“场景ODD”，而是指使用场景测试的ADS的ODD标签。这是为了帮助目录的用户搜索与待测试ADS的ODD相关的场景。ODD是主题车辆的设计工件，由ADS开发人员确定。）

行为标签：场景中的自车行为和动作。它也可能表示预期的反应。场景中所有其他活跃参与者的行为。

场景类型：正常、关键或失败。这些情景类型是由外部条件而不是ADS确定的，需要进一步的工作来确定目录的分类。在功能层面，一个以上的选择可能是合适的。

适用范围：场景使用的范围和/或参数约束

抽象场景（可选）：从功能场景派生的场景的形式化、声明性描述。抽象级别的规范可以突出场景的相关方面，同时专注于关系（因果关系）的有效描述。