第三章 故障树分析（FTA）：从符号到量化
各位工程师朋友，今天我们来聊聊故障树分析。说实话，FTA 这玩意儿我刚开始接触时觉得挺玄乎的，一堆符号看得眼花。但干了几十年可靠性，我越来越觉得它是个好东西——尤其是当你需要跟别人解释「为什么这个系统会出问题」的时候。
3.1 故障树的基本符号
先说说符号。FTA 的符号其实不多，我总结下来就三类：事件符号、逻辑门符号、转移符号。记住这三类，基本就能看懂 90% 的故障树。
3.1.1 事件符号
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形 | 顶事件 / 中间事件 | 需要进一步分析的事件 |
| 圆形 | 底事件 | 最基本的故障原因，不再分解 |
| 菱形 | 未展开事件 | 暂时不分析的事件 |
| 房形 | 条件事件 | 特定条件下才发生的事件 |
我个人习惯把矩形叫做「还能往下挖」的事件，圆形就是「挖到底了」。菱形嘛，说白了就是「先放一放，回头再说」。
3.1.2 逻辑门符号
逻辑门是故障树的核心。常用的就两个：与门和或门。
- 与门（AND）：所有输入事件都发生，输出才发生。我做过一个电源项目，两个保护电路同时失效才会烧板子，这就是典型的与门关系。
- 或门（OR）：任意一个输入事件发生，输出就发生。这个最常见，比如一个电容短路、电阻开路、焊点虚焊，任何一个都能让电路不工作。
还有一个叫「禁门」，用的不多，但遇到条件触发的情况会用到。比如「温度超过85°C时，电容失效才会导致输出异常」——这个「温度超过85°C」就是条件。
3.1.3 转移符号
转移符号就是三角形，分「转入」和「转出」。说白了就是「这里太长了，我画到另一页去了」。我在做大型系统时经常用，不然一张图画不下。
避坑指南：我曾经犯过一个错误，转移符号的编号没对上，结果分析到一半发现逻辑链断了。后来我养成了习惯：每次画完转移符号，先检查一遍编号是否匹配。
3.2 建树方法
建树这事儿，说白了就是「从顶往下，层层分解」。我一般按以下步骤来：
- 确定顶事件：系统最不希望发生的事件。比如「手机无法开机」、「电源模块输出异常」。
- 分析直接原因：顶事件是怎么发生的？用逻辑门连接。
- 逐层分解：每个中间事件继续往下挖，直到底事件。
- 检查完整性：有没有遗漏的原因？逻辑关系对不对？
嗯，这里要注意：建树不是一次就能搞定的。我通常要画三版才能定稿。第一版是草稿，第二版是修正，第三版才是最终版。
我的经验：建树时最好拉上设计工程师一起讨论。你一个人闷头画，很容易漏掉一些「只有设计者才知道」的细节。我记得有一次，一个芯片的复位时序问题，就是设计工程师提醒我才加进去的。
3.3 定性分析
定性分析的目标是找出「最小割集」。啥是最小割集？说白了就是「导致顶事件发生的最少故障组合」。
举个例子：一个系统有三个底事件 A、B、C。如果 A 单独就能导致顶事件，那 {A} 就是一个最小割集。如果 A 和 B 同时发生才能导致顶事件，那 {A, B} 就是一个最小割集。
找最小割集的方法，我常用「下行法」：
- 从顶事件开始，遇到或门就把输入事件列成一行，遇到与门就把输入事件列成一列。
- 一直往下走，直到所有事件都是底事件。
- 最后把重复的、包含关系的去掉，剩下的就是最小割集。
重要：最小割集的数量和阶数（包含底事件的个数）直接反映了系统的薄弱环节。一阶割集越多，系统越脆弱。我曾经分析过一个产品，发现有一个一阶割集——一个电容短路就能让整个系统瘫痪。后来我们给这个电容加了冗余设计。
3.4 定量分析
定量分析，说白了就是算概率。我们需要知道每个底事件的发生概率，然后算出顶事件的发生概率。
3.4.1 基本公式
对于与门：P(输出) = P(输入1) × P(输入2) × ... × P(输入n)
对于或门：P(输出) = 1 - (1 - P(输入1)) × (1 - P(输入2)) × ... × (1 - P(输入n))
你想想看，如果两个事件独立，与门的概率就是乘积。或门呢？就是「至少一个发生」的概率。
3.4.2 实际应用中的坑
定量分析看着简单，但实际用起来有不少坑：
- 数据来源问题：底事件的概率从哪来？我一般用历史数据、供应商数据、或者标准手册（比如 MIL-HDBK-217）。但要注意，这些数据都是统计值，不一定适用于你的具体场景。
- 相关性假设：公式假设事件是独立的。但现实中，很多故障是相关的。比如温度升高，多个器件同时失效的概率会增大。这时候用独立假设算出来的结果会偏乐观。
- 计算复杂度：当最小割集很多时，手工计算很麻烦。我一般用软件工具，比如 Relex、Isograph 之类的。
警告：定量分析的结果只是一个参考值，不要把它当成绝对真理。我曾经见过一个团队，算出来顶事件概率是 10^-6，就以为万无一失了。结果实际测试时发现概率比这个高了一个数量级——因为有些故障模式没考虑到。
3.5 知识体系总览
下面这张图是我自己整理的 FTA 知识框架，方便大家理解整体逻辑：
这张图把 FTA 的核心逻辑串起来了：从顶事件出发，经过逻辑门，到中间事件，再到底事件或未展开事件。最后，底事件用于定性分析和定量分析。
3.6 一个完整的例子
我拿一个简单的「LED灯不亮」来演示一下：
- 顶事件：LED灯不亮
- 直接原因（或门）：电源故障 或 LED损坏 或 线路断开
- 电源故障（或门）：电池没电 或 稳压器损坏
- LED损坏（底事件）：LED烧毁
- 线路断开（底事件）：焊点虚焊
最小割集有三个：{电池没电}、{稳压器损坏}、{LED烧毁}、{焊点虚焊}。如果每个底事件的概率都是 0.01，那顶事件的概率就是 1 - (1-0.01)^4 ≈ 0.0394。
你看，这个例子虽然简单，但 FTA 的核心思想都在里面了。
最后说一句：FTA 不是万能的，但它是一个很好的沟通工具。你画一张故障树，别人一眼就能看出系统的薄弱环节在哪。我建议大家在项目初期就做 FTA，而不是等到出了问题再回头分析。
公众号:蓝海资料掘金营，微信deep3321