ADAS的功能安全要求：涉及安全相关的故障模式，而不是预期的功能

概述

传感器的功能安全要求往往非常通用，包括输入信号的故障模式，因此难以实施和测试。也许作者关注的是系统的预期功能，但预期功能不在安全要求的范围内。安全要求表达了作者对故障模式的期望。本文以雷达传感器的对象列表为例，说明了明确这一点的重要性。

背景

雷达、激光雷达和摄像头等传感器被广泛用于实现现代车辆中的ADAS功能。由于传感器可能会发生故障并提供错误的对象数据，因此必须指定功能安全要求（FSR）以应对潜在的安全目标违规。如果分配给系统元素的FSR在错误的级别（例如车辆功能级别）上指定，则从这些要求中得出的技术安全要求（TSR）将显示较差的质量。不能低估对功能安全性的影响。本文给出了一个示例，并解释了如何提高FSR和TSR质量的实用解决方案。

ADAS常见的功能安全要求

在ADAS传感器规范中，常见的功能安全要求是针对误报和漏报：

传感器不得报告虚假对象

传感器应报告所有相关对象

这些要求看似合理，但更详细的分析表明，这两项要求并不适用于传感器系统。实际上，这些要求是车辆功能被错误地归咎于传感器的几种故障模式中的两种。

对象列表故障模式分析

如果在传感器外部实施数据融合，传感器通常会报告对象列表。每个对象都由几个属性（例如物理属性）描述。在寻找功能或信号的故障模式时，了解感兴趣的信号及其子信号的组成非常重要。对象列表可以根据其目的显示几种故障，而每个对象可以根据其属性显示其他故障。以下分析并不完整，目的是展示一些潜在的陷阱。

对象列表的目的是报告相关对象（这里不再进一步分析“相关性”，但必须在项目中定义验证标准）。因此，可以从列表中添加和删除对象。可能出现的问题包括：

一个对象应该被添加到列表中，但没有被添加（假阴性）

一个对象不应添加到列表中，但被添加了（误报）

一个对象应从列表中删除，但没有被删除（误报）

一个对象不应从列表中删除，但被删除了（假阴性）

一个对象应添加到列表中，但添加得太早或太晚（灰色正值）

一个对象应从列表中删除，但删除得太早或太晚（灰色负值）

这是与对象列表相关的六种故障模式，尽管并非所有这些故障模式都必然与安全相关（这取决于车辆功能和车辆架构）。功能所有者（通常是OEM）需要通过归纳分析方法分析这些故障模式的影响。

详细列表中的前四种故障模式涵盖了上述两种故障模式，因此不禁要问，这份简单的列表是否错误。答案是肯定的。这两种故障模式指的是车辆功能（例如，对物体进行紧急制动），而六种故障模式指的是传感器实现的功能（提供对象列表）。在车辆层面，尚无法知道传感器是否会发送对象列表。在车辆层面，很明显，车辆应对与预期功能相关的对象做出反应，而不应对其他对象做出反应。然而，简单地将这些要求分配给传感器并不能确保足够安全的实现，这一点从更完整的六项要求列表中可以看出。

对象属性故障模式分析

下一个问题是：距离或相对速度等对象属性怎么办？如何考虑这些属性的故障模式？此示例表明，在识别故障模式之前正确定义信号类型非常重要。传感器提供对象列表，列表的故障模式如上所示。列表的每个元素（报告的对象）都有几个属性，报告的数据也可能以不同的方式失效。例如，如果使用动态范围的很大一部分通过12位信号描述偏航率等物理属性，则以下模拟信号故障模型适用：

值停滞

超出上限（超出范围）

低于下限（超出范围）

正偏移（偏差）

负偏移（偏差）

积极跳跃

负跳跃

正向漂移

负漂移

振荡

因此，这为此类对象属性提供了另外10种故障模式。其他故障模型通常适用于状态数较少的信号或通信总线。

安全目标违规分析

对于对象列表和对象属性的每种故障模式，必须通过归纳分析方法分析其对安全目标违规的影响，这是功能或系统所有者（通常是OEM）的责任。然后可以得出所有安全相关故障模式的安全要求。

通用要求的问题

最后但并非最不重要的一点是，通用要求的另一个问题是它们可能涵盖损坏的输入信号对输出信号质量的影响。在系统无法检测和/或控制此类故障的情况下，无法完全实现“传感器不得发送损坏的对象数据”之类的要求，因为潜在的根本原因是输入信号本身。让我们更详细地看一下。

传感器接收系统外部产生的信号。例如，雷达传感器检测来自物体的回声。传感器提供的对象列表可能会失效（见上文）。列表可能会失效，列表中的每个对象也可能会失效。这种失效的根本原因是什么？根据 (1)，系统元素的每个输出信号失效都可能源于系统本身或损坏的输入信号。因此，每当传感器提供损坏的对象列表时，根本原因可能是系统本身，也可能是系统检测到的损坏信号。因此，将以下要求分配给传感器根本没有意义：

传感器不得报告虚假对象。

在这种情况下，底层车辆功能要求在系统层面上尚未得到正确细化。相反，对传感器的可行要求可能是：

传感器应检测任何可能导致对象列表安全相关损坏的内部系统故障。

（注意：当然也必须定义“任何故障”和“安全相关”。）以这种方式制定的要求明确排除了输入信号侧的任何故障。对于雷达传感器，回波质量可能会受到影响，即偏离在未受干扰环境中产生的预期回波。实际上，物体属性（传感器测量的属性除外）和环境都会影响信号，从而导致传感器的输出信号损坏。在分析故障模式和规范安全要求时，必须考虑完整的内部和外部（从传感器的角度来看）信号路径：

传感器发射雷达脉冲

雷达脉冲从天线发射到物体

雷达脉冲在物体上反射

回声从物体传输到天线

传感器接收回声

第一步和最后一步可能会因传感器故障而失败。第二步和第四步可能会因环境条件而失败。第三步可能会因物体属性对信号质量的影响而失败。因此，五个步骤中至少有三个步骤可能会对雷达传感器提供的对象数据产生影响，因此根本原因在传感器之外。因此，不能将“传感器不得报告虚假对象”之类的安全要求分配给传感器。

功能安全要求的细化

功能安全要求通常源自功能的故障模式。因此，上述通用安全要求（“传感器应检测任何内部系统故障……”）需要针对所有这些故障模式进行细化。

对象列表示例：

传感器应检测任何可能将不存在的对象添加到对象列表中（误报）的系统内部故障。

对象数据示例：

传感器应检测出任何可能导致相对速度人为增加5%以上的系统内部故障。

可以为对象列表和对象数据的所有其他故障模式指定类似的要求。

总结

为了规范系统的安全要求，功能故障的根本原因需要是系统故障和输入信号故障。分配给系统的安全要求应明确规定导致正在调查的输出信号故障（=功能故障）的系统内部故障。特别是，系统的安全要求不应过于笼统，以至于它们还涵盖环境对系统输入信号的影响。此类要求不能由系统实现。整体功能安全概念必须涵盖环境（一般而言：系统外部）对系统输入信号的影响。