3. 故障树符号与术语：顶事件、底事件、中间事件、逻辑门（与门、或门、非门）
好，咱们正式开始聊故障树分析的核心——符号和术语。说实话，我刚入行那会儿，看着故障树图觉得挺唬人，又是三角又是圆圈的。后来自己动手画了几次，才发现这东西说白了就是一套「逻辑语言」。你只要搞懂几个基本符号，剩下的就是搭积木。
3.1 三个核心事件：顶、底、中间
故障树里的事件，我习惯把它们分成三类。你想想看，就像一棵真树——有树根、树干、树枝。咱们的故障树也一样。
3.1.1 顶事件（Top Event）
顶事件就是最不想看到的结果。 在BMS里，最常见的顶事件就是「电池起火」或者「系统失效」。它画在故障树的最顶端，用一个矩形框表示。
我个人习惯： 顶事件一定要定义得足够具体。别写「电池出问题」，要写「BMS无法切断充电回路导致过充」。越具体，后面的分析越容易。
我在项目中遇到过一件事。有次做DFMEA，团队把顶事件写成「电池损坏」。结果大家吵了半天——是容量衰减算损坏？还是内阻变大算损坏？后来改成「电芯电压超过4.25V且持续5秒以上」，问题一下子就清晰了。
3.1.2 底事件（Basic Event）
底事件就是最根本的原因。 它不再往下分解了。画成一个圆圈。比如「采样电阻虚焊」、「软件定时器溢出」、「连接器端子氧化」。
底事件有个特点——它必须是可测量、可验证的。你不能写「芯片质量不好」，这太模糊了。要写「AFE芯片的ADC参考电压漂移超过±5mV」。
避坑指南： 我曾经见过一个故障树，底事件写的是「操作人员疏忽」。这其实不是底事件——它还能往下分解：为什么疏忽？培训不够？疲劳？流程缺失？真正的底事件应该是「未执行双人复核流程」这类具体动作。
3.1.3 中间事件（Intermediate Event）
中间事件就是「中间状态」。它上面连着顶事件，下面连着底事件。画成一个矩形框，但位置在中间。比如「采样电路异常」——它可能是由「电阻虚焊」或「PCB漏电」导致的，同时它本身又会导致「电压检测错误」这个更高层的事件。
说白了，中间事件就是逻辑链条里的「中转站」。我一般用它来分组——把相关的底事件归到一个中间事件下面，这样图看起来清爽。
3.2 逻辑门：故障树的「骨架」
事件之间怎么连接？靠逻辑门。这是故障树最精妙的地方。你想想看，现实中的故障很少是单一原因——往往是几个条件凑在一起才出事。逻辑门就是用来描述这种「凑在一起」的关系。
3.2.1 与门（AND Gate）
与门表示：所有输入事件同时发生，输出事件才发生。 画成一个半圆底的门形，有点像拱门。
举个例子：BMS的「过充保护失效」这个顶事件，下面可能连着两个中间事件——「电压检测错误」与「MOSFET无法关断」。只有两个同时发生，才会导致过充保护失效。缺一个都不行。
我的经验： 与门是咱们做可靠性设计的好朋友。为什么？因为只要切断其中一条路径，整个故障就不会发生。比如你给电压检测加冗余，或者给MOSFET加备份，都能打破与门条件。
3.2.2 或门（OR Gate）
或门表示：只要有一个输入事件发生，输出事件就发生。 画成一个尖底的门形，有点像倒过来的V。
或门是最常见的。比如「通信中断」这个中间事件，下面可能是「CAN总线断路」或「控制器死机」或「终端电阻脱落」。任何一个发生，通信就断了。
说实话，或门是咱们最头疼的。因为它意味着系统很脆弱——任何一个薄弱环节都能导致失效。我在做BMS故障树时，看到或门就会特别警惕，会问自己：能不能把这个或门变成与门？
注意： 或门越多，系统越不可靠。这是故障树分析里的一条铁律。如果你发现某个顶事件下面全是或门，那这个设计大概率有问题。
3.2.3 非门（NOT Gate / Inhibit Gate）
非门表示：条件不满足时，输出才发生。 画成一个三角形加一个小圆圈。在故障树里，非门用得相对少一些，但很关键。
举个例子：「均衡功能失效」这个事件，下面可能有一个条件——「电芯压差超过50mV」且「均衡使能信号为低电平」。这里的「均衡使能信号为低电平」就可以用非门来表达——它表示「应该为高电平的时候，它却是低电平」。
我记得有次分析一个BMS的休眠异常问题。故障树里用了一个非门——「唤醒信号有效时，MCU未退出休眠」。这个非门帮我们锁定了问题：不是唤醒信号没来，而是MCU的唤醒中断配置错了。
3.3 符号速查表
嗯，这里我整理了一个表格。你画图的时候可以对照着看。
| 符号 | 名称 | 含义 | BMS应用示例 |
|---|---|---|---|
| 矩形 | 顶事件/中间事件 | 需要进一步分解的事件 | 「电池过充」、「采样异常」 |
| 圆形 | 底事件 | 最基本的原因，不再分解 | 「电阻虚焊」、「固件Bug」 |
| 半圆门 | 与门 | 所有输入同时发生才输出 | 「电压高」且「电流大」才触发保护 |
| 尖底门 | 或门 | 任一输入发生即输出 | 「温度高」或「电流大」都报警 |
| 三角+圆圈 | 非门 | 条件不满足时输出 | 「使能信号应为高但实际为低」 |
3.4 画图时的一个小习惯
我个人画故障树时，会先用便签纸把底事件写出来——一个一个的，像写卡片一样。然后问自己：这些底事件之间是什么关系？是「只要一个就够」还是「必须凑齐」？
如果是「只要一个就够」，用或门连起来。
如果是「必须凑齐」，用与门连起来。
如果某个条件需要取反，加个非门。
你想想看，这样画出来的故障树，逻辑是自洽的。不会出现「明明两个原因都要满足，却画了个或门」这种低级错误。
一个小技巧： 画完故障树后，从底事件往上走一遍。假设每个底事件都发生了，看看顶事件会不会发生。如果不会，说明你的逻辑门用错了。这个方法我每次都用，至少帮我发现了3次逻辑错误。
3.5 总结一下
故障树的符号其实不多。顶事件、底事件、中间事件，加上与门、或门、非门，就这些。但就是这几个符号，能把一个复杂的BMS失效机理梳理得清清楚楚。
我记得刚学故障树时，师傅跟我说了一句话，我一直记着：「故障树不是画给别人看的，是画给自己想明白的。」 你只要把符号用对了，逻辑理清了，后面的定量分析、定性分析都是水到渠成的事。
下一章咱们聊聊怎么建树——从顶事件开始，一层一层往下分解。到时候我会拿一个BMS的实际案例，手把手带你走一遍。