软件bug可以被修复——你发现它，改掉它，系统就恢复正常了。但硬件不同：芯片里的某个晶体管可能在你开车上高速的那一刻，恰好被一个中子击中、永久损坏；焊接点可能在经历三年热胀冷缩后悄悄开裂。这些硬件随机失效无法被“修复”，只能被量化、预测、防范。这就是硬件功能安全最独特的地方——它是一场与概率计算的战争。

从“软件有bug”到“硬件会老化”

前几讲我们一直在讨论软件系统的安全机制：看门狗、程序流监控、MPU……这些对付的是软件系统性失效——代码写错了、指针越界了、任务卡死了。修复方法是“改代码重新烧录”。

但硬件失效的逻辑完全不同。ISO 26262将硬件失效分为两类：

• 系统性失效：设计或制造过程中引入的缺陷——比如芯片版图画错了一条走线。这类失效在出厂前就应该被发现。
• 随机失效：器件在运行过程中因物理原因自发发生的故障——这才是ISO 26262硬件章节真正要对付的敌人。

随机失效又分两种：

• 永久性故障（Permanent Fault） ：晶体管烧毁、焊点断裂、金属迁移……坏了就是坏了。
• 瞬态故障（Transient Fault） ：宇宙射线导致位翻转（Single Event Upset，单粒子翻转）、电源纹波造成逻辑误判……它可能只出现一次，却足以让计算结果完全错误。

汽车电子委员会（AEC）的Q100可靠性标准只能告诉你“这颗芯片在高温下能扛1000小时”，但功能安全要追问的远不止此：这个电源芯片在1000小时里有多大概率突然过压？CPU核的某个寄存器被中子击中后，系统能自己发现吗？

FIT：失效率的“基本货币单位”

所有硬件随机失效的讨论，都从一个叫 FIT（Failures In Time，时基失效率） 的单位开始。

1 FIT = 每十亿（10⁹）器件·小时发生1次失效。

换算成更直观的时间：1 FIT ≈ 每十亿小时坏一次——约114,000年才出一次故障。听起来很安全？对一个车载系统来说，恰恰相反。

一辆车上有几百颗芯片，每颗芯片包含数以亿计的晶体管。假设一辆车有500颗芯片、每颗平均50 FIT，整车的总失效率就是25,000 FIT。十亿小时内出现25,000次故障，意味着平均每隔4.5年就有一处硬件失效。如果其中某个失效恰好发生在刹车控制器上且没有被安全机制发现……

FIT的来源通常有三个：

• 通过JEDEC JESD85A标准规定的加速寿命试验推算（例如高温工作寿命测试HTRB来加速失效，再通过阿伦尼乌斯公式外推）
• 基于SN 29500或IEC 62380等可靠性手册查表
• 现场返修数据统计

FIT是风险计算的最小单位。从FIT出发，ISO 26262－5定义了一套层层递进的安全度量指标体系，用来回答一个核心问题：我们的硬件有多安全？

三大硬件安全度量指标

ISO 26262-5:2018规定，ASIL C/D级别的硬件设计必须计算三个关键指标，并与目标值对标。

（1）SPFM（单点故障度量）

单点故障（Single Point Fault） ：未受任何安全机制保护的、直接导致安全目标被违反的故障。好比一座桥梁只有一个承重柱，那根柱子一旦断裂，整座桥就垮了。

SPFM = 安全机制覆盖的失效占比——被检测到或控制住的故障占所有安全相关失效的比例。计算公式为：

SPFM = 1 — λ_SPF / λ_total

其中λ_SPF是没有安全机制覆盖的单点故障失效率，λ_total是总失效率。

ASIL D要求SPFM ≥ 99%（ASIL C是≥97%，ASIL B是≥90%）。这意味着每100 FIT的安全相关失效中，最多允许有1 FIT被漏掉——这个故障可能直接导致安全事故。

（2）LFM（潜在故障度量）

潜在故障（Latent Fault） ：已经被安全机制发现、但未通知驾驶员也未采取降级动作的故障。它暂时没有危险，但如果第二个故障出现，两个合起来就可能酿成大祸。

LFM衡量安全机制在暴露潜在故障方面的有效性。ASIL D要求LFM ≥ 90%（ASIL C≥80%，ASIL B≥60%）。这要求大部分故障在失效累积前必须被“揪出来”。

小贴士：单点故障关注“这个故障单独会不会出事”；潜在故障关注“这个故障藏着会不会和另一个故障联手出事”。

（3）PMHF（随机硬件失效概率度量）

PMHF是三个指标中最硬核的一个，它回答：整个系统在整个生命周期中，因随机硬件失效违反安全目标的概率有多大？

单位是 每小时的失效率。ASIL D要求 PMHF < 10⁻⁸ h⁻¹，即每行驶一亿小时（约11,400年）发生一次安全相关失效。ASIL B和C要求 < 10⁻⁷ h⁻¹。

PMHF不是靠猜的，而是通过定量故障树分析（FTA）或FMEDA等系统化工具逐层计算得出的。

这些指标在实战中意味着什么？

行业内常用PMHF折算为目标失效的百万台车年故障率来理解其严格程度：一套ASIL D的制动系统以10⁻⁸的PMHF水平投入百万台车的规模化运营，理论年故障率低于0.001%，多数工程师习惯用“一年卖100万辆车，大约不到1辆会因硬件随机失效出刹车事故”来理解这个目标的苛刻程度。

FMEDA：硬件安全分析的核心武器

好的，现在指标摆在这里了。但一台ECU上有几千个元器件，每个元器件有若干种失效模式（有的短路，有的开路，有的参数漂移）——如何计算整体的SPFM和PMHF？

答案是 FMEDA（Failure Modes, Effects and Diagnostic Analysis，失效模式影响与诊断分析） 。它是FMEA的功能安全增强版，核心区别在于加入了定量失效概率和诊断覆盖率。

一个典型的FMEDA流程包括六个步骤：

① 分解硬件模块：列出所有元器件（MCU、电源芯片、MOSFET、电阻电容等）。

② 确定各模块的基础失效率λ_BFR：参考SN 29500、IEC 62380或JEDEC JESD85A试验数据计算FIT值。

③ 定义失效模式与分布：例如一个电阻，可能开路（占70%）、短路（占15%）、参数漂移（占15%）。失效模式分布像一张“故障行为画像”，决定了后续安全机制需要覆盖哪些方向。

④ 判定故障类型：是单点故障？残余故障？潜伏故障？还是安全故障（不违反安全目标，只管放心睡觉）？

⑤ 评估安全机制的诊断覆盖率：看门狗能覆盖MCU故障的多少百分占比？双路冗余信号比较能覆盖多少？诊断覆盖率不是一个随意填的数，必须引用ISO 26262－5附录D推荐的典型值或通过故障注入仿真来论证。

⑥ 计算SPFM、LFM和PMHF，对标修正：不达标就重新设计——加冗余、提高诊断覆盖率、换更低FIT的器件。

一个真实的FMEDA报告（比如某Tier 1供应商的制动控制器）往往长达几十页，包含数百行Excel表格。每一行代表一个元器件的某一种失效模式，每一列记录它的失效率、故障类型、安全关联性、诊断机制以及最终的残余风险。

硬件安全机制面面观

如果说FMEDA是“诊断系统有病没病”的工具，那硬件安全机制就是“治病”的手段。下面盘点几种核心的硬件安全机制。

锁步核（Lockstep Core）—— CPU的“双胞胎兄弟”

在ASIL D系统中，MCU的核心安全问题是如何确认CPU本身没有算错。锁步核的解法简单粗暴：给主核配一个一模一样的“影子核”，两个核接收相同的输入、执行相同的指令，每个时钟周期比较一次输出结果。一旦结果不一致，立即触发故障。

锁步核不像普通冗余那样两个核独立跑任务——那样跑完了还得人工比较结果，来不及。锁步核是每个周期都在同步对比，像一对双胞胎同时完成同一个动作，步调必须完全一致，错一拍立刻报警。

对于一个ASIL D的安全关键任务，锁步核几乎是标配。英飞凌AURIX TC3xx、瑞萨RH850、NXP S32K3等主流安全MCU都内置了锁步核功能。

内建自测试（BIST）—— 芯片自己检查自己

锁步核盯着CPU运行时的问题，但芯片的其他部分呢？BIST（Built-In Self Test）负责在启动时或关机时对整个芯片的“健康体检”。

BIST分为两种：

LBIST（Logic BIST，逻辑内建自测） ：

• CPU内核
• 所有外设
• 硬件安全模块(HSM)
• 包括MPU、总线监控、SMU等在内的安全机制本身测试数字逻辑电路。
  英飞凌TC4xx的LBIST能在开机时5~6毫秒内达到90%的固定故障覆盖率，涵盖锁步比较器、ECC逻辑、安全管理单元等关键监控模块。由于LBIST执行期间数字逻辑被切换至扫描模式，该过程会破坏SRAM中的数据，因此必须在应用数据加载前执行或在关机进入安全状态后趁数据不敏感时执行。开机时执行LBIST可以放心覆盖全部核心逻辑，代价是上电时间略有延长；关机时执行LBIST则可以利用系统已静止的安全窗口释放出更长的50毫秒测试时间进行更全面的逐域检查。

---

• MBIST（Memory BIST，内存内建自测） ：专门测试SRAM/Flash存储器。内存的故障模式比逻辑电路更复杂——地址线短路、存储单元卡死、相邻位耦合干扰……MBIST通过写入/读出特定图形模式来检测内存缺陷。

---

以AURIX TC3xx为例，常见实践是：首次上电时用硬件BMI的方式触发LBIST，如果失败再用软件重试。三次连续失败后，芯片被判定为“不可靠”，系统直接进入安全状态。

硬件安全岛（Safety Island）—— 独立的“守护神”

随着系统集成度提升，越来越多的功能被塞进一颗SoC里。但随之而来的问题：谁来监控SoC自己？

新一代芯片架构采用了 “硬件安全岛” 设计——在芯片内部划出一块专门区域，配备独立时钟、独立电源、独立内存，双核锁步CPU加上内置BIST自检，整体达到ASIL D等级。

华山A2000的“3L”安全架构就是一个典型：高性能计算域（L1）跑感知和规划，达到ASIL B；功能安全岛（L2）从独立的电源域对L1进行实时故障监控；第三层硬隔离域（L3）引入温度监控与外部独立看门狗，逻辑独立性比肩传统外置MCU。

这背后有一条硬道理：安全机制本身的独立性，几乎和覆盖系数一样重要——如果监控者和被监控者用同一个电源、同一个时钟，一个电源尖峰就可能把两者同时击倒，这个共因就要按照ISO 26262相关章节里的共因失效（CCF）防范规则留出额外余量。

一个完整的硬件安全案例：ASIL D制动控制器

上面讲的都是零件层面的分散机制，现在把它们装进一整台ECU里看完整图景。假设我们设计一个线控制动控制器，要求达到ASIL D：

第1步：明确安全目标：在制动控制器发生任何单一随机硬件故障时，车辆仍能稳定减速至停车。

第2步：选择硬件架构：主MCU（带双核锁步） + 安全监控MCU（独立的简单内核），两路独立电源，功率管双并联冗余，制动压力传感器双路信号。

第3步：做FMEDA：列出主MCU、电源芯片、CAN收发器、功率管等每个元器件的每类失效模式，注入安全机制分析其诊断覆盖率，计算SPFM、LFM、PMHF。如果PMHF超标就修改设计。

第4步：部署安全机制：

• 主MCU：锁步核对CPU计算实时比较，LBIST上电自检，MBIST定期扫内存，ECC保护SRAM/Flash。
• 电源：过压/欠压监视器，独立看门狗监控MCU心跳。
• 通信：E2E保护确保LIN/CAN信号不被篡改（详见第6讲）。
• 监控MCU：独立监控主MCU的程序流和关键寄存器。
• 外部信号：制动踏板两路独立传感器，控制器内部交叉对比。

第5步：对标验收：FMEDA计算出的SPFM ≥ 99%，LFM ≥ 90%，PMHF < 10⁻⁸，提交给TÜV审核。审核员签字，硬件设计完成。

这套架构下，任何一个单一故障——主核锁步比较出错、LBIST发现逻辑缺陷、ECC检测到内存位翻转——都会被至少一种安全机制捕获，系统随即切换或安全停车。

结语：硬件安全是设计出来的，不是测出来的

从FIT到FMEDA，从单点故障到锁步核，硬件功能安全的核心哲学其实只有一句话：我们无法让硬件永不失效，但我们可以确保任何失效都不会导致灾难。

这种“被动接受硬件会坏”的容忍度，恰恰体现了工程中最高级的主动应对策略。它不是用蛮力打造永不磨损的零件，而是编织一张精密的安全网——每个元器件坏掉，网里总有一根线把它接住。

下一篇预告：硬件层把失效概率压下去了，但软件的任务是让整个系统实时、有序地运转。第5篇《软件安全篇 —— 让代码自己“质疑”自己》，我们将进入软件领域——看内存保护、程序流监控、安全库如何守护那几百万行逻辑。

---

思考题：假设你在一款ASIL D制动控制器的FMEDA报告中看到“某电阻的失效模式为开路，诊断覆盖率为0%（无任何安全机制可检测该电阻开路）”，这会算作哪一种故障（单点/残余/潜伏还是安全故障）？这个0%覆盖率会对SPFM和LFM分别产生什么影响？