企业官网建设流程全解析

做功能安全的人应该都有这种经历：系列前几篇讲的全是“定性”的活儿——危害分析、安全目标推导、ASIL分解、系统架构的冗余设计、软硬件接口划分。这些内容听上去很有道理，做起来也像模像样，可一旦架构评审进入到深水区，专家问一句“SPFM算到多少，LFM和PMHF达标没有”，很多团队就卡住了。因为架构画得再漂亮，安全机制列得再长，不落到量化指标上，评审就是过不去的。这篇作为系列的第六篇，专门把ISO 26262里硬件架构度量的核心账算明白：SPFM、LFM、PMHF这三个指标的来龙去脉、计算方法，以及它们如何反向逼着架构师改设计。整个推演过程我拿电动助力转向（EPS）当例子，全程带数据，保证你跟着算完就能直接用。

1. 量化度量才是架构设计的“照妖镜”

1.1 定性设计的天花板：图画得再漂亮也躲不开概率

前五篇文章我们做的绝大多数工作是定性的。危害分析时，我们判断一个失效带来什么后果，套严重度S、暴露度E、可控性C，然后查表拿到ASIL等级；ASIL分解时，我们论证两条通道够不够独立、有没有共因失效；系统架构设计时，我们讨论用双通道还是三通道、用哪种安全机制。这些分析方法门槛不高，只要思路清楚、论据扎实，不同团队得出的结论差不太多。

但这种定性分析有一个天生缺陷：图面上看不出“够不够”。你说做了双通道冗余，那我问你，冗余通道能兜住多少比例的失效？你说加了看门狗，那我问你，看门狗自己坏了怎么办？你说安全机制诊断覆盖率有99%，那剩下1%的残余失效进入系统，每年导致安全目标被违反的概率是多大？画图回答不了这些问题，只能靠计算。

说得直白一点，ISO 26262把架构设计往定量方向推，是被真实的失效案例和召回事件逼出来的。靠“感觉”搭出来的安全架构，评审会上通常挑不出硬伤，但真实场景里随机硬件失效是概率问题，不会因为架构图好看就给谁面子。量化度量本质上就是给架构照一次X光，看看哪个零件在漏电、哪个安全机制是摆设。

1.2 ISO 26262-5的考核项：三条路线选一条

ISO 26262第5部分（硬件层面）第8条讲得很清楚：必须对“安全目标因随机硬件失效被违反”这件事做评估。标准给出了几个考核项：

• SPFM（Single Point Fault Metric），单点故障度量；
• LFM（Latent Fault Metric），潜伏故障度量；
• PMHF（Probabilistic Metric for random Hardware Failures），随机硬件失效概率度量；
• 也可以用演绎分析（FTA）或归纳分析（FMEA）来论证安全目标被违反的概率足够低。

这里要破除一个普遍误解：不是每个项目都必须把SPFM、LFM、PMHF三个指标全算一遍才算合规。标准的意思是从几类评估方法里至少选一条路走通。工程上最常用的是SPFM加LFM的组合，因为计算直观，Excel就能搞定；如果客户或管理层想要一个“整机平均失效率”的直观数字，那就再补一个PMHF。

我个人的习惯是三个都算。原因是计算所需的数据几乎共享，多算PMHF不过多花两步时间，但评审和答辩时说服力强得多。先贴一张目标值速查表，后面所有讨论都围绕这张表展开：

注意一个细节，ASIL B和ASIL C的PMHF目标都是1e-7/h，ASIL D才严到1e-8/h。也就是说ASIL D对应的PMHF大约只有10个FIT的预算，很多团队第一次算出个9 FIT还觉得“离10很远”，实际上已经贴着边了。这里的“FIT”是失效率单位，1 FIT等于10⁻⁹/h，也就是十亿小时一次失效。

2. 三个指标到底在算什么

2.1 SPFM：把“裸奔”和“漏网”的失效全揪出来

SPFM可以理解为“单点故障加残余故障的覆盖率”，核心思想是：把安全目标相关的硬件失效全部摆出来，看有多少没有被安全机制覆盖、属于“裸奔”的单点故障，又有多少是被安全机制想兜却没兜完全的“漏网”残余故障。计算公式是：

SPFM = 1 - (Σλ_SPF + Σλ_RF) / Σλ

先解释一下字母含义：λ_SPF是没有安全机制覆盖、直接导致安全目标被违反的单点故障失效率；λ_RF是有安全机制覆盖、但由于覆盖率不是100%而残留下来、仍然能导致安全目标被违反的部分；分母Σλ是这条安全路径上所有相关硬件元素的失效率总和。

用一个生活场景帮助理解。你晚上出门怕家里进小偷，装了一把锁，这把锁就是安全机制。装锁之前，小偷进来的风险全部算“单点故障”；装锁之后，锁芯质量一般、有小概率被技术开锁打开，这部分就是“残余故障”。SPFM衡量的就是：加了这套锁之后，小偷还能进来的比例占整个进门风险的比例。锁越可靠，残余越小，SPFM就越接近100%。

这里的失效分类是个关键动作，ISO 26262把硬件失效划分为单点故障（SPF）、残余故障（RF）、多点故障（MPF）三类，其中多点故障又按被安全机制感知的时点分成“感知到的”和“潜伏的”。分类对不对，直接决定后面所有计算有没有意义，这也是FMEDA表格为什么那么重要的原因。

2.2 LFM：藏在暗处的潜伏故障最阴险

潜伏故障和单点故障最大的差别在于：它发生时不会立刻导致安全目标被违反，但会让安全机制的兜底能力悄悄失效，等第二个故障再发生时，整个防线就直接被击穿。

最经典的例子是EPS里的切断继电器。这个继电器平时不动作，只在系统检测到异常时断开主电源回路。它默默坏掉的时候，车辆开起来一切正常，因为切断路径还没被触发过；等真正需要它切断助力的时候，它不动作，非预期助力就控不住了。这种“平时不暴露、关键时刻掉链子”的故障，就是潜伏故障的典型形态。

LFM的计算公式是：

LFM = 1 - Σλ_MPF_L / (Σλ - Σλ_SPF - Σλ_RF)

分子的MPF_L指的是潜伏的多点故障失效率；分母等于总失效率减去单点故障和残余故障部分，也就是“能被兜住的那些失效”的总盘子。潜伏故障不是完全不可检测，而是需要周期性检测——比如每个驾驶循环对切断继电器做一次自检。检测覆盖率越高、检测周期越短，潜伏部分就越少。这就是为什么架构设计里“可诊断性”那么重要：你得给自检和维修留出接口，否则潜伏故障只能烂在系统里。

一轮计算下来你会发现，SPFM和LFM永远要配对看。SPFM高只能说明“裸奔和漏网的少了”，不能说明“潜伏的也少了”。两个指标一个看表、一个看里，缺一不可。

2.3 PMHF：全年平均下来到底有没有超预算

PMHF关心的是“长久运行下来，平均每个小时安全目标被随机硬件失效违反的概率”。它的计算逻辑是把所有可能导致安全目标违反的失效路径全部折算成失效率加总。工程上常用的简化算法是：

PMHF = Σλ_SPF + Σλ_RF + Σ(λ_MPF_L × 暴露时间修正)

潜伏故障部分要做修正，是因为它不像单点故障那样“一发生就出事”，而是在检测周期窗口内赶上第二次故障才会酿成后果。检测周期越长，这个窗口越大，对PMHF的贡献就越高。“功能安全诊断测试间隔该设多长”这件事，不是拍脑袋定的，它的理论依据就在这个公式里。

2.4 三个指标怎么配合用才不吃亏

衡量架构健康度的时候，三个指标的“体检指向”完全不同。SPFM低了，说明架构上裸奔和漏网的失效太多，优先要去补安全机制、提升DC；LFM低了，说明安全机制自己的健康没人管，优先要加周期性自检、缩短检测间隔；PMHF超了，说明整体风险预算超支，可能得动冗余结构，而不只是调参数。

所以科学的做法是：架构设计初稿出来后，先把FMEDA做掉，算出三者，再根据“哪项指标最难看”决定架构迭代方向。指标打架是好事，说明问题聚焦；三个指标都难看才是真头疼，那意味着架构的底子就有问题，不是修修补补能解决的。

3. 从安全目标到硬件元素：一次干净的拆解

3.1 拿EPS当靶子，把链路画出来

讲公式不落到工程上是纸上谈兵。本篇一致用电动助力转向（EPS）做贯穿案例，它的安全目标清晰、硬件链路典型、安全机制常见，非常适合演示完整拆解流程。

先定安全目标。SG1：“避免非预期转向助力导致驾驶员失去对车辆的控制”，等级ASIL D。为什么是D？转向失控直接对应车辆不可控，严重度S3、暴露度E4、可控性C3，查表下来就是ASIL D。对EPS这种安全关键系统，定到D是行业常态。

围绕SG1，把硬件链路上的元素全部列出来。EPS的核心链路是：扭矩传感器（双通道）→ MCU（执行电机控制）→ 栅极驱动（Gate Driver）→ 功率MOSFET → 直流电机。非预期助力的能量源头在功率级，逻辑源头在传感器和MCU，所以这五类元素全部都要进入失效率计算，一个都不能省。

画这张表的时候，很多团队会漏掉“切断开关”这种不起眼的元素，但它恰恰是安全机制链条上的关键阀，漏掉它，LFM算出来就必然虚高。

3.2 失效率数据不是算命，是有出处的

每个硬件元素的λ值必须写明出处。工程上常用的失效率来源有这些：

• SN 29500：西门子失效率标准，汽车电子领域最常用；
• IEC 62380：原CNET标准，环境因子模型对车载场景也适用；
• 供应商提供的器件级FMEDA或安全手册，这是最理想的数据源，因为包含失效模式分布；
• 整车厂自建的可靠性数据库。

行业里有个说法很实在：FIT数据本身就有统计噪声，同一颗电阻在不同手册里差两三倍很正常。评审专家真正在乎的不是你用了“绝对正确”的数据，而是口径是否一致、出处是否可查。你只要全部锁定SN 29500，环境温度统一按85℃结温修正，一路算到底，这份报告就站得住；最忌讳今天用SN 29500、明天换IEC 62380，算出来的指标再好看也没人信。

3.3 失效模式和安全机制的“配对”关系

拿到λ之后，还得把失效率按失效模式拆分。比如扭矩传感器最常见的失效模式是“卡滞在某个读数”、“输出漂移”、“完全失效”，它们各自占的比例不一样。只有拆分到失效模式级别，才能给每个模式配置对应的安全机制，也才能在FMEDA里准确填写安全机制覆盖了哪些失效。

这里必须强调：安全机制和失效模式必须一一对应。你写“MCU有自检”，就必须回答“自检覆盖哪种失效模式？是运行用例型自检还是MBIST？覆盖率多少”；你写“双传感器互相校验”，就必须回答“两个传感器同时漂移怎么办？校验算法本身按什么ASIL等级开发”。这些问题评审专家几乎每次都会追问，回答不上来，整包架构文档的可信度都要打折扣。

4. 完整推演：EPS架构从96%到99.5%的迭代

4.1 第一版架构：表面稳妥，算出来翻车

假设团队第一版架构长这样，所有安全机制都是从“感觉上应该有”出发配的，DC值也是估的：

表格里“会导致SG违反的失效比例”，指该元素所有失效模式中，一旦发生且没有安全机制拦截就会违反SG1的比例。剩下的部分要么是安全失效（比如传感器断路后系统降级），要么是能被系统吸收的多点故障。

按我们前面对SPF/RF的划分，第一版假设没有裸奔的单点故障，SPF全部为0，因为每个元素都至少配了一个安全机制。但RF一算就露馅了：

• MCU：100 × 60% × (1-90%) = 6 FIT
• 扭矩传感器：100 × 45% × (1-99%) = 0.45 FIT
• 栅极驱动：30 × 67% × (1-90%) = 2 FIT
• 功率MOSFET：80 × 50% × (1-95%) = 2 FIT
• 切断开关：20 × 100% × (1-90%) = 2 FIT
• 直流电机：40 × 25% × (1-90%) = 1 FIT

RF合计13.45 FIT，分母Σλ = 100 + 100 + 30 + 80 + 20 + 40 = 370 FIT。于是：

SPFM = 1 - 13.45 / 370 = 96.4%

这个结果非常打击人。SPFM要求ASIL B≥90%、ASIL C≥97%、ASIL D≥99%，96.4%意味着连ASIL C都摸不到，只能满足ASIL B，离ASIL D的99%差了十万八千里。再看LFM。潜伏故障主要出在切断开关，周期性自检的DC为90%，取MPF_L = 2 FIT：

LFM = 1 - 2 / (370 - 13.45) = 99.4%

LFM倒是轻松过了ASIL D的97%。这种“SPFM难看、LFM好看”的组合在真实项目里太常见了，言外之意就是架构的薄弱点非常集中，全部聚集在那些DC只有90%、95%的功率级和计算环节上。

4.2 被指标打脸之后的三条改法

96.4%的SPFM说明什么？说明表面上堆了一大堆安全机制，实际上漏掉的失效还是太多。这种局面不能靠嘴硬，也不能靠把表格里的DC数字改大糊弄过去，只能靠架构手段把RF真正压下来。常见打法有三种。

第一种，提高单一安全机制的DC。比如把MCU的DC从90%提升到99%，代价是引入锁步核（lockstep）或者更完整的MBIST自检库，硬件成本和开发周期都会上升。

第二种，增加新的、相互独立的安全机制。比如在MOSFET电流监控之外，再加一路基于车辆横摆角速度的扭矩合理性监测，从系统层面拦截“助力输出与驾驶员意图不符”。这样一来，即使功率级局部失效，系统级机制还能兜底，综合DC明显提升。

第三种，降低对安全机制本身的依赖。典型案例就是把切断开关从“默认闭合、触发才断开”改成“默认断开、需要使能才闭合”的结构，让它的失效模式分布从“100%会违反安全目标”降下来。

这三种打法可以组合使用，但每加一个机制都必须回到FMEDA里重新计算覆盖率，绝不能拍脑袋说“加了东西这回肯定够了”。指标是检验架构改动的唯一标准。

4.3 第二版架构：指标终于站上ASIL D

经过一轮实打实的迭代，假设最终架构变成这样：

• MCU引入锁步核加自检库，DC提到99%；
• 栅极驱动增加独立的PWM验证通道，DC提到99%；
• MOSFET在电流监控之外增加系统级扭矩合理性监控，综合DC提到99%；
• 电机增加转速和电流交叉校验，DC提到99%；
• 扭矩传感器保持双通道互校加自检，DC提到99.5%；
• 切断开关保持周期性自检，DC仍为90%。

重算一遍RF：

• MCU：100 × 60% × (1-99%) = 0.6 FIT
• 扭矩传感器：100 × 45% × (1-99.5%) = 0.225 FIT
• 栅极驱动：30 × 67% × (1-99%) = 0.2 FIT
• 功率MOSFET：80 × 50% × (1-99%) = 0.4 FIT
• 切断开关：20 × 100% × (1-90%) = 2 FIT
• 直流电机：40 × 25% × (1-99%) = 0.1 FIT

RF合计3.525 FIT，于是SPFM = 1 - 3.525 / 370 = 99.05%，勉强踩线过了ASIL D。

这时候如果是个较真的架构师，绝不能就坡下驴。99.05%这个余量太小了，FIT数据源波动、失效模式分布假设微调、供应商数据更新，任何一个变化都可能把指标打到99%以下。工程上的正确做法是继续压残留RF，比如把切断开关的DC也从90%往99%提，同时引入额外的冗余结构，把指标稳稳推到99.3%以上再收工。量化达标的最终原则是“余量优先”，不是“擦线万岁”。

4.4 顺手把PMHF也算出来看看余量

同一套数据按简化算法顺手算PMHF。ΣRF是3.525 FIT，切断开关的潜伏部分2 FIT按检测周期折半估算——假设每个驾驶循环都能自检一遍，暴露时间大约为运行时间的一半——折算到PMHF里约1 FIT。于是：

PMHF ≈ 3.525 + 1 = 4.525 FIT，即4.525 × 10⁻⁹/h

低于ASIL D的10 × 10⁻⁹/h，有将近一倍的余量，这条量化路线也成立。这个例子的核心结论是：架构设计不是画完图等着评审，而是算完指标改架构、改完架构再算指标的循环过程。SPFM、LFM、PMHF本质上是在替评审专家预先做体检，把问题暴露在设计阶段而不是审核阶段。

5. DC值和软件组件鉴定报告：安全机制的证据链

5.1 DC值必须有三方证据

前面推演里最怕读者产生一个误解，以为DC值是设计人员自己拍脑袋定的。实际上DC值必须有出处，至少来自以下三个方面之一：

• 行业标准参考值，最典型的是IEC 61508-2 Annex A里的诊断覆盖技术列表，ISO 26262的工具链和咨询机构普遍认可这套参考值；
• 供应商提供的安全手册或FMEDA，比如MCU厂商会明确标注其ECC、锁步核、自检库分别能达到多少DC；
• 基于故障注入测试得到的实测覆盖率，这是最扎实的证据，但测试成本高，通常只在最关键的几个安全机制上做。

现实项目里最常见的违规操作是：没有供应商数据，也没有实测结果，直接照抄别的项目的DC值，还不做任何说明。这种FMEDA评审师一眼就能看出来，到时候整份指标报告都会被质疑。

5.2 常用安全机制的DC参考区间

给没有供应商资料的读者一个出发点，我把业内常用的DC参考区间整理如下，数据基础主要是IEC 61508和各类公开FMEDA的普遍共识：

这张表只能当参考点。真实项目里你用90%还是99%，必须拿证据说话。尤其在ASIL D场景下，任何“我这里写99%是因为别人都这么写”的说辞，评审都不会接受。

5.3 软件组件鉴定报告补上软件侧的空缺

硬件架构度量做久了，你会发现一个容易被忽略的事实：很多安全机制其实需要软件配合实现。比如上面例子里的扭矩合理性检查算法、诊断服务的调度逻辑、看门狗驱动，全部要跑在MCU软件里。如果这些软件用的是第三方组件（比如AUTOSAR基础软件、操作系统、通信协议栈），架构师就必须拿到ISO 26262-8里说的“软件组件鉴定报告”（Software Component Qualification Report）。

这份报告的作用是证明该软件组件是在满足既定ASIL能力要求的前提下开发的，其检测机制、内存保护、时间确定性等指标都经过验证。没有这份报告，你在架构文档里写“依赖OS的看门狗驱动达到ASIL D能力”就是一句空话，评审专家会直接把这条安全机制从DC计算里划掉，指标立刻掉档。所以做硬件量化度量的同时，一定要把软件组件的鉴定资产列进追踪范围，这是证据链上最容易断的一环。

6. 落地时绕不开的几个坑

6.1 FIT数据源的“波动焦虑”

前面说过，同一器件在不同标准下的FIT值可能差两三倍。这不代表架构度量没有意义，而是要求你在报告里锁死口径。我的做法是在计算说明第一页就写明：“本报告失效率统一取自SN 29500，环境温度按85℃结温修正，失效模式分布依据供应商FMEDA及IEC 62380默认表。”然后在这个口径下一路算到底。评审专家认可的是“口径一致、链条完整”，而不是某一家数据的绝对正确。数据源波动这件事，靠的不是消灭波动，而是用透明性让波动变得可控可审。

6.2 SPFM分母之争：哪些元素进计算

SPFM分母到底取哪些元素，是每个项目必吵一轮的问题。我的原则非常明确：凡是处于安全功能实现链路上的硬件，必须进分母；不在链路上、也不影响安全目标实现的功能模块，不进分母。

这里有一个经典灰色地带，就是电源芯片。电源芯片同时给MCU和传感器供电，一旦失效可能导致MCU掉电、传感器失效，属于安全链路的一部分，必须算进去。反过来，音频DSP、充电接口这类与转向功能毫无关系的模块，就放出去。争论不休的时候，最有效的做法是在报告里画一张清晰的架构框图，明确标出“本次计算包含与不包含的元素”，再配一句说明。图一放出来，争议就少了一半。

6.3 工具选型：Excel流派与专业工具流派

最后聊聊工具。国内目前最主流的还是Excel流派：一张FMEDA表把元素、失效模式、λ、DC、SPF/RF/MPF分类全部列出来，公式链一拉，三个指标全部出来。Excel的好处是透明、成本低、审计方便，坏处是人一多、版本一乱就容易出错，而且架构改一版，表格得跟着手工同步一遍。

团队上了规模之后，可以考虑Medini Analyze、PHA RS这类专业功能安全工具。它们最大的优势是FMEDA数据能和架构模型、安全分析强关联，架构里改一个安全机制，全局指标自动联动更新，不容易出现文档对不上设计的问题。

但说句公道话：工具解决的是管理负担，绝不解决工程判断。用Excel算出99.05%就敢宣称ASIL D达标的团队，换了专业工具一样会翻车。指标只是冰山一角，背后的架构思想和数据质量才是真正的底气。

这套算账的功夫，我自己也是被评审专家硬逼出来的。刚开始做功能安全时，总觉得画好双通道架构、列满安全机制就算完工了，直到有次评审被追问“SPFM多少”，当场答不上来，回去熬了两周把整份FMEDA补干净，才算真正看懂了自己的架构。后来我带团队做架构评审，开场第一个问题永远是“把你们的安全机制清单和DC值拿出来”，拿不出来的，后面架构图基本不用看了。这篇是系列第六篇，主要把硬件架构度量的账算透了。下一篇我打算聊聊安全机制的验证和故障注入测试——因为再漂亮的DC数字，最终都要靠实测证明它真实存在。