4. 故障诊断基础：故障树分析(FTA)方法、失效模式与影响分析(FMEA)
各位工程师朋友，咱们今天聊聊故障诊断里两个最实用的工具——FTA和FMEA。说实话，我刚入行那会儿，觉得这些分析方法就是纸上谈兵。直到有一次，一个智能灯控系统在客户现场批量出问题，我才真正体会到它们的价值。
那次排查了整整三天，最后发现是电源模块里一个电容的选型问题。如果当时先做FMEA，可能半天就搞定了。嗯，咱们今天就好好说说这两个方法。
4.1 失效模式与影响分析（FMEA）
FMEA，说白了就是「先想好怎么坏」。我习惯在设计阶段就做这件事，而不是等产品出问题了再回头补。
它的核心思路很简单：列出每个零件可能怎么坏，坏了会有什么后果，后果有多严重。然后根据风险等级，决定要不要改设计。
4.1.1 FMEA的三大要素
做FMEA时，我一般关注三个维度：
- 严重度（S）：失效后影响有多大？比如灯不亮是中等，灯短路起火那就是致命了。
- 发生度（O）：这个失效模式出现的概率高不高？我见过有些电容的失效率标称是10ppm，实际用起来能到100ppm。
- 检测度（D）：问题发生前，我们能不能发现它？比如通过自检程序能检测到LED开路，那检测度就高。
风险优先数（RPN） = S × O × D。这个值越高，越需要优先处理。
我个人经验：RPN超过100的，我一般会强制要求改设计。超过200的，必须重新评审方案。别问我为什么定这个数，吃过亏就知道了。
4.1.2 智能照明FMEA示例
咱们拿一个智能灯泡的电源模块来举例。我做过一个项目，里面用了非隔离的Buck电路。
| 零件 | 失效模式 | 失效原因 | 影响 | S | O | D | RPN |
|---|---|---|---|---|---|---|---|
| 电解电容 | 容量衰减 | 高温老化 | 输出纹波增大，LED闪烁 | 6 | 7 | 3 | 126 |
| MOS管 | 漏源短路 | 过压击穿 | 电源直通，烧毁负载 | 9 | 4 | 5 | 180 |
| 采样电阻 | 阻值漂移 | 焊接应力 | 恒流不准，亮度异常 | 5 | 3 | 6 | 90 |
你看，MOS管短路这个失效模式，RPN高达180。我当时就加了一个保险丝，把发生度从4降到了2，RPN直接降到90。这就是FMEA的价值——用最小的成本，解决最大的风险。
避坑指南：我曾经犯过一个错——只做了设计阶段的FMEA，没做过程FMEA。结果生产时焊接温度没控制好，导致一批LED焊点虚焊。后来我学乖了，生产和组装环节也要做FMEA。
4.2 故障树分析（FTA）
FTA和FMEA正好反过来。FMEA是从下往上推——零件坏了会怎样？FTA是从上往下拆——系统出问题了，可能是哪些原因造成的？
我个人觉得，FTA更适合排查已经发生的故障。比如客户说「灯不亮了」，你不可能把所有零件都查一遍。用FTA，你能快速锁定最可能的原因。
4.2.1 FTA的基本符号
画故障树时，常用的符号就几个：
- 顶事件：系统级的故障，比如「灯不亮」
- 中间事件：子系统或模块的故障，比如「电源无输出」
- 底事件：最底层的零件失效，比如「保险丝熔断」
- 与门：所有输入同时发生，输出才发生
- 或门：任意一个输入发生，输出就发生
你想想看，故障树其实就是把「为什么」一层层拆下去。拆到不能再拆了，就是底事件。
4.2.2 智能照明FTA实例
咱们还是拿「灯不亮」这个顶事件来分析。我习惯先画一个简单的故障树：
灯不亮（顶事件）
├── 或门
│ ├── 电源故障（中间事件）
│ │ ├── 或门
│ │ │ ├── 保险丝熔断（底事件）
│ │ │ ├── 整流桥损坏（底事件）
│ │ │ └── 变压器开路（底事件）
│ ├── 控制电路故障（中间事件）
│ │ ├── 或门
│ │ │ ├── MCU死机（底事件）
│ │ │ ├── 晶振停振（底事件）
│ │ │ └── 复位电路异常（底事件）
│ └── LED负载故障（中间事件）
│ ├── 或门
│ │ ├── LED开路（底事件）
│ │ └── 恒流源损坏（底事件）
这个树画出来，排查思路就清晰了。先测电源输出，有电就查控制电路，没电就查保险丝和整流桥。嗯，这就是FTA的实用之处。
注意：故障树不是越细越好。我见过有人把每个焊点都列成底事件，结果树画了三页纸，根本没法用。一般来说，底事件拆到「可更换的零件」级别就够了。
4.2.3 定量分析
如果知道每个底事件的失效率，还能算出顶事件的发生概率。比如保险丝的失效率是10^-6/小时，整流桥是10^-7/小时，那电源故障的概率就是两者之和（因为是或门）。
不过说实话，我在实际项目中很少做定量分析。原因很简单——底事件的失效率数据往往不准。供应商给的数据，你懂的，多少有点水分。我更看重FTA的定性分析——它能帮你找到最薄弱的环节。
4.3 FMEA与FTA的配合使用
这两个工具不是二选一的关系。我个人的做法是：
- 设计阶段用FMEA：找出所有可能的失效模式，提前预防
- 故障排查用FTA：快速定位问题根源
- 迭代改进：把FTA发现的根因，补充到FMEA的数据库里
举个例子。有一次客户反馈灯具有时闪一下。我用FTA排查，发现是电源的启动电路在电网波动时误触发。找到根因后，我把这个失效模式加到了FMEA表格里，后续所有项目都做了针对性设计。
核心观点：FMEA是「防患于未然」，FTA是「亡羊补牢」。两者结合，才能把可靠性做到位。
4.4 实战建议
最后，给各位几个我踩过坑后的建议：
- FMEA表格别太复杂：我见过有人列了50列，填到后面自己都忘了填的是什么。保持S、O、D三列就够了。
- 故障树要画在纸上：别用软件自动生成。手画的过程，就是思考的过程。我每次画完，都能发现之前没想到的故障路径。
- 定期更新：产品上市后，把售后反馈的故障数据加进去。我每半年更新一次FMEA数据库，现在已经有300多条记录了。
- 团队评审：别一个人闷头做。叫上硬件、软件、测试的人一起过一遍。不同视角能看到不同的问题。
好了，关于FTA和FMEA，今天就聊到这儿。这两个工具不难，难的是坚持用、用到位。下次咱们聊聊故障诊断的另一个重要方法——根本原因分析（RCA）。