做车规芯片功能安全这一块几乎每天都要跟FMEDA打交道。但真正把FMEDA算明白、算到能过评审、能应对客户审计其实比大多数人想得更费功夫。我之前也是一边对着Synopsys等EDA厂商出具的安全分析报告和FMEDA工作簿一边自己重新推公式、查失效模式、核对诊断覆盖率踩了不少坑才把整套计算流程理清楚。这篇文章就把我拆解Synopsys报告、手把手算FMEDA的过程整理出来从前置输入到SPFM、LFM、PMHF三大指标的计算再到各种容易翻车的地方尽量一次讲透。1. FMEDA到底在算什么先搞清楚三种安全指标的区别从事后复盘的角度看FMEDA最核心的输出就是ISO 26262要求的三个随机硬件失效量化指标SPFM单点故障度量、LFM潜伏故障度量、PMHF随机硬件失效概率度量。很多初接触FMEDA的工程师容易把这三者搞混或者以为只是套公式算百分比其实它们的物理含义和数据的组织方式有本质区别。1.1 为什么FMEDA不是填表而是算账FMEDA全称是Failure Modes, Effects and Diagnostic Analysis它和FMEA最大的区别在于FMEA偏定性分析失效影响和措施FMEDA则要把每一种失效模式对应的失效率量化再结合安全机制的诊断覆盖率算出系统到底有多安全。你可以把它理解为给芯片的每一个安全相关模块建立一张失效率资产负债表左边是各种失效模式带来的风险失效率右边是安全机制能够诊断和控制的失效率两边一抵剩下的就是单点故障、残余故障和潜伏故障。我在看Synopsys的FMEDA报告时最先关注的不是最后的达标百分比而是它的失效模式分类表。报告会把每个安全相关模块比如电压监控、时钟监控、看门狗、ECC逻辑等等的失效模式拆细到具体电路层面包括失效率来源、失效模式占比、检测机制、诊断覆盖率。这几张表才是整个FMEDA的灵魂后面所有指标都是从这些原始数据汇总算出来的。1.2 三大指标的分工SPFM、LFM、PMHF谁管什么SPFM衡量的是单点和残余故障被安全机制覆盖得有多好。具体来说它看的是所有可能导致安全目标违背的失效中有多少比例是既没有安全机制覆盖、也没有被部分覆盖而留下来的残余部分。这个指标越高说明单点失效导致危险的几率越低。LFM衡量的是潜伏故障被探测得有多好。潜伏故障本身不会单独导致安全目标违背但它会在其他故障出现时组合成双重故障所以需要在一定时间内被诊断出来。如果潜伏故障长期没人发现那两处小隐患叠加起来就可能出大事故。LFM越低说明诊断机制对这类隐藏故障的把控越差。PMHF则是衡量随机硬件失效导致的整体风险单位是FIT每十亿小时失效次数或者说失效概率密度。SPFM和LFM是百分比PMHF是绝对值两者不能互相替代。ASIL B、C、D对PMHF的门槛有明确要求比如ASIL D通常是小于10 FITASIL B小于100 FIT。SPFM和LFM的门槛也按ASIL等级递增。1.3 结合标准门槛理解FMEDA报告的结论ISO 26262-5对SPFM和LFM的目标值做了规定比如ASIL B的SPFM要≥90%ASIL D要≥99%LFM方面ASIL B要≥60%ASIL D要≥90%这些数字在Synopsys报告的安全指标汇总页里会逐条列出。需要注意的是如果你的芯片同时有多个安全目标FMEDA需要对每个安全目标分别累计而且不同安全目标下同一个模块可能承担不同角色的失效。我之前见过有人把所有模块混在一起算一个总指标结果每个安全目标都看起来达标实际上某一个关键安全目标下早已超标了。2. 算FMEDA之前必须有的三本底账没有输入就没有输出。FMEDA计算的质量上限取决于你输入数据的完整性和可信度。开始拆解Synopsys报告前我一般先确认三样东西齐不齐失效率数据、失效模式分类、安全机制诊断覆盖率。2.1 失效率数据源IEC 62380、SN 29500还是FIDES芯片级FMEDA的失效率来源不外乎那几个IEC 62380、IEC 61709/SN 29500、FIDES以及基于实际生产测试和场测数据回归的自家失效率库。不同标准对同一个器件的λ失效率可能差出好几倍这一点在项目一开始就得锁定否则后面讨论指标达不达标全是空中楼阁。以带隙基准电路为例IEC 62380给出的CMOS模拟电路基础失效率通常按硅片面积和温度循环折算而SN 29500则偏向按元件类型和应力系数来算。我个人的做法是以客户和认证机构认可的那本标准为基准同时把不同标准算出来的结果做敏感性分析放在附录里。Synopsys的报告虽然会给出标准参考但它不会替你决定用哪本标准最终拍板的还是项目组和功能安全经理。2.2 失效模式库开路、短路、漂移三件套失效模式库决定了单个半导体结构可能以什么方式失效。经典的三件套是开路、短路、参数漂移但在实际芯片中还要细分到具体晶体管、电阻、电容的故障行为。例如一个用于电压比较器的差分输入对可能的失效模式包括输入对管短路、输入对管开路、阈值电压漂移、偏置电流异常等。每种模式的失效率占比不是拍脑袋的通常要参考EDA厂商或标准提供的失效模式分布表。这里有个很关键的细节失效模式分布的比例直接决定后续SPFM和LFM的计算结果。同样是100 FIT的模块如果开路占90%、漂移占10%和你把漂移算到90%、开路算到10%安全指标的差异会非常大。所以拿到任何外部报告里的失效模式分布表先确认它是否适用于你的工艺节点和电路设计风格不要盲目套用。2.3 安全机制与诊断覆盖率DC不能拍脑袋诊断覆盖率Diagnostic Coverage, DC是FMEDA里最容易被质疑的参数。它表示安全机制能检测出某种失效模式的比例。比如一个12位ADC的输出通过软件周期性校验如果校验算法能够捕获80%的ADC数据损坏那对ADC数据错误这个失效模式的DC就是80%剩下20%会成为残余故障计入SPFM分子。DC的来源必须可追溯。常见途径包括故障注入仿真比如在Synopsys的仿真环境里注入故障看安全机制能不能响应、芯片实测、或者标准中给定的参考值。我在审查报告时最警惕的就是DC没有支撑证据只写了设计保证四个字。分析师可以给一个乐观的DC但最终拿给第三方认证机构时如果没有故障注入报告项目会直接被开不符项。3. 一步步手算FMEDA先公式拆解再全流程推导理论说再多不如动手算一遍。这一节我用一个简化的车规芯片内部电压监控模块作为例子带大家从失效率表一直算到SPFM、LFM和PMHF。3.1 三种关键指标的基础公式ISO 26262-5给出的SPFM基础公式如下SPFM 1 - (Σλ_SPF Σλ_RF) / Σλ_safety_related其中Σλ_safety_related是安全相关失效的总失效率通常等于总失效率减去安全失效Σλ_SPF是单点故障失效率之和Σλ_RF是残余故障失效率之和。LFM的基础公式为LFM 1 - Σλ_LF / (Σλ_safety_related - Σλ_SPF - Σλ_RF)注意这里的λ_LF是潜伏故障失效率之和分母是安全相关失效总失效率扣除单点故障和残余故障之后的部分。也就是说LFM只关心那些被安全机制覆盖了但没有被及时检测出来的失效里有多少比例最终被诊断机制抓住了。PMHF的计算相对复杂ISO 26262-10里给了系统性的方法对所有双点故障对的贡献做概率学累加。在芯片级别如果做粗略估算可以只合计残余故障失效率和潜在双点故障对的等效失效贡献PMHF ≈ Σλ_RF Σλ_DPF_pair_contribution但工程上真正算PMHF时通常需要借助工具来遍历所有双点故障对手动算非常容易漏项。3.2 一个完整案例电压监控模块的FMEDA手算假设有一个车规MCU的内部电压监控模块安全目标是当主电源电压跌落到阈值以下时系统必须在10ms内进入安全状态。我们把该模块的安全相关总失效率定为100 FIT它细分为以下几种失效模式模式A比较器输入失调电压漂移导致欠压检测阈值偏移。失效率40 FIT。该失效受独立参考电压源配合周期性自校准安全机制保护诊断覆盖率90%因此残余故障率 40 × (1-0.9) 4 FIT。模式B分压电阻网络开路导致感应电压异常。失效率20 FIT。没有任何安全机制覆盖属于单点故障λ_SPF 20 FIT。模式CADC采样链路故障含MUX、采样保持等。失效率30 FIT。有软件斜坡自检安全机制诊断覆盖率60%。其中30 × (1-0.6) 12 FIT计入残余故障。模式D数字比较逻辑失效本身不直接导致安全目标违背但会与模式A/C组成双点故障。失效率10 FIT被周期性逻辑自检LBIST覆盖覆盖率20%未覆盖的10 FIT记为潜伏故障λ_LF。此外该模块还有20 FIT的失效率属于安全失效比如不影响安全目标的功能性失效。好现在开始计算。安全相关失效总失效率为100 FIT。SPFM 1 - (20 4 12) / 100 1 - 36/100 64%LFM 1 - 10 / (100 - 36) 1 - 10/64 ≈ 84.4%这两个结果可以很直观地看到问题SPFM只有64%如果这颗芯片的ASIL目标是B级要求≥90%那肯定不达标。问题出在单点故障太多以及两个有安全机制的模块DC没做够。要么给模式B加监控电路要么把模式A和模式C的安全机制做得更强否则只能靠架构层面做冗余来缓解单点风险。PMHF在这个简化案例中如果只算残余故障是41216 FIT但还要加上双点故障对的贡献。模式D与模式A/B/C组合产生的等效PMHF贡献通常远小于16 FIT但在严格计算中不能省略。这里就看出工具的价值了这种双点故障对遍历正是Synopsys这类报告背后所用分析工具擅长的。3.3 三大指标如何互动不是越高越好很多人以为SPFM和LFM越高就一定越安全其实不一定。比如你为了把SPFM做高加了一个极其灵敏的看门狗结果它动不动误触发复位反而降低了系统可用性。功能安全不是看单个指标的最大化而是看三个指标在架构约束下共同满足目标。而且过高的诊断覆盖率往往意味着安全机制本身很复杂又会引入新的失效率来源形成循环依赖。我在前面这个例子里故意选了DC比较难看的数据是想说明一个现象FMEDA手算的价值不是让你得出好看的百分比而是让你一眼定位到风险集中在哪个失效模式上。64%的SPFM对应的是20 FIT单点故障和16 FIT残余故障那项目组下一步的工作优先级就非常清晰——先去处理那块没有安全机制保护的分压电阻网络。4. 拆解Synopsys报告时容易翻车的五个坑读Synopsys的安全分析报告或者自己复现FMEDA计算时有几个坑几乎每个项目都会遇到单独拿出来说说我的排查思路。4.1 失效率单位换算FIT、ppm、MTBF不能随手等同失效率单位经常混用FIT、ppm/khr、MTBF之间换算错一位结果就会差几个数量级。1 FIT 10^-9/h 1个失效每十亿小时。ppm/khr指每千小时百万分之几的失效率和FIT的换算关系是1 ppm/khr 1 FIT因为10^-6/10^3 h 10^-9/h。MTBF是平均无故障时间MTBF 1/λ如果失效率是100 FITMTBF就是10^7小时也就是约1141年。即使是老工程师偶尔也会在10^3和10^9之间犯迷糊我的习惯是所有数据进表格前先统一成FIT并且用公式列自动换算绝不人工手算。4.2 安全失效和可探测失效被混为一谈ISO 26262明确规定安全失效safe fault不会导致安全目标违背也不应该被计入SPFM/LFM的分母。但在实际报告中有些失效模式既可能被判成安全失效又可能被判成可探测失效detected fault导致归类重叠。比如一个传感器故障被诊断机制检测到后进入安全状态那这个失效既被检测又不会导致危害那么它到底算安全失效还是在SPFM里作为被覆盖部分消掉两种处理方式在数学上都说得通但会导致最终SPFM数值不同而且暴露路径上的总风险并没有变化。我在对比Synopsys报告和自己手算结果时发现差异往往就来自这类归类口径。解决方法是在项目FMEA里先约定好每个模块失效模式的首要安全效应再统一归类规则同一个失效模式绝对不允许在同一张表里出现两个身份。4.3 DC参数的证据链断裂有时候报告里某个安全机制写了95%的DC看起来很漂亮但深入追问后发现这个95%是引用自某个完全不同的电路拓扑并非当前这个项目的设计。这种DC参数移植是行业里最常见的问题。不同工艺、不同版图、不同工作电压下同一个安全机制的诊断覆盖率会有显著差异尤其针对模拟电路失效比如电压漂移、电流泄漏DC几乎没有通用值。我现在的流程是对所有用于最终FMEDA计算的DC值都要求有对应的故障注入或实测数据支撑。如果是参考EDA厂商给出的库必须记录版本号和适用条件。如果拿不到直接证据宁可保守降级也不能为了凑指标虚高DC。4.4 PMHF计算时双点故障对遗漏手算PMHF时最容易漏掉的是双点故障对。漏掉的原因通常是分析师顺手把IEC 62380或SN 29500给出的失效率只做了单点合计却忘了双点故障对需要两个失效率做概率卷积。而这个卷积结果依赖暴露时间diagnostic test interval比如周期性自检是10ms还是100ms暴露时间差10倍PMHF贡献就差点接近一个数量级。这块复杂计算恰恰是Synopsys这类EDA工具链擅长的地方它能把设计网表、失效模式库、安全机制信息全部关联起来自动生成双点故障清单。但工具生成完也要人工抽查几个高风险pair我习惯挑失效率最高、暴露时间最长的几对手工复算验证工具配置是否正确。4.5 报告版本与设计版本严重漂移车规芯片项目动辄三五年期间网表改版、安全机制增减是家常便饭。FMEDA报告如果只更新了安全指标汇总而底层的失效模式表和DC参数还是旧版本这个报告就形同虚设。我见过最离谱的情况报告里写的是V2.0设计但芯片在V1.3时已经改过一次比较器结构FMEDA结论完全失效。应对办法是建立严格的版本对应关系FMEDA工作簿的版本号必须与设计版本、安全手册版本、故障注入报告版本四者联动。每出一个新的设计版本至少要做一次影响性分析判断哪些失效模式和DC可能有变化再决定是否全量重算。5. 从手算走向工具化FMEDA自动化计算的实际工作流前面说了很多手算方法和注意点但在实际的量产车规芯片项目中靠Excel手动做FMEDA既不现实也不受控。Synopsys等EDA厂商的完整安全分析环境已经把网表、失效模式库和故障注入仿真打通了我分享一下自己在实际项目中使用的几条自动化思路。5.1 故障注入仿真如何反过来校准DC很多工程师把故障注入当成一个事后验证的工具其实它更应该在FMEDA计算中起到前置校准作用。在Synopsys的模拟电路仿真环境中对带隙基准、比较器、ADC等模块做故障注入能直接测出每一种故障模式下安全机制的响应情况故障有没有被检测到、检测时延是多少、能否在安全时间内完成处置。这些数据落到FMEDA工作簿里DC参数就有了真实依据。我通常的做法是先跑一批故障注入统计检测成功率形成实测DC表再把实测DC表回填到FMEDA计算里看SPFM/LFM是否仍满足ASIL目标。如果实测DC比设计假设的低但指标仍有余量那就接受如果指标超标就需要修改安全机制设计或增加冗余而不是去给DC注水。5.2 FMEDA工作簿与Safety Manual的联动一份合格的FMEDA报告不是孤立存在的它要和Safety Manual安全手册、Safety Case安全案例保持一致。Synopsys的工具链在这块强调整体流程安全目标分解到硬件失效率指标再映射到FMEDA工作簿再由工作簿生成安全手册需要的参数比如安全机制诊断测试间隔、故障反应时间、安全状态定义等。这些参数如果手工同步很容易出现安全手册里写的诊断测试间隔和FMEDA计算里用的暴露时间不一致的情况。我现在做项目时要求所有安全机制参数以单一数据源为准FMEDA工作簿是主库安全手册和客户回复文档都从主库生成避免多套Excel各自为政。5.3 自动化不代表可以撒手不管工具化的本质是把重复劳动和复杂概率计算交给软件但分析师的判断仍然不可替代。比如某个失效模式到底属于安全失效还是残余故障依赖于功能安全分析和系统架构理解某个安全机制的DC是否存在过度乐观估计依赖于对电路实际失效物理的理解。工具能帮你算出99.9%的SPFM但算不出这个99.9%是不是被一个错误归类堆出来的。我通常在自动化FMEDA跑完之后还会做一次人工抽检随机挑三到五个安全目标倒推它们对应的失效率来源和DC依据是否都成立。这一步看似费时却是我在多次项目评审中最能挽救项目信用度的一环。6. 评审和审计场景下怎么快速回应客户对FMEDA的质疑FMEDA算完只是第一步更考验人的是在客户和第三方认证机构面前把结果解释明白。车规芯片客户对FMEDA报告的审查细致程度往往超过很多人的预期这里分享一下我应对高频质疑的套路。6.1 这个DC数据为什么是80%而不是90%这是个高频问题。客户质疑DC时真正想问的往往不是为什么不是90%而是你的DC依据是什么可不可信。反过来的应对策略是直接出示故障注入仿真报告的那一页指出该安全机制在600个故障样本里检测成功480个置信度多少然后说明工艺偏差扫描后的覆盖情况。只要证据链完整DC数值本身高一点低一点反而没那么重要反倒是拿不出依据的DC无论写多少都会被追着砍。6.2 为什么这颗芯片的PMHF和竞品差两倍不同芯片的PMHF直接对比其实没有太大意义因为安全目标假设、失效率标准选择、诊断测试间隔设定都可能不同。客户如果拿这个问题来问我会先确认双方对比基准是否一致用的失效率标准是否相同、安全目标覆盖范围是否一致、是否都算了双点故障对。如果这些前提不一致数字上的倍数差异完全不代表安全性差距。但如果是同一颗芯片的迭代版本那PMHF的变化就是硬指标必须给出明确解释。6.3 SPFM和LFM达标了是不是FMEDA就可以结束了不是。SPFM和LFM只是ISO 26262-5的量化指标FMEDA还需要覆盖故障反应时间、安全状态可达性、诊断测试间隔等约束假设。这些约束如果和实际软件调度对不上即使指标达标设计也是不合格的。比如一个诊断机制每100ms执行一次但安全机制要求40ms内报出故障那这个诊断机制形同虚设相关DC应该直接按0处理。6.4 把FMEDA当工程问题而不是应付检查的力气活做了这么多年功能安全我的体会是FMEDA算的不是纸面指标它本质是在用概率语言表达我对这颗芯片的安全机制到底有没有信心。Synopsys报告再全面也只能提供方法和部分基础数据真正决定FMEDA质量的是设计团队愿不愿意把每个失效模式、每个DC证据、每个时间约束都较真到底。如果只是为了应付认证去凑SPFM和LFM最终交付的报告必然漏洞百出一到客户现场就会被问垮。反过来每一次FMEDA计算都把架构假设、失效模式、诊断逻辑彻底理清这本身就能倒逼设计团队发现很多隐性风险。我常跟团队说把FMEDA当成给芯片做一次彻底的安全体检你投入得越认真收获的洞察越多报告被质疑的空间就越小。