在聊ISO 26262硬件架构指标怎么分解、薄弱环节又怎么去识别时，光盯着SPFM、LFM、PMHF最后那几个数字是不够的。硬件架构指标本身并不是为了一张漂漂亮亮的计算表，而是要借它去弄明白，随机的硬件失效会不会真的扰动安全目标，看看哪些失效已经被安全机制兜住了，哪些地方其实还残留着风险，又有哪些故障是可以悄悄潜伏很长时间的。在真实项目里，得把安全目标、硬件单元、失效模式、诊断覆盖率，还有验证的证据串到一块儿去看，这样做出来的分析结果才会有实际的意义。

　　一、ISO 26262硬件架构指标怎么分解

　　着手分解硬件架构指标的时候，不能一上来就对着器件清单搞平均摊派。更合理的想法是先看系统定下了哪些安全目标，再理清楚这些安全目标会被哪些硬件链路牵动，就好比系统要防止非预期的输出，那就得多留意传感器采集、MCU处理、电源监控、驱动控制和执行器输出这一长串的环节。

　　1、先确定硬件分析边界

　　这一部分得先把安全目标和硬件设计之间的关系理通顺。并不是每颗元器件都得用同样深的程度去分析，关键是要看它万一失效了，会不会导致安全目标被违背。那些跟安全目标关系很淡的部分，不用使劲去铺开；反而是关系直接的部分，哪怕只不过是一个小小的采样电阻、一个监控引脚，或者是一个驱动输出级，也不该被随随便便跳过去。

　　2、把失效模式放进分析表

　　在【FMEDA表】中，需要把硬件单元、失效模式、失效率、安全机制和诊断覆盖率对应起来。

　　这里不能只写“芯片失效”“电路异常”这种粗粗的描述，而要尽量拆到开路、短路、漂移、卡滞、误导通、通信异常、时钟异常等具体模式。失效模式越清楚，后面判断单点故障、残余故障和多点故障时才越有依据。

　　3、按指标含义拆贡献项

　　SPFM主要用来瞧单点故障和残余故障到底被管住了没有，LFM更侧重去查潜伏的多点故障是不是被揪了出来，PMHF则关注随机硬件失效最终捅到安全目标那里的概率。分解指标的时候不能光看一个总值，还得去看看究竟是哪一个硬件单元的贡献特别高，是哪一种失效模式把结果往下拽，还有哪项安全机制的覆盖还差着一口气。

　　4、不要平均分配指标压力

　　在实际项目当中，指标的压力应该优先搁在高风险的链路上。失效率高、诊断覆盖率低、故障后果又重的位置，要排在前头去分析和整改；而那些贡献特别低、跟安全目标关系不怎么紧密的位置，就不必为了把形式做得很复杂而费太大功夫了。这样分解出来的结果，才更贴近真实的工程问题。

　　二、ISO 26262硬件架构薄弱环节怎么识别

　　硬件架构里的薄弱环节，不是单凭感觉就能断出来的，也不能说哪个器件结构复杂哪个就准是薄弱点。真正要去核对的，是某个位置失效以后会不会连累到安全目标，现存的安全机制能不能把它稳稳地揪出来，揪出来之后系统又有没有可能及时地切进安全状态。

　　1、从单点故障和残余故障里找风险

　　假如SPFM的结果不够理想，那就要重点去瞄单点故障和残余故障贡献偏高的那些位置。比如传感器的输入没有布置交叉校验，电源出了异常却缺着独立的监控，驱动短路以后又找不到一条能可靠关断的通路，这些情形都很容易演变成硬件架构的薄弱点。也有些设计虽然名义上挂了诊断，但覆盖率给得偏低，这就会继续留下残余的风险，一样要单独抽出来分析。

　　2、重点检查潜伏多点故障

　　分析【潜伏多点故障】时，要重点看监控链路、备用通道、看门狗、电源监控电路和比较器这类安全机制本身。

　　这些位置平时不一定去干扰主功能的运行，所以问题很容易就藏起来了。比方说看门狗失效了却没有安排自检，备用通道因为长期不用也没有做过周期测试，监控电路的配置已经出了错但系统还照样在跑，这些故障单拿出来看好像都不怎么起眼，可只要和主链路上的故障叠到一块儿，风险就会猛地往上蹿一截。

　　3、结合故障树看共用资源

　　假如电源、时钟、复位或者通信链路，在关键故障路径里头反复地露面，那么哪怕它在单项计算里的贡献并不是最高的，也还是应当被当成薄弱环节来重点排查。因为这类共用的资源一旦闹出异常，很可能会在同一时间拖累好几个安全机制。

　　4、检查诊断时间是否满足要求

　　有些架构并不是缺诊断，而是诊断的动作本身太慢了。比如过流检测的周期拉得很长，通信异常的确认时间耗得太久，执行器不对劲以后关断的动作又不够利索，这些都会让系统错过安全响应的那个窗口。所以在识别薄弱环节的时候，不能只盯着有没有检测这一项，还要去看检测、确认、响应，以及进入安全状态这整段时间到底能不能闭合得住。

　　三、硬件架构指标分析怎么形成闭环

　　指标分解和薄弱环节的识别终究还只是前半段，后面得要再把整改的闭环给搭起来。这也就是说，问题被揪出来以后，得讲明白它是打哪儿冒出来的，牵动了哪一个指标，准备用哪些法子去改，改过以后指标是不是跟着起了变化，还有最后的验证结果能不能有力地撑住结论。

　　1、把薄弱项整理成整改清单

　　整改的清单里面，要把问题的来源、受影响的指标、涉及到的硬件单元、打算采取的整改措施和验证的方式，一样一样都写清楚。SPFM要是不够，可以考虑增加独立的监控、冗余的采样、输出的回读，或者故障关断的法子；LFM要是撑不住，就补上上电自检、周期自检，还有备用通道的测试；PMHF偏高的时候，就得按照贡献值排一排先后，优先去动那些失效率高、覆盖率低，或者暴露时间偏长的路径。

　　2、把整改结果回填到分析表

　　完成设计调整后，需要在【FMEDA表】中更新安全机制、诊断覆盖率、故障分类和失效率贡献。

　　这一步是万万跳不过去的，因为整改这件事可不是在问题清单上记一笔就算翻篇。原来的那些单点故障，到底有没有被扭成可检测的故障；原来藏着的潜伏故障，有没有被周期测试给兜住；还有PMHF的贡献值有没有往下降，这些变化全都要能在更新之后的分析结果里看得清清楚楚。

　　3、用验证结果支撑结论

　　硬件架构的这些指标，到头来还是要靠测试证据从后面撑住腰。故障注入的测试、诊断覆盖率的验证、安全状态切换的测试，都可以拿来解释安全机制是不是真起了作用。整理证据的时候，别只留一张计算的截图就完事，还要把系统怎么发现故障、怎么去响应故障，以及响应的那段时间到底能不能满足安全要求，给一并交代明白。

　　总结

　　总起来说，硬件架构指标的分解和薄弱环节的识别，最要紧的不是把SPFM、LFM、PMHF这几个数值算完就交差，而是要从安全目标出发，把风险一层层地摊到硬件单元、失效模式和安全机制的上面，再借由FMEDA、FTA、诊断覆盖率，连同故障响应的时间，去找出那些薄弱的位置。随后再把整改的措施、指标的重新计算和验证的结果串到同一条线上，这样一整套硬件架构分析，才算真正地收成了一个闭环。