做功能安全的人应该都有这种经历系列前几篇讲的全是“定性”的活儿——危害分析、安全目标推导、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条讲得很清楚必须对“安全目标因随机硬件失效被违反”这件事做评估。标准给出了几个考核项SPFMSingle Point Fault Metric单点故障度量LFMLatent Fault Metric潜伏故障度量PMHFProbabilistic Metric for random Hardware Failures随机硬件失效概率度量也可以用演绎分析FTA或归纳分析FMEA来论证安全目标被违反的概率足够低。这里要破除一个普遍误解不是每个项目都必须把SPFM、LFM、PMHF三个指标全算一遍才算合规。标准的意思是从几类评估方法里至少选一条路走通。工程上最常用的是SPFM加LFM的组合因为计算直观Excel就能搞定如果客户或管理层想要一个“整机平均失效率”的直观数字那就再补一个PMHF。我个人的习惯是三个都算。原因是计算所需的数据几乎共享多算PMHF不过多花两步时间但评审和答辩时说服力强得多。先贴一张目标值速查表后面所有讨论都围绕这张表展开指标ASIL BASIL CASIL DSPFM≥ 90%≥ 97%≥ 99%LFM≥ 80%≥ 90%≥ 97%PMHF 10⁻⁷/h 10⁻⁷/h 10⁻⁸/h注意一个细节ASIL B和ASIL C的PMHF目标都是1e-7/hASIL 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低了说明架构上裸奔和漏网的失效太多优先要去补安全机制、提升DCLFM低了说明安全机制自己的健康没人管优先要加周期性自检、缩短检测间隔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所以这五类元素全部都要进入失效率计算一个都不能省。硬件元素典型失效模式举例是否进入计算扭矩传感器双卡滞、漂移、断路进入MCU程序跑飞、存储位翻转、内核失效进入栅极驱动输出常高、时序错乱进入功率MOSFET短路击穿、开路进入切断开关卡在闭合位置、动作延迟进入直流电机绕组短路、堵转进入画这张表的时候很多团队会漏掉“切断开关”这种不起眼的元素但它恰恰是安全机制链条上的关键阀漏掉它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值也是估的硬件元素λFIT会导致SG违反的失效比例安全机制DC扭矩传感器双10045%双通道互校99%MCU10060%自检ECC看门狗90%栅极驱动3067%PWM监控输出监控90%功率MOSFET8050%输出电流监控95%切断开关20100%周期性自检90%直流电机4025%电流监控90%表格里“会导致SG违反的失效比例”指该元素所有失效模式中一旦发生且没有安全机制拦截就会违反SG1的比例。剩下的部分要么是安全失效比如传感器断路后系统降级要么是能被系统吸收的多点故障。按我们前面对SPF/RF的划分第一版假设没有裸奔的单点故障SPF全部为0因为每个元素都至少配了一个安全机制。但RF一算就露馅了MCU100 × 60% × (1-90%) 6 FIT扭矩传感器100 × 45% × (1-99%) 0.45 FIT栅极驱动30 × 67% × (1-90%) 2 FIT功率MOSFET80 × 50% × (1-95%) 2 FIT切断开关20 × 100% × (1-90%) 2 FIT直流电机40 × 25% × (1-90%) 1 FITRF合计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 FITLFM 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%。重算一遍RFMCU100 × 60% × (1-99%) 0.6 FIT扭矩传感器100 × 45% × (1-99.5%) 0.225 FIT栅极驱动30 × 67% × (1-99%) 0.2 FIT功率MOSFET80 × 50% × (1-99%) 0.4 FIT切断开关20 × 100% × (1-90%) 2 FIT直流电机40 × 25% × (1-99%) 0.1 FITRF合计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的普遍共识安全机制DC参考区间覆盖的典型失效ECC/EDC90%-99%内存单bit翻转、多bit错误CRC/checksum90%-99%Flash和通信数据损坏窗口看门狗90%-95%程序跑飞、死循环CPU自检MBIST/逻辑BIST90%-99%CPU核内随机硬件失效双通道互校99%-99.9%传感器漂移、卡滞输出电流监控90%-99%功率级短路、过流周期性自检90%-98%继电器、切断通路卡死这张表只能当参考点。真实项目里你用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数字最终都要靠实测证明它真实存在。