EPB功能安全笔记(14)：FTA定量分析之ISO26262对随机硬件失效的要

本文要点：

在上文（EPB功能安全笔记(13)：FTA定量分析之FMEDA和FTA的交互）中介绍了FMEDA的背景并基于案例说明了FMEDA的分析步骤以及与FTA之间的交互。FTA的底事件包含了识别出来的能造成违背整车安全目标的硬件失效，将这些底事件转换成系统对硬件的功能安全需求输入给FMEDA；FMEDA则通过分析构建出底层元器件失效模式与硬件功能安全需求之间的失效网络，并结合元器件的失效模式及对应的失效率，进一步确认该功能安全需求所对应的以下列举的各个失效率并作为FTA的输入。

• 安全相关故障失效率总和：λ _unsafe
• 单点故障失效率总和：λ _SPF
• 残余故障失效率总和：λ _RF
• 潜伏故障失效率总和：λ _MPF_L

FTA与FMEDA之间的交互

FTA如何运用FMEDA的输入，取决于ISO 26262对所研究的系统的随机硬件失效要求。ISO 26262中从两个方面对随机硬件失效提出了要求：

1.硬件架构度量的评估(Evaluation of the hardware architectural metrics)

2.随机硬件失效导致违背安全目标的评估(Evaluation of safety goal violations due to random hardware failures)

本期将对这些随机硬件失效要求进行介绍。

硬件架构度量的评估

简单来说，硬件架构度量用来评估相关项的架构应对随机硬件失效时的有效性。这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件，即那些能对安全目标的违背或实现有显著影响的元器件，并限于这些元器件的单点故障、残余故障和潜伏故障。

硬件架构的度量旨在实现以下目标：

• 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量)；
• 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量)

而要想实现以上目标，在已经确定了随机硬件失效率相关数据的情况下，需要确定硬件架构度量的方法和评价标准，具体来说包括：

• 客观上可评估：度量是可核实的，并且足够精确以区分不同的架构；
• 支持最终设计的评估(基于详细的硬件设计完成精确计算)；
• 为硬件架构提供基于ASIL等级的合格/不合格准则。

接下来就ISO 26262推荐的单点故障度量和潜伏故障度量具体方法和评价标准展开说明。在说明之前再次回顾一下安全相关的故障类型及对应的失效率表达符号，方便后文理解。

安全相关的硬件要素的故障分类

上图中：

• 距离n 表示了在同一时刻存在的导致违背一个安全目标的独立故障的数量(n=1对应单点故障或者残余故障，n=2对应双点故障)；
• 距离等于n 的故障位于圆环n 和n-1之间的区域。
• 除非在技术安全概念中明确表示需要分析，否则认为距离高于n=2的多点故障是安全故障，即只需要考虑双点故障。

假设所有的硬件失效都是相互独立的，那么每个安全相关的硬件要素的失效率总和λ都可以按照下面的公式来表示：

λ_unsafe = λ _SPF + λ _RF + λ _MPF + λ _S

式中

• 安全相关故障失效率总和：λ _unsafe
• 单点故障失效率总和：λ _SPF
• 残余故障失效率总和：λ _RF
• 多点故障失效率总和：λ _MPF
• 安全故障失效率总和：λ _S

而对于多点故障，可以进一步拆分：

λ _MPF = λ _MPF_D + λ _ MPF_P + λ _MPF_L

式中

• 多点故障失效率总和：λ _MPF
• 可探测的多点故障失效率总和：λ _MP_D
• 可感知的多点故障失效率总和：λ _MPF_P
• 潜伏故障失效率总和：λ _MPF_L

1.1.单点故障度量（single-point fault metric）

单点故障度量反映了相关项通过安全机制覆盖或通过设计手段(主要为安全故障) 实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低，系统可靠性更高。

1.1.1.单点故障度量的计算

单点故障度量的计算公式为：

式中分母即安全相关的失效率总和。单点故障度量公式图示如下。

单点故障度量图示

1.1.2.ISO 26262对单点故障度量的要求

ISO 26262中对单点故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

1.2.潜伏故障度量

潜伏故障度量反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段(主要为安全故障)实现的对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低，系统可靠性更高。

1.2.1.潜伏故障度量的计算

潜伏故障度量的计算公式为：

式中分母即安全相关的失效率总和。潜伏故障度量公式图示如下。

潜伏故障度量的图示

1.2.2.ISO 26262对潜伏故障度量的要求

ISO 26262中对潜伏故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

随机硬件失效导致违背安全目标的评估

简单来说，对随机硬件失效导致违背安全目标的评估是用来确定违背安全目标的残余风险已经足够低。ISO 26262对这一评估推荐了两个方法：

• 第一个方法包括使用概率的度量,即“随机硬件失效概率度量”( Probabilistic Metric for random Hardware Failures，PMHF)，通过使用例如定量故障树分析(FTA)及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
• 第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。

因为在实际开发中所有的公司几乎都使用PMHF，所以本文只对PMHF展开说明，感兴趣的朋友可以参考ISO 26262，part5了解第二种方法。

PMHF表示在汽车运行周期中每小时平均失效概率。ISO 26262对PMHF的要求如下，从表格中可以看出两点：

1.PMHF对ASIL A没有要求；

2.PMHF对ASIL C和ASIL B的要求一样，同时与ASIL D的要求差一个数量级。

针对这个目标值，必须要澄清以下两点：

PMHF的目标值不是失效率 (failure rate)

失效率和PMHF的单位虽然都是(per hour)，但是意义不同。也正是由于这一点太容易被混淆，在ISO 26262-2018版的part5中附录F和part10中8.3.2专门针对PMHF补充了说明。附录F中提供的PMHF计算公式如下，通过公式可以清楚为什么PMHF和失效率的单位都是（per hour）但是意义不同，最大的不同点在于PMHF需要考虑多点失效的暴露持续时间 (Lifetime) ：

暴露持续时间从故障可能发生时开始，包括：

a)与每个安全机制有关的多点故障探测时间间隔，或者当故障不对驾驶员显示(潜伏故障)时的车辆生命周期;

b)单次行程的最长持续时间(对于驾驶员被要求以一种安全方式停车的情况)；及

c)直到车辆进入车间维修前的平均时间间隔(对于驾驶员被警示要去维修车辆的情况)。

因此，暴露持续时间取决于涉及的监控类型(例如:连续监控、周期性自检、驾驶员监控、无监控)和探测到故障后的反应种类。对于连续监控触发向安全状态转移的情况，它可以短至几毫秒。当没有监控时，它可以长到车辆的生命周期。

与此同时，对车辆去维修的平均时间的假设取决于故障的类型:

a)对舒适性功能的降级，200次车辆行程;

b)对驾驶辅助功能的降级，50次车辆行程;

c)对黄色警告灯或影响驾驶表现时，20次车辆行程;

d)对红色警告灯，1次车辆行程。

其中对于乘用车而言，1次车辆行程通常假设为1小时。

PMHF的目标值没有绝对意义，仅用于新旧设计的比较

ISO 26262, part5中对PMHF这个特征的说明可能是整个ISO 26262最关键的说明。

注1：这些……定量目标值没有任何绝对的意义，仅有助于将一个新的设计与已有设计相比较。其目的是生成可用的设计指导，并获得设计符合安全目标的可用证据。

换句话说，对研究对象进行PMHF计算的目的在于验证新设计的可靠性比上一代更好。只有对一个全新设计的产品在没有任何可参照的PMHF值时才会采用ISO 26262中推荐的表格进行评定。

下期预告

本文对ISO 26262中对随机硬件失效的硬件架构度量的评估要求和随机硬件失效导致违背安全目标的评估要求进行了说明，并指出了其中的关键点供读者参考。

在进行FTA分析时，我们假设所有的底事件之间是相互独立不受彼此影响的。但是对于一个系统而言，底事件A的发生可能同时导致底事件B的发生，这样一来FTA的分析结果就失真了。如何避免这种情况呢？下期将对DFA（Dependent failure Analysis）进行介绍。

本文转载自：焉知智能汽车