第2章：FMEA基础概念——故障模式、影响、原因与RPN
好，咱们直接进入正题。
FMEA这东西，说白了就是一套“找茬”的方法论。你得先知道东西会怎么坏，坏了会怎样，为什么会坏，然后才能想办法去防。这一章，我把最核心的几个概念掰开揉碎了讲给你听。
2.1 故障模式：它到底是怎么“死”的？
故障模式，就是产品或者过程“失效”的具体表现形式。你想想看，一个零件坏了，它不可能凭空消失，总得有个样子吧？
比如一个电阻，它的故障模式可能是“开路”，也可能是“短路”。一个螺栓，可能是“断裂”，也可能是“松动”。
我个人习惯，在定义故障模式时，一定要用“动词+名词”的结构。比如“轴承卡死”、“电路板烧毁”、“密封圈老化”。这样写，后续分析才不会跑偏。
关键点：故障模式要具体，别写“功能失效”这种笼统的词。要写“输出压力不足”、“信号无输出”这种能直接测量的。
我在项目中遇到过一位同事，写故障模式写了个“不好使”。我当时就问他：“什么算不好使？是转不动？还是转得太快？” 你看，不具体就没法分析。
2.2 故障影响：后果有多严重？
故障影响，就是故障模式发生后，对系统、对用户、对环境造成的后果。
这里有个层级概念，我建议你记住：
- 局部影响：对当前组件本身的影响。比如齿轮断了，齿轮自己肯定转不了了。
- 上一级影响：对所在子系统的影响。齿轮断了，变速箱可能就卡死了。
- 最终影响：对整车或整个系统的影响。变速箱卡死，车就跑不动了，甚至可能出事故。
为什么要分这么细？因为后续定严重度（S）的时候，我们看的是最终影响。齿轮断了本身可能不致命，但车跑不动了，那就是大事。
我的小技巧：写影响时，从下往上写。先写局部，再写上一级，最后写最终。这样逻辑最顺。
2.3 故障原因：为什么会发生？
这是FMEA里最需要花功夫的地方。原因找不准，后面的措施全是白搭。
故障原因，就是导致故障模式发生的“根因”。它可能是设计上的缺陷，也可能是制造过程中的偏差，还可能是使用环境导致的。
举个例子：
- 故障模式：螺栓断裂
- 可能的原因：
- 设计强度不足（设计原因）
- 拧紧力矩过大（装配原因）
- 材料有微裂纹（来料原因）
- 长期腐蚀（环境原因）
我曾经犯过一个错，把“操作工没按规程操作”直接写成了原因。后来被老师傅骂了一顿：“你为什么不设计成防呆的？人都会犯错，你要从设计上杜绝！” 从那以后，我写原因时，尽量往设计端、往系统端去挖。
避坑指南：不要把“人为错误”直接当作原因。要问“为什么人会犯错？是设计不合理？还是培训不到位？” 深挖一层，才是真原因。
2.4 三大评价指标：S、O、D
这三个字母，是FMEA的灵魂。没有它们，FMEA就是一张废纸。
2.4.1 严重度（S）
严重度，衡量的是故障影响的“严重程度”。一般分1到10级。
- 1-2级：几乎没影响，用户可能都察觉不到。
- 3-4级：轻微影响，用户有点不爽，但还能用。
- 5-6级：功能丧失，用户没法正常使用了。
- 7-8级：系统损坏，或者有安全隐患。
- 9-10级：涉及人身安全，或者违反法规。
我个人的经验是，严重度一旦定了，就别轻易改。因为它只跟故障影响有关，跟你怎么预防、怎么探测都没关系。你想想看，车刹不住，不管你怎么防，后果都是严重的，对吧？
2.4.2 频度（O）
频度，衡量的是故障原因“发生的可能性”。也是1到10级。
- 1级：几乎不可能发生。
- 5级：偶尔发生，比如千分之一。
- 10级：几乎必然发生。
这里要注意，频度不是拍脑袋定的。最好有历史数据、试验数据或者类似产品的经验做支撑。我见过有人把所有原因都定成3级，那这个FMEA基本就没意义了。
2.4.3 探测度（D）
探测度，衡量的是“在故障发生前或发生时，我们能不能发现它”。同样1到10级。
- 1级：肯定能发现，比如有自动检测设备。
- 5级：通过人工检查可能发现。
- 10级：根本发现不了，或者没有检测手段。
我建议，探测度的评分要基于“现有的控制措施”。别想着“以后加个传感器就能发现”，那不算。你现在有什么手段，就评什么分。
2.5 风险优先数（RPN）
RPN = S × O × D
就这么简单，三个数乘起来。结果从1到1000。
RPN越高，说明这个风险越需要优先处理。但这里有个坑，我必须要说：
重要提醒：别只看RPN的数值大小！如果严重度（S）是9或10，哪怕RPN只有100，也必须优先处理。因为涉及安全，一票否决。
我习惯的做法是：先看S，S≥9的，直接列为“必须改进项”。然后再看RPN，比如设定一个阈值（比如200），超过阈值的也要改进。
2.6 知识体系总览
下面这张图，把这一章的核心逻辑串起来了。你一看就明白：
你看，从左到右，先有故障模式，再找原因和影响。然后原因对应频度（O），影响对应严重度（S），模式本身对应探测度（D）。最后三个数一乘，就是RPN。
这个逻辑链条，是FMEA的骨架。你把这个搞清楚了，后面做分析就顺了。
2.7 实战小贴士
最后，分享几个我这些年总结的实用技巧：
- 先做功能分析，再做FMEA。 你连产品有哪些功能都没搞清楚，怎么分析故障？
- 团队作战，别一个人闷头写。 设计、工艺、质量、生产的人都要拉进来。一个人想不全。
- RPN不是唯一标准。 我见过有人为了降低RPN，故意把O或D评低。这是自欺欺人。
- FMEA是活的。 产品改了、工艺变了、客户投诉了，都要回头更新FMEA。
嗯，这里要注意：刚开始做FMEA，别追求完美。先做起来，哪怕只分析出几个关键故障模式，也比纸上谈兵强。慢慢迭代，越做越细。
好了，这一章的核心概念就这些。你把这些吃透了，后面学DFMEA、PFMEA都会轻松很多。
公众号:蓝海资料掘金营，微信deep3321