DFA到底是什么？

为什么要做DFA？

先回答一个更根本的问题：FMEA和FTA还不够吗？

FMEA和FTA是功能安全中最常用的两种安全分析方法。但它们都有一个共同的假设：

FMEA假设：分析的是单点故障——一个故障自己坏自己的，不考虑它跟其他故障的关系。

FTA假设：所有底事件之间是相互独立的——一个底事件不会影响另一个。

但现实世界不是这样运行的。

真实系统中，故障之间是“有关系的”：

现实场景	FMEA/FTA能不能处理？
底事件A发生故障，同时导致底事件B和底事件C也故障	❌ 不能
底事件A发生故障，导致底事件B也故障	❌ 不能

这两种情况在FMEA和FTA中都被忽略了。如果不在安全分析中考虑它们，安全分析的结果就是不完整的。

DFA就是来“补这个窟窿”的——它专门分析FMEA和FTA忽略的那些“故障之间的关系”。

DFA的官方定义

ISO 26262-9:2018对DFA的目的定义如下：

① 通过识别潜在的引起相关失效的原因及相关失效的发起点（DFI） ，确认在设计中充分实现了功能安全所需的独立性或不受干扰的能力。

② 必要时定义安全措施以减轻可能引起的相关性故障。

 翻译成人话：

• ① = “找出所有可能让两个‘独立’元素一起挂掉的原因，证明它们真的不会一起挂”
• ② = “如果发现有一起挂的风险，加安全措施把它干掉”

DFA vs FMEA vs FTA：一张表看懂区别

对比维度	🔬 FMEA	🔬 FTA	🔬 DFA
分析方向	自下而上（从故障推影响）	自上而下（从顶事件推原因）	横向分析（要素之间的关系）
分析对象	单点故障	底事件组合	要素之间的关联性
核心假设	各故障独立	各底事件独立	假设故障之间有关联
回答的问题	“这个零件坏了会怎样？”	“什么原因会导致这个事故？”	“这两个‘独立’的零件，会不会因为同一个原因一起坏？”

一句话总结：FMEA看“单个零件坏了会怎样”，FTA看“什么原因会导致事故”，DFA看“两个‘独立’的零件会不会因为同一个原因一起坏”——视角完全不同。

一个重要区别：DFA的执行与ASIL等级没有关系，这是它与FMEA和FTA的明显区别。不管你是ASIL-A还是ASIL-D，只要出现了需要证明独立性的场景，就要做DFA。

相关失效的“两大元凶”：共因失效 vs 级联失效

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

元凶一：共因失效（Common Cause Failure, CCF）

定义：一个相关项中，由一个单一特定事件或根本原因引起的两个或多个要素的失效。

大白话：“一个原因，干掉多个目标。”

典型场景：

一个共享电源故障 → 传感器、控制器、执行器同时断电 → 整个系统瘫痪。

共因失效的常见来源：

来源类别	具体示例
🔌 共享资源	同一个电源、同一个时钟源、同一条通信总线
🌡️ 环境因素	同一个温度、湿度、振动、EMC干扰
👤 人为因素	同一个设计团队、同样的编码习惯、同样的测试遗漏

元凶二：级联失效（Cascading Failure）

定义：同一个相关项中，一个要素的失效引起另一个或多个要素的失效。

大白话：“一个坏了，把另一个也拖下水。”

典型场景：

主控芯片过热 → 热量传导到旁边的传感器 → 传感器也失效。

级联失效的另一种情况：一个功能模块出错，导致它的安全机制也无法正常工作——比如看门狗和它监控的对象共用一个时钟源，时钟一坏，两个一起挂。

 两张图看懂：共因失效 vs 级联失效

对比维度	🔴 共因失效（CCF）	🔴 级联失效（Cascading）
本质	多个要素被同一个原因干掉	一个要素的失效传递给另一个要素
方向	一个原因 → 多个失效	一个失效 → 另一个失效
关注点	要素之间的相似性（共享什么？）	要素之间的干扰（怎么传播的？）
典型例子	共享电源故障导致多个芯片同时掉电	主控过热导致旁边的传感器也失效

 什么时候必须做DFA？

不是所有项目都需要做DFA。ISO 26262-9:2018指出了DFA的四个典型应用场景：

场景一：不同ASIL等级的要素共存（FFI）

低ASIL等级的要素和高ASIL等级的要素共存在一个系统中，需要进行交互。

为什么需要DFA？

低ASIL等级的要素开发要求不如高ASIL等级严格，如果它的故障传播到高ASIL等级的要素，可能导致安全目标被违反。

示例：ASIL-B的通信模块给ASIL-D的ACC控制器传数据。如果通信模块的故障（比如数据损坏）传给了ACC控制器，可能导致ACC做出错误决策。

场景二：QM和带ASIL等级的要素共存

QM（质量管理级）要素和带ASIL等级的要素共存。

QM要素没有任何功能安全要求，更有可能出问题。如果它的故障能影响到安全相关要素，必须通过DFA识别并隔离。

场景三：ASIL分解需要证明冗余要素的独立性

这是最典型的DFA应用场景。

ASIL分解把一个高ASIL需求分给两个低ASIL元素——前提是这两个元素充分独立。DFA就是用来证明这一点的。

场景四：功能与安全机制的独立性

安全机制本身与其监控对象之间是否存在关联失效。

典型陷阱：看门狗和它监控的CPU共用一个时钟源——时钟一坏，CPU挂了，看门狗也挂了，谁也救不了谁。DFA就是用来发现这类“安全机制自己也不安全”的问题。

DFA怎么做？五步实战法

Step 1：确定分析对象

DFA的分析对象是整个产品的架构设计，不是某一个子组件。

 关键原则：不是把所有要素两两配对分析——那样工作量会爆炸。只需要分析存在关联关系的要素组。

哪些要素之间可能存在关联？

关系特征	示例
🔗 ASIL分解后的两个要素	控制通道 + 监控通道
🔗 不同ASIL等级的共存要素	ASIL-B模块 + ASIL-D模块
🔗 功能 + 其安全机制	跟车距离计算 + 看门狗监控
🔗 共享资源的要素	共用同一个电源、时钟、总线的多个模块

Step 2：识别相关失效的发起点（DFI）

DFI（Dependent Failure Initiator） 是可能导致相关失效的根本原因或事件。

ISO 26262 Part 11定义了7类DFI，帮助分析团队系统性地识别潜在的相关失效：

DFI类别	具体内容
🔌 共享资源	电源、时钟、复位、通信总线、内存
🌡️ 共享环境	温度、湿度、振动、EMC干扰
👤 共享人为因素	同一设计团队、同一测试流程、同一工具链
🔧 共享制造因素	同一批次芯片、同一生产工艺
📋 共享规格因素	同一需求文档、同一接口定义
🔄 共享维护因素	同一维修流程、同一备件来源
🧠 共享算法因素	同一算法实现、同一数据处理逻辑

Step 3：分析共因失效和级联失效

针对每个识别出的DFI，分析它是否可能导致共因失效或级联失效。

共因失效分析模板：

共享资源	涉及要素	可能后果	风险等级
同一电源	传感器A + 控制器B	电源故障 → 两个同时掉电	🔴 高
同一时钟源	主MCU + 看门狗	时钟故障 → 两个同时失效	🔴 高
同一CAN总线	多个ECU	总线故障 → 通信全部中断	🟡 中

级联失效分析模板：

失效源	传播路径	受影响要素	可能后果
主控芯片过热	热量传导	相邻传感器	传感器高温失效
通信模块数据错误	数据传递	ACC控制器	ACC做出错误决策

Step 4：评估风险并定义安全措施

如果发现了可能导致安全目标被违反的相关失效，必须定义安全措施来消除或限制它。

发现的问题	安全措施
两个冗余通道共用同一电源	增加独立电源或电源隔离
看门狗和主控共用同一时钟源	看门狗使用独立时钟源
低ASIL模块可能干扰高ASIL模块	增加内存分区（MPU） 或时间隔离

Step 5：记录DFA报告

DFA的最终输出是一份DFA报告，作为安全档案（Safety Case）的一部分。

DFA报告应包含：

• ✅ 分析对象（哪些要素组）

• ✅ 识别的DFI清单

• ✅ 共因失效和级联失效分析结果

• ✅ 风险评估

• ✅ 定义的安全措施

• ✅ 残余风险确认

 实战：电子转向锁（ESCL）的DFA分析

回顾一下上期的电子转向锁（ESCL）案例：

安全目标SG-01：当车辆行驶时，转向锁不应意外接合【ASIL D】。

ASIL分解后：

• 需求1：ASIL B(D) → 控制通道（主控制器）
• 需求2：ASIL A(D) → 监控通道（监控器）
• 需求3：ASIL A(D) → 执行通道（电机驱动）

问题：这三个元素真的“独立”吗？需要用DFA来证明。

Step 1：确定分析对象

要素组：控制通道、监控通道、执行通道

Step 2：识别DFI

DFI类别	具体检查	发现的问题？
🔌 共享电源	三个通道是否共用同一电源？	✅ 是——都从车辆12V取电
⏱️ 共享时钟	控制通道和监控通道是否共用同一时钟源？	✅ 是——都在同一块PCB上
🔗 共享总线	三个通道是否共用同一条CAN总线？	✅ 是——都挂在同一条CAN上
🌡️ 共享环境	三个通道是否受同样的温度影响？	✅ 是——都在同一个机箱内

Step 3：分析共因失效和级联失效

共因失效分析：

共享资源	涉及要素	可能后果	风险等级
同一电源	控制通道 + 监控通道 + 执行通道	电源故障 → 三个同时失效	🔴 高
同一时钟源	控制通道 + 监控通道	时钟故障 → 两个同时失效	🔴 高
同一CAN总线	控制通道 + 监控通道	总线故障 → 通信中断	🟡 中

级联失效分析：

失效源	传播路径	受影响要素	可能后果
控制通道过热	热量传导	监控通道	监控通道也失效

Step 4：定义安全措施

发现的问题	安全措施
三个通道共用同一电源	增加独立电源为监控通道供电
控制通道和监控通道共用同一时钟源	监控通道使用独立时钟源
三个通道共用同一条CAN总线	增加独立CAN总线或看门狗独立监控
控制通道过热影响监控通道	增加物理隔离和独立散热

Step 5：记录DFA报告

DFA结论：通过增加独立电源、独立时钟源、独立CAN总线和物理隔离，所有已识别的共因失效和级联失效风险均已得到控制。三个通道之间的独立性得到充分证明。

审核员看到这份报告： 👍 证据充分，独立性成立！

DFA中容易踩的“坑”

坑1：以为FMEA/FTA已经覆盖了DFA的工作

❌ “FMEA和FTA都做过了，DFA不用做了”
 ✅ FMEA和FTA假设故障之间相互独立，覆盖不了共因失效和级联失效——DFA是必须的补充

坑2：只做“纸上分析”，不落实到设计

❌ DFA报告写得漂亮，但设计上什么都没改
 ✅ DFA的目的是驱动设计改进——发现的问题必须落实到具体的安全措施

坑3：忘了分析“安全机制本身”

❌ 分析了功能模块，但忘了分析它们的安全机制
 ✅ 安全机制如果和它监控的对象共享同一个失效原因（比如同一个时钟源），安全机制本身就失效了

坑4：把“同构冗余”当“独立冗余”

❌ “两个一样的芯片，够独立了吧”
 ✅ 同构冗余可能存在共因失效（同一个制造缺陷、同一个设计缺陷）——需要通过DFA证明没有共因失效才能算独立