企业官网建设流程全解析

1. 开篇——一个数字决定的命运

2020 年，某国内 Tier 1 供应商的制动 ECU 项目进入最终评审阶段。硬件设计团队信心满满——原理图评审通过、EMC 测试通过、环境可靠性测试通过。然而在功能安全评审会上，一个数字像一盆冷水浇下来：PMHF 计算结果为 2.3 × 10−8/h，而 ASIL D 的目标门槛是 < 10−8/h——超标 2.3 倍。

PMHF，Probabilistic Metric for random Hardware Failures，随机硬件失效概率度量。这个看起来冷冰冰的数字，代表的含义是：每小时发生危险随机硬件失效的概率是 2.3 × 10−8，也就是大约每 4975 年才会发生一次危险失效。听起来似乎很安全？但 ISO 26262 对 ASIL D 的要求是更严格的 < 10−8/h（大约每 11415 年一次），2.3 倍的差距意味着硬件架构必须重新设计。

团队的整改方案很痛苦：在主处理通道之外增加一个独立的冗余监控通道，让两个通道交叉比对、互相校验。这意味着重新设计 PCB 布局、增加一颗安全 MCU、修改 BOM 清单、重新跑一轮 EMC 测试和温度循环测试。整个项目因此延期 4 个月，直接成本增加超过 800 万元。

核心教训：硬件安全指标不是"设计完了算一算"的橡皮图章，而是从设计初期就要"预算"的核心约束。就像建筑的结构安全系数必须在画施工图之前就确定，硬件安全指标必须在架构设计阶段就进行预估和分配。

本文核心论点：ISO 26262 Part 5 定义了三个硬件架构度量指标——SPFM（单点故障度量）、LFM（潜伏故障度量）、PMHF（随机硬件失效概率度量）。这三个指标构成了硬件安全评估的"铁三角"，任何一个不达标，硬件架构就不合格。理解三大指标的本质、计算方法和工程实践，是功能安全工程师的必备技能。本文将逐一拆解这三大指标的定义、公式、ASIL 对应关系和计算思路，并通过一个 ASIL D 制动 ECU 的完整案例，展示从理论到实践的全过程。

硬件安全指标就像汽车的"保险杠测试标准"。你不能等车造好了才去测保险杠能不能抗住碰撞——标准必须在设计阶段就定好，工程师要据此选择材料、设计结构、安排工序。PMHF 就是那个"碰撞测试分数"，SPFM 是"正面碰撞得分"，LFM 是"侧面碰撞得分"，三项都要过线才算合格。

2. 为什么需要硬件架构度量？

2.1 ISO 26262 Part 5 的定位

ISO 26262 Part 5 的全称是《产品开发——硬件级》（Part 5: Product Development at the Hardware Level），它是整个标准中专门针对硬件工程的部分。Part 5 的核心任务有两个：

• 硬件安全需求规范（Hardware Safety Requirements）：定义硬件必须实现哪些安全功能，包括安全机制、故障检测时间、故障容忍时间等。
• 硬件架构度量与评估（Hardware Architectural Metrics）：通过 SPFM、LFM、PMHF 三个定量指标，评估硬件架构是否足够"安全"。

为什么需要量化度量？因为"觉得安全"和"证明安全"是两回事。ISO 26262 的哲学是：安全不能凭经验、不能凭感觉，必须用数据说话。硬件架构度量就是这套"用数据说话"的方法论。

2.2 系统性失效 vs 随机失效

在理解硬件度量之前，必须先搞清两种根本不同的失效类型：

系统性失效像"设计图纸画错了"——如果一栋楼的承重墙设计强度不够，那每一栋用这张图纸盖出来的楼都有问题。这不是概率问题，是确定性错误。随机失效像"灯泡烧了"——你不知道哪盏灯什么时候会烧，但你统计一万盏灯后发现平均寿命是 1000 小时，可以据此做出概率预测。ISO 26262 的硬件架构度量（SPFM/LFM/PMHF）针对的就是"灯泡烧了"这类随机失效，通过定量指标证明硬件架构足以应对它们。

2.3 三大指标的分工

ISO 26262 Part 5 定义了三个互补的硬件架构度量指标，它们各有分工、缺一不可：

注意：这三个指标的关系不是"三选一"，而是"三个都要达标"。如果 SPFM 达标了但 PMHF 超标，硬件架构仍然不合格。同样，PMHF 达标了但 SPFM 不够，也不行。三者共同构成硬件安全的"铁三角"。

3. SPFM：单点故障度量

3.1 什么是单点故障？

在讲 SPFM 之前，先明确"单点故障"（Single-Point Fault, SPF）的定义：

单点故障是指这样一个故障——它本身就直接导致违反安全目标，不需要与其他故障组合。换句话说，一个单点故障就是"一颗螺丝松了整台机器就垮"的那种故障。

举个例子：制动 ECU 中的主 MCU 发生了"输出引脚 stuck-at-high"（输出引脚卡在高电平）故障，直接导致制动执行器持续施加制动力——这在高速行驶中可能导致车辆失控。这个 MCU 引脚卡死故障就是一个单点故障，因为不需要其他任何故障配合，它自己就能引发危险。

3.2 SPFM 的定义与公式

SPFM（Single-Point Fault Metric）衡量的是：在所有可能的单点故障中，有多大比例能够被安全机制检测到。

SPFM 公式（ISO 26262 Part 5 Clause 9）：

SPFM = 1 − ΣλSPF,undetected / Σλtotal

其中：

• ΣλSPF,undetected= 所有未被安全机制检测到的单点故障（含残余故障）的失效率之和
• Σλtotal= 所有硬件故障的失效率之和（包括安全故障、单点故障、多点故障等全部故障）

让我们拆解这个公式：

• 分子 ΣλSPF,undetected：那些"坏了但发现不了"的单点故障的总失效率。这个值越小越好——意味着漏检的单点故障越少。
• 分母 Σλtotal：系统中所有硬件故障的总失效率，作为归一化基准。
• SPFM 值越接近 1：说明安全机制对单点故障的覆盖越充分。

3.3 ASIL 等级对应的 SPFM 目标值

注意：ASIL C 和 ASIL D 的 SPFM 目标值相同（≥ 99%），这不意味着两者要求一样。ASIL D 在 PMHF 目标值和 LFM 目标值上都比 ASIL C 更严格（详见第 6 章汇总表），并且软件和流程要求也更高。

3.4 SPFM 的工程含义

SPFM 回答的核心问题是："如果只有一个零件坏了，我有多大把握能发现它？"

假设一个 ECU 有 100 种可能发生的故障模式，其中 80 种是单点故障。如果你的安全机制（看门狗、CRC 校验、电流监控等）能检测到其中 79 种，那么：

• SPFundetected = 1 种（漏检 1 种单点故障）
• 如果 Σλtotal = 100 FIT（10−7/h），漏检的 SPF 失效率 = 0.5 FIT
• SPFM = 1 − 0.5/100 = 99.5%，满足 ASIL C/D 要求

SPFM 就像"烟感器覆盖率"——你在大楼里装了一百个烟感器，SPFM 衡量的是：如果只有一个地方着火了，烟感器有多大把握能发现？如果 SPFM 是 99%，意味着平均 100 次着火中，有 99 次烟感器能报警，只有 1 次可能漏报。对于 ASIL D 这种事关生命安全的等级，ISO 26262 要求至少 99% 的覆盖率。

4. LFM：潜伏故障度量

4.1 什么是潜伏故障？

潜伏故障（Latent Fault）的定义比单点故障更微妙：潜伏故障是指安全机制未能检测到的多点故障。

什么是多点故障（Multi-Point Fault, MPF）？就是需要两个或更多故障同时发生才会导致违反安全目标的故障。单独一个故障不会引发危险，但加上第二个故障就会。

一个多点故障被安全机制检测到了，就叫感知多点故障（Detected Multi-Point Fault, DPF）——系统知道有问题，可以报警或进入安全状态。但如果安全机制没检测到，它就成了潜伏多点故障（Latent Multi-Point Fault, LMPF）——两个故障都存在，但系统浑然不知。

潜伏故障是"隐形炸弹"：第一个故障已经发生了但系统不知道，就像定时炸弹已经埋下了但没人发现。等到第二个故障也发生了——砰！违反安全目标。潜伏故障之所以危险，正是因为它的"潜伏性"：系统运行正常，没有任何报警，但实际上已经处于"一触即发"的危险状态。

潜伏故障就像飞机的两个引擎中已经有一个出了故障但飞行员不知道。飞机还能飞（因为另一个引擎正常），但如果第二个引擎也出了问题——那就是灾难。LFM 衡量的是：飞行安全监控系统能否在第二个引擎出问题之前发现第一个引擎的故障？如果 LFM 是 90%，意味着 100 次单引擎故障中，有 90 次能被及时发现，只有 10 次成了"潜伏炸弹"。

4.2 LFM 的定义与公式

LFM 公式（ISO 26262 Part 5 Clause 9）：

LFM = 1 − ΣλMPF,latent / Σλtotal

其中：

• ΣλMPF,latent= 所有潜伏多点故障的失效率之和
• Σλtotal= 所有硬件故障的失效率之和

关键区别：

• SPFM 的分子是未被检测到的单点故障（含残余故障）
• LFM 的分子是未被检测到的多点故障（潜伏多点故障）
• 两者的分母都是所有硬件故障的总失效率

4.3 ASIL 等级对应的 LFM 目标值

注意：LFM 比 SPFM 的门槛低，这并不意味着 ISO 26262 对多点故障不重视。实际上，多点故障本身已经需要"两个故障同时发生"才会危险，其天然发生概率远低于单点故障。ISO 26262 的思路是：对低概率事件适当放宽度量要求，但对高概率事件（单点故障）施加更严格的要求。

4.4 LFM 的工程含义

LFM 回答的核心问题是："如果有两个零件同时坏了，我有多大把握在第二个坏之前发现第一个？"

在实际工程中，提升 LFM 的常见手段包括：

• 启动自检（Power-On Self-Test, POST）：每次上电时对关键元件做全面检查，检测之前潜伏的故障
• 运行时周期自检（Runtime Periodic Test）：在系统运行过程中周期性地对冗余通道进行自检
• 看门狗交叉监控：两个独立通道互相监控对方的健康状态
• 电流/电压监测：通过监测电路的电气特征来判断元件是否已经发生退化或部分失效

5. PMHF：随机硬件失效概率度量

5.1 PMHF 的定义与本质

PMHF（Probabilistic Metric for random Hardware Failures）是 ISO 26262 Part 5 中最重要的一个定量指标，也是唯一一个直接给出概率数值（而非百分比）的度量指标。

PMHF 的定义：每小时发生危险随机硬件失效的概率。

单位：h−1（每小时）

典型数量级：10−6 ~ 10−8/h

PMHF 的物理含义非常直观：假设有 109 辆车，每辆车每小时有 1 次机会发生危险硬件失效，如果 PMHF = 10−8/h，那么平均每 109 个车辆运行小时中，会发生 10 次危险失效。听起来概率极低，但考虑到全球有超过 10 亿辆汽车在运行，每小时的总暴露量是巨大的。

5.2 ASIL 等级对应的 PMHF 目标值

注意：ASIL C 和 ASIL D 的 PMHF 目标值相同（< 10−8/h），但 ASIL D 在 SPFM 和 LFM 上要求更严格。ISO 26262 在 PMHF 上没有进一步区分 C 和 D，但在实践中，很多整车厂会为 ASIL D 设定更严格的内部门槛值（如 < 5 × 10−9/h）。

5.3 PMHF 与 PFHd 的对比

熟悉 ISO 13849 的读者会注意到，PMHF 与 ISO 13849 的 PFHd（Performance Level 的平均危险失效概率）概念类似。两者对比如下：

5.4 PMHF 是针对"相关项"的

关键理解：PMHF 不是针对某个芯片、某个电阻的指标，而是针对相关项（item）的——即整个安全相关系统。ISO 26262 第 1 部分将"相关项"定义为"在 ISO 26262 中进行安全评估的、在车辆层面实现一个或多个安全功能的系统或子系统"。

这意味着 PMHF 的计算必须覆盖从传感器到 ECU 到执行器的完整链路，而不能只算其中一部分。在工程实践中，PMHF 通常通过 FMEDA（失效模式、影响及其诊断分析）方法，将每个元件的失效率按照故障模式和安全机制覆盖率进行汇总计算。

6. 三大指标与 ASIL 的对应关系

6.1 汇总表格

下面是 ISO 26262 Part 5 Clause 9 给出的三大硬件架构度量指标的完整目标值汇总表：

三个必须同时满足：对于任何 ASIL 等级（A/B/C/D），SPFM、LFM、PMHF 三个指标必须全部达标。如果 SPFM = 99.5%（达标 ASIL D），LFM = 85%（不达标 ASIL D 的 90%），PMHF = 0.5 × 10−8（达标 ASIL D），那么硬件架构评估结论仍然是不合格。

6.2 "三脚凳"模型

三大指标的关系可以用一个"三脚凳"来形象比喻：一条凳子需要三条腿才能站稳——SPFM、LFM、PMHF 就是三条腿。任何一条腿短了，凳子就会歪。

6.3 QM 等级的特殊性

QM（Quality Management）等级不要求满足 SPFM、LFM 或 PMHF 的目标值。这意味着 QM 元件（如车载娱乐系统的音频功放芯片）不需要进行硬件架构度量评估。但要注意：QM 元件如果用在 ASIL 系统中，其失效仍然需要纳入 PMHF 的计算——因为 PMHF 是针对整个相关项的，不分元件的 ASIL 等级。

7. 故障分类体系——理解指标的前提

要正确计算 SPFM 和 LFM，必须先理解 ISO 26262 Part 5 定义的一套完整的故障分类体系。这套体系将硬件故障分为六类，理解每一类的定义是理解三大指标公式的前提。

7.1 六类故障定义

关键关系：残余故障（RF）是单点故障（SPF）的一个子集——当安全机制覆盖了某个 SPF 时，它就不再是 RF；当安全机制没能覆盖某个 SPF 时，它就是 RF。类似地，潜伏多点故障（LMPF）是多点故障（MPF）的一个子集——被安全机制检测到的是 DPF，未被检测到的是 LMPF。

7.2 故障分类树

7.3 故障分类与指标公式的关系

理解了故障分类之后，三大指标公式的含义就清晰了：

8. 安全机制与诊断覆盖率

8.1 安全机制的定义和分类

安全机制（Safety Mechanism）是 ISO 26262 中的一个核心概念：安全机制是设计用来检测故障、控制故障影响、或使系统进入安全状态的工程手段。没有安全机制，硬件架构度量指标就无法达标——因为"检测覆盖率"为零意味着 SPFM 和 LFM 都是零。

ISO 26262 Part 5 Clause 7 将安全机制分为两大类：

软件实现的安全机制需要额外论证：如果安全机制是由软件实现的，那么必须证明"安全机制本身的软件不会因为软件 bug 而失效"。这意味着需要为安全机制软件也分配 ASIL 等级，并按照 Part 6 的要求进行开发。在实际工程中，为简化论证，高 ASIL 等级的安全机制通常优先采用硬件实现。

8.2 诊断覆盖率的概念

诊断覆盖率（Diagnostic Coverage, DC）是指安全机制能检测到的故障比例。它是 SPFM 和 LFM 计算的核心输入参数。

对于某个特定的故障模式，诊断覆盖率 DC 的定义是：

DC = 被检测到的故障失效率 / 该故障模式的总失效率

例如：MCU 的某个 RAM 故障模式总失效率为 100 FIT，其中 90 FIT 能被 March C 算法检测到，那么这个故障模式的 DC = 90%。

8.3 不同安全机制的典型诊断覆盖率

诊断覆盖率就像"安检系统的检出率"。机场安检用 X 光机、金属探测器、手持探测仪多层检测，综合检出率可达 99%。但每种手段各有擅长——X 光机擅长检液体和爆炸物，金属探测器擅长检金属武器。硬件安全机制也是如此：CRC 擅长检数据损坏，看门狗擅长检程序跑飞，双核锁步擅长检 CPU 逻辑错误。没有一种安全机制能检测所有故障，所以需要多种安全机制组合使用。

8.4 诊断覆盖率与 ISO 13849 DC 的异同

熟悉 ISO 13849 S05 篇的读者会发现，ISO 13849 也有"诊断覆盖率"（Diagnostic Coverage, DC）的概念。两者的关系：

9. PMHF 计算方法概述

PMHF 的计算是硬件安全度量中最复杂、最耗时的部分。ISO 26262 Part 5 提供了两种计算方法，分别在 Annex D（附录 D）和 Annex E（附录 E）中描述。

9.1 简化计算公式（Part 5 Annex D）

简化公式适用于故障独立性假设成立的场景（即不同元件的故障相互独立）。其核心思想是：

PMHF_simplified = Sum[ lambda_RF + Sum( lambda_MPF_latent * lambda_MPF_intermediate * T_mission ) ]

其中：

• λRF：残余故障的失效率（单点故障中未被检测的部分）
• λMPF,latent：潜伏多点故障的失效率（第一个故障，未被检测）
• λMPF,intermediate：中间多点故障的失效率（第二个故障）
• Tmission：任务时间（通常取 1 小时）

简化公式的核心思路：

PMHF = 残余故障的直接贡献 + 多点故障的组合贡献

残余故障（RF）本身就是危险的，所以直接计入 PMHF。多点故障需要"两个故障同时发生"，其概率近似等于两个故障失效率的乘积再乘以任务时间。

9.2 完整计算方法（Part 5 Annex E）

完整计算方法考虑了更多因素，包括：

• 安全机制故障自身的影响：安全机制本身也可能失效（比如看门狗电路坏了）
• 共因故障（Common Cause Failure, CCF）：两个本应独立的通道因为同一根因而同时故障
• 故障暴露时间间隔：第一个故障发生后到被检测到（或第二个故障发生）的时间窗口
• 不同运行模式：系统可能在不同工况下有不同的失效率

完整方法的计算公式更为复杂，通常需要借助专门的 FMEDA 工具（如 Exida SILver、TUV SUD FSE、ReliaSoft 等）来完成。

9.3 两种方法的适用场景

9.4 PMHF 计算的输入数据来源

无论是简化公式还是完整方法，PMHF 计算都需要大量基础数据，主要来源包括：

关于数据质量的提示："Garbage in, garbage out"——PMHF 计算结果的可靠性完全取决于输入数据的质量。在实际项目中，元器件失效率数据应优先使用供应商提供的实测数据或经过验证的工业数据库数据，而非简单查表。FMEDA 分析中使用的 DC 值也应有工程依据（如安全机制的详细设计规格、测试报告等）。关于详细的 FMEDA 方法论，将在 A06 篇中深入讲解。

10. 工程实战：ASIL D 制动 ECU 的硬件度量

理论讲完了，现在用一个完整的工程案例来演示三大指标的计算过程。

10.1 场景描述

某电子稳定控制系统（ESC）的制动 ECU，安全目标为"不得因 ECU 故障导致非预期制动或制动力丧失"，ASIL 等级为ASIL D。ECU 的关键硬件组件包括：

10.2 Step 1：故障模式分类

首先对每个组件的故障模式进行分类（SPF / RF / MPF / SF）：

10.3 Step 2：安全机制配置

为每个故障模式分配安全机制并评估诊断覆盖率（DC）：

10.4 Step 3：SPFM 计算

根据故障分类和安全机制配置：

分子（未检测的单点故障失效率之和）：

• 残余故障：供电监控阈值漂移 6 FIT + 扭矩传感器信号漂移 8 FIT =14 FIT
• 其他未检测 SPF：本设计中所有 SPF 均有安全机制覆盖或属于 MPF
• ΣλSPF,undetected =14 FIT

分母（所有硬件故障失效率之和）：

• Σλtotal = 主MCU(120) + 安全MCU(80) + 供电监控(30) + 驱动桥(200) + 扭矩传感器接口(60) + CAN收发器(50) =540 FIT

SPFM 计算：

SPFM = 1 − 14 / 540 = 1 − 0.0259 =97.41%

判定：不达标。ASIL D 要求 SPFM ≥ 99%，当前 97.41% 差距明显。主要原因是供电监控 IC 的阈值漂移和扭矩传感器信号漂移这两项残余故障。

改进措施：增加安全 MCU 的 ADC 采样通道对供电电压进行二次校验（消除供电监控残余故障），增加冗余扭矩传感器（消除扭矩传感器漂移残余故障）。改进后残余故障降至约 2 FIT，SPFM 提升至 1 − 2/540 =99.63%，达标。

10.5 Step 4：LFM 计算

对于潜伏多点故障，需要找出那些"未检测到的 MPF"：

• 主MCU stuck-at（15 FIT），DC = 98%，未检测部分 = 15 × 2% = 0.3 FIT
• 安全MCU stuck-at（10 FIT），DC = 95%，未检测部分 = 10 × 5% = 0.5 FIT
• 驱动桥输出 stuck-at（40 FIT），DC = 92%，未检测部分 = 40 × 8% = 3.2 FIT
• 驱动桥半桥短路（25 FIT），DC = 90%，未检测部分 = 25 × 10% = 2.5 FIT
• CAN 数据错误（8 FIT），DC = 97%，未检测部分 = 8 × 3% = 0.24 FIT

ΣλMPF,latent= 0.3 + 0.5 + 3.2 + 2.5 + 0.24 =6.74 FIT

LFM 计算：

LFM = 1 − 6.74 / 540 = 1 − 0.0125 =98.75%

判定：达标。ASIL D 要求 LFM ≥ 90%，当前 98.75% 远超要求。

10.6 Step 5：PMHF 计算（简化公式）

使用 Part 5 Annex D 的简化公式：

PMHF = lambda_RF + Sum( lambda_MPF_latent * lambda_MPF_intermediate * T_mission )

残余故障直接贡献：

• λRF = 14 FIT = 14 × 10−9/h = 1.4 × 10−8/h

多点故障组合贡献（典型项）：

• 主MCU潜伏（0.3 FIT）× 安全MCU潜伏（0.5 FIT）× 1h = 0.15 × 10−18/h（可忽略）
• 驱动桥潜伏（3.2 FIT）× 供电监控潜伏（4 FIT）× 1h = 12.8 × 10−18/h（可忽略）

多点故障组合贡献在数量级上远小于残余故障贡献（10−18 vs 10−8），可以忽略不计。

PMHF 估算：

PMHF ≈ 1.4 × 10−8/h

判定：不达标。ASIL D 要求 PMHF < 10−8/h，当前 1.4 × 10−8/h 超标 40%。

这与本章开篇的案例吻合——残余故障是 PMHF 超标的主因。采取 SPFM 改进措施（消除残余故障）后，λRF 降至约 2 FIT，PMHF 降至 0.2 × 10−8/h，达标。

10.7 结果判定汇总

最终结论：通过消除残余故障（增加供电电压二次校验通道和冗余扭矩传感器），三个指标全部达标，硬件架构评估合格。这个案例展示了残余故障（RF）对 SPFM 和 PMHF 的双重影响——RF 既降低 SPFM（因为分子增大），又直接计入 PMHF（因为它是未经安全机制保护的残余风险）。

消除残余故障就像给大楼加固"承重墙的最薄弱点"。你不需要加固每一面墙（成本太高），只需要找到那几块"可能被震裂但没人发现"的砖（残余故障），给它们加上额外的支撑。在这个案例中，供电监控和扭矩传感器的残余故障就是那几块"危险的砖"——它们各自只有几个 FIT 的失效率，但在 ASIL D 的严格标准下，这几个 FIT 就足以让整个硬件架构不达标。

11. 常见误区

11.1 误区一：PMHF 只算处理器，不算传感器和执行器

错误做法：某团队在计算制动 ECU 的 PMHF 时，只计算了 MCU 和供电电路的失效率，没有把制动驱动桥、扭矩传感器、轮速传感器的失效率纳入。结果 PMHF 看起来达标了，但实际系统危险失效概率远高于计算值。

正确做法：PMHF 的计算范围是整个"相关项"（item），从传感器到 ECU 到执行器的完整链路都必须纳入。如果制动 ECU 对外有传感器接口和执行器驱动接口，那么这些接口电路的故障模式也需要计入 PMHF。

11.2 误区二：SPFM/LFM 计算时把"安全故障"也算进分母

这是一个容易混淆的点。回顾公式：

• Σλtotal=所有硬件故障的失效率之和（包括安全故障）

是的，安全故障（SF）确实在分母中。但不在分子中——安全故障既不是单点故障也不是多点故障，它们对安全目标没有影响。把它们放在分母中是为了"归一化"，确保 SPFM 和 LFM 的值在 [0, 1] 之间。一些工程师错误地把分母理解为"只有安全相关故障"，这是不对的。

11.3 误区三：认为 ASIL D 就必须用双核锁步架构

纠正：ISO 26262 并没有规定"ASIL D 必须用双核锁步"。ISO 26262 只给出了硬件架构度量的目标值（SPFM ≥ 99%, LFM ≥ 90%, PMHF < 10−8/h），而不规定具体的架构形式。理论上，你可以用完全不同的架构（如异构冗余、时分冗余、检查-确认架构等）来达到同样的指标值。双核锁步只是最常见、最成熟的 ASIL D 架构之一，但不是唯一选择。

11.4 误区四：混淆 PMHF 和 FIT（Failure In Time）

简单来说：FIT 是元器件的"原始失效率"，PMHF 是经过安全机制"打折"后的"残余危险失效率"。一个 100 FIT 的元器件，如果安全机制 DC = 99%，那么它对 PMHF 的贡献只有 1 FIT = 10−9/h。

11.5 误区五：用元器件总失效率代替危险失效率

一个 MCU 的总失效率可能是 120 FIT，但这 120 FIT 包括了很多故障模式——其中只有一部分会导致违反安全目标。例如：

• MCU 的 GPIO 口 stuck-at：如果是用于驱动 LED 的 GPIO，这是安全故障（SF），不计入 PMHF
• MCU 的 PWM 输出 stuck-at：如果用于制动驱动，这是危险故障，需要计入 PMHF
• MCU 的调试接口失效：通常不影响运行，可能是安全故障

正确的做法是按故障模式逐一分析，而不是用元器件的总失效率"一刀切"。这就是 FMEDA 方法的价值——它把总失效率按故障模式分解，再按安全影响分类，最后按安全机制覆盖率"打折"。

12. 与 ISO 13849 的硬件指标对比

如果读者已经读过 ISO 13849 系列（特别是 S04 的 MTTFd 和 S05 的诊断覆盖率），可能会对 ISO 26262 的硬件指标感到既熟悉又陌生。本节做一个系统的横向对比。

12.1 PMHF vs PFHd

12.2 SPFM/LFM vs DCavg

ISO 13849 的诊断覆盖率（DC）和 ISO 26262 的 SPFM/LFM 在概念上相似——都是衡量安全机制对故障的"检测能力"——但在细节上有显著差异：

12.3 ASIL vs PL：硬件度量的不同思路

核心差异：ISO 26262 的 ASIL 体系通过三个独立的硬件指标（SPFM + LFM + PMHF）来约束硬件架构，而 ISO 13849 的 PL 体系通过三个输入参数（MTTFd + DC + CCf）查表确定等级。

ISO 26262 的方法更"精确"（概率建模），但更复杂、更耗时；ISO 13849 的方法更"简洁"（查表法），但精度较低。两个标准各有适用场景——ISO 26262 适合高安全性要求的汽车电子系统，ISO 13849 适合需要快速评估的机械安全控制系统。

12.4 ISO 26262 vs ISO 13849 硬件指标全面对比

如果本文对你有帮助，欢迎点赞👍 + 收藏⭐，关注我，我会持续更新同系列技术干货，专栏《ISO 26262 功能安全深度解读和避坑指南》会汇总完整系列文章和学习路线，欢迎查看，你在功能安全中遇到的问题欢迎评论区交流