用于自动驾驶汽车开发测试与验证的场景

Posted 2021-04-27 焉知自动驾驶

焉知焉知·焉能不知

摘要：2016年更新的ISO 26262标准，引入了涉及车辆安全的关键电气/电子系统开发与测试的最新进展，可以应用于高级驾驶辅助系统（ADAS）和自动驾驶系统的开发和验证。标准规定了基于V型开发模式的各个阶段所要求的工作内容和输出产品。在V型开发模式的各个阶段，均可应用基于场景的方法，来获得相应的工作输出产品。在应用基于场景的方法时，不同开发阶段对场景细节程度的需求存在矛盾。本文作者讨论了ISO 26262标准中不同阶段对场景描述的要求，提出了满足一致性的场景描述方法，并演示了如何系统建立满足不同阶段需求的场景。

一、 需求：基于场景的设计与测试过程

场景可以应用到标准的整个开发过程中以得到各中间产物，从概念阶段到产品开发，再到系统验证和测试。而在整个开发周期中，要求在不同抽象级别上对所用场景有一致性表述。本节分析了基于场景的方法在ISO 26262标准定义的开发过程中的可行性，以及各流程对场景的需求。

1 概念阶段的场景

在标准第3部分的概念阶段，该标准对项目进行了定义，进行了危险分析和风险评估，并引出功能安全概念。

项目定义包括功能定义、系统边界、操作环境、法规需求以及对其他项目的依赖关系的描述。基于这些信息，可以派生出可能的操作场景。此过程中的操作场景应以较抽象的方式描述，并以一种易于理解的方式表示。

危险分析和风险评估包括两个步骤：首先分析出所有故障行为，并描述导致危险事件的所有操作场景，将操作场景和故障行为加以组合从而得到危险场景；然后依据汽车安全完整性级别（ASIL）对所有危险场景进行评级。

现有对危险场景的分析由专家进行，因此为了便于专家之间的沟通理解，应使用自然语言来表述，并需要一个统一的术语表，以半正式*的方式组织起来。

综上，在标准提出的概念阶段，场景必须满足以下需求：

1.1：人类专家应该能够用自然语言来描述该场景。

1.2：场景应以半正式的方式表示。

*译者注：结合上下文，此处应指非格式化的自然语言和格式化的术语组织方式的结合应用

2 系统开发阶段的场景

一旦分析了危险场景，就会形成功能安全概念。为了实现功能安全，须提出安全需求。与功能需求不同，安全需求描述了可量化的条件。例如，保持与其他交通参与者的安全驾驶距离的安全需求通过以米为单位的距离来确定。因此，每个危险场景都必须从半正式的自然语言表述转换为利用状态量表述的方式。

为了减少场景的数量，可以给定状态量的取值范围，或者可以进一步划分有效/无效的取值范围，即安全/不安全的取值，从而明确系统边界。场景的详细表述确保了能以可验证的方式制定开发项目的需求。

综上，在系统开发阶段，场景必须满足以下需求：

2.1：场景应包括用于场景表示的状态量的参数范围。

2.2：场景应为每项参数指定一个标记，以支持自动处理。

3 测试阶段的场景

在测试阶段，将验证系统是否满足了前述流程中指定的需求。这一过程，测试必须依据标准，系统地计划、制定、执行、评估和记录。

测试用例生成的一个难点在于输入数据的规范性，包括每个参数的时间序列。概念阶段已经给出了系统的操作环境和可能的操作场景，这是为测试用例派生一致的输入数据的基础。在安全需求的制定过程中对场景进行了详细说明，包括系统如何对可能影响安全目标的外部影响做出反应，以及满足系统安全需求的参数范围。为了生成测试用例的输入数据，必须从指定场景的连续参数范围中选择离散参数值。此外，还必须将场景转换为正式表达，以确保之后测试用例的可执行性及可复现性。

具体而言，必须通过不同的测试方法（如模拟或场地测试），确定用于执行基于场景的测试用例所需的所有参数，并从基于术语的半正式表达转换为基于系统状态值参数的正式表达。最终，系统地导出参数化场景，作为被测系统的一致输入参数，用于验证系统功能。

综上，在系统测试阶段，场景必须满足以下需求：

3.1：场景应该通过具体的状态值来描述，以确保其可执行性和可复现性。

3.2：场景应具备一致性。

3.3：场景应该以一种高效的机器可读的方式表示，以确保自动化测试的执行。

4 对场景需求的分析

各阶段对场景的需求是存在矛盾的。一方面，1.1要求抽象的、自然语言的表述形式；另一方面，2.2和3.3要求高效的机器可读的表述形式。类似的，2.1和3.1要求场景表述的细节程度不同：2.1要求通过状态空间中的参数范围来表述场景，这样在确定待测量时提供了多个自由度；而3.1要求表述中包括具体的参数值，这是测试用例可重复执行的必要条件。因此，机器可读的场景必须支持两种不同的细节程度。

 

二、实现：设计和测试过程中的场景术语

正如上一节所述，在ISO 26262标准的开发过程中应用场景时，对场景的细节程度的需求是存在矛盾的。本节作者将场景划分为三个抽象级别：功能场景（Functional scenarios）、逻辑场景（Logical scenarios）和具体场景（Concrete scenarios），如图1所示。

图1 满足ISO 26262标准的各开发阶段的场景抽象级别

1 功能场景

功能场景是场景表述的最抽象级别。在概念阶段，这些场景可用于项目定义、危险分析和风险评估。作者提出了以下定义：

功能场景是通过语义描述的操作场景。通过语言场景符号来描述域内的实体以及实体间的关系。场景描述是一致的，用于描述功能场景的术语表应由一般用例或域内专用的术语组成，并且可以具有不同的详细程度。

功能场景的表述包括实体和实体之间的关系，不同场景的描述方式必须是一致的。首先需要制定一个术语表，这个术语表包括不同实体的术语（车辆A、车辆B）和这些实体的关系短语（车辆A超越车辆B）。为了生成一致的功能场景，术语表的所有术语必须是明确的，其来源可以是实际的标准和法规，如道路交通规则。

功能场景的详细程度取决于实际的开发阶段和正在开发的项目。例如，高速公路行驶需要描述道路的几何结构和拓扑结构、与其他交通参与者的交互以及天气状况。而在停车库行驶则需要描述建筑物的布局，而天气条件却无关紧要。

图2为在高速公路行驶的一个功能场景：一辆轿车和一辆卡车正行驶在右侧车道上，轿车跟随卡车行驶。在这个例子中，道路特征主要描述为横断面布置情况和几何结构特征。

图2 功能场景实例：跟车行驶

2 逻辑场景

基于状态空间变量，逻辑场景是对功能场景的进一步详细描述。在系统开发阶段，可以利用逻辑场景派生出安全需求。作者提出了以下定义：

逻辑场景以状态空间呈现操作场景。通过定义状态空间内变量的参数范围，可以表达实体特征和实体间的关系。参数范围可以选择用概率分布来确定。此外，不同参数的关系可以通过相关性或数值条件来确定。逻辑场景应包含该场景的形式标记。

图3 逻辑场景实例：跟车行驶

逻辑场景涵盖了提出安全需求所需的所有元素。为了在标准规定的开发过程中逐步规范场景，必须在状态空间中通过形式标记来表述逻辑场景，并从取值范围中确定参数。可以通过概率分布（例如，高斯分布，均匀分布）为每个参数指定范围。参数范围间的关系可以由数值条件或相关函数来指定（例如，超车速度必须大于被超车速度，车道宽度与曲线半径相关）。

图3显示了从图2所示的功能场景中衍生出的逻辑场景。功能场景术语表中的每一项都必须分配一个描述该术语的参数。在这个例子中，两条车道都是通过车道宽度来描述的，几何结构是由一个半径来表示的，车辆由其纵向位置来描述，并要求卡车纵向位置大于轿车。在实际应用中，可能需要多个参数来描述单个术语，例如，一辆卡车可以通过规定其尺寸、重量和发动机功率来定义。

 

3 具体场景

具体场景由某个确定的参数值来表示状态空间中实体和实体间关系。每个逻辑场景都可以通过从参数范围中选择具体值来转换为具体场景。具体场景可以作为测试用例的基础。作者提出了以下定义：

具体场景以状态空间详细描述了操作场景。通过确定状态空间中每个参数的具体值来明确描述实体和实体间的关系。

对于每一个具有连续取值范围的逻辑场景，都可以派生出任意数量的具体场景。为保证生成具体场景的效率，应选择有代表性的离散值进行组合。必须强调的是，只有具体场景可以直接转化为测试用例。要将具体场景转换成测试用例，需要增加被测对象的预期行为表现，以及对相关测试设施的需求。而被测对象的预期行为则可以从操作场景、逻辑场景或项目定义中导出。

图4显示了从图3中所示的逻辑场景中得出的一个具体场景。图中可以看到，每个参数都从指定的参数范围内确定了一个具体的参数值，从而确定了一个特定的测试条件。

图4 具体场景实例：跟车行驶

三、结论

本文分析了基于场景的方法在依据ISO 26262标准开发自动驾驶系统过程中的可行性。作者分析了可以使用场景来生成工作输出产品的各个工作阶段，并明确了不同阶段对场景描述的需求，阐述了场景描述需求在细节程度上存在的差异。在此基础上，作者定义了场景的三个抽象级别，以满足上文阐述的场景需求。

资料来源：智车科技

---

iKE焉知·车联网·ADAS·自动驾驶·AI