第1章故障树分析概述

一、故障树分析概述

说起故障树分析，我得先聊聊它的来历。这东西最早是1961年由美国贝尔实验室的沃森（H.A. Watson）提出来的。当时他们在搞民兵导弹的发射控制系统，需要一种能系统分析故障原因的方法。嗯，说白了就是怕导弹发射时出岔子。

后来到了1965年，波音公司的哈斯尔（D.F. Haasl）等人把这套方法完善了，正式命名为“故障树分析”（Fault Tree Analysis，简称FTA）。我刚开始接触这玩意儿时，觉得它跟电路图有点像，都是树状结构，但越用越发现，这里面的门道深着呢。

70年代以后，FTA开始从军工领域扩散到核能、化工、航空航天这些高风险行业。我记得有个老前辈跟我说过，三里岛核事故之后，美国核管会就把FTA列为标准分析工具了。你想想看，连核电站都用它，这方法的分量可想而知。

到了今天，FTA已经成了可靠性工程的标配技能。不管是汽车、高铁、医疗器械，还是咱们日常用的手机、电脑，设计阶段都会用到它。我个人习惯，拿到一个新产品的设计图，第一件事就是琢磨它的故障树该怎么画。

可靠性工程里方法很多，什么FMEA、FMECA、ETA、RBD……但FTA为什么能站C位？我给大家分析一下。

第一，它是自上而下的分析方法。 从系统级的故障现象出发，一层层往下找原因。这跟我们平时排查问题的思路完全一致——先看症状，再找病根。我在项目中遇到过不少案例，用FMEA分析半天找不到关键点，换成FTA一下子就抓住了要害。

第二，它能处理复杂逻辑关系。 一个故障可能是多个原因共同导致的，也可能是其中一个原因单独引发的。FTA用“与门”、“或门”这些逻辑符号，把这些关系表达得清清楚楚。说白了，它就是一张故障逻辑地图。

第三，它能做定量分析。 只要给底事件（最底层的原因）配上故障概率数据，就能算出顶事件（系统故障）的发生概率。这一点在实际工程中特别实用。我建议大家在设计评审时，把FTA的定量结果摆出来，比空口说“这个设计可靠”有说服力得多。

核心观点： FTA是连接“定性分析”和“定量分析”的桥梁。它既能帮你理清故障逻辑，又能算出具体概率值。在可靠性工程中，能做到这一点的工具不多。

学FTA之前，得先把它的“行话”搞明白。我刚开始学的时候，就被这些术语绕晕过。咱们一个一个来捋。

FTA里最常用的就是两种逻辑门：

举个例子：

顶事件：发动机无法启动
    |
   或门
    |
    ├── 电池没电（底事件1）
    └── 启动机故障（底事件2）
    |
   与门
    |
    ├── 燃油不足（底事件3）
    └── 点火系统故障（底事件4）

这个例子说明：发动机无法启动，要么是电池没电，要么是启动机故障（或门关系）；但如果同时燃油不足且点火系统故障（与门关系），也会导致无法启动。我在实际项目中就遇到过类似情况，排查了半天才发现是两个小问题同时发生了。

避坑指南： 我曾经犯过一个错误——把与门和或门搞混了。记住一个口诀：“与门要全，或门只要一”。与门是“一个都不能少”，或门是“一个就够了”。

除了逻辑门，事件本身也有不同的符号：

嗯，这里要注意：菱形事件在初步分析时可以用，但到了详细设计阶段，我建议尽量把它展开成底事件。否则分析结果会打折扣。

故障树是一棵倒置的树——根在上，叶在下。顶事件是树根，底事件是树叶。中间事件是树枝。这种结构的好处是：

我给大家画个简单的故障树结构图，方便理解：

这张图展示了一个简单的故障树结构。顶事件通过或门连接到两个中间事件，其中一个中间事件又通过与门连接到底事件。你想想看，如果底事件1和底事件2同时发生，或者底事件3单独发生，顶事件就会发生。这就是FTA的基本逻辑。

注意事项： 画故障树时，一定要确保逻辑关系正确。我见过有人把“与门”和“或门”用反了，结果分析结论完全错误。建议画完后找同事交叉评审一遍。

好了，这一章的内容就到这里。FTA的起源、地位和基本概念都讲清楚了。下一章咱们聊聊怎么实际动手建一棵故障树，包括建树的步骤、注意事项，以及我在项目中总结的一些实用技巧。