DFA / FMEDA / FTA — 功能安全三种核心分析方法
本质 ISO 26262 的 quantitative + qualitative 分析不是单一动作,是三件不同的事——DFA 证"独立性是否可信"、FMEDA 量"随机硬件失效是否被诊断覆盖"、FTA 拆"危险顶事件由哪些故障组合导致"。三者互补不替代,在生命周期里位置不同、产出不同、误用方式也不同。本页把三者并排展开:各自解决什么问题 → 在生命周期里的位置 → 怎么做 → 常见误区,作为团队 review 时的快速对照导图。
学习目标
读完本页后,你应该能够:
- 区分 DFA / FMEDA / FTA 各自回答的核心问题——独立性 vs 随机硬件失效覆盖 vs 危险顶事件路径
- 说出三者在 ISO 26262 V 模型 / 安全开发各阶段的主要使用窗口
- 写出 DFA 五步流程 + 核心检查项(共因 / 共模 / 级联 / 干扰 / 共享资源)
- 写出 FMEDA 六步流程 + SPFM/LFM/PMHF 三个量化目标(ASIL D 时分别 ≥99% / ≥90% / ≤10 FIT)
- 写出 FTA 五步流程 + 顶事件 / 最小割集 / 重要度的概念
- 识别每种方法的常见误区(套 checklist 不分析 / 套库不结合架构 / 顶事件定义过宽)
1. 三者各自解决什么问题
三种方法回答的不是同一个问题——把它们当成"安全分析的三件不同的事"才能各自做对。混着用(常见错误是"做了 FMEDA 就不做 DFA")会留下系统性盲区。
1.1 DFA — 依赖失效分析(Dependent Failure Analysis)
DFA 回答"所谓'独立'是否真的独立"——ASIL 分解、冗余设计、监控-控制双链路这些都假设两个组件独立失效,但实际上共因(power / clock / reset)、共模(同算法 / 同标定)、级联、干扰、共享资源都会破坏独立性。DFA 的任务就是把这些隐藏的耦合路径挖出来。
- 关注:共因、共模、级联、干扰、共享资源
- 典型对象:ASIL 分解通道、冗余通道、监控链与控制链
1.2 FMEDA — 失效模式、影响与诊断分析
FMEDA 回答"随机硬件失效是否被诊断机制覆盖"——每个器件有自己的失效率和失效模式,问题是这些失效是否被安全机制 catch、catch 比例够不够。FMEDA 用量化方式回答这个问题,产出 SPFM / LFM / PMHF 三个核心指标对照 ASIL 目标。
- 关注:失效率、失效模式、诊断覆盖率、SPFM / LFM / PMHF
- 典型对象:器件、模块、硬件安全机制
1.3 FTA — 故障树分析
FTA 回答"危险顶事件由哪些故障组合导致"——从 hazard 出发反向逐层展开,找到能导致顶事件的所有故障组合(最小割集),再判断这些组合的概率贡献。是 system-level 安全论证的标准工具。
- 关注:顶事件、逻辑门、最小割集、概率贡献
- 典型对象:系统级危险事件与安全目标验证
2. 在安全开发中的位置
三种方法沿 V 模型左侧从概念到验证逐次展开——不是平行使用,是按阶段切换主导工具。理解这条时间线决定你什么时候掌握 DFA 有用、什么时候 FMEDA 才不浪费。
| 阶段 | 主用方法 | 输出 |
|---|---|---|
| 概念 + 系统架构 | DFA | 独立性假设清单、ASIL 分解合理性论证 |
| 硬件架构 + 安全机制 | DFA + FMEDA | 共因消除方案、失效模式映射 |
| 定量分析 + 优化 | FMEDA | SPFM/LFM/PMHF 数值、薄弱点改进 |
| 验证 + 安全论证 | FTA | 顶事件路径、最小割集、概率贡献 |
> 三者互补,不是替代** —— DFA 看独立性,FMEDA 看随机硬件失效覆盖,FTA 看顶事件路径与组合。漏一项就漏一类系统性风险。**
3. DFA 怎么做
DFA 走"先假设 → 再挖耦合 → 再消除 / 控制"三段式——5 个步骤里前 2 步最关键(假设错或没识别耦合路径,后面三步都是空跑)。
3.1 五步流程
DFA 走 5 个固定步骤——前 2 步是 setup(假设 + 耦合识别)、中间 2 步是分析 + 措施、最后 1 步归档。每步缺一不可。
| 步 | 动作 | 关键输出 |
|---|---|---|
| 1 | 确定独立性假设 | 假设清单 + 检查项(见下) |
| 2 | 识别耦合路径 | 共因 / 共模 / 级联 / 干扰 / 共享资源清单 |
| 3 | 分析依赖失效场景 | 触发条件 + 影响范围 |
| 4 | 定义预防 / 检测措施 | 设计变更或诊断 |
| 5 | 记录残余风险与结论 | DFA 报告 |
3.2 第 1 步的核心检查项
DFA 80% 价值在第 1 步的检查项是否完整——下面这条清单覆盖最常见的耦合源,review 时按条核对:
- 共享电源 / 参考电压 / 时钟 / 复位 / 通信链路 —— 最频繁的 silent 共因
- 同一软件 / 标定 / 算法缺陷 —— 双通道用同代码不算独立
- PCB 物理邻近 / 热耦合 / EMC 干扰 —— 板级共因
- 监控链与控制链是否真正独立 —— 同 MCU 不同 core 不算独立
- ASIL 分解假设是否成立 —— 分解前 ASIL D 不是分解后两个 ASIL B 的简单叠加
3.3 DFA 输出
DFA 完整产出有 4 类——场景清单 / 论证文档 / 措施清单 / 报告。安全审计时这 4 类缺一不可。
| 类别 | 内容 |
|---|---|
| 场景清单 | 依赖失效场景表 |
| 论证 | 独立性论证、假设、约束 |
| 措施 | 预防 / 检测措施清单 |
| 报告 | DFA 完整 report |
4. FMEDA 怎么做
FMEDA 走"边界 → 失效率 → 模式 → 效应 → 诊断 → 量化"六段式——产出 SPFM / LFM / PMHF 三个量化指标对照 ASIL 目标。是 ISO 26262 量化分析的事实主流工具。
4.1 六步流程
FMEDA 6 个步骤是串行依赖——前 4 步建立失效图谱、第 5 步把诊断映射进来、第 6 步出量化结果。前面任一步草率,后面的指标都不可信。
| 步 | 动作 |
|---|---|
| 1 | 定义分析边界与层级 |
| 2 | 列出器件 / 模块与失效率 |
| 3 | 分配失效模式 |
| 4 | 分析局部效应与最终效应 |
| 5 | 映射安全机制与诊断覆盖 |
| 6 | 计算 SPFM / LFM / PMHF 并识别薄弱点 |
4.2 关键输入
FMEDA 输入质量决定输出可信度——下面这 4 类输入缺一不可:
- BOM / 硬件架构 / 任务剖面 —— 决定哪些器件参与、工作多长时间
- 失效率库与失效模式库 —— SN 29500 / IEC 61709 / 厂商 FMEDA 报告
- 安全目标、FSR / TSR —— 决定"哪些失效算 safety-related"
- 安全机制与测试间隔 —— 决定 DC(诊断覆盖率)的计算依据
4.3 核心产出
ASIL D 系统的量化目标是 FMEDA 必须达成的硬指标——三个数任何一个不达标都要回头改架构或加诊断。
| 指标 | 含义 | ASIL D 目标 |
|---|---|---|
| SPFM | Single-Point Fault Metric(单点失效度量) | ≥ 99% |
| LFM | Latent Fault Metric(潜伏失效度量) | ≥ 90% |
| PMHF | Probabilistic Metric for Hardware Failures(随机硬件失效概率) | ≤ 10 FIT |
其他常规产出:
- FMEDA 表 —— 行=器件失效模式,列=诊断覆盖、SPF/RF/MPF 分类
- 故障分类:单点故障 / 残余故障 / 多点潜伏故障
- 改进清单与主导贡献项 —— 按 FIT 贡献排序,top 5-10 是优化重点
5. FTA 怎么做
FTA 从顶向下展开——以一个具体的危险顶事件为根,逐层向下找到所有能导致它发生的故障组合。是 system-level safety argumentation 的标准工具,也是 ISO 26262 推荐的危险分析手段之一。
5.1 顶事件示例(EPS / 主驱)
下面 3 个顶事件是 EPS / 主驱场景里最典型的 FTA 起点——每个都对应一条 ASIL D 安全目标。
| 顶事件 | 危险后果 |
|---|---|
| 危险扭矩输出 | 控制链错误扭矩 → 车辆失控 |
| 监控链未检出 | 错误状态没被发现 → 安全机制失效 |
| 执行链未按命令关断 | STO 失败 → 转矩持续输出 |
5.2 五步流程
FTA 从顶向下展开——5 步走完才能完整论证一个 hazard。第 1 步定义边界最关键(顶事件不清后面全乱)。
| 步 | 动作 |
|---|---|
| 1 | 定义顶事件与边界 |
| 2 | 逐层展开因果逻辑 |
| 3 | 形成基本事件与逻辑门 |
| 4 | 求最小割集 / 重要度 |
| 5 | 做定性或定量评估 |
5.3 FTA 输出
FTA 5 类产出按"可视化 → 量化 → 论证"层层加深——故障树是输入,最小割集是分析结果,定量结果是论证终点。
| 输出 | 用途 |
|---|---|
| 故障树 | 可视化因果链 |
| 最小割集 | 列出所有能导致顶事件的最小故障组合 |
| 主导路径 | 概率贡献最大的几条 path |
| 定量结果 | 顶事件概率、与 ASIL 目标对比 |
| 假设与约束 | 论证边界条件 |
6. 常见误区
每种方法都有反复出现的"看起来在做但实际没产出"反模式——识别并戒除比掌握更多技巧更重要。
6.1 DFA 误区
DFA 最常见的失败模式是"checklist 化"——团队填了一张共因检查表就交差,但没真正分析耦合路径,留下系统性盲区。
- 只写 checklist,没有真正分析耦合路径
- 忽略电源 / 时钟 / 复位 / 软件共因
- ASIL 分解时假设双通道独立,但用同代码 / 同 MCU
6.2 FMEDA 误区
FMEDA 失败常因"套库不结合架构"——直接抄第三方失效率库,不结合本设计的实际安全机制和工作剖面,得出的 SPFM/LFM 不可信。
- 直接套库,未结合真实架构与安全机制
- 诊断覆盖率宣称过高,缺少依据
- 未考虑 latent fault test interval
6.3 FTA 误区
FTA 最常踩的坑是顶事件定义不清——顶事件过宽时故障树变得无限大,过窄时又漏掉关键 hazard。
- 顶事件定义过大或过模糊
- 逻辑层层混乱,系统边界不清
- 设计变更后故障树未更新
核心要点
- 三者回答不同问题:DFA 看独立性 / FMEDA 看随机硬件失效覆盖 / FTA 看顶事件路径,互补不替代
- 在 V 模型里位置不同:DFA 偏概念 + 架构早期、FMEDA 偏架构后期 + 定量分析、FTA 偏 system-level 验证 + 安全论证
- DFA 80% 价值在第 1 步的检查项——共享电源 / 时钟 / 复位 / 软件 / PCB 物理邻近 / 监控 vs 控制独立性 / ASIL 分解假设
- FMEDA 三个ASIL D 量化目标:SPFM ≥ 99% / LFM ≥ 90% / PMHF ≤ 10 FIT,任一不达标必回头改架构或加诊断
- FTA 关键是顶事件定义清晰 + 算出最小割集和主导路径
- 三种方法各自最大反模式:DFA → checklist 化、FMEDA → 套库不结合架构、FTA → 顶事件过宽 / 过窄