内容提要：在本文中，我们提出了基于依赖关系的组合方法（DBCA），以减少识别自动驾驶车辆运行环境中的各种运行环境和场景的各种实例的工作量。DBCA利用组合算法IPOG生成ODD元素的t路组合来生成代表运行环境的组合，以及属性（或参数）的p路组合。

摘要

对于自动驾驶车辆，为了确保安全，我们需要考虑车辆的预期运行设计域（ODD）进行详细的分析。这要求分析师和工程师考虑ODD中可能出现的各种运行环境 (OE)，以及每个OE内可能出现的各种场景。然而，汽车安全标准ISO 26262和ISO 21448并未就需要分析哪些场景以及多少场景来确保车辆安全提供深入指导。此外，许多现有的仿真工具和验证方法考虑了有限的OE，并为工程师在OE内创建的每个场景详尽地生成测试用例。这样的分析需要大量的时间和精力，但仍然不能确保涵盖ODD元素之间的各种依赖关系。为了解决这些限制，我们提出了一种基于依赖关系的组合方法（DBCA），它使用参数内顺序通用（IPOG），一种组合测试算法来为每个场景生成OE和测试用例。为了评估DBCA，我们将其应用于从ISO 21448中提取的ODD元素以及高速公路切入场景。我们的结果表明，DBCA减少了分析的时间和精力，并减少了场景的OE和测试用例的数量，而没有丢失依赖项。

1.简介

基于场景的分析在确保自动驾驶汽车的安全方面发挥着至关重要的作用，因为车辆运行设计域(ODD)内发生的各种已知和未知的危害场景可能会影响车辆的安全。尽管汽车工业安全标准ISO 26262和ISO 21448分别提供了如何分析车辆功能安全(FuSa)和预期功能安全(SOTIF)的指南，但它们确实没有提供有关如何生成用于分析车辆安全性的场景，以及哪些场景和多少个场景将确保车辆足够安全以进行部署的深入指导。

目前分析自动驾驶汽车安全性的方法取决于自动驾驶汽车行驶的里程数，或者主要通过验证车辆在已知安全关键驾驶场景下的行为，然后确保车辆达到预定义的验证目标（由专家根据自然驾驶数据或基于事故的数据设定）。例如，Altoff和Lutz提出了一种基于车辆可驾驶区域为其可能的安全关键场景生成测试用例的方法。虽然这些现有的方法有助于识别自动驾驶汽车的安全可能受到损害的潜在情况，但它们仍然受到以下限制：

•ISO 26262第3部分和ISO 21448第6部分中当前使用的危害分析方法依赖于专家的集思广益来确定情景及其相应的运行环境。如果在此分析过程中遗漏/忽略了某些场景或环境，则在仿真过程中不会对其进行测试。

•只有涵盖多样化且有代表性的场景，里程数才成为有效的衡量标准。如果在仿真或现实世界中的同一道路上对车队进行测试，则可能会错过定义的ODD内可能发生的一些场景和运行条件。

•当前的安全关键场景生成方法考虑了固定环境的不同可能驾驶场景，即固定的ODD元素及其属性集。然而，驾驶场景只是自动驾驶汽车运行场景的一部分。对于ISO 21448中提到的具有驾驶自动化的车辆，为了识别场景，我们应该考虑环境因素（例如，降雪、降雨）、驾驶场景（例如，超越车辆、在车辆前方进行切入）、相关人员的行为（例如，行人、其他车辆）、道路几何形状（例如，直道）、道路基础设施（例如，交通标志）和场景的目标/目的的组合，即我们希望在场景中完成的任务（例如，当行人在城市街道上过马路时，自我车辆应该停止）。

此外，当前的仿真工具（例如CARLA）、Fortellix需要在测试场景之前创建运行环境，并且大多数运行环境都是根据客户需求创建的。然而，这些运行环境是否可以覆盖自动驾驶汽车工程师定义的整个运行设计域（ODD）尚未得到验证。此外，大多数当前的仿真工具都执行详尽的测试，即为每个场景生成所有可能的测试用例，其中包含由工程师初始化的所有离散参数值、其范围和增量，并在固定的运行环境中运行仿真。虽然 Fortellix等工具提供了一种结合场景和运行条件的方法，但场景描述仅限于Open M-SDL规范，该规范不需要拥有所有基本的ODD元素和属性，我们的目标是作为ODD的一部分进行承保。使用此类工具执行分析并不能解决被忽视的ODD元素或其属性。例如，如果行人的种族或性别等属性无法在仿真工具中设置，尽管ODD中存在该属性，则在使用仿真进行验证时可能会忽略该属性。此外，考虑到自动驾驶车辆ODD的复杂性，用运行环境仿真所有潜在场景可能不可行。这是因为随着ODD复杂性的增加，对资源（例如时间和精力）的需求也增加。

例如，让我们考虑ODD的以下因素（取自ISO 21448的表B.3）：气候、一天中的时间、道路形状、道路特征（例如隧道、大门）、道路状况 、照明（例如眩光）、自我车辆的状况（例如，传感器被灰尘覆盖）、自我车辆的运行（例如，车辆正在停止）、周围车辆（例如，自我车辆左侧的车辆）、道路参与者（例如行人）、道路外的周围物体（例如交通标志）、道路上的物体（例如车道标记）。这些因素中的每一个都可以有多个值。例如，对于“一天中的时间”，其值可以是清晨、白天、傍晚和夜间。根据ISO 21448表B.3中给出的值，ODD因子的组合总数为169554739200。请注意，我们还没有考虑参与者的属性（例如行人的性别）、车辆的属性（例如车辆的速度）、环境属性（例如降雪量）。

这些组合仅代表运行环境，并且仍然不完整，因为没有考虑多种参与者类型和车辆类型。对于这些组合中的每一个，我们都需要通过考虑参与者的属性、环境属性和自我车辆来生成要测试的场景实例。属性的示例是降雨量（环境）、随机初始化的行人数量（与参与者相关）以及车辆的速度范围（与自我车辆相关）。属性值由仿真工程师和专家手动选择/初始化。通过考虑属性之间的所有可能组合，基于这些属性生成仿真测试用例。在上面考虑的示例属性中，如果我们假设降雨量范围从0厘米到10厘米，增量为0.5厘米，则随机初始化的行人数量的范围可以从0到20，增量为1，并且车辆的速度范围被认为在30英里/小时到90英里/小时之间，增量为5英里/小时，那么详尽的测试策略结果将是21（对于降雨量）×21（行人）×13（速度范围）=5733次测试。随着属性数量、范围和增量的变化，这将导致大量的测试。创建大量运行环境并执行详尽的测试可能非常昂贵，而且通常这样做是不可行的。此外，分析从大量测试用例中暴露碰撞和未遂事件的测试用例是很困难的，因为专家通常需要手动分析碰撞和未遂事件的原因。

为了解决这些限制，我们提出了一种基于依赖关系的组合方法（DBCA），用于运行环境识别和场景分析的测试套件优化。DBCA利用IPOG这种广泛使用的组合测试算法，为这些运行环境中定义的每个场景生成运行环境和测试用例的两种组合。我们选择组合方法是因为它在测试高度可配置的系统时非常有效和高效，这些系统需要在数千种配置上无失效地运行。由于自动驾驶车辆还需要确保系统在各种运行条件下的安全性，因此我们相信组合方法将是降低其安全分析复杂性的完美解决方案。t路组合中的“t”值是根据生成运行环境和场景实例时考虑的因素之间的依赖关系手动选择的。为了评估我们的方法是否有助于识别和减少验证自动驾驶汽车安全性所需考虑的运行环境和场景实例的数量，我们使用仿真工具Metamoto进行了案例研究。我们的结果表明，与穷举方法相比，我们的方法可以有效减少场景的测试用例数量，而不影响碰撞检测。我们还发现，根据为自动驾驶车辆定义的ODD考虑需要考虑的不同运行环境非常重要，因为我们发现在仿真中通常只考虑有限的ODD，从而错过了潜在的未知场景。请注意，在本文中，我们将分析在车辆级别的行为，并且不讨论基于机器学习安全的验证。

本文的其余部分安排如下。第2节讨论背景和相关工作。第3节解释DBCA方法，第4节讨论实证研究、其结果和威胁。第5节详细介绍DBCA结果和局限性的见解。最后，我们在第6节中进行总结。

2.术语和相关工作

在本节中，我们将讨论整篇文章中使用的各种术语。

1.自我车辆：它是我们进行分析的自主系统。

2.运行设计域（ODD）：它被定义为一组条件，包括环境因素、道路基础设施元素、车辆周围的交通参与者以及设计系统或系统功能的各种驾驶场景。

3.ODD元素：属于ODD一部分的实体或参与者。例如，天气和行人都是ODD元素。每个元素都有相应的值。例如，天气可以有多个值：下雨、下雪和晴天。每个ODD元素和ODD元素的每个值都可以具有关联的属性。例如，当天气下雪时，我们可以拥有降雪量等属性。

4.运行环境：自我车辆运行的环境。它通常包括交通参与者、道路基础设施和环境因素。运行环境是ODD的子集，即对于给定的ODD，我们可以识别许多运行环境。运行环境的一个例子是一条潮湿且直的高速公路，有3条车道，上面有卡车和车辆，自我车辆在其中向前行驶。

5.场景：场景是运行环境中动作和事件的情景的时间序列，其中自我车辆旨在实现工程师定义的目的和目标。在给定的运行环境中，可能会出现多种情况。对于前面讨论的高速公路运行示例，场景可以是本车在没有碰撞的情况下到达目的地B，前车突然制动。请注意，每个场景都可以有多个实例。对于前面讨论的场景示例，我们可以通过考虑引导车辆和自我车辆之间的不同间隔距离以及引导车辆的各种制动力值来生成各种实例。

6.IPOG算法：一种组合测试算法，用于生成参数值的t路组合。与参数总数相比，“t”的值较小。t路组合意味着考虑任何“t”元素之间的所有组合。例如，如果我们有四个参数p1、p2、p3和p4，每个参数有两个值，则参数的2路组合表示考虑每两个参数之间所有可能的值对的组合。在DBCA中，我们使用IPOG算法生成ODD元素的组合和属性的组合来生成场景的实例。

7.功能安全（FuSa）：它是电气和电子组件故障不会导致不合理风险的系统特征。ISO 26262详细介绍了汽车系统功能安全分析的流程。

8.预期功能安全（SOTIF）：与功能安全不同，预期功能安全是指不存在由于系统功能不充分而导致的不合理风险。SOTIF有助于减少未知风险以及需求和设计方面的差距。ISO 21448详细介绍了具有驾驶自动化功能的车辆的SOTIF分析流程。

9.详尽仿真：如果我们在仿真工具中针对给定场景运行各种参数的所有可能组合，称为详尽仿真。这需要大量的时间和资源。

3.方法

基于依赖的组合方法（DBCA）的概述如图1所示。椭圆形代表该方法中的步骤，矩形代表这些步骤的输出，这些输出可以用作下一步的输入。平行四边形代表我们在DBCA中使用的现有组合算法。椭圆中的数字代表步骤编号。每个步骤详细描述如下。

图1：基于依赖关系的组合方法(DBCA)概述

步骤1.定义ODD和依赖关系。作为DBCA的第一步，我们（利益相关者）定义所分析的自动驾驶车辆的ODD。虽然ODD通常是在SOTIF分析期间进行危害分析和风险评估时进行细化的，但在本文中，我们假设ODD已经进行了细化和考虑，我们更专注于识别运行环境和优化测试用例，以验证仿真中的场景。正如第2节中提到的，ODD由ODD元素、它们的值和属性组成。ODD元素包括环境因素（例如天气、一天中的时间）、参与者（例如道路上的周围车辆）、道路基础设施（例如交通标志、区域、路口）以及所分析的自动驾驶车辆的操作，即自我车辆（例如，车辆正在左转）。ODD详细列表的样本可以在BSI:PAS 1883中找到。

每个元素都有相应的值。例如，天气可以具有雨、雪、多云和晴等值。每个ODD元素值都可以有其关联的属性/参数。例如，当ODD元素是天气并且其值为下雨时，我们可以有一个属性，例如雨量。定义ODD元素、它们的值和属性后，我们通过考虑它们的值来识别ODD元素之间的依赖关系。例如，让我们考虑三个ODD元素：天气、路况和一天中的时间。天气会影响路况。例如，未平整的道路在下雨时可能会出现水坑。因此，我们考虑天气和路况之间的依赖性。然而，路况和天气不会影响一天中的时间。因此，我们不认为它们有任何依赖性。我们识别所有此类依赖性以及ODD元素之间不存在依赖性。

在本文中，由于缺乏对最先进技术的自动依赖性识别的支持，我们手动识别依赖性，因为它有助于我们在车辆安全评估期间提供足够的证据和理由，我们的组合方法减少了运行环境和场景测试用例的数量，而不忽略ODD元素之间的任何依赖关系。

步骤2.生成运行环境。在识别出ODD元素之间的依赖关系后，我们找到彼此依赖的ODD元素的最大数量。我们将此最大数标识为“t”，应用于IPOG，这是一种广泛使用的组合测试算法，用于生成ODD元素及其值的t路组合。这些组合代表了潜在的运行环境。

让我们考虑一下我们在上一步中选择的ODD元素的示例。这些因素是天气、路况和一天中的时间。让我们假设每个元素具有以下值：天气-{雨、雪、多云、晴}（4个值），路况-{干燥、潮湿有水坑、潮湿无水坑}（3个值），一天中的时间-{白天、黄昏/黎明、夜晚}（3个值）。对于这个简单的ODD元素集，如果我们计划生成所有可能的组合，我们会得到4×3×3=36个组合。然而，正如上一步中提到的，只有天气和道路状况具有依赖性（例如，下雨天气可能会导致道路潮湿且有水坑）。因此，只要我们能够涵盖天气和路况之间所有可能的组合，我们就会考虑元素之间所有可能的依赖关系。因此，本例中的“t”值为2。当我们生成三个ODD元素的双向组合时，36个组合减少到12个组合。图2说明了组合的减少。从图中可以看出，双路组合不仅涵盖了{天气，路况}之间的所有可能组合，还涵盖了{路况，一天中的时间}和{一天中时间，天气}之间的一切可能组合。

图2.使用组合方法减少ODD元素组合数量的示例

然后，我们检查这些代表运行环境的组合，并检查仿真工具是否具有与所需运行环境相匹配的环境。如果该工具不提供此类环境，我们会要求负责仿真工具的工程师通过分别提供这些环境中需要存在的元素的信息来开发所需的环境。

步骤3.为每个运行环境(OE)生成场景。如上所述，我们将ODD元素的每个组合及其相应的值视为一个运行环境。在给定的运行环境中，可能会发生各种情况。这是因为根据ISO 21448，每个场景都需要定义一个目标或目的。目标的一个例子是“一辆自我车辆在5分钟内从地图上的位置A行驶到位置B，没有任何碰撞。”由于这种方法依赖于工程师的专业知识，因此在我们的方法中，定义目标和目的是手动的。

每个场景可以有多个唯一实例，因为各种属性和参数可以与每个ODD元素相关联。例如，如果我们考虑天气是下雨的，路况是潮湿的，有水坑的，一天中的时间是晚上，那么它们对应的属性可以是降雨量，道路水坑的密度（道路中每平方米水坑的数量），以及PM/AM的时间。请注意，必须根据场景的目的/目标来选择ODD元素的属性。

假设我们的降雨量范围设定为从0厘米到15厘米，增量为1厘米（总共16个值），道路水坑的密度范围为从0到1，增量为0.1（总共11个值），PM/AM 时间范围为晚上7点到凌晨4点，增量为一小时（10个值）。我们还假设我们认为自我车辆以60公里/小时的速度直线行驶。对于这种情况和给定的属性值，运行环境中可能发生的高级场景的可能实例总数为16×11×10=1760个组合。

然而，随着ODD元素的数量、它们的值、它们的属性和属性范围的增加，组合的数量急剧增加。因此，与上一步类似，我们识别ODD元素的属性/参数之间的依赖关系，并识别“p”值，其中“p”是可以相互影响的属性/参数的最大数量。在上面的示例中，降雨量、PM/AM时间和水坑密度彼此不相关。然而，降雨量可能会影响水坑水位。因此，我们可以将‘p’定义为2。当我们为这三个属性生成双路组合时，组合数量从1760个减少到176个。

步骤4.生成仿真测试用例。一旦确定了每个场景需要考虑的各种实例及其相应的目标，就生成测试用例。这是通过使用仿真工具来完成的，我们可以在其中指定属性值、它们的范围和关联的增量。如果不存在这样的功能，则需要手动创建测试用例，或者我们需要编写一个脚本来提供自动化支持来为我们想要评估的各种案例运行仿真。在DBCA方法中，对于之前有176个实例的场景，我们生成相应的176个测试用例。如果场景的目标失败，测试用例就会失败。

步骤5.运行仿真。生成仿真测试用例后，我们在仿真工具中对其进行评估。如果违反定义的目标或存在潜在的崩溃，仿真工具将使测试用例失败。基于这些失效，我们识别碰撞和不良行为的潜在原因，并与包括领域专家和工程师在内的利益相关者讨论相应的解决方案（例如设计修改、功能增强）。

4.实例研究

为了评估DBCA，我们使用基于云的仿真工具Metamoto进行了实证研究，重点关注以下研究问题：

RQ1.DBCA相对于详尽仿真的效率如何？

RQ2.测试用例数量的减少是否会影响DBCA通过详尽仿真识别碰撞根本原因的能力？

4.1 分析对象

为了分析DBCA，我们考虑了ISO 21448中表B.3中列出的用于定义ODD的场景因素列表。该表包含12个ODD元素的值，例如气候（8个值）、一天中的时间（4个值）、道路形状（16个值）、道路特征（8个值）、道路状况（6个值）、照明（5个值）、自我车辆对状况的感知（10个值）、自我车辆的运行（14个值）、周围车辆（14个值）、其他道路参与者（4个值）、周围物体（16个值）、以及道路上的物体（11个值）。元素及其值的列表如表1所示。可以看出，表中的许多值可以进一步细分。例如，对于ODD元素“周围车辆”，我们将“自行车”作为值。然而，自行车本身可以沿着车辆移动、穿过马路，或者沿相反方向但在自行车道上行驶。然而，我们仅考虑ISO 21448中表B.3中定义的值，以限制分析范围。

对于测试用例生成，我们重点关注车辆切入场景（如图3所示），其中引导车辆尝试切入自我车辆（即正在分析的自动驾驶车辆）的路径。我们分析的自我车辆是SAE 2级系统，它具有车道保持辅助和巡航控制功能。我们还考虑了配备摄像头和激光雷达的SAE 4级车辆的城市街道上有乘客的场景。然而，对于4级系统，仿真工具对大多数测试用例都给出了超时错误。经过分析，发现是仿真工具的问题。因此，我们在本文中不讨论SAE 4级车辆的结果。相反，我们关注2级系统。表2显示了我们用于为2级系统生成测试用例的参数列表，以及它们的范围、步长（生成测试用例时我们在两个值之间使用了多少增量）以及我们分别为每个参数考虑的值的总数。

图3：高速公路切入场景中可能出现的切入情况示例

4.2 变量

自变量。自变量是我们用来生成运行环境和场景实例的技术类型。

我们有一种启发式技术和一种控制技术，如下所示。

启发式：我们在研究中使用的启发式技术是我们提出的DBCA方法，该方法使用IPOG，这是一种组合算法，可以减少运行环境的组合数量以及场景的实例。

控制：我们研究中使用的控制技术是具体的技术，其中ODD元素值的所有可能组合都被考虑用于运行环境，并且属性或参数值的所有可能组合被考虑用于生成场景实例。

因变量。RQ1的因变量是创建运行环境所花费的时间和运行仿真实例所花费的时间。RQ2是导致冲突的根本原因的数量。请注意，导致冲突的根本原因数量与检测到的冲突数量不同。例如，让我们考虑一辆自动驾驶汽车，检测到八次碰撞，其中四次是由于传感器读数不正确，四次是由于大雨。在这种情况下，虽然冲突数量为八，但根本原因的数量只有两个。

4.3 实验流程

在我们的研究中，我们利用了先进的软件组合测试(ACTS)工具，该工具使用IPOG来生成组合。为了评估运行环境、创建场景和测试用例，我们使用了专有的仿真工具，该工具在云上运行仿真。

表1：ISO 21448表B.3中的ODD元素及其值

为了进行我们的研究，我们从表1中定义的ODD元素开始。对于详尽的技术，我们计算了运行环境中需要考虑的ODD元素的所有可能组合。同时，我们还确定了12个ODD元素之间的依赖关系。我们考虑了直接依赖性和间接依赖性来确定使用ACTS工具生成ODD元素的t路组合的“t”值。例如，气候会影响自我车辆中传感器的行为，从而影响其对状况的感知，即无法评估自我车辆在其运行环境方面遇到的正确情况。我们认为这是直接依赖。气候也会影响自我车辆的运行，因为它会影响自我车辆对其运行环境状况的感知。因此，我们可以认为气候和自我车辆的运行具有间接依赖性。根据依赖关系，我们决定将t值从2更改为4，以了解运行环境的数量可能存在多大差异。

表2：测试用例考虑的参数

表3：固定参数及其各自的值

运行环境分析完成后，我们进行了场景分析。正如我们之前的研究中提到的，我们重点分析前车试图切入2级自我车辆路径的场景实例。因此，我们考虑了一个满足所需运行环境需求的仿真环境。如果没有运行环境，那么我们应该与仿真工程师讨论并创建相应的环境来运行仿真。我们为仿真场景定义的目标是让自我车辆在不发生碰撞的情况下到达预定位置。由于我们使用的仿真工具有800个作业的限制，即我们一次不能提交超过800个测试用例。因此，我们固定了一些参数的值并改变了其他参数的值。固定参数及其相应的值如表3所示，参数的范围值以及我们用于每个参数的步长和参数值总数如表2所示。我们选择较大的步长是因为我们相信一旦确定了参数的有问题的范围，我们就可以专注于特定的范围并针对有问题的范围使用较小的步长。这为层次分析铺平了道路，而不是进行详尽的分析。从表3可以观察到，前车（自身车辆前方的车辆）的起始距离固定为910，初始引导车辆（场景中所有车辆前方的汽车）的起始距固定为880。任意选择这些值是为了了解如果自我车辆的位置设置为测试用例中引导车辆之前，车辆将如何初始化。我们选择引导车辆和自我车辆的碰撞避免为零，原因如下：（1）由于资源限制和工作限制（可以一次提交的测试用例的数量，在我们的例子中是800）。由于我们已经有一个随机参数“随机车辆数量”，因此为场景实例添加更多随机性，例如将碰撞避免设置为0.5，其中车辆可以以50%的概率（随机选择）碰撞另一辆车，将需要更多的运行才能对结果有足够的信心。(2)通过使本车和引导车的碰撞避免为零，我们可以确定DBCA技术是否可以识别与穷举技术相同的碰撞原因，即使车辆是随机初始化的。

确定参数值后，我们生成了一组详尽的测试用例，以便使用仿真工具进行仿真。对于组合分析，我们使用ACTS工具创建参数值的组合，然后在模拟工具中创建测试用例。对于参数值，我们选择“p”值2来生成p路组合。这是因为唯一具有部分依赖性的参数是道路湿度和道路水坑。然后，我们在模拟工具中运行这些测试用例来识别碰撞情况。请注意，由于参数“车辆随机数”的存在，每个测试用例都存在一定的随机性，因此我们为每种方法运行了10次测试套件。收集测试用例的结果后，我们分析失败的测试用例，以确定碰撞原因，并与利益相关者讨论可能的解决方案和后续步骤。报告的结果是10次模拟迭代结果的平均值。

4.4 结果

RQ1结果。对于RQ1，我们通过详尽的仿真分析了DBCA的效率。对于表1中定义的12个ODD元素，为每种技术创建运行环境所需考虑的组合总数如表4所示。从表中可以看出，穷举技术为运行环境生成了169554739200个组合; 组合的数量明显大于使用DBCA生成的双路、3路或4路组合的数量。每个组合代表一个潜在的运行环境，并且需要手动检查与该组合相对应的环境是否存在于仿真工具中。如果仿真工具中不存在此类环境，则需要手动创建环境，这可能需要几分钟到几天的时间，具体取决于复杂性。因此，我们可以得出结论，与穷举技术相比，DBCA需要更少的工作量。

同样，对于表2中的5个参数值，使用DBCA和穷举方法生成的测试用例数量以及使用仿真工具每次迭代所需的大致时间如表5所示。我们可以观察到DBCA减少了与穷举方法相比，测试用例数量减少了87.5%，并且在云中运行仿真所需的时间减少了约51%。

表4：使用启发式和控制技术为运行环境生成的组合数量

表5：使用启发式和控制技术生成的测试用例数量（表示为TC数量）以及在云中运行这些测试用例所需的时间（表示为 TT）

表6：从使用启发式和控制技术生成的测试用例中发现的碰撞根本原因的数量

RQ2结果。对于RQ2，我们分别分析了DBCA和穷举方法识别的碰撞根本原因的数量。结果如表6所示。虽然我们有63个碰撞案例来自于穷举方法的640个测试案例的结果，而只有10个碰撞案例来自于DBCA的80个测试案例的结果，但两种方法的碰撞保持相同。我们发现，当本车的起始距离为800和1000时，无论其它参数值如何，都会发生碰撞。这是因为前车和本车之间缺乏足够的距离，从而导致碰撞。当自我车辆的起始距离为900时，几乎错过了碰撞，因此测试用例通过。尽管详尽方法报告的碰撞案例数量为63起，但预期数量为80起。由于仿真工具中的固有问题，其余17个被报告为不同类别，其中周围车辆的硬制动违规可能导致测试用例失效，即使它与自身车辆无关。

4.5 有效性的威胁

首先，DBCA或穷举方法生成的组合可以具有可行或不可行的组合。虽然可以通过在生成组合时向工具添加约束来轻松解决这个问题，但分析可行和不可行的组合至关重要，因为它们可能有助于发现未知的安全问题。这有助于按照ISO 21448标准的要求减少未知风险。其次，场景中参与者或车辆的随机初始化可能会影响结果。为了减少随机化的影响，我们使用仿真工具运行每个测试套件10次，并对结果取平均值。第三，我们的结果基于Metamoto仿真工具。因此，它们可能无法推广到其他工业工具或开源工具。尽管如此，我们根据结果提供的见解对于其他用于自动驾驶汽车的仿真工具可能很有用。

5.讨论

根据我们的研究结果，我们发现DBCA方法比详尽的方法减少了在仿真工具中进行分析的工作量和时间。我们还发现，我们可以识别与使用DBCA的具体方法相同数量的碰撞根本原因，从而使其可以可靠地用于生成自动驾驶车辆仿真的测试用例。

DBCA中‘t’和‘p’值的重要性：虽然组合方法被发现是有用的，但只有当我们选择正确的‘t’和‘p’值来生成组合时它才有效。对于软件应用程序的组合测试，发现双路交互可以暴露大约62％至97％的故障，3路交互可以暴露87％至99％的故障，4路交互可以暴露96％的故障到100%的故障。然而，自动驾驶汽车等安全关键且复杂的系统是否属于这种情况还有待验证。

为了确定用于生成ODD元素t路组合的正确“t”值，必须对ODD元素之间的依赖性进行详细分析。缺少依赖关系可能会导致丢失一些重要的组合，从而导致忽略一些运行环境，这可能会增加自动驾驶汽车面临未知风险的机会。类似地，用于生成元素属性的p路组合的“p”值，即用于仿真的参数，必须根据参数之间的依赖关系进行选择。场景所考虑的元素属性之间缺少依赖关系可能会导致缺少关键测试用例，从而忽视安全问题。该领域未来的一个潜在探索方向是研究可找到的碰撞原因的百分比如何随“t”和“p”值的增量而变化，以及所需的“t”值和“p”值是否小于通过分别识别ODD元素之间的依赖关系和场景的属性/参数所定义的值。

对自动驾驶汽车仿真工具的见解：在分析结果的过程中，我们发现在运行仿真之前确保仿真工具正常工作非常重要。我们发现，在我们研究中使用的Metamoto工具中，即使我们专注于识别自我车辆的碰撞，随机初始化的车辆的硬制动违规也会导致测试用例失败。此外，仿真工具不会根据我们定义的运行环境或每个运行环境的场景覆盖率生成ODD元素覆盖率的任何指标。此类指标应被视为仿真工具的一部分。

我们为仿真工具确定的一个主要发现是，随机初始化的车辆对我们的测试用例的结果没有影响。我们进一步分析了结果，以了解为什么结果中有如此意外的行为。我们发现，仿真工具默认假设车辆在初始化时遵循交通规则并保持最小间隔。然而，这应该留给用户，作为指定场景规则或仿真规则的单独机制，因为假设车辆始终遵循规则可能会导致忽略未知场景，从而增加自动驾驶车辆的未知风险。

对行业的实际影响：使用DBCA，汽车工程师和安全分析师可以识别需要创建的各种运行环境，作为仿真的一部分，以便以更少的精力和时间分析自动驾驶汽车的行为。这也有助于简化作为FuSa和SOTIF分析一部分执行的危害和风险评估的复杂性，我们需要考虑车辆可能所处的各种可能场景。同样，DBCA还可以通过以下方式减少运行仿真所需的工作量和时间：优化测试用例的数量，同时确保满足属性/参数之间的所有依赖性。

局限性：尽管DBCA方法有优点，但它也有局限性。首先，识别ODD元素之间以及用于生成场景实例的属性/参数之间的依赖关系是一个手动过程。我们可以通过使用属性关系表自动化该过程并从表中生成推论来解决此限制。另一个限制是我们没有定义任何系统的程序来定义本文中场景的目标或目的。我们计划通过使用推荐系统建议，可用于基于其ODD元素和属性的场景的各种目标和目的来解决这个问题。

6.结论和未来工作

在本文中，我们提出了基于依赖关系的组合方法（DBCA），以减少识别自动驾驶车辆运行环境中的各种运行环境和场景的各种实例的工作量。DBCA利用组合算法IPOG生成ODD元素的t路组合来生成代表运行环境的组合，以及属性（或参数）的p路组合。为场景选择的元素，其中“t”和“p”值分别通过识别ODD元素和元素属性之间的依赖关系来定义。为了评估DBCA方法，我们通过考虑ISO 21448表B.3中列出的ODD元素和高速公路接入场景进行了实证研究，并将DBCA与穷举技术进行了比较，穷举技术生成ODD元素值的所有可能组合，以生成运行环境，以及属性值的所有可能组合，以生成场景的实例。我们发现，DBCA将运行仿真所需的时间显著减少了51%，而不会影响已确定的碰撞原因的数量。

详询“牛小喀”微信：NewCarRen

详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！