内容提要：自动驾驶汽车（AV）有望通过实现灵活的按需移动来提高交通安全和交通效率等。但是需要正式的自动驾驶道路审批程序。为此，我们提出了一种安全评估框架，该框架将标准化功能安全设计方法与基于交通场景的方法相结合。后者涉及使用驾驶数据来提取与AV相关的交通场景。底层方法基于将场景分解为基本事件、随后的场景参数化以及对场景参数的估计概率密度函数进行采样以创建测试场景。生成的测试场景随后用于仿真环境中的仿真测试以及试验场和现实生活中的物理测试。

摘要

自动驾驶汽车（AV）有望通过实现灵活的按需移动来提高交通安全和交通效率等。但是需要正式的自动驾驶道路审批程序。为此，我们提出了一种安全评估框架，该框架将标准化功能安全设计方法与基于交通场景的方法相结合。后者涉及使用驾驶数据来提取与AV相关的交通场景。底层方法基于将场景分解为基本事件、随后的场景参数化以及对场景参数的估计概率密度函数进行采样以创建测试场景。生成的测试场景随后用于仿真环境中的仿真测试以及试验场和现实生活中的物理测试。因此，由于基于仿真的方法，所提出的评估流程在相对较短的时间内为AV性能提供了统计相关的定量测量。最终，拟议的方法为当局提供了自动驾驶汽车的正式道路审批程序。特别是，拟议的方法将支持新加坡陆路交通管理局对自动驾驶汽车的道路审批。

1.简介

自动驾驶汽车（AV）的发展取得了重大进展。自动驾驶和自动驾驶汽车将在受控环境中引入，而自动驾驶汽车将在2040年或更早成为主流。特别是在新加坡等人口稠密的城市，需要自动驾驶汽车通过启用灵活、自动化、按需出行系统、满足公共交通需求的定期服务以及支持24小时运营和劳动力短缺需求的自动化货运和服务车辆，提高交通安全和交通效率。

自动驾驶汽车（AV）开发的一个重要方面是自动驾驶汽车的安全评估。对于自动驾驶汽车的法律和公众接受度来说，系统性能的明确定义非常重要，系统质量的定量衡量也很重要。用于评估驾驶员辅助系统的更传统的方法已不足以评估更高级别自动驾驶汽车的安全性，因为完成这些方法所需的测试数量是不可行的。因此，评估方法的开发对于不延误自动驾驶汽车的部署非常重要。

我们提出了一种自动驾驶汽车安全评估方法，包括功能安全、预期功能安全和行为安全，最终对自动驾驶汽车的安全性进行定性和定量评估。这是通过采用基于交通场景的评估来实现的。通过分析真实世界的驾驶数据获得交通场景，然后验证场景与被测系统的相关性。这些场景用于对被测系统进行虚拟和物理安全验证，最终生成安全报告，为道路审批机构提供有关被测系统安全性能的定量措施。

拟议的评估方法为自动驾驶汽车的道路审批提供了一种有效的程序，因为该评估方法允许根据设计审查、虚拟安全验证以及最后基于所有测试的安全报告做出三种通过/不通过的决定。此外，该方法利用从现实世界驾驶数据得出的测试场景，提供了有关自动驾驶汽车在现实世界交通中安全性能的定量测量。

拟议的方法为当局提供了自动驾驶汽车的正式道路审批程序。特别是，CETRAN将使用拟议的方法来支持新加坡陆路交通管理局对自动驾驶汽车进行道路审批。

文章结构如下，第2节详细介绍了相关汽车安全概念的背景。接下来，第3节描述了拟议的安全评估流程。第4节提供了有关场景生成方法的更多详细信息，第5节总结了主要结论。

2.汽车安全

汽车安全领域非常广泛，其特点是安全类型众多以及安全各个角度的定义。然而，在高抽象级别上，通常区分两种类型的安全，即功能安全和预期功能安全(SOTIF)。第三种安全类型是行为安全，与自动驾驶汽车的行为方式有关。

功能安全、SOTIF和行为安全可以统称为运行安全，如图1所示。该图还提到了最佳实践，即经验和（非标准）指南的使用，由于ISO 26262标准的限制，通常包括这些指南。SOTIF打算解决这些限制。

图1：运行安全

此处介绍的三种安全类型将在下一节中进行简要说明。

2.1 功能安全

IEC 61508中将功能安全定义为不存在因系统故障行为引起的危害而导致的不可接受的风险。ISO/DIS 26262通常称为ISO 26262，是针对汽车行业的IEC 61508的改编版。它适用于安全相关的电气/电子系统，特别是3500公斤以下的道路车辆。

ISO 26262标准于2011年推出，不包括自动驾驶汽车。高级驾驶员辅助系统(ADAS)将包含在2018年发布的ISO 26262版本中。ISO 26262中定义了功能安全的概念如下。

定义1（功能安全）。功能安全是指不存在因电气/电子系统故障行为引起的危害而导致的不合理风险。

根据这个定义，功能安全是“向内看”，重点关注车辆的故障部件。根据ISO 26262实现功能安全系统设计必须遵循的流程，即所谓的“安全生命周期”，如图2所示。在AV安全评估的范围内，本生命周期中包含的验证过程尤其相关；这些内容简要总结如下。

3-7危害分析和风险评估(HARA)—HARA是一种识别和分类危害事件、指定安全目标以及为系统组件分配汽车安全完整性等级(ASIL)的方法，与预防或减轻相关危害有关，以避免不合理的风险。

图2：ISO 26262安全生命周期

3-8功能安全概念——这涉及实现所需安全行为所必需的功能及其交互的规范。因此，这是设计中的一个步骤，而不是一个以评估为导向的活动。然而，功能安全概念的审查当然应该成为自动驾驶安全评估框架的一部分。请注意，此处省略了技术安全概念，因为这通常是产品开发的一部分。

4-9安全验证——安全验证在车辆层面检查安全目标是否实现。这是通过仿真和物理测试来完成的，代表“预期用例”，即在AV的设想运行环境中发生的交通场景。

上述列表中的关键概念是安全验证，事实上，这是下一节中提出的评估框架的最终目标。在ISO 26262中，该概念定义如下。

定义2（安全验证）。安全验证是基于检查和测试来保证安全目标是充分的并且已经实现。

当采用选定的生命周期主题时，第一步是从功能安全的角度制定自动驾驶汽车的安全评估流程；

图3：受ISO 26262启发的功能安全评估步骤

图3中对此进行了可视化，其中场景生成组件未包含在原始ISO流程中，旨在生成相关交通场景（无论是否作为总体“用例”的一部分）。

总之，可以得出结论，ISO 26262标准面向开发某种自动化功能，作为实施验证和确认流程的一部分。然而，评估框架的目标不是设计安全的自动驾驶汽车，而是评估给定设计的安全性。因此，图3中的流程在术语和内容上都需要进一步调整，以更好地适应这一目标。

2.2 预期功能的安全性 (SOTIF)

如前所述，功能安全是“内向型”，因为它关注的是车辆自动化系统的故障组件。然而，对于自动驾驶汽车来说，“向外看”也很重要，即在安全评估框架中纳入固有的传感器和感知系统限制，并考虑自动驾驶汽车的决策能力。AV安全的这些方面包含在预期功能的安全概念（SOTIF）中。

SOTIF涉及非故障引起的危害行为。特别是对于AV，SOTIF通常与环境感知相关，因为环境传感器通常具有固有的局限性，这可能会导致AV行为不安全。这种限制的例子包括雷达测量中所谓的“重影”的出现，或者相机系统中直射阳光的致盲效应。ISO 21448中描述了这种类型的安全性。该标准将SOTIF从广义上定义为“预期功能不存在不合理风险”。在评估框架的范围内，将采用更精确的定义，如下所示。

定义3（预期功能的安全性）。预期功能的安全性(SOTIF)是自动化系统正确理解环境情况并安全运行的能力，方法是确保系统和组件在其设计范围内运行，如果不在其设计范围内，则启动适当的对策。

图4：安全评估流程概要

2.3 行为安全

除了SOTIF之外，Waymo的一份报告将行为安全的概念引入为“系统安全的一个方面，重点关注系统应如何在其环境中正常运行，以避免危害并降低事故风险：例如，检测物体并以安全的方式做出反应（减速、停车、转弯、变道等）。” 因此，这种类型的安全性解决了开发人员有意编程的自动驾驶行为，车辆自动化系统的所有组件和子系统都按预期运行。例如，与此相关的一个问题是自动驾驶汽车是否遵守交通规则。由于此类安全是否会成为ISO 21448最终版本的一部分尚存疑问，因此行为安全被视为第三种安全。

UN-ECE自动转向功能小组起草的UN-ECE第79条的修正案，该条例描述了3级自动驾驶系统的预期行为。然而，范围仅限于结构良好且受控的高速公路，其中没有行人/自行车，行驶方向至少有两条车道，并且逆流交通之间有物理隔离。作者不知道现有技术描述了在复杂城市环境中运行的4级自动驾驶系统的行为安全要求，因此本研究旨在利用新加坡道路交通规则的背景，为车辆所需的行为特征提供一些定义和交通环境作为案例研究。所提出的评估方法利用交通场景来评估自动驾驶汽车的行为安全性。第3节中描述的安全评估流程阐述了如何通过设计审查练习，以及通过获取真实驾驶数据生成场景来定义场景。接下来，使用这些场景通过虚拟和物理安全验证来评估自动驾驶汽车的行为性能。

3.安全评估流程

图4示意性地概述了拟议的AV安全评估方法。该图显示了评估流程，该流程由八个步骤（或“组件”）组成，如下所述。

1.设计审查——在AV开发过程中，AV开发人员必须根据ISO 26262功能安全标准创建所谓的安全档案，该档案提供了有关AV自动化系统安全措施的广泛信息。该安全档案在评估流程范围内有两个目的。首先，安全档案文件中包含的信息可以对自动驾驶汽车的功能安全进行定性评估，并据此做出是否继续安全评估过程的决定。其次，设计审查还可以深入了解对自动驾驶汽车或自动化系统组件可能特别具有挑战性的测试场景，这些组件在发生失效时会构成威胁（例如“单点失效”）。反过来，这些知识有助于定义和选择评估流程中场景验证组件的仿真测试场景。

2.数据采集——该组件旨在获取真实世界的驾驶数据，最终提供一组与自动驾驶汽车相关的统计上准确的交通场景。理想情况下，驾驶数据应该由自动驾驶汽车获取，因为在自动驾驶汽车存在的情况下，人工交通的行为可能会有所不同，但这在自动驾驶汽车部署的早期阶段是不可行的。除其他外，这些数据包括自车数据和其他交通参与者的物理级数据。数据采集涉及将收集到的数据转换为标准化格式，以便顺利过渡到流程的下一步，还包括数据验证和“清理”（例如，去除异常值）。

3.场景生成——在此步骤中，根据获取的数据生成候选测试场景，以对AV性能进行虚拟评估。为此，测量的场景被分解为基本的“事件”和“活动”，从而实现场景数据的参数化。接下来，利用足够量的测量数据，估计场景参数的概率分布。从这些概率分布中，可以对参数集进行采样，通过重新创建原始场景的变体来获得用于虚拟测试的候选流量场景。这里，安全关键测试场景是通过参数采样生成的，参数采样偏向安全关键场景，即概率分布的尾部。

4.场景验证——场景验证涉及通过仅保留那些被归类为对于特定被测AV安全至关重要的场景，来减少候选测试场景的数量。该组件将场景生成和设计审查组件的结果作为输入，同时还考虑到所谓的“预期功能的安全性”（SOTIF）和行为安全。另一方面，根据功能安全考虑，通过引入涉及组件失效的额外测试，将增加测试场景的数量。因此，该组件的最终结果是一组明确的测试场景，当自动驾驶汽车接受这些测试场景时，它提供了有关自动驾驶汽车运行安全各个方面的定量信息。

5.虚拟安全验证——流程的下一个组成部分涉及通过仿真选定的测试场景来定量评估自动驾驶汽车的安全性，采用能够模拟自动驾驶汽车、其感知和控制软件、其他道路使用者以及静态环境的高保真仿真环境。仿真结果通过关键绩效指标（KPI）进行定量评估。这些KPI受到通过/失败阈值的影响，根据该阈值可以客观地决定是否继续进行下一步的评估过程。

6.物理安全验证——评估流程的这个组成部分旨在通过实际测试验证AV性能，采用根据KPI制定的功能安全和SOTIF要求。物理安全验证的第一个方面涉及选择虚拟测试场景的子集来执行物理测试，其中包括在测试轨道上使用自动驾驶汽车进行测试以及在相关现实情况下进行现场测试。安全验证组件中，通过具有通过/失败标准的KPI对AV安全性能进行定量评估，从而为批准在预期运行环境中部署AV提供客观基础。

7.安全报告——在此步骤中，向相关当局和反病毒开发者提供全面的定性判断，反映总体情况，以及定量判断，呈现先前评估步骤的KPI值。此外，还向有关当局提供了有关自动驾驶汽车道路批准的正式建议。

8.监控部署——成功完成前一个部分后，自动驾驶汽车可以在公共道路上行驶，可能仅限于某些区域和/或某些条件。在此部署阶段，自动驾驶开发人员需要以近乎实时的方式上传驾驶数据，以监控自动驾驶行为。这样做有两个原因。首先，在评估管道完成后，道路当局需要能够持续监控安全。其次，上传的数据经过匿名处理后反馈给数据采集组件。数据采集组件可以不断扩展和完善场景数据库，同时也能够适应个人移动设备等新型交通。

备注1.请注意，设计审查和虚拟安全验证包括经通过/失败标准对AV安全级别进行评级，根据该标准，流程过程将继续或停止。图4中通过相应块的红色实线边框表示了这一点。事实上，物理安全验证还包括通过/失败评级，但结果只会作为程序的最后一步在安全报告中发布。

4.场景生成

场景生成组件的目标是为仿真测试和物理测试生成候选交通场景，最终目标是客观且可重复地评估自动驾驶汽车的运行安全性。场景生成基于道路交通的统一本体，其中道路交通场景是一个重要概念，在接下来的两小节中将进一步解释。

4.1 场景

基于场景的方法是评估方法的关键属性，这就是为什么首先提出场景概念的定义。提出了自动驾驶背景下场景概念的几种定义。我们采用了De Gelder等人的定义，因为它更适用于本文的上下文。场景的定义如下。

定义4（场景）。场景是对自车、其活动和/或目标、其静态环境及其动态环境的定量描述。从自我车辆的角度来看，它包含所有相关事件。

请注意，该定义与Geyer、Ulbrich和Elrofai等人的定义密切相关。定义4与这些现有定义的不同之处在于它明确指出场景是一种定量描述。类似的（定量）场景可以通过定性描述来抽象，称为场景类。因此，场景类包含多个场景。

为了以结构化方式存储测量场景，以便以后可以轻松检索它们以生成测试场景，建议建立与上述道路交通本体相对应的分层标签系统。因此，标签根据天气、道路类型和目标车辆操纵等提供场景的语义分类。根据分层方法，标签被排列成树，如图5所示。该图显示了三个示例，分别与天气类型、道路类型和目标车辆操纵相关。同一层中的标签是互斥的，而树的不同层代表不同的抽象级别。

4.2 事件

场景可以分解为基本构建块，即所谓的事件和活动。事件定义如下。

定义5（事件）。事件标记了模式转换发生的时刻，因此在事件之前和之后，状态对应于两种不同的模式。

(a)天气条件标签

(b)道路类型标签

(c)目标操作标签

图5：关于(a)天气类型、(b)道路类型和(c)目标操作的标签分层结构（“树”）示例

模式转换可能是由输入信号、参数或状态的突然变化引起的。例如，踩下制动踏板可能会导致模式转换，因此，这可以被视为事件。事件间时间间隔，即两个连续事件之间的时间段，以某种活动的发生为特征。例如，当在这样的事件间时间间隔期间纵向加速度为负时，该活动对应于制动。

一般来说，一个场景包含多个事件和活动，其时间属性使得可以区分并行活动和串行活动。作为示例，图6显示了两个连续场景，其中自我车辆（红色车辆）被旅行车超越（第一个场景），之后自我车辆超越皮卡（第二个场景）。图7显示了本例的活动和事件，其中三个参与者的行为以纵向和横向行为的许多系列活动为特征。因此，事件和活动与行动者有关。

将场景分解为基本事件和（事件间）活动的优点有三个：

图6：两个连续交通场景的示意图。轿车（红色车辆）被定义为自我车辆。首先，旅行车（(a)中的最后一辆车）超过了两辆车。接下来，自我车辆超越皮卡车（(a)中的第一辆车）

1.尽管随着时间的推移，相关场景的数量可能会变得非常大，但预计只会获得一组有限的本质上不同的活动，这是车辆可以执行的动作数量相当有限的直接结果（基本上改变了速度和方向）。

2.在分析测量数据以提取场景时，事件有助于自动场景识别。同样，现实生活中的事件可以由自我车辆直接检测到，从而为数据记录提供触发。

3.将场景分解为多个活动允许场景参数化，这反过来又能够估计参数的（可能是多元的）概率密度函数（PDF）。然后可以以特定方式对该PDF进行采样，例如，强调安全关键情景或生成测量数据中实际未遇到的活动。此外，从PDF中采样可以从参数集中自动采样那些被测车辆表现出安全关键行为的情况，而无需先验地了解哪些场景对车辆至关重要。换句话说，场景参数化可以系统地生成候选测试场景，以对被测车辆进行安全评估。

4.3 场景生成主题

介绍了场景、事件和活动的概念后，评估流程的场景生成组件现在可以根据下面的不同主题进行描述，为第3节中的简要描述添加更多细节。

1.事件检测——这涉及在测量数据的离线分析期间或在数据收集期间实时地自动检测事件。由于事件间时间间隔与活动相关，因此事件的检测自动导致事件间活动的检测。

图7：场景分解为并行和串行活动的示例。垂直线代表事件。t = 16 s处的红色垂直线表示第一个场景的结束和第二个场景的开始

2.活动参数化——接下来，检测到的活动将被参数化，并估计参数的PDF。

3.场景挖掘——接下来，根据检测到的活动和事件中的某些“模式”，将它们聚类成完整的场景。本主题还包括场景标记。

4.测试场景生成——最后，可以通过使用标记系统选择感兴趣的场景类来生成（候选）测试场景，并通过从活动参数的概率分布中抽取样本来生成这些场景类的实例。这里，“场景类的实例”是定量的场景描述。如第4.2节所述，采样偏向概率分布的尾部，代表最极端和/或罕见的情况。

5.结论

人口密集的城市对自动驾驶汽车（AV）的需求，将需要道路审批机构制定评估方法。因此，我们提出了自动驾驶汽车安全评估的评估方法，包括功能安全、预期功能的安全和行为安全。最终，对自动驾驶汽车在现实交通中运行时的安全性进行定性和定量评估。

所提出的方法采用基于场景的评估，使用现实世界的数据来使用场景数据库，其中包含自动驾驶汽车在现实生活中运行时可能遇到的场景。除了对AV进行定性评估（即设计审查）之外，还使用虚拟和物理安全验证场景进行定量评估。通过监控AV的部署，获取新数据，可用于场景数据库的持续扩展和改进。

最终，拟议的方法为当局提供了自动驾驶汽车的正式道路审批程序。特别是，拟议的方法将用于支持新加坡陆路交通管理局对自动驾驶汽车的道路审批。

详询“牛小喀”微信：NewCarRen

详询“牛小喀”微信：NewCarRen

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