本文要点：在上文“EPB功能安全笔记(9)——FMEA说: 唯有进化才能不负ISO 26262的力荐”中系统地介绍了一种全新的适用于E/E产品的系统性失效（systematic failure）的方法——FMEA-MSR FMEA-MSR(FMEA for Monitoring and System Response)。可以说FMEA-MSR方法的诞生来源于ISO 26262的需求驱动，针对E/E系统的特点优化了传统FMEA的方法论。

DFMEA与FMEA_MSR的关系

回到功能安全本身，除了系统性失效外，ISO 26262还关注随机硬件失效。在随机硬件失效分析面前，FMEA的局限性就暴露无遗。首先，FMEA只是用来做定性分析而不是定量分析，而对硬件开发的目标是把随机硬件失效限制在能接受的范围，仅有定性分析是不够的，ISO 26262第5部分给出了可量化的衡量标准；其次，FMEA只用来进行单点故障分析，而不能进行多点故障分析，即在分析某个失效模式时，假设的前提是系统中所有其他功能都是正常工作的。但是随机硬件失效的类型除了单点失效外，多点失效也是ISO 26262需要考虑的失效类型。

根据笔者的经验，ISO26262第5部分对硬件开发的指导可以说是整个标准中最为晦涩难懂的章节，其难点在于随机硬件失效相关的概念多且绕，且随机硬件失效评估方法背后的逻辑和难以理清。也正是由于硬件随机失效的复杂性和功能安全要求的抽象性交错在一起，使得寥寥数语无法讲清楚其中要点。基于此，从本文开始，将试图按照如下主题大纲层层递进展开说明，希望为读者理清功能安全对硬件开发的随机硬件失效的要求，并提供一些有价值的参考。

1.随机硬件失效相关概念辨析

2.FTA与定性分析

3.FTA与FMEDA之间的联系

4.FTA与定量分析

本文将对第一部分进行展开。

1.故障，错误，失效

“故障”、“错误”、“失效”在三个词在日常使用中往往不会去细究个中差别而造成一定程度上的混用，但也正因为这三个词的字面意思接近，即使混用也不影响表达。但是，在研究随机硬件失效时非常有必要理清”熟悉ISO 26262中定义的三个概念之间的联系，这是理解随机硬件失效相关的众多概念的基础。

ISO 26262中对三者的定义如下：

• 故障（fault）: 可引起要素或相关项失效的异常情况(abnormal condition that can cause an element or an item to fail)
• 错误（error）: 计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异(discrepancy between a computed, observed or measured value or condition, and the true, specified or theoretically correct value or condition)
• 失效（failure）：要素按要求执行功能的能力的终止(termination of an intended behaviour of an element or an item due to a fault manifestation)

如果借助ISO 26262第10部分的说明图，我们很容易得出以下结论：

• 同一个层级（系统层或组件层）中，故障（fault）是失效（failure）的因，失效是故障的果；错误（error）是故障的表现形式。
• 不同层级间，组件层的失效是系统层的故障。

故障导致失效的示例，截图来自GB/T 34590, 第10部分

图中将故障分为三类：

• 系统性软件故障
• 系统性硬件故障
• 随机硬件故障

对于前两类统称为系统性故障，由它们导致的失效则称为“系统性失效”。“系统性失效”与“随机”这两个概念是相斥的。因为系统性失效是以确定的方式产生的失效，造成这类失效的系统性故障是设计或生产流程、操作规程、文档或其他相关因素导致的，一旦故障存在，则系统性失效100%会发生。比如软件开发工程师人为误写的一个bug，每次程序运行bug对应的代码100%会输出错误的结果。

而随机硬件故障则是在硬件要素的生命周期中，非预期发生并服从概率分布的客观规律，这就好比我们都知道人终有一死，但是没有人能预料到哪一天会死，对于电子元器件也是如此。

2.随机故障的类型

顺着上节末的比喻，我们可以进一步思考以下问题：

1.对于一家正在运营的公司来说，世界上每个人的死都会导致公司运行陷入崩溃吗

答案是否定的。

2.如果这家公司的总裁已经将所有经营公司的信息和资源都给了他的儿子，那么总裁的突然死亡会让这家公司陷入崩溃吗

答案也是否定的，但是如果总裁和儿子突然同时不幸去世就有可能。

回到汽车的ECU上，也存在同样的情况，只不过我们的关注点不是公司的运营情况，而是整车是否发生危害，换句话说，是否违背整车的安全目标。一块ECU由数以万计的元器件组成，虽然每个都有发生随机失效的可能，但并不是所有元器件的失效都必然导致都必然导致危害的发生；有些元器件的失效有导致危害发生的可能，但是需要同时发生另一个元器件失效。

基于此，我们可以将随机硬件故障的类型进行进一步的细分。接下来对这些故障进行说明。

随机硬件故障的类型，截图来自GB/T 34590, 第5部分

2.1.单点故障（Single-point fault）

单点故障具有以下两个特点：

1.可直接导致违背安全目标；

2.是硬件要素的故障，对于该硬件要素，没有任何安全机制预防其某些故障违背安全目标。

比如一个未被监控的电阻，该电阻至少有一种失效模式(例如:开路)有违背安全目标的潜在可能。

单点故障与标签“没有任何安全机制”是完全绑定在一起的。如果一个硬件元器件有至少一个安全机制(例如：微控制器的看门狗)，则该元器件的故障不被归类为单点故障。对于安全机制无法覆盖的那部分故障被归类为残余故障。

2.2.残余故障（Residual fault）

残余故障具有以下两个特点：

1.可直接导致违背安全目标

2.是硬件要素的故障，对于该硬件要素，有至少一个安全机制预防其某些违背安全目标的故障。

比如如果仅用棋盘(checkerboard) RAM 测试的安全机制来检查随机存储器(RAM)模块，则不能探测出桥接(bridging)故障，桥接故障就如果可以直接导致违反安全目标的话，便可以称其为残余故障。

值得一提的是：在实际开发设计时，几乎没有诊断覆盖率能达到100%的安全机制。

2.3.可探测的双点故障（Detected dual-point fault）

可探测的双点故障具有以下两个特点：

1.仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

2.被防止其潜伏的安全机制所探测。

比如被错误探测和纠错码（EDC) 保护的闪存：按照技术安全概念通过测试对这些 EDC逻辑中的故障进行探测并触发响应，如通过警示灯通知驾驶员。

2.4.可感知的双点故障（Perceived dual-point fault）

可探测的双点故障具有以下两个特点：

1.仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

2.在规定的时间内被驾驶员所感知（有或无安全机制探测）。

比如故障发生后会显著和清楚的影响功能，双点故障可被驾驶员感知。

注意：

如果双点故障同时被驾驶员感知并被安全机制探测，该故障可被归类为可探测的双点故障或可感知的双点故障，但它不能同时被归类为这两种类型。因为一个故障如果既是可探测的双点故障, 又是可感知的双点故障, 则潜伏故障度量会错误的计算该故障两次。

2.5.潜伏的双点故障（Latent dual-point fault）

潜伏的双点故障具有以下两个特点：

1.仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

2.不被安全机制所探测也不被驾驶员感知。直到第二个独立故障发生前，系统始终可以运行且驾驶员也不知道发生了故障。

比如对于被 EDC保护的闪存。在读取时，EDC纠正了单个位的永久性故障值，但这不是在闪存中纠正也无信号指示。在此情况中，故障不能导致安全目标的违背(因故障位已得到了纠正)，且它不是可探测的(因对单个位故障无信号指示)，也不是可感知的(因对应用的功能性无影响)。如果在 EDC 逻辑中发生了额外的故障，它可导致失去对单个位故障的控制，从而导致潜在的安全目标的违背。

2.6.安全故障（safe fault）

顾名思义，安全故障就是即使发生了也不违背安全目标的故障。细心的读者可能发现了图中有两处安全故障，它们对应着两种不同的情况：

1.n>2的全部n点故障 (除非安全概念显示它们与安全目标的违背有关联)

2.与安全目标违背无关的故障。

随机硬件故障的类型，截图来自GB/T 34590, 第5部分

比如，三个电阻串联以克服短路情况下的单点故障问题,因为需要三个独立的短路才会违背安全目标(n=3)，每个独立电阻的短路可被视为安全故障。

2.7.小结

我们可以参考下图来梳理思路，将上述提到的失效模式进行串联。

失效模式分类流程图示例，截图来自GB/T 34590, 第5部分

下篇预告

本文系统地介绍了随机硬件失效相关的概念，为后续文章的展开奠定基础。下期我们将站在鸟瞰的视角对FTA（Fault Tree Analysis）进行介绍。