故障树分析是什么？
故障树分析（FTA）是一种从明确顶事件向下演绎的方法，用AND、OR等布尔逻辑说明哪些事件或事件组合足以导致该结果。它的核心不是把所有可能原因画成树，而是明确系统边界、事件状态、充分条件和假设，再通过最小割集、证据或概率识别应优先控制的路径。
故障树可以只做定性分析，也可以在数据与依赖假设充分时做定量分析。定性分析回答有哪些逻辑路径、是否存在单点失效以及哪些组合最简；定量分析才尝试估计规定任务时间内的顶事件概率。两者都不能替代现场验证、工程判断和相应行业的风险接受程序。
什么时候适合使用故障树分析？
目标是一个清晰的不利状态，需要分析冗余、联锁、屏障、供电、控制或多个条件的组合，并希望识别单点失效、关键路径或验证优先级。
问题边界仍在变化、现象描述不稳定或原因空间未知时，应先整理时间线、分层数据、观察现场或生成候选，再进入逻辑建模。
| 方法 | 分析方向 | 适合回答 |
|---|---|---|
| 故障树分析 | 从顶事件向下演绎 | 哪些事件或组合足以导致结果？ |
| FMEA | 从部件向上归纳 | 一个失效模式会造成哪些影响？ |
| 事件树 | 从起始事件向前展开 | 屏障成功或失败后会到达什么后果？ |
| 鱼骨图 | 围绕问题发散分类 | 还可能遗漏哪些原因方向？ |
若仍处于候选生成阶段，可先参考鱼骨图模板指南；需要比较多种调查方法时，可阅读根因分析技术选择指南。
先认识事件、逻辑门和边界
| 元素 | 含义 | 建模检查 |
|---|---|---|
| 顶事件 | 本棵树要解释的不利系统状态 | 是否可观察、可判定，并限定任务和时间？ |
| 中间事件 | 由下层逻辑组合而成的结果 | 文字是否描述明确状态？ |
| 基本事件 | 本次分析不再向下展开的叶事件 | 是否可估计、可验证或可分配控制？ |
| AND门 | 所有输入同时成立，输出才成立 | 缺少任一输入时，输出是否不再发生？ |
| OR门 | 任一输入成立即可使输出成立 | 每个输入单独是否足以产生输出？ |
门描述逻辑，不自动描述时间。如果顺序、延时、修复、备用切换或状态转换会改变结果，应在事件文字和假设中明确处理，必要时使用动态故障树、事件树或状态模型。
故障树分析九步流程
- 明确目标和决策。说明模型用于设计审查、事故调查、测试计划还是风险排序。
- 定义顶事件。规定对象、状态、阈值、时间和判定数据。
- 固定边界与假设。记录配置、模式、环境、维修策略和排除项。
- 列出直接原因。只写紧邻上一层、对输出必要或充分的状态。
- 逐门检查逻辑。判断输入必须全部发生，还是任意一个即可。
- 向下展开并设停止准则。展开到可验证、可估计或可控制的事件。
- 做结构审查。检查遗漏、重复、循环、共享资源、共因和依赖。
- 求最小割集并排序。先看单事件和低阶组合，再结合后果与不确定性。
- 验证并维护模型。把节点绑定到图纸、日志、测试和措施，并保留版本差异。
AND门和OR门：先验证语义，再考虑公式
| 逻辑 | 语义 | 两个事件的概率表达 | 常见误用 |
|---|---|---|---|
| AND | A与B都发生才产生输出 | P(A∩B)，独立时才等于P(A)×P(B) | 把先后关系或一般相关性画成AND |
| OR | A或B任一个发生就产生输出 | P(A∪B)=P(A)+P(B)−P(A∩B) | 直接相加而忽略重叠 |
对每个输入做两个反事实检查：它单独发生是否足以触发输出；拿掉它以后，剩余组合是否仍足以触发输出。若输入共享电源、环境、维护程序或软件版本，独立性必须有证据支持，不能使用默认假设。
用最小割集看见最简失效路径
割集是一组一旦同时发生就足以使顶事件发生的基本事件；最小割集不能再删除任何成员。它把复杂故障树转换为若干最简路径，便于发现单点失效、冗余被共同绕过的方式，以及应先验证哪些组合。
A单独足以导致顶事件，通常提示单点失效，但仍需确认A是否真正充分以及是否已有独立屏障。
B与C组合绕过冗余或保护，需要重点检查两者是否共享资源或共同诱因。
阶数低只代表所需基本事件少，不代表一定最常发生。排序还应结合发生频率、后果严重度、检测能力、可恢复性和输入不确定性。
什么时候可以做故障树定量分析？
定量前应建立数据字典：每个基本事件的定义、来源、样本期、单位、任务时间、可修复性、置信区间和负责人必须可追溯。同一个“泵失效”若一处表示每小时失效率，另一处表示八小时任务内失效概率，不能直接放进同一公式。
事件口径稳定、观察窗与任务匹配、维修和暴露时间有记录、依赖结构已评审，并且有基准案例可以复算。
数据来自不同边界、样本很少却给出过多小数、共因未建模、逻辑持续变化或结果无法用历史与测试校核。
输出不应只有一个点估计。至少报告输入范围、假设、敏感性结果以及哪些基本事件最影响结论。
独立性、共因失效和动态行为是主要陷阱
冗余部件并不天然独立。两台泵可能共享电源、冷却水源、控制软件、维护程序或安装环境；把它们的失效概率简单相乘，往往会低估共同失效路径。
- 显式建立共因节点：例如公共母线失电、同一错误配置下发或同一污染源进入两路。
- 分清条件概率：若B在A发生后更可能发生，应明确条件或使用经评审的依赖模型。
- 记录互斥状态：不同运行模式不能同时存在时，不应当作可同时发生的输入。
- 处理顺序和备用切换：冷备启动、延时门槛和维修恢复可能需要动态模型。
- 做敏感性分析：改变共因参数，观察顶事件概率和优先级是否翻转。
简化案例：冷却不足导致超温停机
以下结构仅用于教学。顶事件定义为：测试台在连续八小时高负载任务内，因有效冷却能力不足而触发超温停机。
| 输出事件 | 门 | 直接输入 |
|---|---|---|
| T：超温停机 | AND | A：发热超过可用冷却；B：超温保护执行停机 |
| A：发热超过可用冷却 | OR | C：冷却输送丧失；D：热负载异常升高 |
| C：冷却输送丧失 | OR | E：主泵路径失效；F：阀门错误关闭；G：换热介质不可用 |
| E：主泵路径失效 | AND | H：运行泵失效；I：备用泵未成功接管 |
布尔化简后可能出现 {D,B}、{F,B}、{G,B}、{H,I,B} 等候选最小割集。评审时应先确认B是否真是顶事件定义的必要条件，以及H与I是否因共享电源或控制器而相关，再考虑概率。
怎样验证故障树不是“漂亮但错误”？
| 审查维度 | 关键问题 | 证据 |
|---|---|---|
| 边界 | 配置、模式、时间和排除项是否一致？ | 系统说明、任务定义、版本记录 |
| 事件文字 | 是否为可判定状态，而不是模糊标签？ | 判定规则、日志字段、测试准则 |
| 门语义 | 输入对输出是否必要或充分？ | 反事实检查、设计图、专家复核 |
| 完整性 | 是否遗漏能源、信息、环境和外部服务？ | 接口清单、事故史、候选原因 |
| 依赖 | 共享资源、共因、互斥和先后关系是否显式处理？ | 架构、布线、部署与维护记录 |
| 变更 | 设计或假设变化后是否重新计算？ | 版本差异、审批和回归记录 |
事故调查中的节点仍只是待验证命题。应把节点关联到原始日志、照片、图纸、访谈、测试和反证；原因接受可参考失效根因分析中的证据链。
从关键路径到措施：不要只消除一个叶节点
措施可以降低基本事件发生率、增加检测、打断AND组合、消除共享资源、提高备用独立性，或改变系统使某条路径不再足以产生顶事件。选择措施时应比较风险降低幅度、实施可行性、新风险和验证成本。
把故障树节点连接到证据、负责人和变更记录
准备顶事件定义、系统边界、节点ID、图纸与日志来源、概率口径、依赖假设、验证负责人和访问权限。InfiniSynapse可辅助检索、归并和追溯多源材料；工程建模、概率批准与风险接受仍由具备相应职责的人员完成。
打开在线工作区故障树分析常见问题
它是一种自顶向下的演绎方法：先定义不希望发生的顶事件，再用布尔逻辑说明哪些事件或组合足以导致它。
所有输入必须同时满足才产生输出时使用AND门；任意一个输入单独成立就足以产生输出时使用OR门。
不一定。定性故障树已经可以检查逻辑、识别单点失效和安排验证。只有数据口径与依赖假设充分时才适合定量。
最小割集是一组足以导致顶事件的基本事件，并且删除其中任何一个成员后都不再足以导致顶事件。