4、失效模式分析（FMEA）入门：FMEA的目的，FMEA的步骤，FMEA的评分标准
好，咱们今天聊聊FMEA。很多刚入行的工程师觉得FMEA就是填表，走个过场。说实话，我刚开始也这么想。直到有一次，我在一个ADAS项目中，因为漏掉了一个传感器的共因失效模式，差点导致项目延期三个月。从那以后，我再也不敢小看这张表了。
FMEA，全称是Failure Mode and Effects Analysis。说白了，就是“在东西坏掉之前，先想想它怎么坏，坏了对我们有什么影响”。这不是事后诸葛亮，而是事前诸葛亮。
4.1 FMEA的目的：我们为什么要做这件事？
你想想看，功能安全的核心是什么？是避免不可接受的风险。FMEA就是实现这个目标最基础、最有效的工具之一。它的目的，我总结为三点：
- 识别失效模式：系统、硬件、软件，到底可能以什么方式“挂掉”？
- 评估影响：这个失效模式一旦发生，对安全目标、对整车、对用户会造成什么后果？
- 制定措施：我们怎么预防？怎么探测？怎么把风险降到可接受的水平？
核心观点： FMEA不是一次性的文档工作，它是一个动态的风险管理过程。我个人习惯在项目概念阶段就启动FMEA，然后随着设计深入，不断迭代更新。
我记得有个项目，团队花了两周时间做FMEA，结果发现一个电源管理芯片的过压保护阈值设置得太高，导致下游电路存在烧毁风险。如果等到样机测试才发现，改板子至少要多花一个月。这就是FMEA的价值——把问题消灭在图纸阶段。
4.2 FMEA的步骤：一步一步来，别着急
FMEA的步骤其实不复杂，但每一步都需要扎实的工程判断。我习惯把它分成七个步骤：
- 定义范围：明确我们要分析的系统边界、功能、以及安全目标。这一步如果做不清楚，后面全是白费。
- 组建团队：FMEA不是一个人能干的活。需要系统工程师、硬件工程师、软件工程师、测试工程师一起参与。我见过最成功的FMEA会议，是大家吵得面红耳赤，但最后把问题都暴露出来了。
- 识别功能与要求：列出每个功能模块应该做什么，不应该做什么。
- 识别失效模式：针对每个功能，问自己“如果这个功能失效了，会是什么样子？”比如，一个刹车灯，它的失效模式可能是“不亮”、“常亮”、“闪烁”等等。
- 分析失效影响与原因：这个失效模式会导致什么后果？根本原因是什么？是元器件坏了？是软件跑飞了？还是线束断了？
- 评估风险并打分：这就是我们接下来要讲的严重度、发生度、探测度。
- 制定改进措施：根据风险优先级，决定哪些失效模式需要立即处理，哪些可以接受。
我的小技巧： 在步骤4和5之间，我通常会加一个“头脑风暴”环节。让团队里的年轻人先发言，老工程师后发言。这样可以避免权威压制，把一些“看似不可能”的失效模式也挖出来。
4.3 FMEA的评分标准：严重度、发生度、探测度
这是FMEA里最“数字游戏”的部分，但也是最容易出错的地方。评分标准通常分为三个维度，每个维度1-10分。分数越高，风险越大。
4.3.1 严重度（Severity, S）
严重度衡量的是失效模式对用户或系统造成的后果有多严重。在功能安全领域，这个评分直接和安全目标挂钩。
| 评分 | 描述 | 功能安全示例 |
|---|---|---|
| 9-10 | 危及人身安全，违反法律法规 | 制动失效、转向失控、气囊误爆 |
| 7-8 | 系统功能丧失，但无直接安全风险 | 仪表黑屏、空调不制冷 |
| 5-6 | 功能降级，用户明显感知不便 | 倒车影像延迟、车窗升降卡顿 |
| 2-4 | 轻微影响，用户可能不察觉 | 氛围灯颜色偏差、按键手感略差 |
| 1 | 无影响 | 外观轻微划痕（不影响功能） |
注意： 我曾经见过一个团队，把“仪表黑屏”的严重度打成了5分，理由是“车还能开”。但如果是夜间高速行驶，仪表黑屏导致看不到车速和故障灯，这其实是非常危险的。所以，评分一定要结合具体的运行场景来考虑。
4.3.2 发生度（Occurrence, O）
发生度衡量的是这个失效模式发生的可能性有多大。这个评分需要基于历史数据、设计成熟度、以及类似项目的经验。
| 评分 | 描述 | 发生概率（参考） |
|---|---|---|
| 9-10 | 几乎必然发生 | 每千次操作发生一次以上 |
| 7-8 | 经常发生 | 每万次操作发生一次 |
| 5-6 | 偶尔发生 | 每十万次操作发生一次 |
| 2-4 | 很少发生 | 每百万次操作发生一次 |
| 1 | 几乎不可能 | 每千万次操作发生一次以下 |
嗯，这里要注意。发生度的评分不能靠拍脑袋。我建议参考供应商提供的元器件失效率数据（比如FIT值），或者参考公司内部的历史故障库。如果没有数据，宁可把分数打高一点，也不要低估风险。
4.3.3 探测度（Detection, D）
探测度衡量的是，在失效模式发生之后，我们现有的设计控制或测试手段，能不能在它造成严重后果之前发现它。注意，分数越高，代表越难探测。
| 评分 | 描述 | 示例 |
|---|---|---|
| 9-10 | 几乎不可能探测 | 软件中的偶发逻辑错误，只有在特定工况下才触发 |
| 7-8 | 探测手段非常有限 | 需要专门的诊断工具，或者需要拆解才能发现 |
| 5-6 | 可以通过常规测试发现 | 功能测试、集成测试可以覆盖 |
| 2-4 | 很容易探测 | 系统有自检功能，或者开机就能发现 |
| 1 | 肯定能探测 | 有硬件看门狗，或者冗余校验 |
避坑指南： 我曾经犯过一个错误，把探测度打得很低，以为“反正有测试团队会测”。结果测试用例根本没覆盖到那个边界条件。所以，评分时一定要问自己：“我们真的有这个探测手段吗？它可靠吗？”
4.4 风险优先级数（RPN）与行动
有了S、O、D三个分数，我们就可以计算RPN了：RPN = S × O × D。
RPN越高，风险越大。但这里有个关键点：不要只看RPN的绝对值。我见过很多团队，设定一个阈值（比如RPN > 100就必须整改），然后低于阈值的就不管了。这是不对的。
为什么？因为如果严重度是10（致命风险），哪怕发生度是1，探测度是1，RPN只有10，你也必须采取行动。因为一旦发生，就是人命关天的事。
所以，我个人习惯的做法是：
- 先看严重度：S ≥ 9 的，必须整改，不管RPN多少。
- 再看RPN：RPN排名前20%的，优先整改。
- 最后看探测度：D ≥ 8 的，考虑增加诊断或测试手段。
好了，FMEA的入门就讲到这里。说白了，FMEA就是一场“纸上谈兵”的演习。但这场演习做得好不好，直接决定了你的产品在战场上能不能活下来。下一章，我们会深入聊聊如何把FMEA的结果转化为具体的安全需求。