浅谈功能安全关联失效分析（DFA）及一种可用于实践的相关性矩阵分析法
1►什么是DFA？
DFA（Dependent Failure Analysis，相关失效分析） 是ISO 26262标准中提出的一种系统化分析方法，也是ISO26262中最区别于其他标准的安全分析。它旨在识别和评估系统中因要素间关联性引发的失效风险，确保功能安全设计中所需的独立性（Independence）和免于干扰能力（Freedom from Interference）得到充分实现。在ISO26262：2018 – Part 9中提到了如下种类的关联失效。
图1.关联失效分类图
由该框图可得出，防止相关性失效的核心目标包括：
1.防止共因失效（Common Cause Failure, CCF）：由单一根本原因导致多个要素同时失效，例如共享电源故障引发传感器与控制器同时宕机。
2. 防止级联失效（Cascading Failure, CF）：一个要素的失效引发其他要素的连锁失效，如某个功能模块错误导致其安全机制亦无法检测或报出。
DFA通过分析这些关联失效的潜在原因（Dependent Failure Initiators, DFI），验证设计中是否通过隔离、冗余或独立的监控机制有效规避了相关风险，从而支撑ASIL分解、冗余架构设计等关键安全策略的实施。
2►DFA与FMEA/FTA的关注区别点
传统安全分析方法（如FMEA和FTA）存在以下局限性，需通过DFA进行补充：
1. FMEA的不足：FMEA的分析对象默认为单点故障，忽略了组件之间相互关系导致的共因失效和级联失效。例如，传感器与主控芯片若取用自同一电源，则二者之间存在关联失效的风险。这类关联失效无法有效地通过FMEA识别。
2. FTA的假设缺陷：FTA分析始于顶事件，并根据分析系统的架构以及功能逻辑关系一路追溯至底事件，底事件即顶事件（安全目标违背）的根本原因。FTA分析中假设底事件独立，因此忽略了实际系统中故障传递的关联性。例如，看门狗若与其监控对象共享时钟源，则时钟故障可能导致功能失效且看门狗无法触发安全状态。
因此， FMEA/FTA更加关注于识别单点故障与双点/多点故障，开发中配合通过评估ISO 26262: 2018-5定义的量化指标（如SPFM/LFM）来定义安全机制，并在必要时进行补充、优化，以达成硬件故障度量指标。但如前述段落提到，他们相对忽略架构要素之间的耦合关系。因此，关联失效分析（DFA）作为补充手段，可用于重点验证安全机制有效性不受共因失效源头的影响。如ISO 26262-5:2018第7.4.3节所述，DFA可以在硬件设计规范阶段，用于进一步制定已识别出的共因(如共享资源)的安全机制；在验证阶段，则可用于确认设计实现达到预期防护效能，以此形成完整的设计-验证闭环。
表1.Table. DFA与FTA、DFMEA的关注点区别
3►DFA可重点用于识别的场景
标准ISO26262：2018-Part 9中粗略的提到了DFA可以实施的场景 1) 不同ASIL等级的要素免于干扰 2)QM和带ASIL等级的要素免于干扰 3）ASIL等级分解需要证明冗余要素独立性 4) 功能与安全机制的独立性。
其中，安全机制的完整性验证是必不可少的考虑要点。若安全机制本身与其监控对象，因为某种共享资源（如时钟、电源）而一同失效，这种情况下，安全机制的设计是无效的。因此需通过DFA识别这类风险并证明其独立性。
图2. 安全机制与其监控对象的关联失效示意
此外，ISO 26262要求在进行ASIL分解或不同ASIL等级组件共存时，通过DFA证明架构的独立性，包括免于干扰以及防止共因失效。否则分解无效。例如：一个ASIL D的需求在实施时分解为ASIL B(D)+ASIL B(D)。
图3.ASIL D的需求在实施时分解图
若冗余要素中使用了相同型号芯片，则可能因为某种共因（如制造问题、EMC抗性问题等系统性失效）同时失效。因此在开发实践中，可以通过异构设计(不同供应商芯片)消除潜在的共因失效；抑或是针对这类同质冗余设计，需通过DFA证明（包括但不限于分析、测试等手段），不存在潜在的共因失效源头。以下是标准对于同质冗余的需求描述和对于ASIL分解及同质冗余的说明：
5.4.3 The initial safety requirement shall be decomposed to redundant safety requirements,that shall be implemented by sufficiently indenendent elements, These elements are sufficiently independent if the analysis of dependent failures (see Clause 7) does not find a plausible cause of dependent failures that can lead to the violation of an initial safety requirement, or if each identified cause of dependent failures is controlled by an adequate safety measure according to the ASlL of the initial safety requirement,
NOTE 1 A given decomposed requirement can be the result of the decomposition of several initial safety requirements.
NOTE 2 The use of homogenous redundancy to implement the decomposed requirements (e.g. by duplicated device or duplicated software) does not address the systematic failures of hardware and software. This prevents the ASlL from being reduced, unless an analysis of dependent failures (see Clause7) provides evidence that sufficient independence (see ISO 26262-1:2018, 3.78) exists or that the potential common causes lead to a safe state. Therefore, homogenous redundancy alone is, in general, not sufficient for reducing the AslL without the support of the analysis of dependent failures for the specific system context.
当进一步落到项目实践中时，ISO26262-9：2018 Annex C中对于系统级功能安全项目实践中的DFA提供了更详细的指导。在执行DFA时，可以考虑7个方面的耦合因素：
表2.ISO26262-9：2018 Annex C对系统级功能安全项目实践中的DFA的指导
而ISO26262:2018 – 11中针对半导体，也提到了类似的DFI Checklist，不再赘述。但值得注意的是，半导体器件通常没有service，因此可以不予考虑。
4►标准ISO 26262-11：2018 对半导体DFA的
推荐执行方法
针对半导体厂商实施DFA的方法，ISO 26262 Part 9（安全分析）和Part 11（半导体指南）详细提出了一种供参考的执行流程与技术要求。
图4.工作流一览（Part 11流程图）：
上述工作流可简要概述如下：
1. B1-B2：通过架构分析、遍历识别半导体设计中可能引发关联失效的要素组，建立关联失效源头（DFI）清单
2. B3-B5：通过不断迭代和完善，检查DFI清单的完整性，合并关键DFI。
3. B6-B8：为满足独立性要求及免受干扰性要求，需在目标架构中实施针对性安全措施以缓解相关性失效影响。所有必需的安全措施需形成文档化记录。该过程亦需要通过迭代、完善确保措施完整性。
4. B9-B12：评估措施有效性，迭代优化直至风险达标。为验证所实施安全措施在缓解或避免依赖失效方面的有效性，评估可采用安全分析、故障注入仿真、EMC测试或专家评审等系统性验证方法。
5►一种基于关联性矩阵的DFA实践方法
常见的DFA执行方法中，通常基于标准推荐的“耦合因素表”或演绎式检查清单，要求工程师依据经验逐项列举系统中可能存在的关联失效。此类方法的核心问题在于其强主观性与经验依赖性：工程师需凭借个人对系统架构和功能交互的理解，手动遍历如共享资源、通信协议、环境干扰等项目并逐一映射到具体模块中去。然而，在复杂系统中，模块间的物理与逻辑耦合关系往往呈现多层级、跨领域特征，单纯依赖人工推导极易因认知局限或思维盲区导致关键关联路径的遗漏。
为此，本文提出一种结构化关联性矩阵分析方法，该方法采用关联性矩阵通过结构化约束与系统性遍历机制为工程师的分析提供一种思路指引，相较于标准上的表格法显著降低了分析过程的主观偏差，尤其适用于高复杂度、多安全等级共存的系统设计，亦可用于芯片安全架构设计。
该分析方法的核心在于关联失效分析矩阵。分析时，矩阵的首行与首列需系统化纳入当前设计中的关键模块集合，涵盖功能模块（如LDO1，LDO2）与安全机制模块（如LDO UV/OV Monitor等），即广义的电路功能单元集合。由于DFA主要贡献于架构设计，模块颗粒度的定义需遵循架构设计阶段的需求：即避免过度细化至详细设计级别。
图5.关联性矩阵示意
通过模块的完整列举，工程师将获得一个N×N的交叉验证矩阵，其交叉单元格代表任意两模块间的潜在关联路径。在此框架下，需结合ISO 26262标准推荐的典型分析场景进行定向聚焦，例如：
1. 功能与安全机制的独立性验证
以某功能（如传感器）及其安全机制（如集成于MCU中的传感器信号合理性校验）为例，需遍历用于监控该功能的安全机制中涉及到的所有相关模块（如ADC采样单元、故障上报模块、上述所有模块的供电）。注意，分析时应包含检测和上报全路径。识别出所有关联模块后，可采用标号定义为Coupling_Case_0x。针对该Case应进行深入探究，以识别涉及到的所有模块是否存在共因失效、级联失效。
图6.功能与安全机制关联模块示意
举例：
· 共因失效（CCF）：若功能模块与安全机制共享带隙基准，电压漂移可能导致两者同时失效。
· 级联失效（CF）：功能模块的软件溢出错误可能覆盖安全机制的配置寄存器，导致检测逻辑失效。
2. ASIL分解与多安全等级组件的交互分析
在ASIL分解场景中（如将ASIL D功能分解为两个ASIL B模块），需验证冗余要素间是否存在共因失效和级联失效。任一不满足，则ASIL等级分解不成立。
3. 不同ASIL等级要素间应免于干扰
当不同ASIL等级的组件或安全与非安全要素共存时，低安全等级要素的失效可能通过时序、内存或通信干扰，导致高安全等级组件无法实现其安全需求。例如，非安全相关的软件模块错误写入共享内存，可能破坏安全关键功能的数据完整性。因此在识别出此类关联失效时，架构设计优化、资源隔离等进行消除。
除硬件随机失效外，针对每一个DFA_Case_0x, 还需重点评估系统性失效。包括但不限于开发阶段的设计缺陷、生产阶段的工艺偏差及环境干扰等。
该方法的优势在于:
1. 结构化约束降低主观偏差
矩阵的Crosscheck通过强制遍历所有模块组合，规避传统演绎式清单中因经验局限导致的遗漏。
2. 场景驱动的优先级划分
基于ISO 26262推荐的的典型场景（如功能安全机制独立性、ASIL分解有效性），可快速定位高风险单元格，避免“全矩阵均匀分析”的资源浪费。
3. 系统性失效的全覆盖
除硬件随机失效外，该方法需集成对系统性失效模式的评估字段，包括：
1. 开发错误
2.生产错误
3.环境因素
4. 等等
通过上述方法的联动，即可将DFA分析的主观性和随机性降低到一个可接受的水平。
6►结论
本文系统性地介绍了DFA作为ISO26262独有的一种安全分析方法的通用概述。DFA作为功能安全分析的关键环节，填补了传统安全分析方法在关联失效识别上的盲区，其独特性导致它在功能安全开发中不可或缺。 此外，基于工程实践，本文提出一种优于标准推荐workflow的DFA实施方法，旨在通过采用关联失效分析矩阵，约束并引导工程师进行系统性遍历，进而避免主关联想带来的分析不完备以及随机性，大大降低了DFA分析中的系统性失效。
A.Hills| 作者
胡冲 | 审核
来源：sasetech
作者：A.Hills
