3. 单点故障度量指标：SPFM 的计算公式与含义
好，咱们进入正题。SPFM，全称 Single Point Fault Metric，中文叫单点故障度量。这个指标是 ISO 26262 功能安全里最基础、也最容易被误解的一个。我见过不少工程师，一上来就盯着数字算，却搞不清它到底在度量什么。
说白了，SPFM 衡量的是：你的安全机制，到底能挡住多少单点故障。它不是一个抽象的分数，而是实打实的“覆盖率”。
3.1 什么是单点故障？
先明确概念。单点故障，指的是一个硬件故障，它本身就能直接违反安全目标。没有其他故障帮忙，没有冗余保护，一个点坏了，系统就出事了。
举个例子。你想想看，一个刹车踏板的位移传感器。如果它内部短路了，输出一直显示“未踩下”，那刹车系统就不会响应。这就是典型的单点故障。它自己就能导致危险。
核心定义：单点故障 = 单个故障点 + 直接违反安全目标 + 无冗余保护
3.2 SPFM 的计算公式
公式不长，但每个参数都有讲究。我直接写出来：
SPFM = 1 - ( Σλ_SPF + Σλ_RF ) / Σλ_total拆开看：
- λ_SPF：单点故障的失效率。就是那些没有被任何安全机制覆盖的故障。
- λ_RF：残余故障的失效率。安全机制覆盖了，但没完全挡住，漏掉的那部分。
- λ_total：所有相关硬件故障的总失效率。
嗯，这里要注意。分母是总失效率，分子是“没被安全机制处理掉”的失效率。所以 SPFM 越高，说明安全机制越有效。
3.3 公式的物理含义
我习惯用一个比喻来解释。你有一个筛子，用来筛沙子。总共有 100 粒沙子（λ_total）。筛子（安全机制）能筛掉 95 粒，剩下 5 粒漏下去（λ_SPF + λ_RF）。那你的 SPFM 就是 95%。
这个指标，本质上就是安全机制的“过滤效率”。
| 参数 | 含义 | 典型来源 |
|---|---|---|
| λ_SPF | 单点故障失效率 | 无安全机制覆盖的故障 |
| λ_RF | 残余故障失效率 | 安全机制覆盖但未检测到的故障 |
| λ_total | 总失效率 | 所有相关硬件故障 |
| SPFM | 单点故障度量 | 安全机制的覆盖率 |
3.4 安全目标等级与 SPFM 要求
ISO 26262 对不同 ASIL 等级有明确要求。我直接列个表，你对照着看：
| ASIL 等级 | SPFM 目标值 | 说明 |
|---|---|---|
| ASIL A | 无要求 | 通常不做定量分析 |
| ASIL B | ≥ 90% | 基础安全机制即可满足 |
| ASIL C | ≥ 97% | 需要较强的诊断覆盖 |
| ASIL D | ≥ 99% | 几乎要覆盖所有单点故障 |
你看，ASIL D 要求 99% 以上。这意味着，1000 个故障里，最多只能有 10 个漏网。这个要求非常苛刻。
3.5 计算示例：一个简单的传感器模块
咱们来算一个实际的例子。假设有一个温度传感器模块，总失效率 λ_total = 100 FIT（Failures In Time，每 10^9 小时故障次数）。
安全机制是一个比较器，能检测出传感器短路和开路。但比较器本身也有残余故障。
λ_total = 100 FIT
λ_SPF = 5 FIT （传感器漂移故障，比较器无法检测）
λ_RF = 3 FIT （比较器自身故障，导致检测失效）
SPFM = 1 - (5 + 3) / 100 = 1 - 0.08 = 0.92 = 92%92% 的 SPFM，刚好满足 ASIL B（≥90%），但离 ASIL C（≥97%）还差一截。我在项目中遇到过类似的情况，客户要求 ASIL C，结果我们不得不加一个额外的看门狗定时器来覆盖残余故障。
我的经验：别只看最终数字。SPFM 计算过程中，λ_SPF 和 λ_RF 的分配才是关键。很多团队在 λ_RF 上估算不足，导致实际覆盖率远低于理论值。
3.6 SPFM 与安全机制的关系
SPFM 不是凭空算出来的。它依赖于你设计的安全机制。常见的安全机制包括：
- 自检（Self-Test）：比如 CPU 的 LBIST，上电时跑一遍。
- 比较器（Comparator）：两个通道比较，不一致就报错。
- 看门狗（Watchdog）：监控程序是否跑飞。
- 冗余（Redundancy）：双路或三路表决。
每种安全机制都有自己的诊断覆盖率（DC）。DC 越高，λ_RF 就越低，SPFM 就越高。
3.7 常见误区与避坑指南
我见过不少团队在 SPFM 上栽跟头。这里列几个典型问题：
- 误区一：把所有故障都算成单点故障。 实际上，有些故障是潜伏故障，属于 LFM 的范畴。别混在一起算。
- 误区二：忽略安全机制自身的故障。 安全机制也会坏。它的残余故障必须算进 λ_RF。
- 误区三：用理想化的 DC 值。 我曾经看到一个项目，用了 99% 的 DC 值，结果实际测试只有 80%。数据来源要可靠。
避坑指南：我曾经在一个 ASIL D 项目中，团队把 SPFM 算到了 99.5%，但审核时发现他们把安全机制的失效率全忽略了。结果重新计算后，SPFM 掉到了 97%。嗯，那段时间加班改设计，记忆犹新。
3.8 SPFM 的局限性
SPFM 不是万能的。它只关注单点故障，不关注潜伏故障。一个系统 SPFM 很高，但 LFM 很低，依然可能因为多个潜伏故障的累积而失效。
所以，SPFM 必须和 LFM（潜伏故障度量）一起看。两者互补，才能全面评估硬件安全。
3.9 小结
SPFM 是功能安全的第一道防线。它告诉你，你的安全机制对单点故障的“屏蔽能力”有多强。计算不难，难在准确估算 λ_SPF 和 λ_RF。我建议你在项目初期就建立故障库，把每个故障的分类和覆盖率都记录下来。这样后期审核时，心里有底。