1. 课程导入

各位工程师朋友，咱们直接进入正题。FMEDA 这个词，你肯定在功能安全相关文档里见过。它全称是 Failure Modes, Effects and Diagnostic Analysis——失效模式、影响与诊断分析。

说白了，FMEDA 就是给硬件做一次「体检」。它不光要找出芯片或电路板可能怎么坏，还要算清楚：坏了之后，系统能不能自己发现？发现了又能处理到什么程度？

我刚开始接触功能安全时，总觉得 FMEDA 就是填表格。后来在项目里吃过亏才明白——FMEDA 是连接「失效分析」和「量化指标」的桥梁。没有它，你根本没法回答「我的硬件到底安不安全」这个问题。

1.1 什么是 FMEDA？

FMEDA 是一种系统化的硬件可靠性分析方法。它从元器件级别出发，逐一分析每个失效模式，然后评估三件事：

• 失效模式：这个器件会怎么坏？（短路、开路、漂移…）
• 失效影响：坏了之后对系统功能有什么后果？
• 诊断能力：系统能不能检测到这个失效？检测覆盖率是多少？

嗯，这里要注意——FMEDA 和传统 FMEA 最大的区别，就在于它引入了「诊断」这个维度。传统 FMEA 只问「坏了会怎样」，FMEDA 还要追问「坏了能不能被抓住」。

1.2 FMEDA 在功能安全中的角色与价值

功能安全标准 IEC 61508 和 ISO 26262 都要求：硬件架构必须满足两个量化指标——安全失效占比（SFF）和随机硬件失效概率（PFH/PFD）。

这两个指标怎么算出来的？靠的就是 FMEDA。

我参与过一个汽车域控制器项目，客户要求达到 ASIL D。架构设计阶段我们拍脑袋觉得没问题，结果 FMEDA 一跑，SFF 差了 2 个百分点。后来加了一路诊断电路才过。你想想看，如果没有 FMEDA，等流片回来再改，那成本就大了去了。

FMEDA 在项目中的具体价值，我归纳为四点：

价值维度	具体说明
量化安全指标	输出 SFF、PFH、DC（诊断覆盖率）等硬数字，用于安全等级判定
指导架构设计	暴露安全薄弱环节，告诉你哪里需要加冗余或诊断
支撑安全案例	FMEDA 报告是安全档案的核心组成部分，审核必查
优化 BOM 成本	避免过度设计——不是所有地方都需要三冗余，FMEDA 帮你找到「刚好够」的方案

1.3 FMEDA 与 FMEA、FTA 的关系

很多初学者容易把这三个工具搞混。我画了一张图，帮你理清它们的关系：

我再用人话解释一下这三个工具的区别：

• FMEA 像「侦察兵」——它告诉你每个零件可能怎么坏，但不说概率，也不管能不能检测到。
• FMEDA 像「军需官」——它把 FMEA 的结果量化了，算出每个失效模式的风险数字，还评估了诊断措施的效果。
• FTA 像「总参谋部」——它从系统级故障出发，倒推哪些底层失效组合会导致这个故障，然后用 FMEDA 的数据算概率。

1.4 什么时候该用哪个？

这个问题我经常被问到。我的建议是：

项目阶段	推荐工具	产出物
概念设计	FTA（粗粒度）	识别关键安全目标
架构设计	FMEDA	量化安全指标，指导冗余设计
详细设计	FMEA + FMEDA	完整失效分析，诊断方案验证
验证确认	FTA（细粒度）	系统级安全完整性验证

嗯，这里要强调一点：FMEDA 不是一次性工作。随着设计迭代，你的 FMEDA 也要跟着更新。我习惯在每次设计评审前都跑一遍 FMEDA，确保安全指标没有恶化。