Skip to content

故障树分析(FTA)

学习目标

完成本模块后,你将能够: - 理解故障树分析的基本概念 - 掌握故障树的符号和构建方法 - 进行定性和定量故障树分析 - 应用FTA到医疗器械风险分析 - 识别最小割集和关键路径

前置知识

  • ISO 14971基本概念
  • 布尔代数基础
  • 概率论基础
  • 系统工程知识

FTA概述

什么是故障树分析?

定义: 故障树分析(Fault Tree Analysis, FTA)是一种自顶向下的演绎分析方法,用于识别导致特定不希望事件(顶事件)的所有可能原因。

特点: - 演绎方法(从结果推原因) - 图形化表示 - 逻辑关系清晰 - 可定性也可定量 - 系统化分析

FTA vs FMEA

特征 FTA FMEA
方向 自顶向下(演绎) 自底向上(归纳)
起点 特定失效事件 所有组件/功能
目的 找出导致特定失效的原因 识别所有可能的失效模式
表示 树形图 表格
逻辑关系 明确的逻辑门 因果关系
定量分析 容易 较难
适用场景 分析特定严重事件 全面风险识别
复杂度 较高 中等

互补关系: - FMEA用于全面识别风险 - FTA用于深入分析高风险项目 - 两者结合使用效果最佳

FTA的应用场景

1. 分析严重失效事件 - 可能导致死亡或严重伤害的事件 - 法规特别关注的事件 - 客户关注的关键失效

示例: 输液泵过量给药

2. 分析复杂系统失效 - 多个组件交互导致的失效 - 系统级失效 - 共因失效

示例: 多个子系统同时失效导致系统崩溃

3. 可靠性分析 - 计算系统可靠性 - 识别薄弱环节 - 优化设计

4. 安全分析 - 核电、航空等高风险领域 - 医疗器械安全关键功能 - 符合安全标准要求

故障树符号

基本符号

事件符号:

┌─────────┐
│ 顶事件  │  矩形: 顶事件或中间事件
└─────────┘  (需要进一步分析的事件)

    ○        圆形: 基本事件
             (不需要进一步分析的事件)

    ◇        菱形: 未展开事件
             (可以进一步分析但暂不展开)

   ┌───┐
   │   │     房屋形: 正常事件
   └───┘     (正常运行状态)

逻辑门符号:

    ┌─┐
  ──┤ ├──    与门(AND): 所有输入都发生,输出才发生
    └─┘

    ┌─┐
  ──┤ ├──    或门(OR): 任一输入发生,输出就发生
    └─┘

    ┌─┐
  ──┤ ├──    非门(NOT): 输入不发生,输出才发生
    └─┘

    ┌─┐
  ──┤ ├──    异或门(XOR): 恰好一个输入发生,输出才发生
    └─┘

    ┌─┐
  ──┤ ├──    表决门(k/n): n个输入中至少k个发生,输出才发生
    └─┘      (如2/3表示3个中至少2个)

转移符号:

    △        转出符号: 树的一部分在其他地方继续

    ▽        转入符号: 从其他地方转入的子树

逻辑门详解

1. 与门(AND Gate)

逻辑: 所有输入事件都发生,输出事件才发生

示例: 双传感器系统失效

        系统失效
           |
        ┌──┴──┐
        │ AND │
        └──┬──┘
      ┌────┴────┐
   传感器A   传感器B
    失效      失效

概率计算: P(输出) = P(A) × P(B)

应用: 冗余系统、多重保护

2. 或门(OR Gate)

逻辑: 任一输入事件发生,输出事件就发生

示例: 电源失效

        电源失效
           |
        ┌──┴──┐
        │ OR  │
        └──┬──┘
      ┌────┴────┐
   主电源    备用电源
    失效      失效

概率计算: P(输出) = 1 - (1-P(A)) × (1-P(B))

应用: 多种失效路径、单点失效

3. 表决门(Voting Gate)

逻辑: n个输入中至少k个发生,输出才发生

示例: 三传感器系统(2/3表决)

        系统失效
           |
        ┌──┴──┐
        │ 2/3 │
        └──┬──┘
      ┌──┬─┴─┬──┐
    传感器A B  C
     失效 失效 失效

应用: 表决冗余系统

构建故障树

步骤1: 定义顶事件

选择标准: - 严重性高的事件 - 法规关注的事件 - 客户关注的事件 - 需要深入分析的事件

顶事件特征: - 明确定义 - 可观察/可测量 - 不希望发生 - 有明确的边界条件

示例: - ✓ "输液泵过量给药(流速>设定值10%)" - ✗ "输液泵故障"(太宽泛)

步骤2: 定义边界条件

明确: - 系统边界 - 分析深度 - 时间范围 - 环境条件 - 假设条件

示例 - 输液泵过量给药: - 系统: 输液泵主机(不包括输液管路) - 深度: 分析到组件级 - 时间: 正常使用期间 - 环境: 医院环境,正常温湿度 - 假设: 用户按说明书操作

步骤3: 识别直接原因

问题: "什么直接导致顶事件发生?"

方法: - 头脑风暴 - 专家咨询 - 参考FMEA - 系统分析 - 历史数据

示例 - 输液泵过量给药:

      过量给药
         |
      ┌──┴──┐
      │ OR  │
      └──┬──┘
    ┌────┼────┐
流速控制  流速测量  流速设定
  失效     失效     错误

步骤4: 逐层展开

对每个中间事件: 1. 判断是否需要进一步分析 2. 如需要,识别其直接原因 3. 选择合适的逻辑门 4. 继续展开

停止条件: - 达到基本事件(不能或不需要进一步分析) - 达到预定分析深度 - 事件概率已知 - 事件可以通过测试/检查发现

示例 - 展开"流速控制失效":

   流速控制失效
         |
      ┌──┴──┐
      │ OR  │
      └──┬──┘
    ┌────┼────┐
  泵故障  阀门  控制器
         故障   故障

步骤5: 识别基本事件

基本事件特征: - 不需要进一步分析 - 有已知或可估计的概率 - 是最底层的原因

基本事件类型: - 组件失效 - 人为错误 - 环境因素 - 软件缺陷

示例: - 传感器失效 - 操作员误操作 - 电源波动 - 软件bug

完整示例: 输液泵过量给药

故障树图

                    输液泵过量给药
                    (流速>设定值10%)
                          |
                       ┌──┴──┐
                       │ OR  │
                       └──┬──┘
          ┌──────────────┼──────────────┐
    流速控制失效    流速测量失效    流速设定错误
          |              |              |
       ┌──┴──┐        ┌──┴──┐       ┌──┴──┐
       │ OR  │        │ OR  │       │ OR  │
       └──┬──┘        └──┬──┘       └──┬──┘
      ┌───┼───┐      ┌───┼───┐     ┌───┼───┐
    泵   阀门 控制   传感器 A/D   软件  用户  显示
   故障  故障  器    失效  转换   错误  误操  错误
              故障        失效         作
    ○    ○    ○      ○     ○     ○    ○    ○

基本事件概率

基本事件 描述 概率 数据来源
E1 泵故障 1×10^-4 可靠性数据
E2 阀门故障 5×10^-5 供应商数据
E3 控制器故障 2×10^-4 测试数据
E4 传感器失效 3×10^-4 历史数据
E5 A/D转换失效 1×10^-5 组件规格
E6 软件错误 1×10^-3 缺陷密度估计
E7 用户误操作 5×10^-3 可用性测试
E8 显示错误 1×10^-4 测试数据

定性分析

最小割集(Minimal Cut Set)

定义: 导致顶事件发生的最小基本事件组合

意义: - 识别关键失效路径 - 找出单点失效 - 指导风险控制

识别方法:

1. 布尔代数法

将故障树转换为布尔表达式:

顶事件 = (E1 + E2 + E3) + (E4 + E5) + (E6 + E7 + E8)

展开:

= E1 + E2 + E3 + E4 + E5 + E6 + E7 + E8

最小割集: - {E1}: 泵故障 - {E2}: 阀门故障 - {E3}: 控制器故障 - {E4}: 传感器失效 - {E5}: A/D转换失效 - {E6}: 软件错误 - {E7}: 用户误操作 - {E8}: 显示错误

分析: 所有都是单点失效,系统没有冗余!

2. 自底向上法

从基本事件开始,逐层向上: 1. 识别所有基本事件 2. 通过逻辑门组合 3. 简化得到最小割集

最小路集(Minimal Path Set)

定义: 防止顶事件发生的最小基本事件组合

意义: - 识别关键保护措施 - 评估系统可靠性 - 指导冗余设计

识别方法: 1. 将故障树转换为成功树(所有逻辑门取反) 2. 识别成功树的最小割集 3. 即为原故障树的最小路集

结构重要度

定义: 基本事件对顶事件的结构贡献

计算: 包含该事件的最小割集数量

示例: - E1出现在1个最小割集中 - E2出现在1个最小割集中 - ... - 所有事件结构重要度相同

应用: 识别关键组件

定量分析

顶事件概率计算

方法1: 最小割集法

公式: P(顶事件) ≈ Σ P(最小割集i)

对于单点失效:

P(顶事件) = P(E1) + P(E2) + ... + P(E8)
          = 1×10^-4 + 5×10^-5 + 2×10^-4 + 3×10^-4 
            + 1×10^-5 + 1×10^-3 + 5×10^-3 + 1×10^-4
          = 6.76×10^-3
          ≈ 0.68%

方法2: 布尔代数法

对于OR门: P(A+B) = P(A) + P(B) - P(A)×P(B)

对于AND门: P(A×B) = P(A) × P(B)

方法3: 蒙特卡洛模拟

适用于复杂故障树: 1. 随机生成基本事件状态 2. 计算顶事件状态 3. 重复多次 4. 统计顶事件发生概率

重要度分析

1. 概率重要度(Probabilistic Importance)

定义: 基本事件概率变化对顶事件概率的影响

计算:

I_P(i) = ∂P(顶事件) / ∂P(E_i)

示例: - I_P(E7) = 1 (用户误操作,概率最高) - I_P(E6) = 1 (软件错误,概率次高)

应用: 识别对系统可靠性影响最大的事件

2. 关键重要度(Criticality Importance)

定义: 基本事件对顶事件概率的相对贡献

计算:

I_C(i) = P(E_i) × I_P(i) / P(顶事件)

示例:

I_C(E7) = (5×10^-3 × 1) / 6.76×10^-3 = 0.74 (74%)
I_C(E6) = (1×10^-3 × 1) / 6.76×10^-3 = 0.15 (15%)

解释: 用户误操作贡献了74%的风险!

应用: 确定风险控制优先级

3. Fussell-Vesely重要度

定义: 包含该事件的最小割集对顶事件概率的贡献

计算:

I_FV(i) = P(顶事件|E_i发生) / P(顶事件)

应用: 评估组件对系统安全的重要性

敏感性分析

目的: 分析基本事件概率不确定性的影响

方法: 1. 改变基本事件概率 2. 重新计算顶事件概率 3. 观察变化

示例:

如果E7(用户误操作)概率降低50%:
P(顶事件) = 6.76×10^-3 - 2.5×10^-3 = 4.26×10^-3
降低37%!

应用: 评估风险控制措施的效果

风险控制应用

基于FTA的风险控制

1. 消除单点失效

问题: 所有基本事件都是单点失效

控制措施: 增加冗余

改进后的故障树:

      过量给药
         |
      ┌──┴──┐
      │ OR  │
      └──┬──┘
    ┌────┼────┐
流速控制  流速测量  流速设定
  失效     失效     错误
    |        |        |
 ┌──┴──┐  ┌──┴──┐  ┌──┴──┐
 │ AND │  │ AND │  │ OR  │
 └──┬──┘  └──┬──┘  └──┬──┘
 ┌──┴──┐  ┌──┴──┐  ┌──┴──┐
主控 备控 传感器 传感器 软件 用户
制器 制器  A     B    错误 误操
失效 失效 失效  失效        作

效果: - 控制失效: P = P(主) × P(备) = 2×10^-4 × 2×10^-4 = 4×10^-8 - 测量失效: P = P(A) × P(B) = 3×10^-4 × 3×10^-4 = 9×10^-8 - 大幅降低风险!

2. 降低关键事件概率

关键事件: E7(用户误操作,贡献74%)

控制措施: - 改进用户界面(防呆设计) - 增加确认步骤 - 提供培训 - 增加警告

目标: 将P(E7)从5×10^-3降低到1×10^-3

效果: 顶事件概率降低约60%

3. 增加检测能力

控制措施: - 增加自检功能 - 实时监控 - 报警系统

效果: 即使失效发生,也能及时发现和处理

FTA工具

手工绘制

工具: - 纸和笔 - 白板 - 绘图软件(Visio, Draw.io)

优点: 简单、直观、适合小型分析

缺点: 难以处理复杂树、难以定量计算

专业FTA软件

商业软件: - Isograph FaultTree+: 功能强大,广泛使用 - ReliaSoft BlockSim: 可靠性分析套件 - PTC Windchill: PLM集成 - Item ToolKit: 安全分析工具

开源软件: - OpenFTA: 免费FTA工具 - SCRAM: 概率风险评估工具

功能: - 图形化编辑 - 自动计算 - 最小割集识别 - 重要度分析 - 敏感性分析 - 报告生成

最佳实践

FTA成功要素

1. 明确定义顶事件 - 具体、可测量 - 有明确边界 - 严重性高

2. 系统化展开 - 逐层分析 - 逻辑清晰 - 完整性检查

3. 正确使用逻辑门 - 理解逻辑关系 - 选择合适的门 - 避免混淆

4. 识别基本事件 - 适当的分析深度 - 有可用数据 - 可以控制

5. 数据质量 - 使用可靠数据 - 记录数据来源 - 考虑不确定性

6. 团队协作 - 跨职能团队 - 专家参与 - 充分讨论

7. 文档化 - 记录假设 - 记录边界条件 - 保持可追溯性

常见错误

错误1: 顶事件定义不清

问题: 顶事件太宽泛或太具体

错误示例: - "设备故障"(太宽泛) - "传感器A的第3个引脚断开"(太具体)

正确示例: - "输液泵过量给药(流速>设定值10%)"

错误2: 逻辑门使用错误

常见错误: - 混淆AND和OR - 忽视时序关系 - 忽视条件依赖

示例:

错误: 使用OR门连接"主电源失效"和"备用电源失效"
正确: 使用AND门(两者都失效才导致电源失效)

错误3: 分析深度不当

问题: 过深或过浅

过深: 分析到螺丝松动、焊点失效 - 数据难以获取 - 分析复杂度过高

过浅: 停在"软件错误" - 无法识别具体原因 - 难以制定控制措施

合适深度: 到可以获取数据和实施控制的层级

错误4: 忽视共因失效

问题: 假设事件独立,实际上有共同原因

示例: - 双传感器都受同一电源影响 - 多个组件都受温度影响

解决: 识别并建模共因失效

错误5: 数据不可靠

问题: 使用不准确或不相关的数据

常见问题: - 使用通用数据而非特定数据 - 忽视使用环境差异 - 数据过时

解决: 使用可靠数据源,记录假设

自测问题

问题1: FTA和FMEA的主要区别是什么?什么时候使用FTA?
答案

主要区别:

特征 FTA FMEA
方向 自顶向下(演绎) 自底向上(归纳)
起点 特定失效事件 所有组件/功能
目的 找出导致特定失效的原因 识别所有可能的失效模式
表示 树形图 表格
逻辑 明确的逻辑门 因果关系
定量 容易 较难

使用FTA的场景:

  1. 分析严重失效事件:
  2. 可能导致死亡或严重伤害
  3. 法规特别关注
  4. 需要深入分析根本原因

  5. 分析复杂系统失效:

  6. 多个组件交互
  7. 系统级失效
  8. 共因失效

  9. 定量可靠性分析:

  10. 计算失效概率
  11. 识别关键路径
  12. 评估冗余设计

  13. 补充FMEA:

  14. FMEA识别高风险项目
  15. FTA深入分析这些项目

建议: 两者结合使用效果最佳

问题2: 什么是最小割集?如何使用最小割集进行风险控制?
答案

最小割集定义: 导致顶事件发生的最小基本事件组合。

特征: - "最小": 移除任何一个事件,顶事件就不会发生 - 每个最小割集代表一条失效路径

示例:

顶事件 = (A AND B) OR C
最小割集: {A,B}, {C}

意义:

  1. 识别单点失效:
  2. 单元素最小割集 = 单点失效
  3. 示例: {C}是单点失效

  4. 评估系统脆弱性:

  5. 最小割集越多,失效路径越多
  6. 最小割集元素越少,系统越脆弱

  7. 计算失效概率:

  8. P(顶事件) ≈ Σ P(最小割集)

风险控制应用:

1. 消除单点失效:

原始: {A}, {B}, {C}  (3个单点失效)

控制: 增加冗余
改进: {A,A'}, {B,B'}, {C,C'}  (无单点失效)

2. 增加割集元素:

原始: {A}  (单点失效)

控制: 增加保护措施B
改进: {A,B}  (需要两个都失效)

3. 降低割集概率: - 提高组件可靠性 - 降低基本事件概率

4. 优先处理: - 优先处理单元素割集 - 优先处理高概率割集 - 优先处理包含关键事件的割集

问题3: 如何计算故障树的顶事件概率?
答案

方法1: 最小割集法

步骤: 1. 识别所有最小割集 2. 计算每个最小割集的概率 3. 求和(近似)

公式:

P(顶事件) ≈ Σ P(最小割集i)

对于割集{A,B,C}:
P({A,B,C}) = P(A) × P(B) × P(C)

示例:

最小割集: {A,B}, {C}
P(A) = 0.01, P(B) = 0.02, P(C) = 0.05

P({A,B}) = 0.01 × 0.02 = 0.0002
P({C}) = 0.05

P(顶事件) ≈ 0.0002 + 0.05 = 0.0502

注意: 这是近似值,假设割集之间独立


方法2: 布尔代数法

步骤: 1. 将故障树转换为布尔表达式 2. 使用布尔代数规则计算

规则: - OR门: P(A+B) = P(A) + P(B) - P(A)×P(B) - AND门: P(A×B) = P(A) × P(B)

示例:

顶事件 = (A AND B) OR C

P(A AND B) = P(A) × P(B) = 0.01 × 0.02 = 0.0002

P(顶事件) = P((A AND B) OR C)
          = P(A AND B) + P(C) - P(A AND B)×P(C)
          = 0.0002 + 0.05 - 0.0002×0.05
          = 0.050190

注意: 这是精确值


方法3: 蒙特卡洛模拟

步骤: 1. 为每个基本事件随机生成状态(发生/不发生) 2. 根据逻辑门计算顶事件状态 3. 重复N次(如10000次) 4. 统计顶事件发生次数 5. P(顶事件) = 发生次数 / N

优点: - 适用于复杂故障树 - 可以处理相关性 - 可以处理时序

缺点: - 需要大量计算 - 结果有随机性


选择方法: - 简单树: 布尔代数法(精确) - 中等复杂: 最小割集法(快速近似) - 复杂树: 蒙特卡洛模拟或专业软件

问题4: 什么是重要度分析?有哪些类型的重要度?
答案

重要度分析目的: 识别对系统可靠性/安全性最重要的组件,指导风险控制优先级。

主要类型:

1. 结构重要度(Structural Importance)

定义: 基本事件在故障树结构中的重要性

计算: 包含该事件的最小割集数量

示例:

最小割集: {A,B}, {A,C}, {D}

I_S(A) = 2  (出现在2个割集中)
I_S(B) = 1
I_S(C) = 1
I_S(D) = 1

A最重要

特点: 只考虑结构,不考虑概率


2. 概率重要度(Probabilistic Importance)

定义: 基本事件概率变化对顶事件概率的影响

计算:

I_P(i) = ∂P(顶事件) / ∂P(E_i)

物理意义: P(E_i)增加1%,P(顶事件)增加多少

应用: 识别对系统可靠性影响最大的事件


3. 关键重要度(Criticality Importance)

定义: 基本事件对顶事件概率的相对贡献

计算:

I_C(i) = [P(E_i) × I_P(i)] / P(顶事件)

物理意义: 该事件贡献了多少百分比的风险

示例:

P(E1) = 0.01, I_P(E1) = 1, P(顶事件) = 0.05
I_C(E1) = (0.01 × 1) / 0.05 = 0.2 = 20%

E1贡献了20%的风险

应用: 确定风险控制优先级


4. Fussell-Vesely重要度

定义: 包含该事件的最小割集对顶事件概率的贡献

计算:

I_FV(i) = P(顶事件|E_i发生) / P(顶事件)

物理意义: 如果E_i发生,顶事件概率增加多少倍

应用: 评估组件对系统安全的重要性


如何使用:

  1. 识别关键组件:
  2. 高重要度 = 关键组件
  3. 优先改进这些组件

  4. 分配资源:

  5. 根据重要度分配改进资源
  6. 高重要度组件投入更多

  7. 评估改进效果:

  8. 改进高重要度组件效果最好
  9. 改进低重要度组件效果有限

  10. 维护优先级:

  11. 高重要度组件更频繁维护
  12. 更严格的质量控制
问题5: FTA分析中常见的错误有哪些?如何避免?
答案

常见错误和避免方法:

1. 顶事件定义不清

错误: - 太宽泛: "设备故障" - 太具体: "传感器A的第3个引脚断开" - 不可测量: "性能下降"

正确: - 具体: "输液泵过量给药" - 可测量: "流速>设定值10%" - 有边界: "正常使用条件下"

避免方法: - 明确定义顶事件 - 定义边界条件 - 团队达成共识


2. 逻辑门使用错误

错误: - 混淆AND和OR - 忽视时序关系 - 忽视条件依赖

示例:

错误: 
"电源失效" = "主电源失效" OR "备用电源失效"

正确:
"电源失效" = "主电源失效" AND "备用电源失效"
(两者都失效才导致电源失效)

避免方法: - 理解逻辑关系 - 仔细分析因果 - 团队审查


3. 分析深度不当

过深: - 分析到螺丝松动、焊点失效 - 数据难以获取 - 分析复杂度过高

过浅: - 停在"软件错误" - 无法识别具体原因 - 难以制定控制措施

合适深度: - 到可以获取数据的层级 - 到可以实施控制的层级 - 到基本事件层级

避免方法: - 明确分析目的 - 考虑数据可用性 - 考虑控制可行性


4. 忽视共因失效

错误: - 假设事件独立 - 忽视共同原因

示例:

错误:
双传感器独立失效
P(两者都失效) = P(A) × P(B)

实际:
两者共用同一电源
电源失效导致两者都失效

避免方法: - 识别共同原因 - 建模共因失效 - 使用β因子模型


5. 数据不可靠

错误: - 使用通用数据 - 忽视环境差异 - 数据过时 - 无数据来源

避免方法: - 使用特定数据 - 考虑使用环境 - 使用最新数据 - 记录数据来源 - 进行敏感性分析


6. 忽视人为因素

错误: - 只分析硬件/软件失效 - 忽视操作错误 - 忽视维护错误

避免方法: - 包含人为错误 - 考虑误用场景 - 参考可用性测试


7. 文档不完整

错误: - 无假设记录 - 无边界条件 - 无数据来源 - 无审查记录

避免方法: - 完整文档化 - 记录所有假设 - 记录数据来源 - 保持可追溯性

相关资源

参考文献

  1. IEC 61025:2006 - Fault tree analysis (FTA)
  2. NASA Fault Tree Handbook with Aerospace Applications
  3. Vesely, W.E., et al. (1981). Fault Tree Handbook. NUREG-0492
  4. Stamatelatos, M., et al. (2002). Fault Tree Handbook with Aerospace Applications
  5. ISO 14971:2019 - Medical devices - Application of risk management to medical devices
  6. Ericson, C.A. (2005). Hazard Analysis Techniques for System Safety

💬 讨论区

欢迎在这里分享您的想法、提出问题或参与讨论。需要 GitHub 账号登录。