做车规芯片的同行应该都有体会：架构评审时DFMEA聊得火热，一谈到FMEDA就安静了不少。倒不是大家不愿意做，而是FMEDA这个活“想快很快，想细很深”——一张Excel表填了两周，最后认证审核员一句“lambda来源是什么”“DC为什么取80%”就能让你全部重来。Synopsys这些年围绕半导体可靠性和功能安全发布了不少报告与白皮书，核心解决的正是FMEDA里最容易被扯皮的两个问题：芯片级的失效率到底取多少，失效模式按什么比例分。这篇文章我就用我自己做车规MCU和SoC安全分析时的思路，把Synopsys报告里那套逻辑、FMEDA的底层公式、表格怎么拆、工具怎么配合，完整地拆一遍。内容偏实操，适合正在做功能安全量化分析、或者准备给芯片补ISO 26262材料的工程师参考。
1. 为什么车规芯片绕不开FMEDA，Synopsys报告到底解决哪一步
1.1 FMEDA在ISO 26262里的真实位置
先把框架理清楚。ISO 26262对随机硬件失效提出了两类要求：一类是定性的，即通过安全机制把单点故障、残余故障、双点故障控制在可接受范围内；另一类是定量的，要用数字去证明“这个芯片在生命周期内，因为随机硬件失效导致的安全目标违背概率足够低”。FMEDA（Failure Modes, Effects and Diagnostic Analysis）就是连接这两者的桥梁。
项目里很多人把FMEDA和FMEA混着讲。FMEA是定性分析，侧重于“失效模式-原因-影响-对策”，关注的是关系梳理；FMEDA则是在FMEA基础上，给每个失效模式分配失效率λ、诊断覆盖率DC，然后把它们“数值化”。你可以把FMEA看作一张关系图，FMEDA是这张图上的每个节点都标上了速率和覆盖度。
ISO 26262-5里要求的SPFM、LFM、PMHF，本质上都来自FMEDA的计算输出。没有FMEDA，你没法说清楚这颗芯片凭什么满足ASIL B或者ASIL D；没有FMEDA，你也没法跟TÜV、SGS这类审核机构解释清楚安全机制到底覆盖了多少硬件故障。所以在实际项目中，FMEDA往往和功能安全手册、安全分析报告一起，成为芯片流片前必须冻结的交付物。
1.2 Synopsys报告提供的是“公共底座”
说到Synopsys，很多人的第一反应是VCS、Design Compiler、PrimeTime这些EDA工具。但Synopsys在功能安全领域还输出过一个非常关键的东西：半导体器件的可靠性失效模型和失效率参考数据。
芯片设计公司自己拿不到足够多的量产失效统计数据，尤其是早期项目，晶圆厂给的数据往往只覆盖工艺良率，不覆盖“运行阶段随机失效”。Synopsys这类报告的价值，是在行业积累的基础上，给出了一套可以复用的框架：不同芯片模块（标准单元逻辑、SRAM、寄存器堆、PLL、IO、LDO）的失效模式大致分几类，每类占比多少，失效率怎么按面积和工艺修正，诊断机制对某些失效模式的覆盖效果如何评估。这套东西不是你直接抄答案的，而是给自己一个合理起点，至少不用从零开始拍脑袋。
我习惯把Synopsys报告当“标定工具”：先按它推荐的模型建立Base FIT和失效模式比例，再结合自家芯片的面积、温度、电压工况修正，最后通过故障注入或仿真结果去修正DC。这样产出的FMEDA，逻辑链条完整，审计时也容易讲清楚。
2. 三个底层公式是FMEDA的地基
2.1 单位换算：FIT、ppm、MTBF和寿命之间的关系
FMEDA里所有指标的计算都绕不开失效率λ。芯片行业最常用的单位是FIT，全称Failures In Time，1 FIT表示每10的9次方小时（约11.4万年）平均发生1次失效。之所以用这个单位，是因为芯片失效概率很低，用百分比表示太小，用FIT表示阅读起来更直观。
失效率换算很多人会搞混。假设某个功能模块的失效率λ等于50 FIT，如果车辆一年运行8760小时，那它一年内发生失效的期望次数就是50×8760×10^-9 = 0.000438，也就是0.0438%的年失效概率。如果这颗芯片设计寿命是15年，每天运行2小时，那么总暴露小时是15×365×2=10950小时，失效期望是50×10950×10^-9 = 0.0005475；但如果按全天24小时算，总暴露小时变成15×365×24=131400小时，失效期望就会变成0.00657，两者相差约12倍。这个差距直接决定了你算PMHF时能不能过10 FIT的线。
所以做FMEDA第一步不是打开Excel，而是先定义清楚mission profile：每天跑几小时、生命周期多少年、运行温度和待机温度如何。这个不定，所有λ都是浮动的。MTBF也常被拿来做对标，但MTBF本质上是1/λ，只适用于指数分布假设，对芯片早期失效和磨损失效阶段并不完全适用。工程上更严谨的做法是给早期失效、寿命期失效、退化期分别建模型，FMEDA一般取寿命期相对稳定的失效率区间。
2.2 SPFM、LFM、PMHF：目标指标和计算口径
ISO 26262里最容易被挂在嘴边的三个指标是SPFM、LFM和PMHF，它们其实是三种视角：
- SPFM（Single Point Fault Metric）衡量的是单点故障和残余故障的控制程度，计算方式是1减去“未被覆盖的单点故障失效率加残余故障失效率”除以“安全相关失效率总和”。
- LFM（Latent Fault Metric）衡量的是潜在双点故障的控制程度，重点是那些“本身不立即导致安全问题，但如果第二个故障到来就会出事”的失效。
- PMHF（Probabilistic Metric for Random Hardware Failures）则是用失效率的绝对值去衡量整个安全目标违背概率，通常给ASIL D做定量论证用。
公式层面，一般可以写成下面这些形式，具体写法不同报告可能略有差异，但物理含义一致：
SPFM = 1 - (λ_SPF + λ_RF) / λ_related
LFM = 1 - λ_MPF_L / (λ_MPF_D + λ_MPF_L)
SFF = (λ_safe + λ_SU + λ_MPF_D) / (λ_safe + λ_SU + λ_SPF + λ_RF + λ_MPF_D + λ_MPF_L)
PMHF ≈ λ_SPF + λ_RF + λ_MPF_L（工程简化，单位FIT）
注意SPFM这里的分母λ_related是“与这个安全目标相关的所有失效”，不是整颗芯片的所有失效。如果你把安全无关的失效率也塞进分母，结果会虚高或者虚低，完全看你怎么凑。审核员最喜欢抓的就是这个分母口径问题，我们后面会专门讲。
在目标值上，常见参考值是：ASIL B要求SPFM≥90%、LFM≥60%，ASIL C要求SPFM≥97%、LFM≥80%，ASIL D要求SPFM≥99%、LFM≥90%。PMHF通常按ASIL D小于10 FIT、ASIL B/C小于100 FIT的量级来控制，具体以产品安全概念和认证策略为准。这个“模糊”是有原因的，因为不同安全目标、不同任务剖面会导致参考值差异，工程上一定要先跟功能安全经理确认清楚。
2.3 DC（诊断覆盖率）怎么算，Case A/C的直觉
诊断覆盖率DC算错，是FMEDA最容易翻车的地方。DC的严格定义是：安全机制能够检测到的失效率占潜在可检测失效率的比例。单个失效模式对应的DC = λ_detected / λ_total_for_that_mode。
日常生活中理解DC，可以想象一个防盗门。门锁能拦住一部分入侵者，但拦不住撬窗进来的，也拦不住伪装成快递员的。防盗门的“覆盖率”绝不是100%，也不是只算“开锁”这一种入侵方式。DC要针对失效模式来谈：对一个stuck-at-0故障覆盖率可能是95%，对两个bit同时翻转可能只有40%，对全芯片电源短路可能是0%。如果你拿一个笼统的DC去算所有模式，结果一定是错的。
ISO 26262里还有一个概念叫Case A和Case C，很多人看到就头疼。简单说，Case A指的是双点故障能在安全机制检测后及时暴露，Case C指的是故障处于潜伏状态，等第二个相关故障到来才暴露。这对FMEDA的影响是：同一个双点故障，在不同架构下要分的类不一样，分配的DC也不一样。比如带lockstep和ECC的CPU，如果MBIST只在开机自检时跑，那运行期间出现的RAM故障就可能是Case C；如果RAM有实时ECC校验，那故障就可能是Case A。这个选择和你的诊断周期、安全状态定义强相关，不要硬套。
3. 手把手做一张Synopsys风格FMEDA表
3.1 第一步：划分分析边界并确定Base FIT
拿到芯片设计，先不要急着填表，先把分析边界画清楚。通常一颗车规SoC可以按功能安全分析粒度分成几个层级：顶层是芯片级，往下是安全相关IP和独立模块，再往下是子模块和信号。FMEDA颗粒度太粗，交不了差；太细，工作量巨大且容易陷入过度分析。我的经验是至少细化到SRAM、Register File、标准单元逻辑块、时钟生成模块、复位模块、IO接口、电源监控模块这一级别。
Base FIT的确定是第一个技术活。Synopsys报告提供的失效模型，一般会按模块类型给参考失效率。实际使用时，我会先按门数或面积估算基础失效率，再乘上工艺与温度修正系数。
不同模块的失效率差异很大。逻辑门的主要失效模式是stuck-at和时序相关失效，内存类是bit翻转和固定位故障，PLL是失锁和频率偏差，IO是静电损伤和ESD退化，LDO是输出电压漂移。工程上可以先按一个基准面积密度折算。比如一个面积为2.5平方毫米的安全相关逻辑区域，如果按工艺库给定的百万门失效率参考值，再折算面积，可以得出一个Base FIT；SRAM和寄存器堆又要单独按bit数和失效率模型算。这里最忌“拍一个总FIT”，因为后面所有失效模式比例都基于这个，源头不准，全表白做。
3.2 第二步：给每个失效模式分配比例
Base FIT确定后，下一步是把每个模块的失效率按失效模式拆开。这个过程最依赖Synopsys这类报告的经验数据，因为不同模块的失效模式分布差异很大。
以SRAM为例，我一般按这样的比例分配：单bit翻转（soft error）可能占40%～50%，stuck-at-0占15%～20%，stuck-at-1占15%～20%，address decoder故障占5%～10%，sense amplifier偏置漂移等模拟性失效占5%～10%。具体数字来自失效模型库和实际memory compiler的可靠性数据，不是随意凑的。
逻辑模块的失效模式分配方式又不一样。标准单元逻辑主要按stuck-at-0、stuck-at-1、时序故障、桥接故障来拆。纯组合逻辑里，桥接故障和时序故障容易被低估，但这些在高性能车规SoC里恰恰可能是主要风险源。
分配比例时还要注意一个细节：软错误（soft error）跟硬失效（hard fault）在FMEDA里的处理方式不同。软错误可以用系统级故障注入或中子测试数据来建模，硬失效则更依赖工艺失效率数据。如果你在FMEDA里把两者混成一个λ，后面做诊断措施分析时会对不上。
3.3 第三步：安全机制与故障分类
失效模式分好之后，就要开始给每个失效模式匹配安全机制，并做故障分类。ISO 26262里常见的分类是Safe、SU（Safe with no detection）、SPF（Single Point Fault）、RF（Residual Fault）、MPF_D（Multiple Point Fault Detected）、MPF_L（Multiple Point Fault Latent），以及Safety-related but not relevant之类的情况。
“Safe”不是指没有故障，而是指故障本身不会导致安全目标被违背。例如一个功能模块完全冗余，失效后由另一路接管，且接管过程符合安全状态要求，这种故障可以分类为Safe。但这里有个陷阱：Safe类故障不是你想归就归的，必须要有证据，比如架构上的冗余设计、安全机制可以在规定时间内完成切换。没有证据支撑，审核员可以直接把你的Safe改成SPF。
分类时还有一组容易混淆的概念：SU和Safe有什么区别？SU是Safe中的一类，特指安全故障本身没有被诊断检测，但因为故障性质无害，所以不影响安全。很多工具表里会用Safe-SU之类的组合标记。实际操作时我建议表格里设立两个独立字段：一个是“故障类别”，一个是“诊断覆盖状态”，这样审计时关系更清晰。
3.4 第四步：汇总计算并对照指标
所有失效模式分类后，就可以汇总计算了。以项目中一个简化过的安全相关模块为例，假设这个模块总失效率是90 FIT，并且全部与一个安全目标相关。经过分类后，各类型失效率如下表基线所示：
| 故障类别 | 失效率(FIT) | 说明 |
|---|---|---|
| Safe / SU | 70.0 | 冗余接管、安全状态切换，不会违背安全目标 |
| SPF | 1.0 | 没有安全机制覆盖的单点故障 |
| RF | 0.5 | 有安全机制，但残余未被检测的部分 |
| MPF_D | 15.0 | 双点故障，已被诊断检测并在诊断窗口内响应 |
| MPF_L | 3.5 | 双点故障，当前处于潜伏状态 |
| 合计 | 90.0 | 所有与该安全目标相关的失效 |
带入公式：
SPFM = 1 - (1.0 + 0.5) / 90 = 98.33%
LFM = 1 - 3.5 / (15.0 + 3.5) = 81.08%
PMHF ≈ 1.0 + 0.5 + 3.5 = 5.0 FIT
SFF = (70 + 15) / 90 = 94.44%
这个基线结果很典型：PMHF能过ASIL D的10 FIT，SPFM也接近ASIL D的99%，但LFM只有81%，过不了ASIL D的90%。也就是说，这颗模块的双点故障潜伏问题比单点问题更严重。
针对这个问题，如果增加一个周期性的自检机制，把一部分MPF_L转成MPF_D，同时加大硬件冗余让RF进一步下降，改进后的结果可能如下：
| 故障类别 | 改进后失效率(FIT) | 与原值对比 |
|---|---|---|
| Safe / SU | 71.0 | 冗余逻辑和诊断逻辑让安全故障占比更高 |
| SPF | 0.3 | 冗余覆盖了部分单点故障 |
| RF | 0.2 | 诊断覆盖率提升，残余更少 |
| MPF_D | 17.5 | 自检机制把潜伏故障转为已检测故障 |
| MPF_L | 1.0 | 潜伏故障大幅减少 |
| 合计 | 90.0 | 总量不变 |
改进后：
SPFM = 1 - (0.3 + 0.2) / 90 = 99.44%
LFM = 1 - 1.0 / (17.5 + 1.0) = 94.59%
PMHF ≈ 0.3 + 0.2 + 1.0 = 1.5 FIT
这才满足ASIL D的整体要求。这里可以看到三条指标不是同向变化的，有时候SPFM过了但LFM差得远，设计就得往诊断检测方向补。这种“指标不达标就找原因，再针对性加机制”的迭代过程，才是FMEDA设计的常态。
3.5 第五步：做一张可审计、可追踪的FMEDA表
最后说下表格本身。一张合格的FMEDA表至少要有这些列：分析模块名称、功能安全目标关联、失效模式、失效模式占比、失效率计算过程和结果、对应安全机制、诊断覆盖率DC、故障类别分类（Safe/SPF/RF/MPF_D/MPF_L）、诊断周期、安全状态定义、证据文件编号、备注。
强烈建议把“失效率计算过程”单独拉一个sheet。比如SRAM那一行，你写“总FIT=34.5”，后面就要有对应表格显示这是根据多少个bit、哪个工艺失效率模型、什么温度修正系数算出来的。没有这个细节，任何一行数字被审核员要求解释时都要现翻资料。
我自己的习惯是把FMEDA表格做成“半工具化”的：用公式关联失效率和分类列，最后SPFM/LFM/PMHF直接自动算出。每次改动只动源头数据，指标自动更新，这样版本迭代时不会因为手改漏了导致汇总对不上。再配合Git做版本记录，每次修改填写修改原因，审计时整个演进过程一目了然。
4. 实际项目中用Synopsys工具链怎么配合FMEDA
4.1 故障注入帮你拿DC依据，而不是空口取DC
DC是整个FMEDA里最容易被质疑的数字。很多团队喜欢对着安全机制“估计”一个DC，比如看门狗80%、ECC 95%、lockstep 99%。审核机构现在越来越不吃这一套，他们会要求你拿出故障注入或仿真数据来支撑DC。
Synopsys工具链在这个环节能帮上大忙。你可以在RTL阶段，用故障注入工具把某个信号置成固定值或翻转值，然后观察安全机制是否触发、是否进入安全状态、失效是否在规定时间内暴露。这个过程不需要等芯片回来，就能提前把DC的底数测出来。实际项目中我会先把FMEDA里识别出的关键失效模式做成一个故障清单，然后按清单在RTL上跑故障注入，统计每种模式下安全机制的检出率。
这里的关键教训是：故障注入的结果要和FMEDA表格里的失效模式一一对应。你不能只在FMEDA里写“SM1覆盖率90%”，然后故障注入报告里完全找不到SM1对应的测试条目。对应关系越清晰，后续认证沟通成本越低。
4.2 结构覆盖率不等于诊断覆盖率
DFT工具在车规项目里也很重要，但很多人踩过同一个坑：把结构测试覆盖率当成DC用。比如TestMAX跑出来某个模块的stuck-at覆盖率是99%，就把FMEDA里对应安全机制的DC写成99%，这通常是错的。
原因很简单：结构测试覆盖率衡量的是可测性，不等于安全机制在系统运行期间能实际检出故障。一个故障在DFT模式下可以被扫描链抓出来，但在运行模式下，如果没有对应的自检机制，它可能就是潜伏故障。FMEDA里的DC必须对应落实到“运行时的诊断机制”，而不是“生产测试时的可测性”。
我的经验是：DFT覆盖率可以作为DC的上界判断依据，但不能直接等同。如果非要参考，必须在FMEDA表的备注里写明“该值来自DFT覆盖率，仅作为设计能力评估，运行时DC以故障仿真结果为准”。这样写虽然保守，但比误导审核员风险低得多。
4.3 DC不是你说了算：报告与审计的闭环
最后再说一下“证据闭环”这件事。FMEDA归根到底是给认证审核用的，所以从第一版开始就要考虑“这个数字有没有出处”。我见过太多项目，FMEDA做到后期才想起来补文件，补起来非常痛苦。
建议在项目初期就建立这样的证据目录：安全机制清单与规格说明，每个安全机制对应到RTL实现模块；诊断覆盖率报告，里面是每个机制的故障注入或仿真结果；失效率来源资料，包括工艺库提供的可靠性数据或Synopsys等报告的相关章节；FMEDA主表，每一步计算都能追溯回上面的资料；安全分析结论，写明是否满足项目安全目标。
闭环的逻辑是：FMEDA表格里的每一行，要么来自设计文档，要么来自仿真报告，要么来自外部标准数据，不允许出现无源之水。如果某一行确实只能拍脑袋，那建议先按最保守的数值填，然后后续补充真实数据来修正。审核时的主动权在你这边的感觉，跟被追问到现场翻文档是完全两回事。
5. 避坑点与经验总结：六个容易翻车的地方
5.1 失效率来源混用导致数量级偏差
FMEDA里最常见的问题，是同时用了多种失效率标准，却没人注意到它们的口径根本不同。IEC 62380、SN 29500、MIL-HDBK-217这些标准的模型假设、环境因子、置信区间都不一样，算出来的λ可能相差几倍甚至十几倍。
特别是同一个模块，如果你在安全分析里用了IEC 62380，在PMHF里又换了SN 29500，最后汇总的指标完全没意义。我踩过这个坑后，现在项目里会强制规定：所有模块只能用同一套失效率标准和同一套修正因子，所有来源必须在材料清单里列全。哪怕标准本身存在争议，至少内部一致，审核员也好追溯。
5.2 “运行小时”和“日历小时”被混为一谈
PMHF的单位讨论里，最微妙的就是时间基数。很多团队算PMHF时，用日历小时乘以一个λ，但λ本身是基于运行小时定义出来的；也有人反过来，用运行小时算但λ却是基于日历小时给出的，最后指标结果完全失真。
正确做法是先看失效率模型是怎么定义的。如果是基于“上电运行小时”的模型，那PMHF计算里的暴露时间就该用运行小时；如果是基于“日历寿命”的模型，就要用校准后的日历寿命。一个折中策略是：在FMEDA附录里明确写明“本项目PMHF按每天X小时运行、生命周期Y年、总暴露Z小时计算”，这样别人复核的时候不会产生歧义。
5.3 把软件层的DC直接算进硬件FMEDA
软件安全机制的作用越来越重要，比如CPU自检程序、内存读写测试、看门狗喂狗逻辑。但把软件诊断覆盖当成硬件DC直接写进FMEDA，是很多从系统级转过来的人常犯的错误。
FMEDA的核心分析对象是硬件失效模式。软件DTC（Diagnostic Test Coverage）可以说明某个硬件失效能被软件检测出来，但软件本身有执行周期，存在诊断窗口。比如自检程序每10毫秒跑一次，如果故障发生在自检结束后的第9毫秒，那真正被检测到的时间就要等下一个周期。在FMEDA里，如果要求诊断窗口内的覆盖率，就不能简单把软件诊断周期当成完全实时的机制，需要把诊断周期对DC的影响折算进去。
5.4 Memory故障不要只用字级覆盖率
安全机制对Memory的覆盖，是个重灾区。很多人写“SRAM使用ECC，DC 95%”，这是过度简化的典型。
一个标准SEC-DED ECC，对单bit错误的检测和纠正覆盖可以接近100%，但对双bit错误的检测概率虽然高，纠正能力却是0%。更关键的是，多bit错误或地址线故障，单个ECC往往无法处理。所以Memory部分的FMEDA应该按失效模式粒度拆分，对单bit翻转、双bit翻转、固定位故障、地址解码故障、写使能故障分别评估DC，而不是一句话带过。
作者以前做过一个含大容量SRAM的模块，用字级故障统计SPFM能到95%，但拆到bit级和地址线级后，SPFM直接掉到85%，因为地址线故障几乎没有被ECC覆盖到。这个差距如果不拆出来，流片后功能安全验证会很难补。
5.5 安全相关与安全无关部分没有物理隔离
FMEDA计算里，把安全无关部分踢出分母的动机是合理的——它们不参与安全目标，自然不该影响SPFM。但前提是：安全无关部分真的不会影响安全相关部分。
有些芯片设计里，安全相关模块和安全无关模块共用同一个时钟源、同一条总线、同一个电源域。这种情况下，即使你把安全无关模块的失效全部标记为“no safety related”，它的失效也可能通过共因路径传导到安全相关模块。审核员对这类问题非常敏感，一旦发现没有隔离证据，整个FMEDA都会被质疑。
实践上，我会在FMEDA里对每一类“安全无关”失效加一个额外说明，证明它与安全相关部分在物理上是隔离的，或者在设计中存在监控保护。如果有条件，最好在架构阶段就做电源域和时钟域的隔离，这样FMEDA做起来省心很多。
5.6 共因失效不在单点指标里的“坑”
双点故障有一个很隐蔽的陷阱：你以为两个通道都失效才算事故，但实际上两个通道可能因为同一个共因同时失效。比如两个冗余通道共用同一个LDO，LDO输出异常会导致两个通道同时挂掉。从FMEDA单点指标看，LDO的故障分摊到两个通道里，每个通道的指标都很好看，但整体安全目标是失效的。
共因失效CAF（Common Cause Failure）需要在FMEDA里单独分析。通道A和通道B各自的双点失效组合，不等于整体评估结束，还要检查两个通道是否存在任何共享的资源、共享的时钟、共享的电源、共享的复位路径。只要有共享资源，就要评估该资源的失效如何被安全机制检测，或者把该资源本身作为单点故障纳入指标计算。这一步很考验设计理解深度，但如果真的认真做了，能提前发现不少架构层面的安全隐患。
做FMEDA最怕的不是公式不会，而是表格里每一个数字都经不起追问。我自己的做法是：每次给单元格填数之前，先问自己一句“这个数明天有人问的时候，我能不能三句话说清楚来源”，如果不能，就先不填。芯片功能安全不是做给审核员看的，而是做给未来每一个因为软件误诊而不敢跑高速的驾驶员看的。数据严谨一点，比什么都重要。
