第二节 故障树基本符号与逻辑门
各位工程师朋友，咱们今天聊聊故障树分析里最基础的东西——符号和逻辑门。说实话，我刚入行那会儿，觉得这些符号不就是些圈圈框框嘛，有啥好学的？直到有一次在项目评审会上，我把“与门”和“或门”搞混了，被老专家当场指出来……那场面，至今记忆犹新。
所以啊，别小看这些基础符号。它们是故障树的“字母”和“语法”。你写不好字母，就写不出好文章。同样，你搞不清这些符号，画出来的故障树就是一团乱麻。
2.1 事件符号：三个核心角色
故障树里的事件，说白了就三种角色：顶事件、中间事件、底事件。我习惯把它们比作一个项目的三层结构——老板、经理、干活的人。
2.1.1 顶事件（Top Event）
符号：矩形框，里面写事件描述。
定义：系统最不希望发生的故障状态。它是整棵树的根，所有分析都围绕它展开。
特点：
- 只有一个顶事件。一棵树只能有一个根。
- 通常是系统级的失效模式。比如“BMS无法正常上电”、“电池包热失控”。
- 必须可分解。不能分解的事件不适合做顶事件。
我个人的经验：选顶事件时，别太宽泛也别太窄。比如“BMS故障”就太宽了，没法分析。我建议拆成“通信故障”、“采样故障”、“保护动作故障”等具体事件，每个单独建树。
2.1.2 中间事件（Intermediate Event）
符号：矩形框，和顶事件一样。区别在于位置——它不在树根，在树干上。
定义：介于顶事件和底事件之间的事件。它既是上一层的原因，又是下一层的结果。
举个例子：顶事件是“电池过充”，中间事件可能是“充电MOS管无法关断”。这个事件往下还能继续分解。
避坑指南：我曾经见过有人把中间事件画成菱形框，这是不对的。菱形框是未展开事件，表示“到此为止，不再往下分析”。中间事件必须能继续分解，所以用矩形框。
2.1.3 底事件（Basic Event）
符号：圆形框。
定义：故障树的最底层原因。它不需要再往下分解了。
底事件有两种：
- 基本事件：有足够数据（如失效率）的事件。比如“电阻开路”、“MCU引脚虚焊”。
- 未探明事件：菱形框表示。比如“软件逻辑错误”——你知道它会发生，但没法给个具体的失效率。
嗯，这里要注意：底事件必须是独立的、可量化的。如果你写“环境温度过高”，那得问自己——高到什么程度？有没有概率数据？没有的话，建议用菱形框。
2.2 逻辑门：故障树的“连接词”
事件之间怎么连接？靠逻辑门。说白了，逻辑门就是告诉你“这些原因怎么组合才会导致上面的结果”。
2.2.1 与门（AND Gate）
符号：一个拱形门，下面有多个输入，上面一个输出。
逻辑：所有输入事件都发生，输出事件才发生。
数学表达：P(输出) = P(A) × P(B) × P(C) ……
实际案例：“BMS无法检测到过流”这个顶事件，下面可能是“电流传感器故障”与“备用传感器也故障”。两个都坏了，才出问题。一个坏了另一个还能顶上去。
我遇到过的情况：某款BMS的过流保护总是误动作。一查故障树，发现设计者把“电流采样值超过阈值”和“持续时间超过延时”用或门连起来了。实际上应该是与门——两个条件同时满足才触发保护。这就是逻辑门用错了的典型。
2.2.2 或门（OR Gate）
符号：一个拱形门，底部是弧线，和与门有点像但不同。
逻辑：只要有一个输入事件发生，输出事件就发生。
数学表达：P(输出) = P(A) + P(B) + P(C) - 重叠部分
实际案例：“电池包通信中断”这个顶事件，下面可能是“CAN总线断路”或“主控芯片死机”或“隔离芯片损坏”。任何一个发生，通信就断了。
注意：或门会让故障树快速膨胀。因为每加一个或门，系统的失效概率就增加一大截。我见过有人把十几个底事件全用或门连起来，结果算出来失效率高得离谱——其实很多事件是互斥的，不能简单相加。
2.2.3 非门（NOT Gate / Inhibit Gate）
符号：三角形加一个小圆圈，或者用“禁止门”符号。
逻辑：输入事件不发生，输出事件才发生。或者说，输入事件发生时，输出被禁止。
实际案例：“BMS进入休眠模式”这个事件，需要“唤醒信号消失”且“无故障状态”。这里的“无故障状态”就可以用非门——故障发生 → 非门输出为假 → 休眠条件不满足。
我个人习惯：非门在BMS故障树里用得不多，但一旦用到就很关键。比如安全相关的“禁止充电”逻辑，经常需要非门来表达“条件不满足时触发保护”。
2.2.4 表决门（Voting Gate / k-out-of-n Gate）
符号：一个六边形或椭圆形，里面写“k/n”。
逻辑：n个输入事件中，至少有k个发生，输出事件才发生。
常见形式：
- 2/3表决：三个传感器中至少两个报故障，才判定为真故障。
- 1/2表决：两个通道中至少一个正常，系统就能工作（相当于或门）。
- 2/2表决：两个通道都必须正常（相当于与门）。
实际案例：BMS的电压采样经常用“2/3表决”。三个采样芯片各自测量同一节电芯的电压。如果两个芯片都报“电压异常”，系统才触发保护。为什么？防止单个芯片误报导致误动作。
避坑指南：我曾经在项目里用2/3表决门，但忘了考虑“共因失效”。三个芯片虽然独立采样，但供电电源是同一个。如果电源出问题，三个芯片同时失效——那2/3表决就形同虚设了。所以用表决门时，一定要检查输入事件之间是否真的独立。
2.3 知识体系总览
下面这张图，是我自己整理的故障树符号与逻辑门的关系图。你一看就明白：
2.4 符号与逻辑门速查表
为了方便你快速查阅，我整理了一张表：
| 符号名称 | 图形 | 逻辑含义 | BMS应用举例 |
|---|---|---|---|
| 顶事件 | 矩形框 | 系统最不希望发生的故障 | 电池包热失控 |
| 中间事件 | 矩形框 | 可继续分解的故障 | 采样芯片通信失败 |
| 底事件 | 圆形框 | 最小原因，不再分解 | 电阻开路、焊点脱落 |
| 与门 | 拱形门 | 所有输入都发生才输出 | 主备传感器同时故障 |
| 或门 | 拱形门（弧底） | 任一输入发生即输出 | 任一保护通道失效 |
| 非门 | 三角+圆圈 | 输入不发生才输出 | 无故障时才允许休眠 |
| 表决门 | 六边形 k/n | n个中至少k个发生 | 2/3电压采样异常 |
2.5 实战中的几个提醒
最后，说几个我踩过的坑，你注意避开：
- 别把“与门”和“或门”搞反。我见过最离谱的案例——一个BMS的过温保护，设计者把“温度超过阈值”和“持续时间超过延时”用或门连起来。结果温度一波动就触发保护，天天误报警。其实应该是与门：两个条件同时满足才触发。
- 非门慎用。非门会让故障树的分析变得复杂，尤其是做定量计算时。能用其他方式表达，尽量不用非门。
- 表决门要检查独立性。前面说了，共因失效是表决门的头号杀手。用表决门前，先问自己：这些输入事件真的独立吗？
- 底事件要可量化。如果你写“环境恶劣”作为底事件，那后续的定量分析就没法做了。尽量把底事件落到具体的元器件失效或具体的事件上。
总结一下：故障树的符号和逻辑门，说白了就是一套“故障语言”。顶事件是你要解决的问题，中间事件是分析路径，底事件是根本原因。与门、或门、非门、表决门，就是告诉你这些原因怎么组合。把这套语言学好了，后面的建树、定性分析、定量计算，才能顺风顺水。
公众号:蓝海资料掘金营，微信deep3321