4、FMEA核心要素：严重度(S)、发生度(O)、探测度(D)的定义与评分标准，风险优先数(RPN)的计算与阈值设定

好，咱们进入FMEA最核心的部分。说白了，FMEA整个分析过程，最后都要落到三个数字上：严重度（S）、发生度（O）、探测度（D）。这三个数字一乘，就是风险优先数（RPN）。

很多新手拿到评分表就开始打勾，觉得这是填表作业。我刚开始做硬件FMEA时也这么想，直到有一次评审会上，一个老专家指着我的评分说：“你这个S打低了，这个安全漏洞流片回来就是废片，甚至可能烧板子。” 那次之后我才明白，这三个数字背后是对风险的深刻理解，不是随便填的。

4.1 严重度（S）：出事了，后果多严重？

严重度，就是失效模式一旦发生，对系统、用户、环境造成的最坏后果的等级。注意“最坏”两个字——我们评估的是最糟糕的情况，不是平均情况。

我个人习惯把严重度分成两类：安全相关和功能相关。安全相关的严重度通常更高，因为涉及人身安全或设备损毁。

4.2 发生度（O）：这事儿发生的概率有多大？

发生度，评估的是失效原因出现的频率。注意，不是失效模式本身出现的频率，而是导致这个失效模式的根因出现的概率。

举个例子：芯片的JTAG调试接口在量产时没熔断。失效模式是“调试接口可被攻击者利用”，失效原因是“生产流程中遗漏了熔断步骤”。那么O应该评估的是“生产流程遗漏熔断步骤”这个事件的发生概率，而不是“攻击者利用调试接口”的概率。

4.3 探测度（D）：问题能被发现吗？

探测度，评估的是在产品交付给客户之前，通过现有的检测手段发现失效模式或失效原因的能力。注意，这里说的是“交付前”，不是“出事后”。

探测度评分是反向的：越难探测，分数越高。也就是说，D=10表示完全无法探测，D=1表示肯定能被发现。

4.4 风险优先数（RPN）的计算与阈值设定

RPN = S × O × D。就这么简单，三个数字相乘。但简单背后有大学问。

RPN的范围是1到1000。理论上，RPN越高，风险越大，越需要优先处理。但实际工作中，我们不会对所有RPN>1的问题都投入资源——那样做项目就别想往前走了。

4.4.1 阈值怎么设？

阈值设定没有标准答案，不同公司、不同产品、不同安全等级都不一样。我分享一个常用的做法：

• 红线阈值（必须处理）： RPN ≥ 100，或者 S ≥ 9 且 O ≥ 5。这类风险必须制定整改措施，并跟踪闭环。
• 黄线阈值（建议处理）： 50 ≤ RPN < 100，或者 S ≥ 7 且 O ≥ 4。这类风险建议制定整改措施，至少要有缓解方案。
• 绿线阈值（持续监控）： RPN < 50。这类风险可以接受，但需要持续监控，防止条件变化后风险升级。

你想想看，为什么我要把S≥9且O≥5单独拎出来？因为严重度极高的事件，即使发生概率不高，一旦发生就是灾难。我见过一个项目，RPN只有72（S=9, O=8, D=1），但S=9意味着会烧板子，谁敢不处理？

4.4.2 RPN的局限性

说实话，RPN不是完美的。它有三个明显的坑：

1. 乘法放大效应： S=10, O=10, D=1 的RPN是100，S=5, O=5, D=4 的RPN也是100。但前者是安全灾难，后者只是小毛病。只看RPN会误导你。
2. 评分主观性： 不同工程师对S、O、D的理解不同，评分结果可能差异很大。我建议团队做交叉评审，至少两个人独立评分，然后讨论对齐。
3. 忽略组合风险： 多个低RPN的失效模式组合在一起，可能产生高RPN的后果。RPN是单点评估，不擅长处理系统性风险。

4.5 知识体系图：S-O-D-RPN核心逻辑

下面这张图展示了S、O、D、RPN之间的核心逻辑关系，以及它们如何驱动风险决策。

4.6 实战中的评分对齐

最后说一个实操问题。我参与过好几个项目的FMEA评审，最头疼的就是评分不一致。同一个失效模式，硬件工程师打S=7，安全工程师打S=9，两个人吵得不可开交。

怎么解决？我的做法是：

• 建立评分案例库： 把过去项目中典型的失效模式、评分结果和实际后果记录下来。下次遇到类似情况，直接查案例。
• 做一次团队校准： 项目启动时，找3-5个典型失效模式，让团队成员独立评分，然后一起讨论差异。通常讨论两三轮后，大家的评分尺度就对齐了。
• 引入第三方视角： 如果内部争议太大，可以请安全架构师或外部专家做仲裁。别让争议拖太久，FMEA的目的是推动改进，不是争论分数。