第4章故障树建树步骤

第4章：故障树建树步骤——顶事件、边界条件、逐层分解、最小割集求解

好，咱们直接进入正题。故障树分析，说白了就是一张逻辑图。你把最不想看到的事故放在最顶上，然后一层层往下问「为什么会发生」。今天我就把这四个步骤掰开揉碎了讲清楚。

4.1 确定顶事件——选对「靶子」

顶事件就是故障树的根。它必须是一个明确的、可测量的故障状态。我见过不少新手一上来就写「BMS失效」，这太模糊了——BMS失效到底是过充保护没动作？还是SOC估算不准？你得把范围收窄。

顶事件选取原则：

唯一性：一次只分析一个故障模式
可观测性：顶事件必须能被检测到（比如电压超限、温度报警）
可追溯性：顶事件的原因能向下分解到基本事件

举个例子。我在做某款48V轻混系统时，顶事件定为「充电过程中电池单体电压超过4.25V」。这个事件很具体——超过4.25V就是过充，后果是析锂甚至热失控。你想想看，如果写成「充电异常」，下面能分解出几十种原因，根本没法聚焦。

4.2 设定边界条件——别让树长成森林

边界条件就是给故障树画个圈。哪些因素考虑，哪些不考虑，一开始就要说清楚。我习惯把边界条件分成三类：

边界类型	说明	示例
系统边界	分析范围限定在BMS内部还是包含电池包、充电机	只考虑BMS硬件电路，不考虑充电桩故障
环境边界	温度、湿度、振动等外部条件	假设环境温度在-20°C~60°C范围内
初始状态	系统在故障发生前的状态	假设电池初始SOC为50%，且无历史故障

注意：边界条件设得太宽，故障树会膨胀到无法管理；设得太窄，又会漏掉关键原因。我曾经因为没把「线束接触不良」纳入边界，结果现场复现故障时查了三天才找到问题。

4.3 逐层分解——从顶到底的逻辑拆解

这一步是核心。从顶事件开始，用「与门」和「或门」把原因一层层展开。我的经验是：每层只问一个「为什么」。

比如顶事件是「过充保护失效」。第一层分解：

要么是「硬件检测电路失效」
要么是「软件保护逻辑未触发」
要么是「执行器件（如MOSFET）无法关断」

这三个原因用「或门」连接——任何一个发生，顶事件就发生。然后继续往下拆：

「硬件检测电路失效」可以拆成「采样电阻开路」和「ADC通道损坏」
「软件保护逻辑未触发」可以拆成「MCU死机」和「看门狗未复位」

嗯，这里要注意：分解到基本事件（底事件）就停。基本事件是那些你无法再往下拆、或者没必要再拆的事件，比如「电阻开路」「电容短路」。我一般分解到元器件级别就够了，再往下就是物理失效机理了，那是可靠性工程师的事。

4.4 最小割集求解——找到最脆弱的链条

割集，就是能让顶事件发生的一组底事件。最小割集，就是去掉任何一个底事件后，顶事件就不再发生的割集。说白了，最小割集就是系统的「命门」。

求解方法有两种：

4.4.1 下行法（手工计算）

从顶事件往下走，遇到「或门」就把输入事件分行写，遇到「与门」就把输入事件同行写。最后每一行就是一个割集，再合并重复项、去掉非最小项。

示例（简化）：
顶事件 = (A 或 B) 与 (C 或 D)

步骤：
1. 遇到「与门」，同行写：A或B, C或D
2. 展开「或门」：
   - 第一组：A, C
   - 第二组：A, D
   - 第三组：B, C
   - 第四组：B, D
3. 检查是否最小：如果A和B是同一类故障，可能合并

4.4.2 上行法（布尔代数化简）

从底事件往上写布尔表达式，用吸收律、幂等律化简。我更喜欢用下行法，因为直观，不容易出错。

我的习惯：对于超过20个底事件的故障树，我会用软件工具（比如Isograph、CAFTA）自动求解。手工算到第3层就很容易漏项。但如果是10个底事件以内，手算反而更快，还能帮你理解逻辑结构。

4.5 实战案例：BMS过充保护故障树

咱们看一个完整的例子。顶事件：「充电过程中电池电压超过4.25V且保护未动作」。

顶事件：过充保护失效
   |
   +-- 或门 --
   |         |
   检测失效   执行失效
   |         |
   +-- 或门--+-- 或门--
   |    |    |    |
  采样   ADC  MOSFET 保险丝
  电阻   损坏  短路   误熔断
  开路

这个树有4个底事件。最小割集是：

{采样电阻开路}
{ADC损坏}
{MOSFET短路}
{保险丝误熔断}

你看，每个底事件单独就能导致顶事件发生。这说明系统单点故障风险很高。我当时给客户的建议就是：在采样路径上加冗余设计，或者增加二级保护（比如硬件比较器直接触发关断）。

4.6 建树时的常见坑

我曾经踩过的坑：

把「正常状态」当成底事件——比如「MCU正常工作」不是故障事件，不能出现在故障树里
忽略共因失效——两个看似独立的底事件，可能因为同一颗电源芯片故障而同时发生
分解层次不一致——有的分支拆到元器件，有的分支只拆到功能模块，导致割集无法比较

说白了，故障树建得好不好，关键看你能不能把「模糊的担心」变成「具体的、可验证的底事件」。我每次建完树都会问自己一句：如果这个底事件发生了，我能通过测试复现吗？如果答案是否定的，说明分解得还不够细。

本章小结：

顶事件要具体、可测量
边界条件要提前约定，别事后补
逐层分解时每层只问一个「为什么」
最小割集告诉你系统最脆弱的点在哪

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录