4. 故障树构建步骤：定义顶事件、边界条件、逐层分解、逻辑门连接
故障树分析（FTA）是预防性维护计划中用于定位系统薄弱环节的核心工具。构建一棵逻辑严密、可量化的故障树，必须遵循标准化的四步流程。本节将逐一拆解每个步骤的操作要点与工程规范。
4.1 步骤一：定义顶事件（Top Event）
顶事件是故障树分析的起点，代表系统最不希望发生的失效状态。定义顶事件需满足以下原则：
- 唯一性：一次分析只针对一个顶事件，避免多目标混淆。
- 可分解性：顶事件必须能够向下拆解为更具体的子事件。
- 可观测性：顶事件应具备明确的判定标准（如“泵出口压力低于2.0 MPa”）。
工程案例： 某化工厂离心泵组预防性维护计划中，顶事件定义为“主输送泵在运行周期内非计划停机”。
4.2 步骤二：确定边界条件（Boundary Conditions）
边界条件用于限定故障树的分析范围，防止分析范围无限扩散。通常包含以下三类：
| 边界类型 | 定义 | 示例（主泵非计划停机） |
|---|---|---|
| 系统边界 | 明确分析包含哪些子系统/部件 | 包含电机、联轴器、泵体、密封系统；不包含上游电源变压器 |
| 环境边界 | 考虑的外部环境条件 | 环境温度 -10°C ~ 40°C；不考虑地震、洪水 |
| 初始状态 | 系统在分析开始时的状态假设 | 假设所有部件在 t=0 时均为全新且功能正常 |
常见错误： 边界条件定义过宽会导致故障树规模失控；定义过窄则会遗漏关键失效路径。建议在项目启动阶段由系统工程师、维护工程师和可靠性工程师共同评审边界条件。
4.3 步骤三：逐层分解（Top-Down Decomposition）
从顶事件出发，按照“直接原因 → 子原因”的逻辑逐层向下展开，直到到达无法再分解的底事件（基本事件）。分解过程需遵循 MECE 原则（相互独立，完全穷尽）。
分解深度通常由以下因素决定：
- 数据可用性：底事件应具备历史故障率数据或专家经验数据。
- 维护可操作性：底事件应对应具体的可更换或可维修部件。
- 分析目标：若用于定量计算，需分解到部件级；若仅用于定性排查，可停留在子系统级。
4.4 步骤四：逻辑门连接（Logic Gate Connection）
逻辑门用于描述下层事件与上层事件之间的因果关系。故障树中最常用的两种逻辑门是 与门（AND Gate） 和 或门（OR Gate）。
| 逻辑门类型 | 符号 | 逻辑含义 | 工程示例 |
|---|---|---|---|
| 与门（AND） | 圆弧底 + 平顶 | 所有下层事件同时发生，上层事件才发生 | “备用泵无法启动” = “主电源故障” 且 “备用电源故障” |
| 或门（OR） | 尖底 + 圆弧顶 | 任意一个下层事件发生，上层事件即发生 | “泵出口压力低” = “进口堵塞” 或 “叶轮磨损” 或 “转速不足” |
工程经验： 在预防性维护计划中，与门通常对应冗余设计（如双电源、双泵并联），而或门则对应单点故障。故障树中或门的数量越多，系统的脆弱性越高。
4.5 构建流程总结与检查清单
以下检查清单可用于验证故障树构建的完整性：
- 顶事件是否定义清晰、唯一且可量化？
- 边界条件是否已明确系统范围、环境假设和初始状态？
- 逐层分解是否遵循 MECE 原则，无遗漏、无重叠？
- 逻辑门是否正确反映了事件间的因果关系？（与门 vs 或门）
- 底事件是否已分解到可获取故障率数据或可执行维护操作的层级？