2. 基本概念与符号：顶事件、底事件、中间事件、逻辑门符号
各位工程师朋友，咱们今天聊聊故障树分析里最基础的东西——那些事件和符号。说实话，我刚入行那会儿，觉得这些概念太简单了，不就是几个圈圈框框嘛。直到有一次在高铁信号系统的故障排查中，我因为搞混了中间事件和底事件，画出来的树根本没法用……嗯，从那以后我再也不敢小看这些基础符号了。
2.1 顶事件——故障树的“根”
顶事件，说白了就是咱们最不想看到的结果。它是故障树最顶端的那个事件，是整个分析的起点。你想想看，我们做故障树分析，不就是为了搞清楚“系统为什么会失效”吗？这个“系统失效”就是顶事件。
顶事件的特点：
- 唯一性：一棵故障树只有一个顶事件
- 明确性：必须定义清晰，不能含糊
- 可分解性：能够向下分解为更具体的原因
我在项目中遇到过这样的情况：有人把“信号系统故障”直接当作顶事件。这太笼统了！我建议你定义顶事件时，一定要加上具体场景。比如“列车进站时信号系统未能正确显示允许信号”——这样才够精准。
2.2 底事件——故障树的“叶子”
底事件是故障树最底层的事件。它不能再往下分解了，是导致故障的根本原因。底事件通常分为两类：
| 类型 | 说明 | 举例 |
|---|---|---|
| 基本事件 | 不需要再展开的故障 | 继电器触点氧化、电缆断裂 |
| 未展开事件 | 因信息不足暂不展开 | 外部供电异常（原因待查） |
底事件用圆形符号表示。我个人习惯在画图时，把底事件用不同颜色标注——基本事件用实线圆，未展开事件用虚线圆。这样一眼就能看出哪些是已知的、哪些是待查的。
小技巧：底事件的数量决定了故障树的规模。我一般控制在20-30个底事件以内，太多了分析起来太累，太少了又不够细致。
2.3 中间事件——故障树的“枝干”
中间事件，就是顶事件和底事件之间的那些事件。它既是某个原因的结果，又是更细原因的原因。用矩形符号表示。
举个例子：顶事件是“信号机显示异常”，中间事件可能是“控制电路故障”。而“控制电路故障”又可以分解为“电源模块失效”和“逻辑板卡故障”这两个底事件。
我曾经犯过一个错误：把中间事件画得太多，导致故障树又深又乱。后来我总结了一个原则——中间事件的数量不要超过底事件的一半。这样树的结构才清晰。
2.4 逻辑门符号——连接事件的“桥梁”
逻辑门是故障树的核心。没有它们，事件之间就是孤立的。咱们重点讲三种最常用的门：
2.4.1 与门（AND Gate）
与门的逻辑是：所有输入事件都发生，输出事件才发生。用符号表示就是半圆形，下面带一个弧线。
在信号系统中，与门很常见。比如“联锁系统失效”这个中间事件，需要“联锁计算机故障”且“备用联锁计算机故障”同时发生。这就是典型的与门关系。
与门的数学表达：
P(T) = P(A) × P(B) × ... × P(N)其中P(T)是顶事件概率，P(A)、P(B)是底事件概率。
你想想看，与门其实是个好消息——因为多个条件同时发生的概率通常很低。我在做可靠性设计时，就喜欢用与门来构建冗余结构。
2.4.2 或门（OR Gate）
或门的逻辑是：只要有一个输入事件发生，输出事件就发生。符号是半圆形，下面不带弧线。
或门在故障树里出现频率最高。为什么？因为大多数故障都是“多个原因中的任何一个”导致的。比如“轨道电路失效”这个事件，可能是“钢轨断裂”或“绝缘破损”或“发送器故障”……任何一个发生，系统就出问题。
注意：或门会让故障概率快速上升。我曾经见过一个系统，底事件有10个，每个故障概率只有0.001，但通过或门一组合，顶事件概率变成了0.01——整整大了10倍！所以设计时一定要警惕或门过多的结构。
2.4.3 非门（NOT Gate）
非门的逻辑很简单：输出事件是输入事件的相反状态。符号是三角形加一个小圆圈。
非门在故障树里用得不多，但很关键。比如“安全防护系统启动”这个事件，它的非门就是“安全防护系统未启动”。在信号系统中，非门常用于描述“应该发生但没发生”的情况。
我记得有一次做道岔控制系统的故障分析，就用了非门。顶事件是“道岔转换不到位”，其中一个中间事件是“驱动电机未动作”。这个“未动作”就是“驱动电机动作”的非门结果。嗯，这里要注意：非门通常只用于描述状态取反，不要滥用。
2.5 事件符号汇总
为了方便你记忆，我把常用符号整理成了一张表：
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形 | 顶事件/中间事件 | 需要进一步分解的事件 |
| 圆形 | 基本事件 | 最底层、已知原因的故障 |
| 菱形 | 未展开事件 | 暂不展开或信息不足的事件 |
| 房形 | 正常事件 | 系统正常状态下的事件 |
| 三角形 | 转移符号 | 表示故障树分支的转入/转出 |
2.6 实战中的一点体会
说了这么多理论，最后分享一点我的实战经验。画故障树时，最容易犯的错误就是事件定义不清晰。比如“电源故障”这个事件——是交流电源故障还是直流电源故障？是主电源还是备用电源？
我建议你遵循“5W1H”原则来定义每个事件：
- What：什么故障
- Where：发生在哪个设备/模块
- When：在什么条件下发生
- Why：为什么是故障
- Who：哪个子系统受影响
- How：故障的表现形式
举个例子，别写“继电器故障”，要写“车站联锁柜内K201继电器线圈开路导致信号机无法点亮”。这样定义，后续分析才有意义。
最后提醒：故障树不是画完就完事了。我习惯在画完第一版后，找两个同事一起评审。一个人画树，容易陷入思维定势。三个人一起看，往往能发现遗漏的底事件或者错误的逻辑门关系。
好了，基本概念和符号就讲到这里。下一节咱们会把这些符号串起来，真正开始构建一棵完整的故障树。到时候你会发现，今天学的这些基础，就像盖房子的砖瓦——看似简单，但缺了哪一块都不行。