做ISO 26262硬件架构指标时，SPFM最容易被误解成“故障检出率”，但它实际看的不是某一个诊断点好不好，而是整个安全相关硬件里，单点故障和残余故障还剩下多少没有被架构有效压住。TI的功能安全资料给出了工程上常用的表达式，SPFM等于1减去单点故障失效率与残余故障失效率之和再除以安全相关总失效率。Infineon的说明也强调，QM部分不计入这项计算，而且ASIL B、ASIL C、ASIL D常见目标分别是不低于90%、97%、99%。

　　一、ISO 26262 SPFM怎么计算

　　真正算SPFM，核心不是先套公式，而是先把FMEDA里的故障分类做对。TI的FMEDA资料说明，每一行失效率都要先判断是不是安全相关，再根据失效模式、是否会违反安全目标、有没有安全机制、诊断覆盖率有多高，最终分到单点故障、残余故障、潜在多点故障等类别里。只有这一步分类做稳，后面的SPFM才有意义。

　　1、先定分母

　　分母通常取安全相关总失效率，也就是ΣλSR，而不是把所有随机故障一股脑全加进去。TI的示例公式和FMEDA工具说明都按这个口径来算，所以做表时先把安全相关边界划清，比后面反复调覆盖率更重要。

　　2、再定分子

　　分子是ΣλSPF加ΣλRF，也就是单点故障失效率与残余故障失效率之和。NXP的安全应用说明对两类故障的定义很清楚，单点故障是没有被安全机制覆盖且会直接违反安全目标的故障，残余故障则是虽有安全机制但仍有一部分未被覆盖的故障。

　　3、最后代入公式

　　工程上最常见的写法就是

　　SPFM等于1减去ΣλSPF加ΣλRF再除以ΣλSR。

　　TI的公开示例里还给了完整算例，安全相关总失效率为9 FIT，单点故障与残余故障合计0.042 FIT，算出来SPFM为99.5%。这类算例的价值，不是照抄数字，而是帮你核对表格口径有没有跑偏。

　　4、算完以后要对照目标等级

　　SPFM不是单独看高低，而是要对照目标ASIL。TI与Infineon的资料都给出了常用目标，ASIL B不低于90%，ASIL C不低于97%，ASIL D不低于99%。如果你的结果只比门槛高一点，也不要急着收尾，因为后面一旦mission profile、失效率分配或诊断覆盖率调整，结果还可能继续波动。

　　二、ISO 26262 SPFM结果偏低怎么解决

　　SPFM偏低，说到底只有两个大方向，要么分子太大，也就是SPF和RF太多，要么你前面的安全相关划分和FMEDA分类没有收准。TI的FMEDA工具说明写得很直白，用户可以调整mission profile、环境假设和所采用的诊断措施，这些都会影响原始FIT、safety related FIT和最后的架构指标。所以真正要改低分，不是只盯公式，而是要回到故障分类和诊断手段本身。

　　1、先压单点故障

　　SPFM低分时，第一反应应该是去找那些没有安全机制兜底、会直接违反安全目标的故障路径。只要把这部分故障从单点故障变成“可检测故障”或“不再直接违反安全目标的故障”，分子就会明显下降。这一步本质上是在改架构，而不是改表格。NXP对SPF的定义和TI的算式都支持这一判断。

　　2、再压残余故障

　　如果已经有安全机制，但SPFM还是低，问题通常就落在残余故障。NXP明确说明，残余故障是安全机制存在但覆盖不完整留下来的那一部分。要把RF压下去，最直接的办法就是提高诊断覆盖率，让原来未覆盖的那部分继续缩小。NXP还给出过常见覆盖率分级，低覆盖约60%，中覆盖约90%，高覆盖约99%，残余FIT会随之下降。

　　3、把检测做进FTTI里

　　NXP的安全应用说明特别提醒，单点故障必须在FTTI内被检测并进入安全反应，否则它还是会按单点故障去计。也就是说，有些项目SPFM低，不是诊断手段完全没有，而是故障指示时间加反应时间没有压进FTTI，结果在指标里依然算不掉。

　　4、补强诊断机制而不是只改判定口径

　　TI的功能安全手册给了很多典型思路，比如外部电压监控、内外部看门狗、棕断复位、软件回读配置寄存器、周期性静态寄存器回读、时钟完整性检查、ECC相关事件监控，以及异构处理单元做reciprocal comparison。这类手段的共同点不是名字多，而是都在提高对安全相关故障的诊断覆盖率。

　　三、ISO 26262 SPFM低分先查什么

　　很多项目SPFM偏低，不是设计真的很差，而是FMEDA录入和分类顺序本身就没收住。更稳的做法，是先从表格里把最影响结果的几层拆开看，而不是一上来就补很多安全机制。TI的FMEDA工具说明已经把关键影响项点出来了，故障分类、mission profile、环境条件和诊断措施选择都会改动结果。

　　1、先查故障分类

　　优先看SPF、RF、MPF的分类有没有混。只要把本该是潜在多点故障的项误放进SPF，或者把本该有覆盖的故障仍按RF算，SPFM就会被直接拉低。TI明确说明，FMEDA每一行都要按ISO 26262的分类逻辑落到对应类别里。

　　2、再查safety related边界

　　如果分母里的ΣλSR口径乱了，结果也会跟着乱。Infineon资料明确提到QM部分不纳入SPFM计算，所以安全相关边界一定要和安全目标一致，不能为了好看随意缩，也不能把无关部分硬塞进来。

　　3、再查诊断覆盖率依据

　　诊断覆盖率不能拍脑袋给。TI和Microchip的资料都强调，FMEDA的价值就在于把故障率和诊断覆盖率量化，并把这些量化值用于架构指标计算。所以当某一块SPFM偏低时，要回头看DC的依据是不是来自实际设计、验证或供应商安全手册，而不是经验填值。

　　4、最后查mission profile和环境假设

　　TI的FMEDA工具说明明确写到，地理位置、环境因子、功耗和相关使用条件都会影响原始FIT以及safety related FIT。也就是说，如果你换了应用环境却还沿用旧假设，SPFM结果可能看上去不合理，但问题不一定在安全机制本身，而在输入假设。

　　总结

　　ISO 26262 SPFM怎么计算，工程上最常用的口径就是SPFM等于1减去单点故障失效率与残余故障失效率之和再除以安全相关总失效率。ISO 26262 SPFM结果偏低怎么解决，真正有效的方向也很明确，先去压SPF，再去压RF，同时确认诊断动作能否在FTTI内完成，最后回到FMEDA里核对故障分类、safety related边界、诊断覆盖率依据和mission profile假设。把这几层收顺，SPFM往往会比单纯修改一个百分比数字更容易做实。