ISO26262 Part 9 之 DFA的输入确定方法

1. 标准要求

在进行DFA分析的时候，首先需要确定分析对象，标准中的说的方法如下：

7.4.1 应按照第8章安全分析的结果识别出相关失效的潜在可能性。
注1:系统性失效和随机硬件失效都有可能成为相关失效。
注2:对相关失效的潜在可能性的识别可基于演绎分析法,例如,割集检查或者FTA中重复的相同事件。
注3:归纳分析法也可支持相关失效的潜在可能性的识别,例如,在FMEA中多次出现的具有相似失效模式的相似元器件或组件。
注4:应用于半导体的相关失效分析的示例可参考GB/T34590.11—2022的4.7。

2.经验方法汇总

基于经验，方法汇总如下：

方法1：对于ASIL C, D的产品，原本就会进行FTA分析，在FTA分析的最底层是该层级的最小颗粒度的元素，有相关性的元素形成了一个个cut set。**而DFA正可以直接参考这些cut set进行分析。**如果cut set=1，说明存在单点故障，FTA中就会提出新的安全需求；cut set=2时，DFA分析是否该两者之间是否存在相关性失效，以证明单点故障已被覆盖，当然此时可能还需要对潜伏故障的诊断；对于cut set≥3时，理论上此时已经是安全故障，但是仍应当通过DFA分析，证明该多点之间不存在相关性失效，否则可能存在系统性的失效导致多点同时失效。方法1是比较传统的分析方式，分析两两要素之间的关系，需通过FTA的形式，筛选出需要避免相关失效的元素后，再进行互相之间的分析。看似合理，在实现的时候会有一种感觉，需要分析的两两元素组合太多了。比较实际的可能是，尤其诊断cut set≥3的情况，通过一些概括性的分析，证明避免潜伏故障的安全机制与功能与避免单点的安全机制之间的不相关性，以减少工作量。此外，方法1还有个缺点在于，非常依赖于正确的FTA分析

方法2：基于先前列出的需要分析相关失效的场景，见【DFA的使用场景】，进行DFA分析。这样的分析，有可能会遗漏，但当ASIL=A或者B，不存在FTA分析时，该方法也是最有效实施的方案，只是需要确切的给出论据，设计中相关的适用场景均被分析到了。这样的方法，需要架构设计者和安全分析的人员有很好的意识和信任，确认所有需要被分析的设计已经被DFA所包括了。

方法3：当存在FTA或者FMEA分析，标准提出了一种隐含的方法。参加ISO 26262-9, Clause 7.4.1 NOTE 2和NOTE 3

7.4.1: The potential for dependent failures shall be identified from the results of safety analyses in accordance with Clause 8 NOTE1 Both systematic failures and random hardware failures have the potential to be dependent failures. NOTE2 The identification of the potential for dependent failures can be based on deductive analyses, e.g. examination of cut sets or repeated identical events of an FTA. NOTE3 The identification of the potential for dependent failures can also be supported by inductive analyses, e.g. similar parts or components with similar failure modes that appear several times in an FMEA.
在FTA或者FMEA中多次出现的相同的时间、组件或者失效模式，均可能是需要分析的潜在相关失效。但该方法是从分到失效中去找相关性，遗漏的概率很大，更多的只能作为一些补充更合适。

方法4：这里提一个可能更易于项目去实现的方法。形式有点像FMEA，对该层级中所有的组件（不会遗漏），判断是否属于DFA需要分析的factor来分析，该元素是否会影响其他元素，主要目的是找出它可能影响的组件，并分析其后果。这样，不需要要求较高的FTA，也不太会遗漏，虽然也许在分析可能受影响的组件及其后果时，会需要分析较多组件，但大多分析出来的结果会是一样，可能需要单独分析的组件不会太多，会是一个较为高效的做法，该做法本质上可以结合在FMEA过程中实现，比如增加FMEA分析的check项“是否影响其他模块”，“local effect”来分析。

方法5：**以附录中列出的所有factor class为导向，逐个分析该class下有哪些可能的factors，设计中是否存在此类factor。**这样的做法可能存在遗漏，而且主要依赖分析者对设计的理解以及对相关factor的敏感度。比如考虑shared source，应该考虑设计中是否存在相同的电源，相同的时钟，相同的软件库等。

参考：

以上内容，部分引用自 https://mp.weixin.qq.com/s/ZWZyV1lnX8MYtgg8ZjO2cA