3. 故障树构建步骤
故障树分析（FTA）是工业安全与故障诊断的核心工具，其构建质量直接决定后续排查与SOP整合的有效性。本节将拆解故障树构建的四个标准步骤，并结合报警联动场景进行实战说明。
3.1 步骤一：明确顶事件
顶事件是故障树分析的起点，即系统最不希望发生的、需要重点防范的故障状态。顶事件必须满足以下条件：
- 唯一性：一次分析只针对一个顶事件。
- 可度量：能够通过传感器、报警信号或人工观察明确判定是否发生。
- 可分解：存在明确的、可追溯的底层原因。
实战提示：在报警联动场景中，顶事件通常直接取自报警联动配置表中的“报警触发条件”，例如“冷却水流量低于阈值导致设备停机”或“反应釜温度超限触发紧急切断”。
3.2 步骤二：界定系统边界
系统边界定义了故障树分析的范围，避免分析范围过宽或过窄。边界界定包括：
| 边界类型 | 说明 | 报警联动示例 |
|---|---|---|
| 物理边界 | 明确分析对象包含哪些设备、子系统、管路或区域 | 仅分析“冷却水泵组”及“冷却水循环管路”，不包含“冷冻机组” |
| 功能边界 | 明确系统在何种运行模式下进行分析 | 仅分析“正常运行模式”，不包含“检修模式”或“启动模式” |
| 时间边界 | 明确分析的时间窗口或阶段 | 仅分析“连续运行24小时”内的故障，不包含“首次投运调试阶段” |
| 外部条件边界 | 明确环境、供电、气源等外部条件假设 | 假设“市电供电正常”、“环境温度在0~40℃范围内” |
常见错误：边界界定过宽会导致故障树过于庞大，难以维护；边界界定过窄则可能遗漏关键原因，导致故障树分析失效。建议在SOP中明确标注边界条件。
3.3 步骤三：逐层分解原因
从顶事件出发，按照“自上而下”的方式，逐层追问“导致该事件发生的直接原因是什么”，直到分解到无法再分解的底事件（基本事件）。分解原则：
- 完整性：每一层必须穷举所有可能的直接原因。
- 独立性：同一层的各原因之间应尽量保持逻辑独立，避免交叉。
- 可验证性：底事件应能够通过检查、测量或观察来确认是否发生。
分解深度参考：在报警联动场景中，通常分解到“传感器故障”、“执行器卡涩”、“管路堵塞”、“控制器逻辑错误”等可直接对应SOP检查项的层级即可，无需过度分解到电子元器件级别。
3.4 步骤四：建立逻辑关系
使用逻辑门（与门、或门、非门等）将各层事件连接起来，形成完整的故障树结构。逻辑关系决定了故障传播的路径和条件。
| 逻辑门类型 | 符号 | 逻辑含义 | 报警联动场景示例 |
|---|---|---|---|
| 与门 | AND | 所有输入事件同时发生，输出事件才发生 | “冷却水流量低” AND “备用泵未启动” → “冷却系统失效” |
| 或门 | OR | 任意一个输入事件发生，输出事件就发生 | “主泵故障” OR “管路泄漏” → “冷却水流量低” |
| 非门 | NOT | 输入事件不发生，输出事件才发生 | NOT “备用泵可用” → “备用泵未启动” |
3.5 故障树构建实战SVG图
以下SVG图展示了以“冷却系统失效”为顶事件的故障树构建示例，包含四个步骤的完整逻辑关系：
3.6 故障树构建步骤清单
以下清单总结了故障树构建的四个核心步骤及其关键输出物，可直接用于课程实战演练：
| 步骤序号 | 步骤名称 | 关键活动 | 输出物 | 质量检查点 |
|---|---|---|---|---|
| 1 | 明确顶事件 | 定义故障状态、确认可观测性、确认唯一性 | 顶事件描述文档 | 是否与报警联动配置表中的触发条件一致 |
| 2 | 界定系统边界 | 划定物理/功能/时间/外部条件边界 | 系统边界定义表 | 边界是否清晰无歧义，是否覆盖所有关键子系统 |
| 3 | 逐层分解原因 | 自上而下追问直接原因，直至底事件 | 故障树初步结构图 | 每层是否穷举、底事件是否可验证 |
| 4 | 建立逻辑关系 | 使用与门/或门/非门连接各层事件 | 完整故障树图 | 逻辑门使用是否正确，是否存在冗余或遗漏 |