EPB功能安全笔记(15)：什么是DFA(Dependent Failure Analysis)

本文要点：在前几期的文章中对ISO 26262推荐的功能安全分析方法FMEA(Failure Mode and Effects Analysis)和FTA(Fault Tree Analysis) 进行了详细的介绍。FMEA和FTA的主要目的概括如下：

FMEA在构建系统架构的基础上识别出系统的底层各个功能的失效模式，并自下而上识别出这些底层的失效模式对整车层造成的失效影响，进而评估系统使用过程中所有可能的风险，并制定和实施适当的措施以优化产品开发和生产环节的质量控制以降低故障成本。

FTA从整车层Safety Goal出发，基于系统架构搭建故障树从而自上而下识别出所有可能违背Safety Goal的底层事件；在确定电子元器件相关的底事件的失效率基础上，通过布尔运算定量分析系统是否符合功能安全对随即硬件失效的要求。

因为FMEA用来进行单点故障分析，因此在考虑某个底层故障时既不考虑其他故障对自身的影响，也不考虑对其他故障的影响；而FTA进行定量计算的前提是假设所有的底事件之间是相互独立的不受彼此影响。但是对于一个真实的系统而言，可能出现两种情况：

底事件A发生故障同时导致底事件B和底事件C发生故障

底事件A发生故障导致底事件B也发生故障

这两种情况也存在安全风险，如果在安全分析如FMEA和FTA中不对这两种情况进行考量的话，安全分析的结果是不完整的。ISO 26262将对以上两种情况的分析称为“相关失效分析(DFA, Dependent Failure Analysis)”。相对于FMEA和FTA而言，读者对DFA比较陌生，2011版ISO 26262中也只有第9部分对其进行了简单而抽象的说明。2018版ISO 26262对DFA的内容进行了大量补充，并增加了很多示例，从某种程度上说明了DFA应该受到更广泛的重视。本文将对DFA进行说明，抛砖引玉，希望能给读者带来一些参考。

ISO 26262将相关失效归纳为两类：

1. 共因失效Common Cause Failure (CCF)

一个相关项中，由一个单一特定事件或根本原因引起的两个或多个要素的失效。Failure of two or more elements of an item resulting directly from a single specific event or root cause which is either internal or external to all of these elements.

共因失效图示，截图来自ISO 26262, 2018, part1

2. 级联失效 cascading failure

同一个相关项中，一个要素的失效引起另一个或多个要素的失效。failure of an element of an item resulting from a root cause [inside or outside of the element] and then causing a failure of another element or elements of the same or different item.

级联失效图示，截图来自ISO 26262, 2018, part1

ISO 26262将相关失效分析的目的归纳为两点：

（1）通过识别潜在的引起相关失效的原因及相关失效的发起点(DFI, Dependent Failure Initiators)，确认在设计中充分实现了功能安全所需的独立性或不受干扰的能力 (to confirm that a required independence or freedom from interference is sufficiently achieved in the design by analysing their potential causes or initiators)

（2）必要时定义安全措施以减轻可能引起的相关性故障 (to define safety measures to mitigate plausible dependent failures, if necessary.)

对于第一点中提到的独立性(independence)，读者比较熟知的是ASIL分解，ISO 26262中要求ASIL分解的前提是：ASIL分解需要安全要求具有冗余性，且分配给充分独立的架构要素。

而对于第一点中提到的不受干扰的能力(freedom from interference)，指的是两个或两个以上的要素之间不存在可能导致违背安全要求的级联失效。举个例子，如果功能安全概念往下分配时对软件模块A是ASIL D的要求，而对其他软件模块是QM的要求，那么对于其他模块存在的比如篡改模块A存储地址的风险，被称为对模块A的干扰，需要有相应的安全机制来避免这些干扰。

结合上一节的内容，相关失效分析的目的可以简单概括为：证明系统既不存在级联失效，也不存在共因失效。进一步地，ISO 26262指出，当级联失效和共因失效都不存在时，可以认为实现了独立性；当不存在级联失效时，则证明相关性有避免干扰的能力。

相关失效定义的图示，截图来自ISO 26262, 2018, part1

实际上和DFA相关的元素(element)可以从安全分析的结果中识别出来，这些情况包含于：

1.双点故障，比如：

a. 安全相关的功能及其对应的安全机制；

b.功能性冗余

2.共享元素(shared elements)引起的单点故障或残余故障，比如：

a. 时钟

b.嵌入式稳压器

安全分析着眼于识别单点故障、残余故障和多点故障，以评估是否满足ISO 26262，part5中对随机硬件失效的指标要求，当指标不能满足时需要定义新的安全机制对设计进行改进；而DFA则通过证明安全机制之间或者安全机制与底层故障之间不存在相关失效，从而证明安全机制的有效性。从这个角度看，DFA相当于从另一个视角填补安全分析过程中的“盲区”，因此DFA应在进行安全分析的过程中就予以考虑，从而保证最终的安全分析结果已经充分考虑了相关失效。

2018版ISO 26262中总结了DFA流程图，旨在梳理相关失效分析中的主要活动。

DFA流程图，截图来自ISO 26262, 2018, part11

限于篇幅，本文对DFA流程图的步骤总结如下，感兴趣的读者可以阅读ISO 26262, part11, 4.7.6了解每一步的详细说明。

Steps

Description

Comments

B1

DFA decision and identification of hardware and software elements

分析系统架构并评估每一个元素或者一组元素之间的相关性

B2

Identification of DFI

罗列出DFI清单

B3&B4

Sufficiency of insight provided by the available information on the effect of identified DFI

证明DFI清单的完整性

B5

Consolidation of list of relevant DFI

基于DFI清单创建独立性安全需求

B6

Identification of necessary safety measures to control or mitigate DFI

对安全需求定义安全措施

B7&B8

Sufficiency of insight provided by the available information on the defined mitigation measures

证明安全措施的完整性

B9

Consolidate list of safety measures

合并安全措施清单

B10

Evaluation of the effectiveness to control or to avoid the dependent failures

评估控制或避免相关故障的有效性（如进行FTA, FEMA分析）

B11&B12

Assessment of risk reduction sufficiency and if required improve defined measures

安全分析结果审核

下期预告本文介绍了相关失效分析DFA的背景，目的以及展开步骤。如本文所述，DFA主要确认在功能安全设计中充分实现了所需的独立性(independence)或不受干扰的能力(freedom from interference)。那么，如何深入理解“独立性”和“不受干扰的能力”？下文将结合示例对其进行说明。