ISO26262 Part 9 之相关失效分析DFA/FFI的适用场景

Alex_Zhao_JLU

已于 2024-08-06 10:23:01 修改

阅读量700

点赞数 30

分类专栏：功能安全文章标签：安全

于 2024-08-06 10:20:23 首次发布

本文链接：https://blog.csdn.net/Aleeex_Zhao/article/details/140934486

版权

功能安全专栏收录该内容

42 篇文章 2 订阅

订阅专栏

1. 标准要求

通过分析其潜在原因或引发因素，确认设计中充分体现了要求的独立性和免于干扰；
如有必要，定义安全措施，以减轻可能的相关失效；

免于干扰FFI：用于证明分配了不同ASIL等级的，或者无ASIL等级和有ASIL等级的要素可以共存；
免于干扰和不存在共因失效 DFA：用于证明在进行ASIL等级分解时的独立性；
在这里插入图片描述

2.相关失效分析考虑架构特征：

相似的和不相似的冗余要素；
由相同的软件和硬件要素实现的不同功能；
功能及其相关安全机制；
功能的分割或软件要素的分割；
硬件要素间的物理间距，有隔离或无隔离；
共同的外部资源；

在进行相关失效分析之前，需要分析各个要素的ASIL等级；

3. 需要DFA分析情况

定性或定量的安全分析（FMEA、FTA）可以作为DFA的输入，但与安全分析不同的是，DFA更加关注架构要素之间的耦合关系，执行DFA分析的目的是当架构设计中出现以下如图4所示的**四种情况（①~④）**时，通过DFA分析结果提供充分的证据这些情况存在的合理性：
在这里插入图片描述
需要执行DFA分析的四种情况

a. 情况①：架构设计中存在不同ASIL等级的要素，需要证明不同ASIL等级的安全要素之间免于干扰；

b.情况②：架构设计中存在ASIL等级的要素，又存在QM要素，需要证明安全要素与非安全要素之间免于干扰；

c. 情况③：开发过程中应用了ASIL分解，需要证明冗余路径的独立性；

d. 情况④：设计中使用了安全机制，需要证明安全机制与被诊断要素之间的独立性；

针对情况①和情况②，当DFA不能提供充分的证据证明要素间的免于干扰时，则应按其影响的最高ASIL的要素开发，
在这里插入图片描述
针对情况③，如果DFA不能提供充分的证据证明ASIL分解后的冗余路径之间的独立性，则分解后的需求不能低于原始需求的ASIL等级，这种情况下的ASIL分解是没有任何收益的，

情况④与情况③是类似的，如果DFA不能提供充分的证据证明安全机制与被诊断要素之间的独立性，则该安全机制的有效性和诊断覆盖率都会受到威胁，
在这里插入图片描述
总的来说，在架构设计过程中执行的DFA，目的就是为了找出架构设计中的属于情况①~④，然后分析其存在的合理性，若发现存在相关失效的可能，则根据分析结果进行设计优化。

4. DFA分析的实施方法

ISO 26262-11:2018，4.7.6条款中给出DFA的完整分析流程，为了方便理解，此处提供一个简化版的流程，如图所示：
在这里插入图片描述
以下是针对图所示DFA流程的进一步说明：

a. 010：架构设计（系统、硬件、软件架构设计），该步骤是DFA分析的输入；
– 来源可以时FMEA和FTA的分析
–注1:系统性失效和随机硬件失效都有可能成为相关失效。
–注2:对相关失效的潜在可能性的识别可基于演绎分析法,例如,割集检查或者FTA中重复的相同事件。
–注3:归纳分析法也可支持相关失效的潜在可能性的识别,例如,在FMEA中多次出现的具有相似失效模式的相似元器件或组件。

b. 020：分析两个及以上要素之间是否存在DFI；DFI检查表是一种用于识别DFI常用方法；

c. 030：分析耦合因素是否导致相关失效；

– 举个例子，

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

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

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

d. 040：分析030步骤产生的相关失效是否违背安全目标或安全需求；

e. 050：不违背安全目标或安全需求的相关失效按质量管理要求优化；

f. 060：分析是否有安全机制控制那些违背安全目标或安全需求的相关失效；

g. 070：违背安全目标或安全需求且无安全机制控制的相关失效按功能安全要求优化；

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

h. 080：若已有安全机制控制违背安全目标或安全需求的相关失效，则进行下一组相关失效的分析，回到020步骤，直到所有相关失效的组合（即图4中满足①~④的所有情况）分析完成。