自动驾驶汽车功能安全评估方法

本文主要研究AV的一个特定自动化级别，即SAE L4。J3016B定义了六个级别的驾驶自动化，从无自动化（SAE L0）到全自动化（SAE L5）。在L4，AV是完全自主的，但仅限于给定的ODD。如果需要，AV会执行回退响应，在没有人为干预的情况下达到安全状态。J3016B将安全状态定义为：“当给定的行程不能或不应该完成时，用户或ADS（自动驾驶系统）在执行DDT（动态驾驶任务）回退后可以将车辆带入的状态，以降低发生碰撞的风险”。

1.2研究问题

我们解决了荷兰高速公路环境中SAE L4 AV功能安全的两个方面，重点是基于人工智能的传感和感知子系统。第一个方面涉及FSR的引出和适当的回退行为。第二个方面侧重于功能安全评估。研究问题具体如下：

RQ1：在荷兰高速公路环境中，SAE L4自动驾驶汽车的安全系统应满足哪些功能安全需求，涉及基于人工智能的传感和感知子系统的故障和功能效率不足？为了回答RQ1，我们遵循ISO 26262和SOTIF安全标准中概述的FSR安全流程。安全需求是针对荷兰高速公路ODD运行条件下基于人工智能的传感和感知子系统的故障和功能效率而得出的。

RQ2：如何评估SAE L4自动驾驶汽车在基于人工智能的传感和感知子系统中的故障和功能缺陷方面的功能安全性？为了回答RQ2，我们从两个层面进行评估；设计层面和实施层面。设计评估通过检查AV设计中是否采用了安全相关的架构策略和人工智能安全相关的最佳实践来调查可行性研究报告的完整性。在实施层面，我们考虑采用基于模拟的测试方法来评估可行性研究报告的完整性。基于仿真的测试对于AV测试和验证非常重要，因为它为大规模测试提供了一种安全、可重复和低成本的解决方案。西门子拥有与基于仿真的自动驾驶汽车测试相关的专业知识和产品，例如Simcenter PreScan。因此，西门子有兴趣研究基于仿真的功能安全评估测试方法。

RQ2的活动理想情况下需要一个工业级、成熟的AV软件栈，而西门子或TU/e内部没有这种软件栈。因此，在比较了三种流行的开源工业级AV软件栈后；（i）汽车软件。汽车，（ii）汽车软件。AI和（iii）Apollo，我们选择了Apollo来进行这个项目。Auto专为自动代客泊车的特定用例而设计，而Autoware。人工智能很快就要走到尽头了。Apollo没有这样的限制。此外，软件栈有良好的支持文档和活跃的开源社区。

1.3文章提纲

第2章回顾了自动驾驶汽车安全系统的实践现状和新技术。本章还探讨了基于人工智能的AV传感和感知子系统的验证和确认（V&V）方法的新进展。

第3章定义了荷兰公路环境的ODD。还介绍了AV的功能概念和Apollo软件栈的功能架构。本章中的规定进一步用于RQ1中FSR的推导和RQ2中功能安全的评估。

第4章描述了荷兰公路ODD可行性研究报告的启发，回答了RQ1。FSR是根据ISO 26262和SOTIF标准中概述的安全过程得出的，涉及AV传感和感知组件的故障。引发的FSR是为了Apollo的安全而制定的。

第5章介绍了评估Apollo功能安全性的方法和结果，回答了RQ2。通过检查Apollo设计中安全策略和人工智能安全相关最佳实践的使用情况，首先在设计层面评估可行性研究报告的完整性。然后通过基于模拟的测试在实施层面评估可行性研究报告的完整性。

第6章介绍了结论和未来的工作。

本章介绍了我们研究活动的相关工作。第2.1节回顾了高度自动驾驶汽车安全系统的实践状态和最新技术。第2.2节随后探讨了基于人工智能的AV传感和感知子系统的验证和确认方法的最新进展。

2.1 高度自动驾驶汽车的安全系统

我们回顾了为SAE自动化级别3及以上的高度自动驾驶汽车设计的安全系统的实践状态和最新技术。尽管AV制造商没有披露安全系统的详细信息，但会检查公开的安全报告和出版物，以了解实践情况。最先进的技术更为广泛，我们根据驾驶员的参与程度和安全系统提供的回退响应类型对其进行分类。

2.1.1 实践状况

我们审查了自动驾驶汽车制造商Waymo和通用汽车（GM）的公共安全报告。

两家制造商都在公共道路上测试了他们的系统，因此被认为采用了适当的安全系统。制造商强调“设计安全”的重要性，将安全纳入每个开发阶段。

Waymo和通用汽车自动驾驶汽车的安全机制包括安全关键硬件组件的冗余，包括传感器、执行器、网络、电力系统和计算。由于个体模式的局限性，环境传感和定位方法的多样性也得到了强调。此外，还提供了一个独立的碰撞检测和避免系统作为主要功能的备份。在操作过程中，系统状态会被持续监测，以检测组件中的故障。通用汽车公司有一个车辆健康监测模块，用于管理所有AV部件的诊断。Waymo表示，该车辆“每秒运行数千次检查，寻找故障”。此外，自动驾驶汽车会自动检测可能无法安全处理的情况，例如其ODD之外的环境条件。在这种故障或复杂情况下，车辆会切换到降级运行，或执行故障安全操作并停用车辆。

出版物《Safety first for automated driving》（SFAD）总结了自动驾驶汽车的安全设计方法。该出版物是由主要原始设备制造商、分层供应商和视听技术提供商合作出版的。它系统地将安全原则转化为必要的AV能力、组件和架构。安全原则来自ISO 26262和SOTIF标准以及其他来源。

SFAD中确定了AV的两个关键安全相关能力。首先是确定何时无法实现AV的标称运行。强调了影响标称运行的几个因素，包括技术限制（功能效率不足）、系统性和随机性故障（故障）以及人为误用。第二种能力是对标称操作失败做出响应，以确保安全不受影响。例如，在发生故障时，AV可能会将其操作降级到较低的行驶速度。提出了一种包含这些功能的通用功能架构。检测故障的监控功能被包括为“子元素[嵌入组件中]或作为单独的元素[组件]”。监控功能检测组件或系统级别的标称性能不足。协调组件在标称和降级运行模式之间切换。

2.1.2 最新技术

使用谷歌学者搜索，使用以下搜索字符串确定自动驾驶汽车安全系统的最新技术：（26262 OR“功能安全”），（21448 OR SOTIF），（故障运行或“降级”或故障安全或故障降级或跛行或“容错”）

我们首先讨论安全系统，该系统将驾驶员参与视为后备响应的一部分。

接下来，讨论了在没有驾驶员干预的情况下实现回退响应的安全系统。在这里，我们区分了实现故障安全响应的系统和包括降级运行模式的系统。故障安全响应会在短时间内将车辆转换为自动驾驶汽车可以安全停用的状态。相反，在降级运行中，AV可能会在有限的时间内继续在某些限制下运行。所有类型的安全系统都应包括对妨碍安全操作的情况的监测和检测，例如AV组件中的故障。

对于SAE L3 AV，可以考虑驾驶员参与回退响应。根据J3016b标准，一旦SAE 3 AV识别出需要回退响应的情况，它就有两个额外的职责。首先，它必须警告驾驶员接管车辆的控制权。然后，自动驾驶汽车必须保持安全运行几秒钟，以便驾驶员有足够的时间接管车辆控制。

Otsuka等人提出了监测器/执行器对，用于检测传感、感知和规划组件的随机和系统失效，如图2.1所示。发生失效时，会发出警告，要求驾驶员接管车辆控制。为了在失效后维持安全运行，直到驾驶员接管，安全轨迹↵如图所示，提出了缓冲组件。该组件存储了几秒钟长的自我车辆轨迹，该轨迹是在考虑其他道路使用者的预测未来状态的情况下计算出来的。然而，Otsuka等人没有考虑到与人类自动化交互相关的挑战，导致驾驶员可能不会对发出的接管警告做出反应的情况]。Horwick等人提出，如果驾驶员对接管警告没有反应，则应过渡到安全状态。考虑的安全状态是“在无危险的地方停车或低速行驶”。Horwick等人考虑了其安全系统的几种故障类型，如驾驶员误用、部件失效、不可信的车辆行为以及AVODD之外的情况。

图2.1：Otsuka等人为SAE L3 AV提出的架构。相对信息控制和轨迹验证分别是感知和规划子系统的监视器。选择器组件选择是使用标称轨迹还是安全轨迹进行驱动

根据J3016b标准，SAE L4+AV必须能够在没有驾驶员干预的情况下自行转换到安全状态。在这里，我们介绍能够提供这种安全响应的安全系统。我们首先描述了以故障安全状态为目标的系统，然后涵盖了包括降级运行在内的系统。Novickis等人提出了SAE L4+AV的功能架构及其实现，其中包括在严重故障时的紧急制动。分别通过传感器数据监测和心跳安全机制检测传感器和标称逻辑控制器的关键故障。研究人员提出了一种安全系统，该系统能够使车辆更缓慢地停止。所提出的架构包括一个观察器组件，用于评估计划的AV轨迹相对于其环境的安全性。每个时间步的计划AV轨迹包括一个逐渐停止，存储在安全轨迹中缓冲组件，类似于Otsuka 等人的安全系统。如果计划的轨迹被认为是不安全的，则安全轨迹中的轨迹缓冲部件使车辆停止。作者声称，所提出的设计能够实现故障安全操作，而无需在感知和规划组件中进行昂贵的冗余。然而，作者指出，安全轨迹缓冲考虑到其他道路使用者行为预测的挑战，仅适用于低速设置。

据观察，为复杂的故障安全运行（如路边停车）提出的架构由用于标称功能和故障安全功能的单独通道组成。Torngren等人提出了一种具有标称和安全通道的功能架构，如图2.2所示。安全通道包含两个逻辑回路，一个用于故障检测，另一个用于将AV转换为安全状态。作者考虑了两种故障类型：硬件故障和系统失效。它们还表明了通过安全通道检测性能限制的可能性。Ishigaoka等人提出了一种基于具有诊断模式的二选一系统的架构，该架构具有一级和二级控制逻辑。对每个控制输出进行运行时监控，以检测控制器失效。

图2.2：Torngren等人提出的L3+AV架构。箭头和红色块分别表示数据流和功能组件。安全通道称为监督通道（Sc）

Luo等人受安全执行模式的启发，提出了一种3通道安全架构模式。该模式包括：（i）标称通道，（ii）故障检测专用通道，以及（iii）负责过渡到安全状态的安全通道。该模式涵盖了随机硬件故障的检测，以及标称和安全通道之间交叉检查中的冲突，这些冲突可能表明其他故障。Fu等人还提出了一种模式，该模式支持多种故障安全模式，例如路边停车、逐渐停车，以及在安全部件本身发生故障时的降级运行模式。涵盖了控制器、安全监视器、网络、传感器中的故障以及外部ODD条件的检测。Fu等人基于他们的模式提出的架构如图2.3所示。

图2.3：Fu等人基于他们提出的L3+AV安全模式提出的架构。安全传感器和安全控制器专门用于回退操作

之前讨论的几个安全系统建议使用简化的安全通道作为标称功能的次要通道。相比之下，Fruehling等人声称，由简化的机器人算法组成的安全通道在“许多可能的情况下”无法实现复杂的故障安全策略，尽管没有提供此类情况的示例。此外，他们建议在安全通道中使用人工智能（AI）组件。所提出的架构由一个主控制器和一个辅助控制器组成，每个控制器都包含两个基于人工智能（AI）的数据处理和控制单元。在每个基于人工智能的单元内，通过本地诊断/预测监测对单个组件输出进行验证。这两个基于人工智能的单元也在进行“连续结果比较”，两个控制器也是如此。

最后，我们讨论了最先进的安全系统，这些系统使AV在故障时能够在车辆功能退化的情况下安全地继续运行。Colwell等人建议在运行时限制运行设计域（ODD）以应对失效。该安全策略将失效映射到ODD上的相应限制。例如，如果AV上的右雷达发生失效，则T交叉口的左转将被排除在ODD之外。随后，AV将其功能修改为受限ODD（ROD）。涵盖的失效类型包括硬件、软件组件失效或性能限制，例如，由于激光雷达扫描中的雪干扰而可能出现的失效。Reschka等人还提出了功能退化，包括修改驾驶参数，如车速，或限制某些驾驶操作，如变道操作。如图2.4所示，退化概念基于系统健康状态（心跳、软件循环时间、硬件模块）或当前传感器视野等性能标准。Colwell等人和Reschka等人的安全系统都包括故障安全措施，如果无法进行降级运行。

图2.4：Reschka等人为其研究原型AV提出的降级功能概念。未提及目标自动化水平

Molina等人旨在使安全模块完全独立于标称功能。安全模块检测标称功能中的故障，并监测系统变量，如行驶速度，以检查异常行为。出现问题时，安全模块会强制车辆进入降级状态，例如降低行驶速度。表2.1总结了最先进的安全系统。在这里，我们介绍：（1）作者提到的SAE自动化水平，（2）涵盖的故障类型，以及（3）回退响应（安全状态）。我们注意到，许多最先进的安全系统不是为特定的ODD设计的。

表2.1：各类已提出的安全系统。表中SAE自动驾驶等级均为各文献作者原文标注

对拟议安全系统的评估也不考虑ODD。Colwell和Ishigaoka等人进行了概念验证研究。Colwell等人测试失效场景，例如前置摄像头受损，并进行概念验证。Ishigaoka等人对一个简单的室内轨道进行了案例研究，也通过注入故障。Fu等人使用正式验证来满足安全需求，例如：“必要时，AV成功转换到降级或紧急模式”。许多最先进的系统根本没有经过评估。

2.2基于人工智能的传感和感知子系统的V&V方法

我们通过使用以下搜索字符串从谷歌学者那里检索二级研究，确定了基于人工智能的传感和感知子系统的V&V方法的相关工作：（“神经网络”或“机器学习”或“深度学习”或”人工智能”）和（26262或21448）以及（验证或确认）和（“系统文献综述”或“系统综述”）确定了8篇相关综述文章；五个专门针对自动驾驶汽车的V&V，三个与跨领域基于人工智能的安全关键系统的V＆V有关。我们的审查范围仅限于与两项汽车安全标准相关的传感和感知子系统的AI安全V&V，即ISO 26262涵盖的故障和SOTIF涵盖的ODD条件下的功能效率不足。我们没有解决人工智能组件相对于其他挑战的安全性问题，例如可解释性、透明度和对抗性示例的鲁棒性。

此外，我们的目标是确定可能适用于虚拟世界仿真测试环境的V&V方法。这些方法对于通过基于模拟的测试方法评估功能安全非常有趣，这是我们回答RQ2的目标的一部分。因此，基于这些考虑，我们从综述文章中提取了初步研究。以下各小节描述了我们的发现。第2.2.1节描述并分类了研究中模拟的测试条件。第2.2.2节随后讨论了相应的安全评估。

2.2.1试验条件

用于测试AV基于人工智能的传感和感知子系统的模拟条件是：（1）故障，（2）环境条件，（3）图像转换，以及（4）传感器噪声。故障可能会在基于AI的组件的输入端、神经网络（NN）内或组件的输出端注入。Jha等人在原始传感器数据级别（输入数据）和神经网络内注入与损坏变量相关的故障（单比特或多位故障）。它们还模拟了基于人工智能的物体感知组件的错误输出，例如误报检测。Chen等人模拟了导致神经网络内比特漂移的硬件瞬态故障。Rubaiyat等人为基于AI的对象感知组件输出注入了两种类型的故障：输出的随机添加或断开的组件（无输出）。

Rubaiyat、Zhang和Tian等人研究了包括雨、雾和雪在内的环境条件。Rubaiyat和Tian等人还分析了图像变换（输入数据）的影响，包括对比度、亮度、模糊、平移、旋转。最后，Rao等人确定传感器噪声通过失效模式和对物体检测性能有重要影响安全分析。这种类型的噪声可能是由于相机传感器的软件或硬件失效而发生的。图2.5总结了研究中模拟的测试条件。

图2.5：AI安全V&V方法：测试条件

2.2.2安全评估

一些研究直接在真实世界的图像数据集上进行测试，或者从原始图像数据集中合成测试条件。虚拟世界仿真仅由Jha和Rubaiyat等人使用。Rubaiyats等人也为其视觉模块使用图像数据集，但在OpenPilot PC仿真环境中评估被测系统Comma.ai OpenPilot。Jha等人利用了流行的开源仿真环境Carla，以及Nvidia的专有仿真环境。

表2.2：人工智能安全验证与确认（V&V）方法：测试对象与测试判定标准

表2.2总结了研究的评估设置。一些研究在AV的子系统级别进行安全评估，仅测试目标检测功能或神经网络模型本身。在这种情况下，使用的测试标准与神经网络性能直接相关，如误分类率或精确度和召回率。在系统级进行安全评估的研究中，受试对象多种多样，包括自动驾驶汽车的端到端神经网络转向模型、高级驾驶辅助系统（ADAS）和完整的自动驾驶软件栈。对于端到端神经网络模型，使用的测试标准包括输出中违反变质关系或与地面真值输出的偏差。最后，对ADAS和自动驾驶汽车进行的研究使用了车辆级标准，如违反安全距离或其他危害行为。

本章介绍了AV的ODD和功能表示。第3.1节规定了荷兰公路运行设计域（ODD），代表了自动驾驶汽车应安全运行的驾驶条件。第3.2节介绍了功能概念，对ODD中的AV运行进行了功能描述。第3.3节描述了所选AV软件栈Apollo的功能架构，并详细介绍了其传感和感知组件。最后，第3.4节通过描述功能架构中如何实现功能概念来统一这两种表示。

本章开发的ODD和功能表示用于第4章功能安全需求的推导和第5章功能安全的评估。

3.1 运行设计域（ODD）

ODD定义对于AV的功能安全非常重要，因为它明确描述了AV可以安全运行的运行条件。现实世界运行自动驾驶汽车的状况包含许多变量，如天气状况、道路基础设施和交通状况。ODD识别支持的条件，例如，AV只能在晴朗的天气条件下运行。它还捕获了AV运行所需的条件，如清晰的车道标记或GPS信号的可用性。美国交通部（DOT）等监管机构建议对自动驾驶汽车进行评估、测试和验证，以明确界定部署前的ODD。为了正确定义ODD，我们根据两份文件进行定义。SAE自动驾驶汽车安全联盟（AVSC）的一份文件概述了ODD定义框架和方法的最佳实践。第二份文件来自美国国家公路交通安全管理局（NHTSA），其中提出了定义ODD的属性分类。

这些文件以互补的方式使用；遵循AVSC文件中的方法来描述NHTSA文件中的属性分类。ODD由自下而上的方法定义，从自动驾驶汽车的运行路线开始。与ODD相关的其他变量可以定义为：

• 描述已识别的路线或道路网络，例如十字路口的类型或道路使用者的类型。

• 识别不属于ODD的运行限制，例如极端天气条件或一天中的特定时间，如早高峰。

我们为ODD选择的路线如图3.1所示。该路线对应于A270公路，该公路是荷兰北布拉班特埃因霍温市和赫尔蒙德市之间公路的一部分。它的跨度为3.4公里。

图3.1：荷兰A270公路。地图上的绿色和红色标记分别对应路线的埃因霍温和赫尔蒙德终点

路线的大部分属性可以从地图、谷歌街景和荷兰当局的指南中推断出来。A270公路基础设施在限速、车道类型和数量等属性上并不统一。A270公路车道示意图的一部分如图3.2所示。北布拉班特地区的天气状况包括降雨、降雪、雨夹雪、风和雾。该地区的温度被描述为-15至40摄氏度之间的保守范围。最后，ODD内也可能因事故或施工而发生交通条件的变化。

关于路线特征的设定，我们做了以下几点前提假设：

· 本次研究的自动驾驶车辆不搭载车联网连接功能，因此除GPS信号相关特性外，其余和联网相关的属性都不纳入考量。

· 由于缺少对应信息，我们默认路线中不存在“干扰区”和“负向障碍物”。干扰区指的是GPS信号可能被遮挡的区域；负向障碍物指沟渠、坑洼这类可能引发系统误检测的道路基础设施。要精准刻画这两类属性，必须开展专项道路测试。

· 除雾气之外，其余形式的颗粒物影响都不做考虑。另外结合当地气候特点，除雨水形成的少量路面积水外，天气因素引发的特殊路面状况基本不会出现，因此也不纳入分析。

· 我们没有定义“部分遮挡”这一属性，因为NHTSA的官方文件及其他公开资料里，都没有明确它的具体含义。

路线的运行边界，必须结合当前自动驾驶技术的实际局限来划定。我们参考了 Waymo、通用汽车、宝马三家的安全报告，梳理了高等级自动驾驶的典型运行条件：行业通用的设计是车辆支持所有光照条件下运行，但天气适配仅限中等恶劣程度，不包含暴雨、大雪、雨夹雪、大风、浓雾这类会明显削弱车辆性能的极端天气。本次的运行设计域（ODD）也沿用了同样的约束标准。

图3.2：A270公路ODD一部分的车道示意图。长度并不代表实际距离

3.2功能概念

A270高速公路ODD中L4 AV运行的功能概念由四种运行模式和两类功能组成。这两类功能是（i）避免与其他道路使用者和障碍物碰撞，以及（ii）遵守ODD中的交通规则。每个类别中的功能是根据表3.1中总结的四种运行模式进行评估。基本运行模式是车道行驶模式。在高速公路车道上行驶时，自动驾驶汽车必须避免在车道上发生碰撞，并遵守高速公路交通规则。避撞功能中的“物体”一词既指障碍物，也指其他道路使用者。

表3.1：A270高速公路运行设计域下L4级自动驾驶车辆运行功能定义

在某些情况下，自动驾驶汽车可能会在高速公路上改变车道。执行此操作时，车辆必须避免与目标车道上的交通工具发生碰撞。它还必须指示车道变换，并根据公路规则优先考虑任何过往车辆。这些功能是变道运行模式的一部分。ODD中的两个设置还需要在基本车道驾驶模式下提供额外的AV功能。在十字路口设置中，自动驾驶汽车必须与十字路口车辆互动，并遵循指示交通流量的交通灯。交叉口特有的功能是交叉口运行模式的一部分。同样，汇合点是多条车道上的交通汇合成一条车道的指定点。在这里，自动驾驶汽车必须避免与来自另一条车道的合并车辆发生碰撞。这是交叉口合并点运行模式的一部分。

请注意，以下交通规则类别中的功能仅涵盖适用于A270高速公路的一小部分交通规则。虽然这对于我们的概念验证研究来说是足够的，但自动驾驶功能概念可以扩展到包括整套荷兰公路交通规则。

3.3功能架构

Apollo的最新版本，v6.0不包括整个感知功能。因此，Apollo功能架构的推导是基于Apollov5.5的软件架构、文档和代码。功能架构如图3.3所示。为了可追溯性，功能组件的命名与Apollo软件模块的命名相匹配。

图3.3：Apollo的功能架构。块和箭头分别表示功能组件和数据流。虚线框表示数据流向框内的所有功能组件。安全组件以紫色显示

传感功能组件位于Apollo软件栈外部，但在这里表示为AV系统级功能架构的一部分。我们排除了与驾驶任务不直接相关的功能，例如通过人机界面（HMI）组件向乘客更新状态。

表3.2和表3.3进一步阐述了功能组件和数据流。请注意，Apollo有两种定位方法，即实时动态（RTK）定位和多传感器融合（MSF）。虽然这两种方法都使用由传感组件提取的自我车辆姿态信息，但MSF还使用了传感的环境数据。所描述的功能架构基于MSF定位方法。此外，虽然Apollo支持叙事推演组件和所有其他模块之间的交互，但它目前只与预测模块交互。这在功能架构中得到了体现。

表3.2：各功能组件说明（注：文中自车ego vehicle指代自动驾驶车辆AV）

表3.3：各功能组件输出数据流说明（注：文中ego vehicle指代自动驾驶车辆AV）

图3.4：传感与感知功能架构说明。系统级组件、子系统级组件、细分底层组件分别以绿色、白色、蓝色框体展示；虚线框代表数据流会下发至框内所有功能组件。本架构主要基于Apollo自动驾驶平台感知模块软件架构搭建

图3.4进一步详细说明了传感和感知功能组件。额外的细节标识了系统级架构（1）中未捕获的功能，例如车道检测和跟踪。此外，在详细的架构（2）中可以看到各种冗余，例如多个Sense环境组件。最后，我们对其他组件与传感和感知组件的相互作用有了更深入的了解。例如，定位数据流（3）在感知组件中由Traffic光检测和识别组件以及目标检测、分类和跟踪（雷达）组件使用。详细架构中引入的数据流是车道（4），它提取道路车道信息。

最后，我们介绍Apollo功能架构中的三个安全组件。监视器组件（1）确保其他组件的完整性，并在检测到问题时触发监护组件（2）。当触发时，监护组件会执行安全响应。超声波传感组件（3）在安全响应期间感知近距离物体。

3.3.1与其他功能架构的比较

文献和工业界已经提出了几种自动驾驶汽车的功能架构。在这里，我们将Apollo功能架构与实践状态架构进行比较

来自安全出版物《自动驾驶安全第一》（SFAD），也在第2.1节中进行了描述。与传感和感知组件相关，SFAD有两个方面与Apollo相比。首先，感知包括交通信号检测功能。这为从HD地图检索到的交通标志信息增加了各种冗余。再看传感器融合模块，它的作用是生成周边环境的综合模型，但在Apollo架构里，传感器融合只覆盖动态物体。这虽然给交通信号灯这类环境目标的感知增加了多源冗余，但也导致除动态物体之外，Apollo功能架构在环境感知层面的多样性冗余度偏低。

再说到安全机制，从Apollo的官方文档来看，它的监测器组件只负责自动驾驶各组件的健康状态监测。而SFAD架构里，除了组件健康监测，还覆盖了运行设计域（ODD）、用户状态、车辆平台状态的监测。另外，Apollo设有专门的监护组件来执行安全响应动作；SFAD则是通过一个中央协调组件统一处理所有运行模式的切换，其中也包含安全响应，模式切换的指令会下发给规划组件，由它执行对应的动作。

Apollo和SFAD在安全机制上的区别可以总结为两点：第一，从Apollo的文档能明确看出，它的安全相关监测仅局限于组件健康监测，SFAD的安全监测范围更广；第二，两者执行安全响应的架构逻辑不同。

3.4 功能分配

功能分配描述的是，第3.2节提出的自动驾驶功能概念，具体如何在Apollo功能架构中落地实现。我们以“避免与车道内物体发生碰撞”这一功能为例，梳理对应的功能分配逻辑，具体见图3.5。需要注意的是，图中没有标注安全类组件，因为这类组件不参与自动驾驶正常工况下的标称运行。要实现这个示例功能，首先由传感组件采集环境中各类物体的信息，以及自车的姿态原始数据。

图3.5：避免与车道上的物体碰撞的功能分配。灰色显示的组件和数据流对功能没有贡献。请注意，此图中未显示安全组件

定位组件（2）使用原始数据，在HD地图组件（3）的地图信息的帮助下，确定自我车辆相对于其环境的姿态。

感知组件（4）使用地图和自我车辆姿态进行过滤和坐标变换，从原始环境数据中提取环境中物体的状态信息。预测组件（5）估计检测到的对象的未来轨迹。它还为每个检测到的对象分配优先级，这表明了对象对自我车辆行为的重要性。该任务利用了地图、自我车辆姿态、当前场景和上次计划的自我车辆轨迹。当前场景由基于地图和自我车辆姿态的讲故事组件（6）确定。

规划组件（7）使用预测的对象轨迹和自我车辆的当前状态生成自我车辆轨迹以避免碰撞。自我车辆的当前状态是通过车辆底盘数据、自我车辆姿态和地图信息确定的。控制部件（8）基于自我车辆轨迹、底盘数据和自我车辆姿态生成自我车辆控制命令。最后，在CANbus组件（9）中执行控制命令，该组件还检索车辆底盘数据以反馈给规划和控制组件。

由于Apollo4中关于数据流重新路由请求的文档不清楚，因此在功能分配中没有考虑到这一点。

3.5 总结

本章定义了AV的ODD和功能表示。这些人工制品是推导功能安全需求（详见第4章）和评估功能安全（详见第5章）的先决条件。荷兰A270公路路线被选为L4自动驾驶汽车的ODD，并根据AVSC和NHTSA指南进行特征描述。

自动驾驶汽车在其ODD中运行的功能概念由四种运行模式描述：（i）在车道上行驶，（ii）变道，（iii）穿过十字路口，以及（iv）穿过合并点。

为每种运行模式确定了两类功能：（i）避免与其他道路使用者和障碍物碰撞，以及（ii）遵守ODD中的交通规则。所选AV软件栈Apollo的功能架构来自文档和代码。传感和感知组件被进一步详细描述，揭示了组件中的各种冗余和更深入地了解它们的功能。最后，AV的功能概念通过功能分配与功能架构中的组件和数据流相关联。

本章推导了关于L4自动驾驶汽车传感和感知组件故障和功能不足的功能安全需求（FSR）。功能安全需求的推导基于汽车安全标准、ISO 26262和SOTIF中提出的框架。ISO 26262中指导FSR推导的特定部分是标准的概念阶段（第3部分）。概念阶段有三个步骤：（1）项目定义，以收集车辆及其周围环境的表示；（2）危害分析和风险评估（HARA），以识别AV的潜在安全危害并制定相应的安全目标；（3）功能安全概念，其中安全目标被映射到分配给特定功能部件的安全需求中。

FSR这一概念，在图4.1展示的SOTIF标准安全生命周期里并没有明确定义。但我们梳理后发现，设计与验证确认阶段（标准第8-11条）之前的三个分析步骤（第5-7条），可以结合相关研究作为推导FSR的基础。其中规范与设计（第5条）、SOTIF相关危害识别与风险评估（第6条）这两步，和ISO 26262概念阶段的前两个步骤逻辑相近；而识别、评估功能不足与触发条件的步骤（第7条）是SOTIF特有的环节，核心是找出可能导致自动驾驶车辆出现危险行为的组件功能缺陷。我们的研究目标，就是针对这类识别出的功能不足，推导对应的FSR。

图4.1：DIS/ISO 21448（SOTIF）标准中的安全流程总览，与FSR推导相关的条款（第5-7条）以红色标注

第3章提出的功能规范，已经覆盖了两套安全框架均要求的自动驾驶车辆及运行条件的描述内容。接下来4.1节会先介绍两套安全框架中危害分析与风险评估（HARA）的通用执行步骤。开展HARA时我们遵循ISO 26262的指引，因为SOTIF标准中也明确说明：“预期功能引发的危害，其识别与评估流程与ISO 26262的HARA保持一致”。

后续4.2节会将安全目标映射到传感、感知组件的功能安全需求上。这部分我们会先开展故障树分析，再分别按照ISO 26262和SOTIF的专属要求，梳理出针对故障、功能不足两类问题的安全需求。到4.3节，我们会结合Apollo的安全架构，对推导得出的安全需求做重新定义。第5章会用这些明确的安全需求评估功能安全水平，同时本节也会针对A270公路的运行设计域（ODD）搭建一套理想化的安全概念。最后4.4节会总结并讨论本次得出的、针对传感与感知组件故障及功能不足的FSR相关结论。

4.1 危害分析与风险评估

首先要识别所有潜在的危害事件：也就是车辆层面的危害，叠加可能引发伤害后果的运行场景，二者结合就构成了危害事件。之后评估每个危害事件对应的风险水平，再据此提炼安全目标，以此降低对应风险。

4.1.1 危害事件的识别

要系统地识别危害，ISO 26262 建议采用成熟的系统化分析方法，比如失效模式与影响分析（FMEA），或是危险与可操作性分析（HAZOP）。FMEA是一种自下而上的方法，分析系统单个组件的失效模式，以识别系统的相应危害。组件的失效模式描述了组件可能发生故障的方式及其后果。相反，HAZOP探索系统功能（根据功能概念）与其预期设计的偏差，以识别危险。由于对AV的许多组件进行FMEA的复杂性，我们在这个项目中使用了HAZOP。

HAZOP利用引导词系统地识别可能导致危险的功能偏差。最常见的引导词是no、more、less以及part of、reverse、other、early、late、before、after。我们观察到，自动驾驶汽车的相关工作为子系统级功能执行了危险与可操作性分析，并为子系统量身定制了指导词。欧盟ENSEMBLE卡车队列研究项目对特定类别的功能（通信、加速、制动和人机界面）进行分析。该分析使用了“损失”、“意外”、“缺乏”等引导词，以及“过度”和“不足”等不正确行为的其他词。Bagschik等人也定制了引导词，例如，自我车辆规划相关功能具有物理上不可能和不相关的引导词。与相关研究不同，我们的功能概念在车辆层面定义了相对抽象的功能。因此，我们不会为HAZOP分析定制常见的指导词。只有引导词和功能的某些组合会导致危险。例如，考虑避免与车道上的物体碰撞的功能。虽然引导词没有导致危险，也没有避免与车道上的物体碰撞，但引导词没有相应的危险。我们观察到，只有引导词no、reverse、early和later会对第3.2节中的AV功能概念造成危害。

接下来，将确定危害可能导致潜在风险的运行场景。ISO 26262标准将危害、AV运行模式和运行场景的组合称为危害事件。由于我们ODD中可能出现的场景数量很大，我们再次参考ENSEMBLE项目和Bagschik等人的相关工作，以确定与定义危害事件目的最相关的运行场景。

ENSEMBLE和Bagschik等人都考虑了以下变量：（i）车辆状态，（ii）其他道路使用者的状态，（iii）道路坡度等道路基础设施。ENSEMBLE还考虑了（iv）特殊事件，如行驶道路上的障碍物，而Bagschik等人也考虑了（v）天气条件。只有在以下情况下，才能考虑这些变量中的多种变化等等危害事件带来的风险。正如Bagschik等人所说：“过于详细的场景会扭曲风险评估（…），并导致较低的暴露等级”。我们使用相关工作中提出的类似变量来定义运行场景。ODD不会直接捕捉其他道路使用者的状态。目前，我们只关注其他车辆，因为它们是高速公路上的主要道路使用者。行人和骑自行车的人，特别是在十字路口，以及动物或碎片等障碍物，将在未来的安全分析迭代中予以考虑。高速公路上其他车辆的状态可以用一系列可能的行为来描述：减速、加速、驶入车道、合并车道、变道和跟随交通灯。我们还考虑了另一名道路使用者的不正确行为；十字路口的一辆不跟在交通灯后面的十字路口交通工具。

然后，提取与AV功能概念相关的行为，例如，前方车辆减速触发相应的避免碰撞功能。图4.2总结了所进行的安全分析中涵盖的运行场景。某些变量在自动驾驶运行模式和功能中被捕获，例如，功能中的交通灯和信号交叉口跟随交通灯和穿越交叉口的运行模式。因此，我们可以通过道路使用者和障碍物等剩余变量来表达运行场景。

图4.2：危害事件覆盖的行驶场景说明。表格左侧蓝色底色为各类变量维度，黄色底色单元格代表本研究已覆盖的变量细分情形

所有可能的危害事件都是通过在运行模式下结合每种危害和运行场景获得的。运行模式的危害是指与该运行模式中的功能相对应的危害。接下来确定危害事件的潜在有害后果，以随后评估事件带来的风险。我们过滤掉无效的危害事件，例如，危害避免与车道上的物体碰撞，以及目标车道上从后面接近的运行场景车辆的组合。假设危害事件何时可能导致有害后果。例如，由于跟车反应时间有限，高速公路速度（限速100公里/小时）下的紧急制动被认为是有害的。然而，在十字路口（限速50km/h）紧急制动被认为是安全的，因为后面的车辆有足够的反应时间。

4.1.2风险评估和安全目标

评估危害事件造成的风险及其后果。为每个危害事件分配质量管理（QM）的汽车安全完整性等级（ASIL）或ASIL A-D。指定QM的危害事件构成可容忍的风险，而指定ASIL D的危害事件则构成高风险。ASIL水平由三个因素决定；危害事件的可控性（C）、严重性（S）和暴露（E）。可控性水平估计驾驶员或车辆用户减轻危害事件后果的能力。水平范围从一般可控（C0）到不可控（C3）。在L4自动化时，自动驾驶汽车不能依赖驾驶员干预，所有危害事件都是C3级

严重程度是潜在危害的衡量标准，从无伤害（S0）到致命伤害（S3）。我们根据速度限制估计碰撞的潜在危害，将S2分配给区间（50公里/小时），将S3分配给高速公路上的其他位置（100公里/h）。因此，如果导致碰撞的危害事件对应于穿过交叉口的运行模式，则其严重程度为S2，如果它们对应于其他运行模式，那么严重程度为S3。当危害事件没有导致碰撞时，分配S0。

根据ISO 26262，暴露水平可以通过持续时间或频率来估计，范围从极低（E0）到高概率（E4）。根据ISO 26262概念阶段的示例，通过其发生频率来估计运行场景的暴露情况。例如，在一次行程中，车辆在自动驾驶汽车前方减速可能会发生多次（E4），但因施工而关闭的车道每年最多只能遇到一到两次（E2）。尽管ISO 26262标准中没有明确说明，但危害事件的暴露也应取决于相应运行模式的暴露。对运行模式的暴露可以通过在该模式下花费的时间比例来确定。最终暴露水平被视为运行模式和运行场景暴露水平的最低值，因为对运行模式或运行场景的低暴露会导致整体低暴露水平。表4.1总结了暴露水平。

表4.1：危害场景暴露度等级表

表4.2：汇总安全目标清单

HARA的最后一步是明确安全目标，以减轻ASIL A或更高级别的所有危害事件。安全目标被描述为AV的功能目标。一旦为每个危害事件指定了安全目标，就可以汇总类似的安全目标。表4.2列出了最初制定的69个安全目标中的18个汇总安全目标。与穿越十字路口的运行模式相对应的安全目标具有最低的ASIL水平。这是从与其他运行模式相比分配给运行模式的较低严重性级别继承而来的。SG5、SG6和SG18是QM，因为相应的危害事件不会导致有害后果。每个危害事件都会导致交叉口紧急制动，如4.1.1所述，在较低的交叉口行驶速度下，这是安全的。

4.2 功能安全需求的推导

本节首先进行故障树分析（FTA），将违反AV级别安全目标的行为（如第4.1节所述）映射到传感和感知组件中的失效事件。然后，根据ISO 26262和SOTIF标准规定的步骤，为失效事件推导出FSR。请注意，在本文中，我们使用术语26262 FSR和SOTIF FSR分别指代具有故障和功能效率不足的FSR。FTA是一种自上而下的故障分析，它确定了组件级失效如何导致系统级事件。此映射需要第3.4节中的功能分配。例如，图4.3显示了违反安全目标“自动驾驶汽车在运行模式下应遵循红色和黄色交通灯：穿过十字路口”的FTA。FTA的语义包括两种类型的事件和两个布尔门。由圆圈表示的基本事件是主要失效，而由矩形表示的次要事件是基本事件导致的失效。在我们的FTA中，我们只关注与传感和感知组件相关的基本事件。

图4.3：安全目标SG17被违背的故障树分析（FTA）。安全目标SG17内容：“车辆通过交叉路口工况时，遵守红灯与黄灯交通信号灯指示”。本分析不纳入与传感、感知组件无关的失效事件（图中灰色标注项）。定位相关失效事件下方的三角符号，表示该故障树分析分支将在另一张图中继续展开

布尔“AND”门表示所有输入失效都必须发生才能导致输出失效。相反，“OR”门表示单个输入失效导致输出失效。布尔门主要通过功能架构来确定。通过FTA确定了11个基本失效事件，如表4.3所示。每个事件对应一个独特的传感和感知功能组件。

表4.3：本次故障树分析（FTA）识别出的11类基础失效事件

4.2.1 ISO 26262 FSR

ISO 26262概念阶段的功能安全概念步骤导出了FSR，以防止违反车辆级安全目标。根据ISO 26262，与功能组件相对应的基本事件可能是由于（i）组件无法运行或（ii）组件输出丢失或损坏。FSR专门用于检测所有11个基本事件的故障，并防止相应违反安全目标。一个示例FSR是，交通灯检测和识别组件的非操作状态不应导致AV在运行模式下忽略红色或黄色交通灯：穿过十字路口。在功能安全概念步骤中，FSR也被分配给特定的组件。分配通常是ISO 26262第4部分的输入，该部分涉及基于FSR的产品开发。在我们的案例中，我们的目标是评估现有AV的功能安全性。因此，我们不假设FSR由特定的子系统级组件完成，而是将FSR分配给整个传感和感知子系统。此外，FSR也可能由Apollo的安全组件来填充。因此，FSR的分配额外扩展到Apollo的安全组件。

4.2.2 SOTIF FSR

在这里，我们描述了与通过FTA分析在传感和感知组件中识别的故障相关的SOTIF FSR的推导。SOTIF标准的相关章节是第7条：潜在功能效率和触发条件的识别和评估。在我们的研究中，我们将基于相机的物体检测、分类和跟踪（相机物体感知）的功能视为概念证明。该功能由详细的传感和感知架构中的三个功能组件组成（如图3.4第3.3节所示）。这些组件是：（1）感知环境（摄像头），（2）车道检测和跟踪，以及（3）目标检测、分类和跟踪（摄像头）。术语功能效率被定义为功能的具体说明或技术能力的限制，这可能会导致与触发条件相结合的危害行为。触发条件可被视为ODD内的先验最坏情况条件；可能引发功能失效并导致潜在危害行为的条件。

使用SOTIF标准中的示例作为参考，对与照明（一天中的时间）和天气条件相关的功能效率进行SOTIF分析。根据该标准，这些类别的功能效率是感知相关功能的关键。被确定会降低目标检测性能的功能效率是低光照条件，训练数据集中很少捕捉到的光照条件，如黄昏和黎明，以及天气条件，特别是雾、雨和雪。目标检测性能的恶化进一步恶化了目标跟踪的性能。因此，功能效率具体取决于相机对象感知功能的对象检测和对象跟踪性能。

接下来，确定每个功能效率的触发条件。触发条件由三个实体表示；（i）场景，（ii）AV行为，以及（iii）其他道路使用者的行为。明确规定了与功能效率直接相关的场景特征，即天气或照明条件。对应于一天中所有时间的照明条件是ODD的一部分。天气条件包括：（ii）风、雨、雪、雨夹雪和雾达到中等恶劣程度；（iii）温度范围为-15摄氏度至40摄氏度；以及（iv）道路上积水。我们不对其他变量的最坏情况变化做出任何假设。因此，ODD内除与功能效率直接相关的场景特征之外的变量的所有可能变化都被视为触发条件的一部分。

车辆等级功能效率的影响，车辆等级e的严重程度评级相关触发条件的影响（S*）和发生率（O*）将作为分析的一部分进行指定。SOTIF标准中的示例提供了与HARA中用于风险评估的严重程度相同的S*标准：从无伤害（S*=0）到致命伤害（S**=3）。O*评级的范围从不太可能（O*=0）到每个驾驶循环一次或多次（O*=6）。

根据FTA，基于摄像头的物体检测、分类和跟踪功能的故障违反了表4.2中关于避免碰撞的安全目标SG1-SG11和关于在变道期间给予优先权的安全目标SG16。对于所有功能效率，这两个评级被确定为S*=3（最高）和O*=5（第二高）。SOTIF中的严重性标准与HARA中的标准相同，S*评级继承自违反安全目标SG1-11和SG16的严重性。发生标准基于触发条件的频率，O*=5对应每年发生一次或多次。最高O*额定值6对应于每次跳闸，这在触发条件下是不预期的。

最后，SOTIF FSR专门用于防止由于潜在的功能效率不足及其相关触发条件而违反安全目标。表4.2中SG1（避免与车道上的物体碰撞）的SOTIF要求示例是“夜间物体检测和跟踪性能恶化不应导致与车道上物体碰撞”。SOTIF FSR被分配给Apollo的传感和感知子系统以及安全组件。

4.3 安全理念

本节概述了第4.2节中为Apollo安全概念定义的要求的定义。Apollo安全概念具有车辆级安全状态，在AV出现安全相关问题时触发。本节首先讨论A270公路ODD的适当安全状态。随后，第4.3.1节提出了A270公路ODD的理想安全概念。然后，第4.3.2节讨论了Apollo计划中实施的安全状态，我们确定了所引发的FSR。

高速公路上可能的故障安全状态包括车道紧急停车、车道慢速停车或路边停车。紧急停车可能会导致以高速公路速度与后面的车辆发生碰撞。在活跃的高速公路车道上行驶的固定车辆也可能导致事故，特别是在低能见度的情况下。然而，实现这些安全状态需要有限的AV能力。路边停车是一种更安全的最终状态，但需要额外的功能。

同样，故障运行状态（降级模式）AV的可用性更高，但需要额外的功能。可能的故障运行状态包括降低驾驶速度或自动化水平，或限制某些运行模式或功能。自动化水平的降低不适合我们的L4 AV，因为我们不假设驾驶员可用。在高速公路上减速行驶也很危险。然而，AV可能会在路肩上减速行驶，直到高速公路出口或停车位。将运行模式限制为基本车道行驶运行模式也可能是合适的。如果故障不影响该模式的运行，这可能是合适的。

4.3.1 理论安全概念

图4.4显示了与传感和感知组件中的失效事件相关的高速公路ODD安全概念的状态机。安全概念的制定考虑了Apollo的功能架构，包括感知近距离物体的超声波传感器安全组件（如第3.3节所述）。表4.4总结了我们安全概念向特定安全状态过渡的原因。安全概念区分了功能架构中具有冗余或不同冗余的组件（分配的安全状态S3或S4）和不具有这种冗余的组件的故障（分配的安全状态S2）。车辆是应该停在路边（安全状态S3）还是继续在路肩上行驶（安全状态S4）的选择是基于受影响的功能。

图4.4：安全概念的状态机。事件E1-E12是指表4.3中的失效事件。安全状态S1-S4是指表4.4中的安全状态

表4.4：A270高速公路运行设计域（ODD）对应的安全状态

AV定位功能有两个不同的冗余输入，而对象感知（对象检测、分类和跟踪）有三个不同的重复输入和相应的组件，如图3.4所示。对于以下失效事件如果输入与定位相关，则选择安全状态S3。安全状态S4被认为是危险的；失效事件可能导致定位不准确，并导致危害行为，例如转向回活动车道。如果发生失效事件考虑到与物体感知相关的一个输入或组件，安全状态S4被认为是安全的，因为（i）物体感知的两个不同输入或组件仍然是可操作的，并且（ii）物体感知任务的复杂性在路肩上较低。

安全概念还根据失效事件的原因（即故障或功能效率不足）选择适当的安全状态。传感器融合功能组件和物体感知功能中的各种冗余（见图3.4）旨在缓解车辆级，由于个体模态（例如基于相机的物体感知）在ODD条件下的功能效率不足。从当前行业的实际落地情况来看，也印证了这一点。也就是说，针对ODD范围内的触发事件，要满足对应的SOTIF功能安全需求，不一定非要触发安全状态切换，也不需要额外施加运行限制。

ISO 26262对应的功能安全需求覆盖的是组件的非预期失效，这类失效会直接削弱系统的各类冗余设计，因此针对这类需求，采用车辆级安全状态是适配的。除此之外，涉及触发条件的SOTIF功能安全需求，同样需要切换到车辆级安全状态。按照定义，超出ODD范围的工况本身就属于不安全场景，因此不管是ISO 26262还是SOTIF的功能安全需求，只要对应ODD外的触发条件，都需要进一步明确定义，规定对应失效事件发生后，车辆该切换到哪种合适的安全状态。

4.3.2 Apollo安全概念与安全需求优化

3.3节已经介绍过Apollo的安全机制，包括监测器、监护模块和超声波传感器。Apollo现有的安全响应只覆盖了前述安全状态中的两类：S1为车道内紧急停车，S2 为车道内缓速停车。选择S1还是S2，取决于超声波传感组件的功能完整度，以及车辆与周边障碍物的距离。至于S3安全状态——也就是靠边停车，虽然规划组件本身具备这项功能，但Apollo目前大概率还无法在故障触发时自动切换到S3状态。

为了得到可用于Apollo功能安全评估、且具备可测试性的安全需求（详见第5章），我们基于Apollo的安全概念，对4.2节提出的安全需求做了适配调整。同时我们也参考了4.3.1节的分析结论，区分出哪些需求需要进一步优化。最终调整结果为：ISO 26262的功能安全需求，以及对应ODD外触发条件的SOTIF功能安全需求，都明确写入了安全状态切换的要求；而对应ODD范围内工况的SOTIF功能安全需求，现阶段不需要额外调整。需要说明的是，和我们提出的理想化安全概念不同，Apollo的安全概念里并没有建立失效事件与安全状态的映射关系，因此对应的安全需求中，也没有指定具体要切换到哪一种安全状态。

4.4 结果与讨论

图4.5汇总了本章为A270公路ODD、结合Apollo功能架构制定安全需求的完整流程。我们从最初梳理的69个安全目标中，归纳出18个汇总级安全目标，其中15个达到了ASIL A及以上等级（见表4.2）。正如4.1.2节提到的，对应路口通行运行模式的安全目标，ASIL等级最低。通过故障树分析（FTA），我们识别出11个失效事件（如表4.3所示），每个失效事件都对应一个独立的传感与感知功能组件。功能部件的失效事件及其违反安全目标的行为也通过FTA进行识别。例如，基于摄像头的物体检测、分类和跟踪（物体感知）功能的故障违反了与避免碰撞相关的安全目标SG1-SG11和关于在变道期间给予优先权的安全目标SG16。

图4.5：功能安全需求的激发过程

在SOTIF和ISO 26262的具体步骤中，我们得出了传感和感知组件失效事件的安全需求。ISO 26262涵盖了两种故障类型；（i）非操作状态和（ii）输出数据损坏或丢失。在SOTIF分析中，我们确定了与基于相机的物体感知功能相关的功能效率不足。车辆严重程度等级功能效率的影响（S*）和相关触发条件（O*）的发生被确定为S*=3（最高）和O*=5（次高）。因此，已识别的功能缺陷可能会出现在ODD中，并导致危害行为。

然后，我们为A270公路ODD提出了一个理想的安全概念，以及Apollo安全概念。与Apollo安全概念相比，理想的安全概念考虑了额外的安全状态。另一个安全状态的例子是S3，停在路肩上。如第4.3节所述，对于高速公路上的车辆来说，这可能是一个更安全的最终状态。这表明Apollo在高速公路环境中运行的安全概念存在潜在的局限性。

作为可行性研究报告引出的最后一步，可行性研究报告是为Apollo安全概念而制定的。表4.5展示了SG1的安全需求示例：避免与车道上的物体碰撞，以及基于摄像头的物体检测、分类和跟踪功能的失效事件。

表4.5：基于Apollo安全方案细化后的安全需求示例

该表给出了示例26262 FSR、ODD内触发条件的SOTIF要求以及与失效事件对应的ODD外触发条件的SOTIF要求。

本章介绍了Apollo功能安全评估的方法和结果。功能安全评估是根据与基于人工智能的传感和感知子系统的故障和功能不足相关的诱发功能安全需求（FSR）（详见第4章）进行的。可行性研究报告的完整性在Apollo的设计和实施层面进行了评估。我们将功能安全评估方法的应用重点放在与两个基于人工智能的功能相关的FSR上；基于激光雷达和基于相机的目标检测、分类和跟踪功能。相关组件如图5.1所示。

图5.1：Apollo传感和感知子系统的详细功能架构。我们将功能安全评估方法的应用重点放在与红色标记的组件相关的FSR上

首先，第5.1节使用Kochanthara等人的现有方法来评估FSR在车辆软件架构中的完整性。由于该方法没有考虑与基于人工智能的组件相关的FSR，我们进一步扩展了该方法，以考虑与人工智能安全相关的最佳实践和与人工智能相关的设计工件。

然后，第5.2节概述了一种基于仿真的测试方法，用于评估Apollo实施中的FSR。首先，第5.2.1节描述了一种系统的方法，用于推导所引发的FSR的测试用例。然后，第5.2.2节演示了几个示例测试用例的测试。最后，第5.3节对本章进行了总结。

5.1 设计评估

为了在设计层面评估可行性研究报告的完整性，我们使用了Koch-anthara等人提出的方法。该方法通过检查安全策略在车辆软件架构中的应用，提出了功能安全的设计级评估。架构策略是一种影响系统非功能属性的抽象设计决策。安全策略是一种解决安全问题的架构策略。可行性研究报告的完整性分两步进行系统评估。首先，通过将FSR描述与策略描述进行匹配，确定可以满足每个FSR的安全策略（组合）。然后，检查车辆软件架构在识别集内是否使用了安全策略。在他们的案例研究中，作者依靠一组在设计中最广泛使用的13种安全策略来评估合作自动驾驶汽车的ISO 26262 FSR。13种安全策略是：心跳、简单、替换、健全性检查、比较、复制冗余、多样化冗余、状态监测、修复、投票、降级、覆盖和屏障。

在这里，我们将Kochanthara等人提出的方法应用于我们的背景，除了ISO 26262 FSR外，还包括SOTIF FSR。我们的安全需求也针对基于人工智能的组件，这些组件除了车辆的功能和技术架构外，还有其他人工制品（数据集、神经网络（NN）模型）。此外，基于人工智能的组件的安全挑战是独一无二的；例如，在新颖或罕见的驾驶条件下不可预测的行为。因此，我们探索了13种安全策略的可能扩展，这些策略解决了基于人工智能的组件的安全问题。由于对基于人工智能的组件的安全策略的初步文献搜索没有得出任何结果，我们将搜索范围扩大到基于人工智能组件的软件工程的最佳实践。

从检索到的文章中，我们提取了解决基于人工智能的组件安全性的最佳实践，并进一步筛选出与我们的背景相关的最佳实践。例如，人工监督基于AI的组件的安全相关最佳实践不适用于我们的L4 AV。与AV开发相关的安全最佳实践也不在范围内，因为Apollo没有提供此类信息，例如神经网络的训练实践。基于人工智能的组件安全的最佳实践列表如表5.1所示。

我们使用13种安全策略和11种人工智能组件安全最佳实践来评估我们的FSR。根据FSR的描述和目标，将战术和最佳实践与FSR相匹配。例如，不确定性估计和监测的最佳实践旨在：“识别模型退化或错误输出”。此最佳实践适用于引发的SOTIF FSR，因为它能够检测到对象检测、分类和跟踪功能的性能恶化。

表5.1：基于人工智能组件的安全开发最佳实践

作为一个案例研究，我们评估了与基于相机的物体检测、分类和跟踪功能相关的FSR的最佳实践和策略的使用情况，并对其进行了概念验证SOTIF分析（详见第4.2.2节）。安全策略和人工智能安全最佳实践的使用在功能架构、Apollo文档和Apollo代码中进行了检查。我们将代码审查限制在与目标功能相关的某些组件上：

（i）摄像机对象管道，（ii）传感器融合，以及（ii）两个安全组件；监视器和监护人。此外，一些人工智能安全最佳实践将根据训练数据集、Waymo Open数据集和NN模型、SMOKE NN模型进行评估。我们基于这些设计实体的文档，为与数据集或神经网络模型相关的实践制定评估标准。我们在表5.2中用两个例子说明了最佳实践的评估标准。

表5.2：用于核查AI组件安全最佳实践是否落地于设计产物的评估判定标准

介绍了与AI安全最佳实践相关的几个人工制品：（i）从文献中提取和筛选AI组件安全相关最佳实践的完整过程，（ii）检查是否采用最佳实践的评估标准的完整列表，以及（iii）详细说明识别FSR相关最佳实践过程的示例。

同样，对于安全策略，我们记录了：（i）如果采用安全策略，评估标准的完整列表，以及（ii）详细说明为FSR确定相关安全策略的过程。

5.1.1结果和讨论

表5.3总结了与基于摄像头的物体检测、分类和跟踪功能相关的FSR设计级评估结果。我们的结果表明：（i）人工智能安全相关的最佳实践主要与SOTIF FSR相关，而不是26262 FSR，（ii）Apollo设计中缺乏人工智能安全的最佳实践，（iii）几种安全策略与FSR和SOTIF FS相关，（iv）设计中采用了一些相关的安全策略。

表5.3：功能安全需求（FSR）设计评估结果

我们首先详细阐述了针对人工智能安全的最佳实践的评估结果（与可行性研究报告的相关性、设计中的应用）。就与FSR的相关性而言，只有监测数据质量问题的最佳实践（实践11）与ISO 26262 FSR（FSR 26262 19，FSR 262620 20）相关。相比之下，对于SOTIF FSR，除了NN的设计规范（实践2）、领域泛化（实践6）和监测数据质量问题（实践11）之外，大多数与AI安全相关的最佳实践都是相关的。一些相关的最佳实践降低了可行性研究报告所解决的相应功能效率，例如输入数据特征（实践1）。其他措施防止功能效率不足导致违反安全目标，如要求中所述，例如不确定性估计（实践8）。

发现这些最佳实践在设计中的应用率很低。Apollo设计中只采用了实践11和9。与FSR 26262 19、FSR 262620 20相关的实践11以监视器组件执行的数据完整性检查的形式使用。与SOTIF要求相关的实践9通过使用不同的冗余（激光雷达、雷达、基于摄像头）来实现目标检测、分类和跟踪功能。Apollo设计中缺乏其他相关的人工智能安全相关实践。接下来，我们讨论安全策略的评估结果（与可行性研究报告的相关性、设计中的应用）。就与FSR的相关性而言，26262 FSR和SOTIF FSR都确定了几种相关的安全策略，如超控、多样化冗余和健全性检查。据观察，其中一些战术被用于Apollo的设计中。将车辆带入安全状态的超控策略被确定用于四个26262 FSR中的三个。还确定采用与SOTIF和ISO 26262 FSR相关的多样化冗余和复制冗余策略。通过使用不同的功能模式（激光雷达、雷达、基于摄像头）存在不同的冗余，而通过使用具有部分重叠视野的两个摄像头应用复制冗余。

设计中某些策略的使用尚未确定。例如，从功能架构或我们对传感和感知组件的高级代码审查中，对于对象级信息（如SOTIF FSR和26262 8）的比较或状态监测等策略的使用并不清楚。需要对组件进行详细的代码审查，以确定是否使用了这些策略，这超出了设计评估范围。

5.2 基于模拟的测试

本节介绍了一种基于模拟的测试方法，用于评估FSR在实施层面的完整性。第5.2.1节介绍了一个通用框架，用于推导第4章中引出的FSR的测试用例。接下来，第5.2.2节演示了针对与基于激光雷达的目标检测、跟踪和分类功能相关的FSR的测试示例测试用例。

AV仿真工具的最初选择是西门子的模拟器Simcenter PreScan。不幸的是，西门子PreScan和Apollo之间的内部集成忽略了Apollo中的感知组件。目前，PreScan直接向Apollo的预测组件提供地面实况感知数据。由于集成修改并非易事，我们无法使用PreScan进行测试。

相反，我们选择了开源的AV模拟器Lgsvl，它支持与Apollo的开箱即用集成。然而，我们遇到了与这种集成相关的几个技术挑战，尽管在多个版本的Apollo上进行了尝试，并与Apollo和Lgsvl团队进行了联系，但这些挑战仍无法解决。所面临的技术挑战包括：（a）基于雷达的物体检测不起作用（b）基于摄像头的物体检测具有不稳定的检测输出（c）车辆在突然制动时运动不稳定（可能是由于指出的高资源使用率）。鉴于这些技术挑战，我们缩小了最初计划的测试范围，只考虑了几个测试用例进行演示。

5.2.1 测试用例要求

正如Post等人所提出的，我们通过首先定义测试场景，系统地推导出了诱发FSR的测试用例。测试场景包括填写FSR所需的一组测试用例，如图5.2所示。为了系统地探索测试场景中的测试用例空间，我们采用了类别划分方法，并讨论了相对于Apollo测试FSR的分区选择。

图5.2：使用Post等人的测试场景将需求与测试用例联系起来的描述

在我们的上下文中使用的测试场景被定义为将功能安全需求编码为先决条件和后决条件。此外，我们为测试场景定义了相应的通过/失败标准，可用于测试场景中的测试用例集。测试场景和通过/失败的标准如表5.4中的FSR所示。在SOTIF 1的情况下（仅对应于“避免与车道上的物体碰撞”的安全目标1），必须参考具有先决条件日间条件的额外（参考）测试场景的结果来确定通过/失败标准。通过比较前置条件白天条件和夜间条件的后置条件，我们可以评估SOTIF要求所涵盖的夜间条件的特定功能效率。

接下来，我们将探索FSR测试场景中的测试用例空间。测试用例有两个方面：（i）输入；其对应于测试场景的先决条件和（ii）测试条件；进行测试的一组条件。为了系统地探索输入和测试条件空间，我们使用了类别划分方法中提出的类别和划分的概念。类别划分方法是一种常见的黑盒测试方法，用于为功能需求生成测试用例。类别是指输入空间和测试条件的特征。分区是指一个类别中需要处理的选项↵最终由被测系统决定。

为了说明我们的方法，我们考虑了表5.4中所示的相同示例要求。对于FSR 26262 7，为前置条件、传感环境（摄像头）模块变为非工作状态的输入空间确定了一类非工作状态持续时间。这里，这是指模块不工作的持续时间，从非常短的瞬时失效（例如0.05秒）到永久失效。对于SOTIF，预条件可以在下一段中解释的测试条件内表示，因此不需要输入。

表5.4：示例（i）ISO 26262功能安全需求、（ii）预期功能安全需求对应的测试场景与判定通过/失败标准

测试条件的表示方式取自SOTIF标准中的触发条件表示方式（如第4.2.2节所述）。测试条件空间分为三类：

（i）场景，（ii）AV状态，以及（iii）其他道路使用者的状态。场景类别可以进一步拆解，对应到运行设计域（ODD）里各个变量的细分类型。比如在SOTIF场景中，“夜间工况”这个前置条件，就对应场景类别下的昼夜子类。自动驾驶车辆的状态类别也有细分，比如运行模式（详见3.2节）和系统健康状态，比如是否存在已触发的失效事件。最后，其他道路使用者（周边车辆）的状态，可以通过其他车辆的行为清单来描述（危害事件的详细说明见HARA部分4.1.1节）。自动驾驶车辆和其他道路使用者的状态，还应当补充行驶速度这类动态变量对应的子类。

针对每项需求，输入空间和测试条件空间该怎么划分类别，取决于被测系统的设计预期。对于ISO 26262对应的功能安全需求（FSR），测试条件类别通常不需要划分太多分区。结合我们对安全组件中监测模块与监护模块的代码审查结果来看，26262 FSR里规定的自动驾驶安全响应——也就是切换至安全状态——是固定逻辑，不受三类因素影响：一是具体场景，二是部分自动驾驶状态，比如我们功能概念中定义的行驶速度、运行模式（详见3.2节），三是其他道路使用者的行为。

系统自身的健康状态，比如车辆内部其他已触发的故障，会对被测系统产生影响，因此这部分需要划分多个分区。与之相反，SOTIF对应的FSR受外部因素和车辆状态的影响会非常明显，因为这类需求本身就直接关系到车辆行为的安全性。因此，SOTIF FSR对应的分区设置，可以结合领域知识推导，也可以通过探索性测试来确定。

5.2.2 测试演示

在这里，我们首先演示了与基于激光雷达的目标检测、分类和跟踪功能相关的FSR的两个示例测试用例的执行。随后，我们使用第5.2.1节中的框架来讨论这些测试用例在评估可行性研究报告完整性方面的效率。

图5.3：ISO 26262功能安全需求（FSR）测试环境搭建示意图。自动驾驶车辆以蓝色标识，静止障碍物车辆以白色标识

表5.5：两条基于激光雷达目标检测、分类与跟踪功能的ISO 26262功能安全需求所对应的注入失效条件（测试输入）

FSR、其相应的测试场景和所选的失效条件（输入）如表5.5所示。所选的测试条件如图5.3所示，并在Lgsvl中使用PythonAPI进行了设置。在设置中，一辆文具车（白色）位于自动驾驶汽车的车道上。自动驾驶汽车（蓝色）在高速公路车道上设有目的地，以便在行驶过程中遇到文具车。在这里，我们将AV的最高速度限制在20km/h³。

接下来，我们将描述如何注入两个输入故障测试条件。为了模拟非操作传感器，我们拦截了Lgsvl和Apollo之间的数据通道，以获取激光雷达传感器数据。设置一个中间节点，该节点从Lgsvl获取数据，并将其提供给Apollo。因此，通过停止该中间节点，可以在AV行程期间的任何时候模拟非操作传感器故障。通过清除神经网络生成的对象列表，模拟基于相机的对象感知组件输出数据中缺失对象的数据损坏。此故障在编译时插入（在Apollo代码中）。

为了评估两种测试场景的后状态，即处于安全状态的AV，选择与后状态相对应的测试结果为“HMI屏幕上出现一条消息，指示已触发安全状态”。当监视器组件触发监护人执行紧急停止（安全状态S1）或缓慢停止（安全模式S2）（如第4.3.2节所述）时，HMI上会出现该消息。鉴于车辆运动中观察到的不稳定性，我们选择在HMI上检查消息，而不是观察车辆行为。图5.4显示了ApolloHMI上的示例消息，指示在未检测到传感器时转换到安全状态。

图5.4：Apollo HMI上用于确定测试结果的消息示例。该消息描述了在未检测到传感器时触发安全状态

表5.6：两条激光雷达目标检测、分类与跟踪相关ISO 26262功能安全需求的演示测试用例结果

5.3 总结

本章介绍了Apollo功能安全评估的方法和结果，这些方法和结果与车辆基于人工智能的传感和感知子系统在（i）设计层面和（ii）实施层面的功能安全需求有关。

功能安全的设计级评估是基于现有的方法进行的，该方法通过检查车辆软件架构中是否应用了合适的架构策略（安全策略）来评估FSR的完整性。我们进一步扩展了这种方法，以设计与人工智能组件（数据集、神经网络模型）相关的工件，以及解决人工智能组件安全问题的最佳实践。

该评估应用于与目标检测、分类和跟踪功能相关的FSR。结果特别表明，Apollo设计中缺乏与SOTIF FSR相关的基于人工智能的组件安全的最佳实践。功能安全的实施级评估考虑了基于模拟的测试方法。我们首先为每个FSR定义一个测试场景，从而系统地推导出所引发的FSR的测试用例。然后，我们探索测试场景中的测试用例空间；通过类别划分方法表示输入和测试条件的变化。通过这种方式，我们可以确定所执行测试的效率，并对评估所引发的FSR所需的测试用例类型进行推理。我们通过示例测试用例展示了测试结果，这些测试用例揭示了Apollo中未完成的FSR。

自动驾驶汽车（AV）技术正在迅速发展，近年来已被多个国家认证为公共道路测试。确保自动驾驶汽车的安全是公众接受和监管该技术的重要一步。根据安全标准ISO 26262和SOTIF的规定，功能安全领域解决了由于系统失效和功能效率低下而带来的风险。本文章与西门子数字工业软件公司合作发起，旨在评估在荷兰高速公路环境中运行的SAE L4 AV的功能安全性。

ODD对功能安全需求（FSR）和适当的回退响应的影响突显了评估AV在特定运行设计域（ODD）方面的功能安全的重要性。此外，在AV中使用基于人工智能的组件对功能安全提出了挑战。这激发了本次毕业设计的两个研究问题。对于我们的调查，我们选择了一个开源的工业级AV软件栈，Apollo。

第6.1节总结了我们对研究问题的发现。然后，第6.2节重点介绍了本文的主要贡献。最后，第6.3节描述了本研究的局限性，并提出了未来的研究方向。

6.1 研究问题结论

RQ1：在荷兰高速公路环境中，SAE L4自动驾驶汽车的安全系统应满足哪些功能安全需求，涉及基于人工智能的传感和感知子系统的故障和功能效率不足？

FSR是根据基于A270荷兰高速公路的ODD的汽车安全标准ISO 26262和DIS/ISO 21448得出的。这两个标准共同的危害分析和风险评估（HARA）过程确定了15个汽车安全完整性等级（ASIL）A或更高的安全目标。FSR是关于基于人工智能的传感和感知子系统中的故障和功能效率不足，这可能会导致违反安全目标。ISO 26262 FSR解决了与故障相关的两种失效类型：（i）非运行状态和（ii）输出数据损坏。SOTIF FSR解决了基于相机的物体检测、分类和跟踪功能在ODD中对照明和天气条件的功能效率不足的问题。安全需求最终根据Apollo的安全概念确定，该概念在部件失效时激活车辆级安全状态。

RQ2：如何评估SAE L4自动驾驶汽车在基于人工智能的传感和感知子系统中的故障和功能缺陷方面的功能安全性？

功能安全评估在两个层面上针对FSR进行；设计层面和实施层面。对于设计级评估，我们采用了一种现有的方法，通过检查车辆软件架构中的相关安全策略来评估FSR的完整性。由于该方法和安全策略没有考虑到与基于人工智能的组件相关的FSR，我们进一步扩展了该方法，以包括与人工智能安全相关的最佳实践和与人工智能相关的设计工件（数据集、神经网络模型）。我们方法的应用表明，Apollo设计中缺乏基于人工智能组件安全的最佳实践。对于可行性研究报告的实施层面评估，考虑了一种基于模拟的测试方法。

概述了一种系统的方法来推导所引发的FSR的测试用例。随后，我们演示了在用于评估FSR的模拟测试设置中执行示例测试用例。

6.2 主要贡献

本文的主要贡献总结如下：

1.结合汽车行业安全标准ISO 26262和DIS/ISO 21448的安全流程，引出荷兰公路设置的功能安全需求。

2.通过额外考虑人工智能安全相关的最佳实践和人工智能相关的设计工件（数据集、神经网络模型），将现有的方法应用于评估架构级别FSR对基于人工智能组件的FSR的满足情况。

3.概述一种系统的方法，用于推导基于模拟的功能安全需求测试用例，并在模拟测试设置中演示该方法。

6.3 限制和未来工作

在这里，我们概述了当前研究的一些局限性，并提出了未来的研究方向。我们首先讨论FSR的启发过程，特别是ApolloFSR的制定。然后，我们讨论了基于人工智能的组件的AV功能安全评估的未来机会。

最后，我们概述了基于仿真的功能安全评估测试方法的可能扩展。FSR启发的最后一步是根据Apollo的车辆级安全状态安全概念确定FSR。例如，可行性研究报告“交通灯检测和识别组件的非操作状态不应导致自动驾驶汽车在运行模式下忽略红色或黄色交通灯：穿过十字路口。”被定义为“如果交通灯检测与识别组件变为非运行状态，自动驾驶汽车应转换为安全状态”。以这种方式制定可行性研究报告可能无法完全证明其合理性，因为Apollo可能会实施其他实现前可行性研究报告的机制，但不会实现其最终版本。因此，基于模拟的测试方法评估FSR的原始公式（以及确定的FSR）可能更适合功能安全评估。

此外，用于确定可行性研究报告的方法也有进一步的局限性，例如缺乏对决策的考虑↵FSR中考虑的不同严重程度的故障。例如，FSR“感知环境（摄像头）模块输出数据损坏或丢失不应导致AV与物体碰撞”被定义为“如果感知环境（摄像机）模块输出的数据损坏或损坏，AV应转换为安全状态。”FSR的前一版本适用于所有严重程度的数据损坏和丢失，因为它与确保故障不违反安全目标有关。然而，定义的FSR可能只对数据损坏或丢失的某个阈值严重程度有意义，这不允许正常运行。因此，在制定可行性研究报告时，应考虑故障类型的进一步粒度。目前的功能安全评估方法仅部分解决了与基于人工智能的组件相关的功能安全问题。FSR启发过程是使用行业安全标准进行的，这些标准包括其范围内的基于人工智能的组件。然而，FSR启发过程没有考虑基于AI的组件的特定特征，例如在新条件下的不可预测行为。在评估功能安全性时，也可以考虑基于人工智能的组件的特定特征。这是在我们的设计级评估中完成的，但在我们的基于模拟的测试方法中没有进行探索。

我们基于模拟的测试方法是通用的，也可能包括基于人工智能的组件的安全考虑。例如，基于人工智能的组件的一个安全问题是它们对输入数据分布的微小变化的鲁棒性较低。因此，在测试基于AI的组件时，可能有必要在低粒度下考虑测试条件的变化来定义测试用例。

我们的方法中没有定义或测试基于模拟的测试的这些考虑因素，这可能是一个有趣的未来研究方向。此外，尽管我们研究了基于人工智能的传感和感知子系统的V&V方法的最新进展，但我们没有考虑将其整合到我们的方法中。探索如何使用这些方法来评估在行业安全标准框架内引发的FSR，就像我们的情况一样，也是一个有趣的研究方向。

最后，由于在为Apollo建立模拟测试设置时面临的技术挑战，我们基于模拟的测试范围仅限于示例测试用例的演示。因此，通过基于模拟的测试对FSR进行功能安全评估需要进一步调查。我们还注意到，FSR的可能测试用例空间，特别是SOTIF要求，很大。因此，在未来的工作中，与组合测试技术或用于评估FSR的自动关键测试用例生成相关的研究方向可能值得探索。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。