安全是自动驾驶汽车开发中最复杂的要求之一，被列为接受和采用自动驾驶汽车的首要考虑因素。最近发生的涉及自动驾驶汽车的致命事故清楚地表明，安全对自动车辆的接受、测试、验证和部署至关重要。在传统的汽车系统中，安全隐患是由硬件或软件故障或错误引起的。然而，由于性能限制，自动化车辆相比于传统的硬件或软件故障或错误，对安全隐患高度敏感。例如，在恶劣的天气中，伪造消息和漏检会给自动驾驶车辆带来很大的风险。预期功能安全(SOTIF)是一个安全类别，它解决了由于自动驾驶车辆的性能限制而造成的危险，特别是感知系统的危险。

1.1简介

自动驾驶汽车，可以减少事故，改善行驶环境，减少拥堵，帮助老年人和其他弱势群体，并产生其他社会效益。然而，最近发生了几起涉及不同程度自动化的自动驾驶汽车的事故，这在很大程度上降低了人们对自动驾驶汽车早期的兴奋感。

对于这些事故，如果这些车辆的安全系统能够按照其规定的自动化水平进行设计和正常运行，情况会好很多。在佛罗里达州的特斯拉事故中，车辆未能激活前向碰撞预警(FCW)系统和自动紧急制动(AEB)。在Uber事故中，车辆处于计算机控制下，没有启用紧急制动，使系统依赖于车辆操作者的安全。在加州的特斯拉事故中，车辆未能检测到受损的碰撞衰减器，并以每小时71英里的速度撞上了它。

目前，作为一个行业，我们不完全了解自动驾驶汽车安全的本质和如何设计安全的自动驾驶汽车。关于如何评估、分析、计算、测量自动驾驶汽车设计和安全级别的讨论很少。所以需要从全面描述它开始，

1.2 描述自动驾驶的安全性

与在航空，过程控制和汽车等其他行业中使用的自动驾驶相比，尽管自动驾驶汽车的基本概念相同，但自动驾驶汽车的安全性具有其他行业中不存在的特定属性，接下来简要讨论这些属性。

1.2.1 性能退化

传统的安全是基于硬件组件的故障，这被称为安全的可靠性方法。相比之下，即使没有硬件设备出现故障，也有可能发生涉及自动驾驶车辆的事故，只是自动驾驶车辆的一些功能或预期功能出现性能下降。解决这些情况下的安全问题被称为预期功能安全(safety of the intended functional, SOTIF)，这是一个应用于自动驾驶车辆安全的相当新的概念。一些故障是由于自动驾驶汽车部件的性能下降造成的，通常涉及更高级别的处理或更高级别的自动化，例如服务故障。这种安全问题超出了ISO 26262标准，但是与其他安全框架，如系统理论过程分析(System Process Analysis, STPA)或其他实时分布式系统兼容。

例如车辆检测系统的故障，其中感知系统提供了漏检(即假阴性)或伪造的检测(即假阳性)。这种情况的发生是由于环境数据的处理非常复杂，特别是在恶劣的天气或夜间能见度低的情况下，目标检测功能容易出现错误和缺陷。这些失败中的任何一个都可能是灾难性的，并可能导致事故或伤害。另一个例子是无线电探测和测距(雷达)系统，它只在物体移动时才正确地探测到物体，因此由于性能的限制而无法探测静态物体。安全问题出现在上述性能下降的场景中。

1.2.2 专注于软件

众所周知，随着线控系统的发展，车辆中软件的数量持续快速增长。自动驾驶汽车的大部分功能是在软件中实现的，因此需要将感知系统视为一组软件服务器，每个服务器都向系统的其余部分提供服务。可以将这些不同的功能称为车辆检测服务器、行人检测服务器、道路检测服务器等。与传统行业相比，无人驾驶汽车的软件在规模和范围上都要大得多，因此，我们应该关注软件的安全性。如前所述，如果软件服务偏离了正确的服务，就可能发生故障，这可能会导致安全隐患和安全风险。最终，自动驾驶汽车的整体安全将取决于它的软件的安全。

1.2.3 非确定感知系统

在没有硬件故障的情况下，传统行业的感知系统在本质上大多是确定性的。 例如，在汽车系统中检测进气歧管压力或发动机转速是确定性的。 相反，自动驾驶车辆的感知系统是不确定的，当其性能下降到无法避免服务故障的程度时，会导致高水平的误报。感知系统的不确定性源于这样一个事实，即人们永远不知道它的性能何时会下降到系统所提供的服务开始出现故障的地步。 例如，当天气恶化或系统出现检测错误时，由感知系统提供的服务会产生随机的故障。

1.2.4 感知系统的复杂性

感测诸如温度或压力之类的基本物理现象相对简单，仅涉及某些确定性传感器，某些电子设备和通信。 相反，由于缺少被感知或感知的结构，因此感测或检测诸如另一车辆，道路边界，城市街道或街道交叉口的人造实体或构造是复杂的。 感知系统的复杂性意味着容易出错，从而降低了整车的性能或安全性。

1.2.5 总体系统复杂性

除了其感知系统之外，自动驾驶车辆还包括定位和地图绘制，计划和控制，从而导致高度复杂的系统。系统复杂性的主要问题之一是使得测试安全性具有挑战性，尤其是在使用机器学习技术的情况下。因为这会使设计不透明，由于没有人们可理解的设计用于验证和测试，因此使设计和测试计划难以跟踪到需求。另外，当系统很复杂时，系统的安全性会受到复杂性和紧密耦合的影响。系统复杂性另一方面的问题是，自动驾驶车辆在复杂的外部环境中操作，并且由于自动驾驶车辆的范围外的事件（例如无论是否是自动驾驶的其他车辆）引起的安全隐患。因此，自动驾驶汽车的安全属性与航空电子，过程控制和汽车等其他行业的安全属性明显不同。

与航空电子，过程控制和汽车等其他行业的安全性相比。一方面存在一些安全共性，例如涉及部件故障和故障率的安全性（所谓的功能安全性）。另一方面，自动驾驶汽车行业有两种在其他行业中并不普遍的安全性：SOTIF和多代理安全性。

因此，自动驾驶汽车安全性的安全性类型包括：（1）ISO 26262定义的传统功能安全性；（2）SOTIF；（3）多代理安全性。

1.3 预期功能安全

如前所述，SOTIF是自动驾驶安全的重要组成部分，尤其是在汽车工程师协会（SAE），是初期研究的重点。

系统工程在设计复杂或大型系统时使用V模型来指定和描述关键任务。这些关键任务包括需求，设计，实现，测试，验证和确认，它们在特定时间执行，如下图中所示。需求，设计和实现的生命周期阶段（或任务）在左侧执行在V的右侧执行涉及测试，验证和验证的任务。在V模型上（而非以线性方式）描述这些活动的原因是，在进行需求说明时，同时定义了了相应的验证规范。Gauerhof等人描述了如何构造验证目标，以确保自动驾驶中行人检测功能的安全性，解决由于性能限制或功能不足造成的危害。

Gauerhof等人的总体目标是为使用人工智能（AI）机器学习技术实现的行人检测功能提供强大的安全保证案例。为了防止功能不足（即解决性能限制），这组规范必须完善预期的功能，并且这些规范必须适合任何车辆操作环境。他们认为，需要在所有潜在的物理环境中对预期功能进行一组结构良好且经过验证的规范。功能不足的主要原因有两个：（1）环境的不确定性和复杂性；（2）功能实现中的不确定性，例如机器学习。

为了完成对内在不确定性的彻底分析，必须充分了解和指定预期的功能。Gauerhof阐述了三种SOTIF危险源：规格不足，语义鸿沟和演绎鸿沟。如果预期功能比指定功能多样化，则会规格不足。通过概括解决规格不足的问题可能导致安全要求集的定义不足。语义鸿沟是指对安全目标的满意度使用隐性知识。演绎鸿沟涉及在不同抽象级别上使用无效假设，从而导致意外功能。

Gauerhof等人是开发了一系列结构良好的验证目标，以证明机器学习实现的行人检测功能无法实现其预期功能。 行人检测功能包括两个子任务：分类和定位。 对于每个步行者类别，他们提出了以下功能需求，需要在以后的阶段进行验证：

•对行人的高度（X1像素）和宽度（X2像素）进行分类。

•如果隐藏了Y％的人，则将检测到行人。

•每1000帧的误报率小于W1。

•每1000帧的W2假阴性数少于W2。

•错误分类的检测次数少于B1。

•置信度水平应能弥补分类正确性的实际不确定性。

在降低由于规格不足引起的危害带来的风险方面，提出了以下验证目标：

•充分认知环境。

•充分认知任务。

•对环境属性的不可预测性或不确定影响的敏感性足够低。

在机器学习的背景下，一方面要减少因语义鸿沟造成的危害所致的风险，另一方面又要声称其用于训练，测试和验证数据集的参考文献的相关性。为了解决这些问题，建议以下子目标：

•足够准确地描述行人等级。

•足够准确地描述定位精度。

•实际环境与所述环境之间的差异非常小。

在机器学习的背景下，确定了以下问题，同时减少了由演绎鸿沟引起的危害所致的风险：（1）分类特征可能会被错误学习（2）特征分类器可能会被错误地实现。为了解决这些问题，建议在神经网络训练之前和训练过程中使用以下验证目标：

•数据集足以满足预期的功能。

•显著减少重叠现象。

•显著减少欠拟合现象。

要评估机器学习实现的功能的弱点，普遍方法是：特征可视化，输入空间的结构化，形式验证以及处理不确定性。就后者而言，每个类输出的置信度级别不代表对象本身存在的可能性。因此，不确定度计算可用于衡量分类结果的可靠性。不确定度量化可用于进一步的措施，从而提高后续轨迹规划任务的整体鲁棒性和可靠性。基于此提出了以下证据：

•对机器学习功能的基本影响已被充分理解。

•机器学习功能非常强大。

•学到的功能足以满足要求。

考虑到机器学习普遍的弱点（例如对对抗攻击的敏感性），建议在系统开发过程中使用以下验证目标集：

•更改参数不会违背安全要求。 

•培训平台与目标平台之间的差异不会违背安全要求。

•目标平台的更改符合安全要求。 

总而言之，Gauerhof等人的论文提供了一组验证目标，旨在提供强有力的安全案例，以解决由于功能不足（例如，性能限制）而引起的安全隐患，尤其是在自动驾驶汽车感知系统中引起的隐患。

1.4自动驾驶汽车安全的综合方法

在讨论自动驾驶汽车的安全性时，安全性主要有以下三个方面：功能安全性，SOTIF和多代理安全性。在最高层次上，基本概念和对安全的理解是相同的，风险或降低风险可能导致事故。但是，在较低的抽象级别上，将这些安全性观点应用于自动驾驶汽车安全性时的方法并不相同，尤其是在讨论多用户安全性时。本节中提出了一个框架，用于在较低的抽象级别上集成和统一对安全性的讨论。

统一框架基于可靠性理论，该可靠性理论不仅包括功能安全性，而且还包括可靠性，可用性和安全性等基本原理，并且基于因果关系。根据功能安全规范，事故的根本原因是故障，错误和失效，它们可能导致危险，构成风险并导致事故。如果不加以处理，则会产生一个高度不安全的系统。相反，如果处理得当，可以产生一个高度安全的系统。

由知名安全标准（如ISO 26262）起草的安全概念的定义。故障定义为“可能导致元素或项目失效的异常情况，可以将其分类为永久性或间歇性。”错误是“计算值，观察值或测量值或条件与真实值之间的差异”。可能由于不可预见的运行条件或故障而导致错误。失效是“终止元素或项目执行所需功能的能力。”

安全危害被定义为“由于项目的故障行为而引起的潜在伤害或事故源。”危害是一个抽象概念，需要对其进行保护才能实现或具体化，并造成伤害或事故。 人员或资源面临危险时的情况称为风险。 风险级别很多，为了正确区分它们， 以下等式传达了各种风险级别的概念：

其中R是安全风险，PE是危险发生的概率，S是危险的严重程度，PC是情况可控的概率。

功能安全被定义为“由于电气/电子系统故障行为造成的危害而没有不合理的风险”。因此，功能安全只处理为实现自动化而引入的设备的故障。从这一定义可以清楚地看出，功能安全并不像多代理安全那样处理由时间性能限制引起的危险，或由其他驾驶员（人类或自动）或其他代理引起的危险。

1.4.1基于风险的多代理安全方法

如下图所示模型，该模型可用于使用基于风险的方法来讨论多用户安全性，从而可以与其他安全性观点（即功能安全性和SOTIF）集成在一起。该模型描述了一种统一的方法，用于对三个主要自动驾驶汽车安全类别的事故根本原因进行建模：功能安全，SOTIF和多用户安全，从功能安全的角度描述了导致事故的事件链。

就SOTIF而言，某些功能单元（如自动驾驶汽车的感知系统）的性能限制可能导致错误，进而导致故障，构成危险并最终导致事故。一个很好的例子是光检测和测距传感器在恶劣天气下的性能局限性，特别是在雨天和雾天时，会导致误报和误报。因此，即使功能完善（即没有硬件和软件故障），激光雷达装置也可能是导致事故的错误根源。

可以将为功能安全性开发的整个安全性理论和应用程序用于SOTIF的建模和讨论。为了在功能安全性框架内协调SOTIF，可以严格按照测量设备的性能限制，对错误定义进行补充。性能限制在上图中被建模为性能错误，性能错误可能导致其他可能导致事故的错误和故障。

从多用户安全的角度来看，自动驾驶汽车上其他代理的行为或自动驾驶汽车的计算系统驱动程序的行为，可能是导致故障或危害的根源并导致事故。此框架需要对故障、错误、失效、危险和风险的概念进行额外的定义和说明，以使其与功能安全性相一致。对于多用户安全而言，可以添加如下驾驶失效的定义：“终止驾驶员或车辆系统避免危险情况的能力。” 

因此，通过对图示模型的潜在事故根源采用更通用的模型，并通过添加与故障，错误和失效有关的其他定义和概念，我们可以对自动驾驶汽车的安全性拥有统一的看法，涵盖三个方面类别：功能安全，SOTIF和多用户安全。 总之，就功能安全而言，硬件或软件故障会导致错误和故障，从而导致安全隐患。 对于SOTIF而言，感知系统的性能下降会导致错误，从而导致涉及安全隐患的故障。 最后，对于多用户安全而言，基于人或计算机系统的驱动程序可能会导致故障，从而导致安全隐患。

1.4.2 HARA和降低风险

ISO 26262标准详细说明了HARA（危害分析和风险评估）和风险降低的阶段，这些阶段从功能安全的角度对设计安全系统至关重要。从SOTIF和多代理安全的角度出发，解决HARA和降低风险来设计安全系统并不是一件容易的事。因为在功能安全的情况下，这是通过对各个系统组件使用汽车安全完整性等级（ASIL）分类并根据ASIL等级以及在SOTIF的情况下设计特定的安全机制（即降低风险）来完成的以及多用户安全性，业界尚未定义相应的ASIL级别。

在功能安全的情况下，ASIL的确定取决于暴露于危险的可能性，潜在危害或事故的严重性以及可控性，如等式（1）所示。使用3个级别的严重性，4个级别的暴露性和3个级别的可控制性来完成此操作，从而导致ASIL需要3x4x3 = 64级别，并分为QM，ASIL A，ASIL B，ASIL C和ASIL D。对于传统的汽车应用，在如何确定或估算严重性，暴露程度和可控性水平以及如何估算ASIL水平方面拥有丰富的知识和技术。却没有用于SOTIF和多代理安全的此类知识和技术，因此需要在这一领域进行更多研究和工作，使它们与功能安全中的相协调。

1.5 SOTIF安全措施与机制

使用适当的标准（例如ISO 26262）或系统工程概念（例如验证目标）不能有效保证规避危险或风险。我们需要将上述内容与能够主动应对危害并将风险降低到可接受水平的技术措施或机制结合起来。在行人检测功能的背景下，Gauerhof等人进行了分析。我们提出了一些在功能和系统层面的措施，这些措施将有助于减少功能不足引起的风险。在功能级别上建议的安全措施包括，根据明显影响机器学习性能的已知因素对机器学习输入进行预处理，的对机器学习输出进行后处理，对信心水平的调整，以便做出驾驶行为决策和轨迹规划适合于感知功能的可靠性。

在系统级别建议的安全措施包括：

•多样的冗余增加了功能的可靠性。对于行人检测，存在几种可能性，例如LIDAR，RADAR和传统的计算机视觉算法。

•操作模式（也称为降级模式）取决于车辆的环境模型。只要环境模型是可靠的，就可以在更广泛的可能轨迹范围内做出决策。相反，如果检测到具有低置信度的物体，则根据谨慎和防御性的驾驶策略选择降级模式。

•操作模式之间的转换可确保持续的驾驶行为。

•对假设的运行时监视允许验证关于环境的假设属性是否仍然有效。在运行时检测到环境属性的分布与设计假设之间的差异表明，受过训练的功能存在错误，或者表明系统在未经充分训练的环境中运行。

•必须从系统工程角度审查适用于自动驾驶的驾驶员辅助系统（例如，紧急制动辅助系统）。必须明确在何种程度上必须在系统级别采取措施以减少单个功能组件的完整性要求。

其他有助于减少由与车辆检测功能相关的功能不足引起的风险的安全措施的示例包括容错技术和故障包含协议，例如Pimentel和Bastian以及Pimentel，Bastian和Zadeh讨论的技术。

一旦确定并分析了安全隐患和风险以提高安全性，就必须使用技术将风险降低到可接受的水平。通过使用容错设计方法来降低自动驾驶车辆的安全风险，该方法包括组件复制，安全机制和安全措施。容错是在存在一个或多个指定故障的情况下提供指定功能的能力。在本节中，我们讨论后面用到的术语，并提出一种容错体系结构，该体系结构充分利用了复制组件。冗余是关键元素的特性重复，旨在执行所需的功能或表示信息。冗余用于实现安全目标或指定的安全要求或表示安全相关信息。为了提高可用性或允许进行故障检测，重复的功能组件可以是冗余的一个实例。例如，向表示安全相关信息的数据添加奇偶校验位可提供冗余，以实现故障检测。安全机制是通过电气和电子功能或元件或通过其他技术实现的技术解决方案，以检测和减轻或容忍故障，或控制或避免故障，以维持预期的功能或达到或维持安全状态。

在物品内实施安全机制可防止故障导致单点故障或减少残留故障并防止潜在的故障。安全机制要么（a）能够过渡到系统或使其处于安全状态，要么（b）能够向驾驶员发出警报，以使驾驶员期望控制功能所定义的故障后果安全概念。一种或几种安全机制构成一种安全措施，其定义是一种活动或技术解决方案，用于避免或控制系统性故障和随机硬件故障以及减轻其有害影响。不合理的风险是在某些社会背景下被认为是不可接受的风险。

1.5.1容错感知系统

典型的自动驾驶汽车感知系统传感器和执行器通过以太网，控制器局域网（CAN），CAN可变数据速率（CAN-FD）和通用串行总线（USB）通信驱动程序提供其输出（或输入），从而可以与所有传感器接口感知系统。这些传感器包括摄像机，LIDAR单元，RADAR系统，超声波传感器，惯性测量单元（IMU）等。用于以太网，CAN和USB的通信驱动程序通常与诸如中央处理器（CPU），图形处理之类的计算单元互连。如下图所示，通过外围组件互连Express（PCIe）总线实现了GPU单元和现场可编程门阵列（FPGA）。众所周知，可以通过使用复制的组件来提高系统的安全性，特别是使用主动复制，假设无故障条件，组中的所有服务器并行执行相同的服务请求并执行协议，以在给定相同输入的情况下就输出达成共识。

感知系统的计算、通信、传感器和执行器组件。S：传感器，A：执行机构，CAN，控制器区域网络，FPGA：现场可编程门阵列，GPU：图形处理器。

对于自动驾驶汽车的感知系统，可以复制以下内容：计算节点，通信和计算节点，通信线路，传感器和执行器。尽管可以如下图所示对任何组件进行复制，但只有最安全关键的组件或模块才应具有冗余或复制的组件，其中包括计算元素，感知系统和通信功能。凭感觉来看，使用主动复制时，系统安全性得到了提高，因为每当任何元素出现故障时，它的副本就可以提供与失败相同的服务，因此系统可以继续正常运行。显然，复制组件，尤其是昂贵的传感器（如LIDAR）会增加成本，因此必须谨慎权衡以安全换取成本。

复制的架构组件:物理描述。E：以太网，U；通用串行总线，C：控制器区域网络，CN：计算节点。

复制的架构组件:逻辑描述。E：以太网，U：通用串行总线;C，控制器区域网络，CCN：计算和通信节点。

1.6 故障控制协议

如前所述，当系统是复杂的，系统的安全性受到相互作用的复杂性和紧密耦合的影响，这将导致错误和故障传播。控制错误和故障传播从而降低风险的一种方法是使用故障包含协议。在本节中，我们提出了一种适用于车辆检测的故障控制协议。故障控制是降低风险的主要方法之一。其思想是检测故障并最小化其对系统其余部分的影响，并可能隔离出故障的组件、服务或模块。容错协议由感知系统模型、控制器模型和错误检测三部分组成，并按层次结构进行组织。故障包含协议在顶层(控制器模型)运行，利用感知系统模型和错误检测活动对感知系统故障进行建模。

1.6.1 感知系统模型

自动驾驶汽车的感知系统具有多种功能，如检测其他车辆、车道、道路、行人等。这些功能并没有完美地执行，因此它们将受益于SOTIF类别中的安全措施。为了提供容错设计，我们对感知系统中任何安全关键型传感器的行为建模，如下图的状态转换图所示。感知系统模型在无误差的正常运行状态下启动。当有一个错误在车辆检测功能,该系统的瞬态故障状态,错误在哪里监视时间间隔τ。如果没有间隔τ内进一步报告错误,则系统返回到正常运行状态;否则系统进入半永久故障状态和车辆检测状态，如果车辆检测功能复位或重新启动，例如切换车辆并重新启动，则系统返回正常工作状态。但是，如果车辆检测误差计数器超过了极限值，则认为感知系统永久失效。

安全临界感知系统组件的状态转移模型。EC:错误计数器。

1.6.2 控制器模型

车辆控制系统中处理车辆检测的相关故障包含模型如下图所示。安全控制器状态，假设无错误操作，在状态的正常操作和检测到的车辆之间切换。在车辆检测状态下，控制器执行安全控制动作，返回正常运行状态。当一个错误发生时，无论是漏检还是假检，控制器都会进入相应的状态。在进入漏检或伪检测状态时，控制器执行紧急控制动作，使控制器状态进入故障安全状态，以避免事故或减少危害。当处于车辆检测状态时，控制器可能执行不安全的控制操作(UCA)，导致故障安全状态。从后一种状态，控制器的动作可能会导致事故，这取决于进入故障状态时的车辆总体情况和环境条件。

安全关键控制系统组件的状态转换图。SCA：安全控制行动;UCA：不安全控制措施;ECA，紧急控制行动。

1.6.3错误检测

故障包含协议要求检测错误。感知系统硬件传感器故障检测比软件故障或错误检测容易得多;例如，正确地识别或识别假探测或漏检是非常困难的。检测软件错误需要对底层软件中使用的算法有深入的理解。车辆检测,如果检测软件是基于机器学习算法如深度学习(DL),现在看来是一个尚未解决的问题,因为我们作为一个研究团体不完全了解DL算法实际执行对象检测由于“端到端”的本质过程。因此，神经网络模型被认为是不透明的。如果检测软件是基于模型的计算机视觉算法,例如,涉及面向梯度直方图特征提取(HOG),特征提取，线性支持向量机(SVM)分类器的训练,和使用的滑动窗口技术评估检测到车辆的一个边界框,然后一种N-version编程可以用于错误检测。一种检测感知系统错误的方法是使用一组关键性能指标(kpi)来跟踪车辆检测系统的可信度水平，从而得出最终的结论，即车辆检测到或未检测到车辆。kpi可以是算法各阶段参数的函数，如HOG特征法、SVM分类器滑动窗口、边界框等。如果置信水平较低，则可以假定存在误差。采用冗余度可以大大降低误码率;更具体地说，如果使用多个副本，则可以使用多数投票人。然而，无论采用何种软计算方法以及如何对其输出进行评估，自动车辆感知系统中的错误和故障检测都是一项具有挑战性的工作，而研究工作才刚刚开始。

1.7 总结

SOTIF是一个重要的安全类别，在研究和实施中逐渐建立，是对多主体和功能安全类别的补充。SOTIF涉及到处理由于性能限制或功能不符合而导致的危险，即使在没有故障的情况下也是如此。功能不充分性主要有两个来源:(1)固有的不确定性和复杂性的环境,和(2)内在的不确定性在功能实现,例如,机器学习为了完成彻底的内在不确定性的分析,目标功能必须被理解和规定。SOTIF危害的一些可能来源包括:信息不全、语义鸿沟和演绎鸿沟。在本章中，我们描述了SOTIF的特征，并总结了它的主要概念，特别是什么是功能不确定性和例子。此外，提出了一个综合的安全框架，该框架使用基于风险的方法将三种安全类别(功能安全、SOTIF和多用户安全)统一起来。此外，我们还总结了SOTIF安全措施和降低风险机制的最新研究成果。从顶层的角度来看，有几种主要的方法可以减少由危害、性能限制或功能缺陷造成的风险。一种方法是使用严格的系统工程规则来确保自动驾驶汽车s的安全性，并提供强有力的安全保证案例。另一种方法是结合来自适当规程的技术解决方案、技术和方法(例如，容错机制)来实现相同的目标。

我们总结了Gauerhof等人的工作。开发了一组结构良好的验证目标，以演示一个机器学习实现的行人检测功能实现了预期的功能。关于减少由物种不足引起的危害所带来的风险，作者提出了以下验证目标:(a)环境是众所周知的;(b)任务是众所周知的;(c)对环境属性的不可预测或未知影响的敏感性极低。使用适当的标准(如ISO 26262)或系统工程概念(如验证目标)不能保证危害不会发生或降低风险的措施有效。我们需要结合上述技术措施或机制，积极应对危险，并帮助将风险降低到可接受的水平。

在行人检测功能的背景下，由Gauerhof等人分析。我们提出了一些功能和系统层面的措施，将有助于减少由功能不充分引起的风险。建议在功能级安全措施包括机器学习的预处理，输入根据已知因素显著影响性能和机器学习产出的处理,包括调整的信心水平基于已知因素影响性能,所以决定驾驶行为和轨迹规划适应感知功能的可靠性。建议的系统安全措施包括(a)多种冗余;(b)工作模式，亦称退化模式，根据车辆的环境模式而定;(c)工作模式之间的转换确保连续的驾驶行为;(d)假设的运行时监测;建立驾驶员辅助系统(如紧急制动辅助系统)。皮门特尔和巴斯蒂安提出了适用于降低SOTIF风险的其他安全措施和机制。