📚 课程目录第3章符号体系

第3章：符号体系——事件符号与逻辑门符号

故障树说白了就是用符号画出来的逻辑图。我刚入行那会儿，觉得这些符号不就是些方方圆圆嘛，有啥好学的？直到有一次评审，我把菱形和圆形搞混了，被老专家当场指出来……嗯，从那以后我再也不敢小看这套符号体系了。

这一章咱们就把FTA的“字母表”彻底搞清楚。你想想看，如果连字母都认不全，怎么可能读懂一篇英文文章？故障树也是一样的道理。

事件符号代表系统中发生的各种状态或故障。我个人习惯把它们分成四类，记起来特别方便。

符号	名称	含义	是否需要继续往下分解
矩形	顶事件 / 中间事件	需要进一步分析的事件	是
圆形	底事件	基本失效，无法再分解	否
菱形	未展开事件	信息不足，暂不分解	否（暂时）
房形	正常事件	系统正常状态下的事件	否

矩形是故障树里最常见的符号。顶事件用矩形，中间事件也用矩形。说白了，只要这个事件下面还有“故事”要讲，就用矩形框起来。

我在项目中遇到过一件事：有人把顶事件写成了“系统故障”，这个范围太大了，根本没法往下分析。后来我建议改成“发动机在启动后30秒内熄火”，一下子就清晰了。矩形里的文字一定要具体，别含糊。

我的习惯：矩形事件编号用 T 开头（顶事件）或 M 开头（中间事件），比如 T-01、M-03。这样在大型故障树里一眼就能定位。

圆形代表底事件，也就是故障树的最底层。到了圆形这里，分析就停了——因为要么是物理极限，要么是已知的失效率数据。

举个例子：如果“继电器触点粘连”是一个底事件，那我们就画个圆形。为什么？因为继电器触点为什么会粘连，那是材料科学和制造工艺的事，FTA不需要再往下钻了。

注意：圆形事件必须有失效率数据支撑。我曾经见过有人把“操作员误操作”画成圆形，结果评审时被问“误操作的概率是多少？”答不上来……后来改成了菱形。

菱形表示“我现在不想分析它”。原因可能是：

我建议：菱形事件一定要在分析报告中注明“暂不展开”的理由。否则评审时会被追问：“这个菱形到底什么时候展开？”

房形比较特殊，它代表的是正常事件。比如“电源正常供电”“冷却水正常循环”——这些不是故障，但它们是故障发生的背景条件。

我记得有一次做核电系统的FTA，分析“冷却泵停转”这个顶事件时，下面有个房形写着“电源正常”。有人问：“电源正常也算事件？”我说：“对，因为如果电源都不正常，那冷却泵停转的原因就变了，逻辑门也会不一样。”

事件符号是名词，逻辑门就是动词——它们把事件连接起来，表达因果关系。

与门的逻辑：所有输入事件都发生，输出事件才发生。

画法：一个圆弧底的门，上面横着一条线。

我在项目中遇到过最经典的与门案例是“双冗余系统失效”：两个通道都坏了，系统才失效。只要有一个通道还在工作，系统就没事。

  与门的数学表达： T = A ∩ B ∩ C

  如果A、B、C的失效率分别是λ₁、λ₂、λ₃，那么T的失效率大约是 λ₁ × λ₂ × λ₃ × t²（对于同时发生的需求）。

或门的逻辑：只要有一个输入事件发生，输出事件就发生。

画法：一个尖底的门，上面横着一条线。

说白了，或门是最“危险”的门——任何一个底事件都能导致顶事件。我见过一个系统，顶事件下面直接挂了8个或门输入，那可靠性能高才怪。

避坑指南：我曾经犯过一个错误——把两个互斥的事件用或门连起来。比如“阀门卡在开位”和“阀门卡在关位”，这两个不可能同时发生，但用或门表达“任一发生都导致故障”是没问题的。关键是要在分析文档里注明互斥关系。

非门表示“取反”。输入事件不发生，输出事件才发生。

画法：一个小圆圈加一条短线。

非门在FTA里用得不多，但有时候很关键。比如“安全联锁系统未触发”这个事件，下面可能接一个非门，输入是“安全联锁系统正常触发”。

我个人不太建议在故障树里大量使用非门，因为会让逻辑变得绕。能用其他方式表达的，尽量不用非门。

表决门也叫k/n门。意思是：n个输入中，至少有k个发生，输出才发生。

画法：一个门中间写“k/n”。

最常见的例子是“三取二”表决系统（2/3门）：三个传感器，至少两个同时报警，才判定为真报警。

经验之谈：表决门在可靠性设计中非常有用。2/3系统比1/3系统（或门）可靠得多，但比3/3系统（与门）又更容易触发报警。选哪个，要看你是要“安全”还是要“可用”。

下面这张图把本章的核心内容串起来了。我建议你把它存下来，以后画故障树时对照着看。

最后，我把自己这些年踩过的坑总结一下：

  一句话总结：事件符号回答“是什么”，逻辑门回答“怎么连”。把这两套符号吃透了，FTA就算入门了。