3. 故障树符号与术语：顶事件、中间事件、底事件、逻辑门详解
各位工程师朋友，大家好。我是老张，在储能系统可靠性这个行当摸爬滚打了十几年。今天咱们来聊聊故障树分析（FTA）里最基础、也最绕不开的东西——符号和术语。
说实话，我刚入行那会儿，看着故障树图也是一头雾水。什么顶事件、底事件，跟门、或门，感觉像在看天书。后来自己动手画了几次，才慢慢摸到门道。说白了，故障树就是一套“逻辑语言”，用来描述系统是怎么出毛病的。
咱们今天就把这套语言拆开揉碎了讲。你想想看，如果连字母都不认识，怎么读文章？所以，先把这些“字母”搞明白。
3.1 事件符号：顶事件、中间事件、底事件
故障树里，所有“发生了什么”都叫事件。但事件和事件不一样，有主次之分。
3.1.1 顶事件（Top Event）
定义： 系统最不希望发生的、我们最关心的故障状态。它是故障树的根，也是分析的起点。
特点：
- 只有一个顶事件。
- 通常是系统级的、后果严重的故障。比如：“储能系统起火”、“BMS通信中断”、“PCS停机”。
- 顶事件必须定义得非常清晰、具体。不能含糊。
我个人习惯： 定义顶事件时，我会问自己三个问题：
- 这个故障发生后，系统会怎样？
- 它有没有明确的边界？（比如是整站起火，还是单个模组热失控？）
- 我能不能通过往下分解，找到根本原因？
如果答案都是肯定的，那这个顶事件就定对了。
3.1.2 中间事件（Intermediate Event）
定义： 位于顶事件和底事件之间的事件。它既是上一层事件的原因，又是下一层事件的结果。
特点：
- 需要继续往下分解，直到找到根本原因。
- 通常用矩形框表示。
- 比如：“电池模组过温”就是一个中间事件。它可能是“BMS失效”和“冷却系统故障”共同导致的。
我记得有一次做项目，团队里有人把“电池管理系统失效”直接当成了底事件。我说不行，BMS失效太笼统了，你得继续往下挖——是电压采样芯片坏了？还是通信线束断了？还是软件逻辑跑飞了？你看，这一挖，就挖出了好几个中间事件。
3.1.3 底事件（Basic Event）
定义： 故障树最底层的事件。它不需要再往下分解了，因为我们已经找到了根本原因。
特点：
- 是故障树的“叶子节点”。
- 通常用圆形框表示。
- 必须是可测量的、可验证的。比如：“继电器触点粘连”、“保险丝熔断”、“温度传感器开路”。
避坑指南： 我曾经见过有人把“人为误操作”当成底事件。这其实不对。人为误操作还可以继续分解——是培训不到位？还是操作手册写错了？还是人机界面设计反人类？真正的底事件，应该是“操作员未按SOP步骤3执行”这种具体行为。
3.2 逻辑门符号：与门、或门、非门
事件之间怎么连接？靠逻辑门。逻辑门决定了故障传播的“规则”。
3.2.1 与门（AND Gate）
符号： 像一个拱门，底部是平的，顶部是弧形的。
逻辑： 只有所有输入事件都发生时，输出事件才发生。
数学表达： 输出 = A ∩ B ∩ C ...
实际案例： 储能系统发生“热失控”这个顶事件，可能需要同时满足三个条件：
- 电池内部短路（底事件1）
- BMS未检测到异常（底事件2）
- 消防系统未启动（底事件3）
这三个条件缺一不可。这就是与门的关系。
我的经验： 与门在故障树里其实是个“好消息”。因为只要你能切断其中任何一个输入，就能阻止故障发生。所以，设计冗余系统时，我们特别喜欢用与门——多个条件同时满足才出事，可靠性自然就高了。
3.2.2 或门（OR Gate）
符号： 像一个尖顶的拱门，底部是平的，顶部是尖的。
逻辑： 只要有一个输入事件发生，输出事件就会发生。
数学表达： 输出 = A ∪ B ∪ C ...
实际案例： “PCS停机”这个中间事件，可能由以下任一原因导致：
- 电网过压（底事件1）
- IGBT模块损坏（底事件2）
- 控制板电源失效（底事件3）
任何一个发生，PCS就停了。这就是或门。
注意： 或门是故障树的“噩梦”。因为输入越多，系统越脆弱。你想想看，一个系统有10个或门输入，那任何一个出问题，系统就挂了。所以，设计时我们要尽量减少或门的输入数量，或者给关键路径增加冗余。
3.2.3 非门（NOT Gate / Inhibit Gate）
符号： 通常用一个三角形加一个小圆圈表示。在故障树里，非门也叫“禁止门”。
逻辑： 输出事件是输入事件的相反状态。或者说，当条件不满足时，输出才发生。
实际案例： “消防系统误喷”这个事件，可能发生在“火灾探测器未报警”且“灭火装置启动”的情况下。这里的“未报警”就是非门的作用。
说实话，非门在故障树里用得相对少一些。但一旦用上，往往都是关键点。比如，安全联锁系统里，经常用非门来表达“当安全条件不满足时，禁止设备启动”。
3.3 其他常用符号
除了上面这些，还有几个符号你也会经常见到：
| 符号名称 | 图形 | 说明 |
|---|---|---|
| 未展开事件 | 菱形 | 表示暂时不往下分解的事件。可能是信息不足，或者影响不大。 |
| 条件事件 | 椭圆形 | 表示一个特定的条件或状态。通常与禁止门配合使用。 |
| 转移符号 | 三角形 | 用于连接不同页面的故障树。避免一张图画不下。 |
3.4 知识体系结构图
下面这张图，把咱们今天讲的核心内容串起来了。你可以把它当成一张“地图”，以后画故障树时，对照着看就行。
3.5 小结与避坑指南
好了，咱们今天把故障树的“字母表”过了一遍。最后，我总结几个容易踩的坑：
- 顶事件定义太宽泛： 比如“系统故障”这种，没法往下分析。一定要具体到“什么系统、什么故障、什么后果”。
- 底事件挖得不够深： 我见过有人把“传感器故障”当底事件。但传感器故障有很多种——是漂移了？还是彻底坏了？还是线断了？继续挖！
- 逻辑门用错： 与门和或门搞混，是新手最常见的错误。记住：与门是“一个都不能少”，或门是“一个就够了”。
- 忽略非门： 非门虽然用得少，但在安全联锁、互锁逻辑里非常关键。别把它忘了。
一个小技巧： 画故障树时，我习惯先用便签纸把事件写下来，然后在地上摆一摆，用箭头连一连。等逻辑关系理清了，再上软件画正式的图。这样不容易出错。
嗯，今天就到这儿。这些符号和术语，是故障树分析的“砖瓦”。砖瓦不牢，房子就盖不稳。下一节，咱们会把这些砖瓦砌起来，看看怎么一步步构建一棵完整的故障树。
公众号:蓝海资料掘金营，微信deep3321