MUNIK解读ISO26262：功能安全之DFA相关失效分析

 （DFA: Dependent Failure Analysis）

—原创文章，文章内所有内容文字资料，版权均属本公司所有，任何媒体、网站、公众号或个人未经本公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公司授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任. 

回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务

回到知识分享，请点击链接：MUNIK中国-技术分享

我们在学习功能安全过程中，经常会听到很多安全分析方法，有我们熟知的FMEA(Failure Modes Effects Analysis)和FTA(Fault Tree Analysis)还有功能安全产品设计中几乎绕不开的FMEDA(Failure Modes Effects and Diagnostic Analysis)，相比于它们而言，今天我们的主角DFA（Dependent Failure Analysis）可能会稍微有点陌生。

在开发功能安全产品过程中，我们会进行大量的定性分析工作，其中主要就包含上面提到的FMEA和FTA。这两种分析方法一个是从底层的要素出发，分析要素故障会对系统造成何种失效影响，一个是从系统已知的单一失效模式出发，深挖造成失效发生的根本原因。无论如何，它们的研究对象都是单独的要素和系统之间的关系，并且是建立在这些底层要素之间不会发生互相影响的前提下，但是在实际的电子电气产品中，要素之间的相互影响是普遍存在的，要素之间的这种影响会不会影响我们终极目标（顶层安全目标）的实现？我们只有执行了DFA才会知道答案。

反过来讲，我们执行DFA就是为了验证我们设计中的要素之间互相影响的可能性和严重程度都比较低，它们之间尽可能不要互相影响，其实这就是在证明标准讲的“独立性”，标准对于独立性的定义是：两个或多个要素之间不存在导致违背安全要求的相关失效。意思就是只要要素具有充足的独立性以后，也就不会发生相关失效。这里面的相关失效其实就两种情况，一种叫级联失效，一种叫共因失效。关于级联失效的解释，标准是分为了内部原因和外部原因这两种情况，无论是内部原因还是外部原因，归根结底都是前者的故障最终导致后者的失效。共因失效是由于一些公用资源，公用信息等发生故障，从而导致多个组件同时发生失效的情况。

1.       所有项目都要做DFA吗？

首先DFA（相关失效分析）的执行与ASIL没有关系，这是与FMEA还有FTA明显的一个区别，其次就是在架构设计过程中若产生了ASIL分解，有要素共存的情况（低等级的要素我们通常会认为他的开发要求不够严谨，可能会对高要求的产品造成不利影响），有冗余设计，功能电路和安全机制等情况时，那么就要执行相关失效分析。

2.       DFA分析对象

在功能安全设计中，DFA一般在整个产品架构设计结束后执行，因为分析对象是整个产品，所以没必要细化到某一个子组件内部进行分析，将产品的架构设计框图作为DFA分析的输入信息就可以。

3.       DFA的执行流程

标准对于DFA执行的详细流程见下图，此图虽然是定位于芯片层面，但是任何层面的产品，使用同样的方法，那么思考逻辑就是一样的。

上图中重要的活动可概括为以下四点：

l                      目标识别：就是明确分析对象。因为相关失效分析是分析要素之间是否会有影响，所以分析对象肯定是要素组，在实际产品设计中，内部的要素数量一般会比较庞大，那么我们在考虑分析产品内部是否存在共因失效或者级联失效时，如果将产品所有的组件进行配对分析的话，这个工作量会很巨大。标准也考虑了这个问题，因此对实施相关失效分析对象也是做了提前的分类和筛选的。这些互相可能发生相关失效的要素，他们之间会存在一些比较明显的关系特征，比如：我们在架构设计中进行了ASIL分解，那么分解后的两个要素，就要考虑之间会不会有相关失效的发生，或者有要素共存的情况发生时，若低等级的要素和高等级的要素进行了交互，那么它们之间就要执行相关失效分析。如果有冗余设计，功能电路和其安全机制这种关系也要对其进行相关失效分析，我们在进行其他安全分析比如FMEA分析过程中多次出现的具有相似失效模式的相似元器件或组件,FTA过程中出现重复的相同事件，这些都是可以作为DFA分析的输入指导。

l                      确定耦合因子类型：在明确产品中可能会发生相关失效的要素之后，按照标准中的要求进行耦合因子类型的判断。标准对于耦合因子进行了总结和归纳分为了共享资源，共享信息输入，环境抗干扰能力不足，系统耦合，相同类型的组件，通信，非预期接口这七类。

l                      失效分析：在确定了要素组的耦合因子类型后，对于每种耦合因子深层次的失效原因，故障模式（也就是故障发生如何导致系统失效），故障影响进行分析。根本的失效原因我们通常称之为相关失效引发源，缩写DFI。

我们举个例子，第一步目标识别：假设我们的架构设计中存在PLL(锁相环，实现外部输入信号与内部震荡信号同步)和对其的监控电路CMC，它们之间的关系就属于功能电路和安全机制的关系，所以我们要分析这两者会不会发生相关失效。

第二部分析耦合因子的类型：我们分析后发现PLL和CMC共用了一个电源，因此就满足“共享资源”类型的耦合因子。

第三步失效分析：也就是目前的这个阶段，我们对这种情况分析后发现，如果共用电源电压过高或过低，PLL和CMC都无法工作，最终影响了产品安全目标的实现。因此我们就要制定安全措施来对此情况进行处理，也就是我们的下一个环节。

l                      措施：通过上面的分析活动之后，进入到第四步制定措施，因为共享电源的故障会导致PLL和CMC的失效，最终违反安全目标，我们对电源增加独立的PVT监控电路（安全机制），当电源电压过高或过低时，PVT会检测到异常，并将异常上报给CPU进行故障诊断，最终结果可能会向外发送一个异常信号。从发现异常，到上报异常，再到系统发送出异常信号，整个过程会控制在60ms以内（其中发送出异常信号就是经常讲的安全状态，其中的60ms应小于它最终分配到的FTTI）。这些增加的安全措施最终都要通过一些验证或测试手段证明他的有效性。

需要注意的是这里的安全措施不局限于安全机制。