3. FTA基本符号与建树规则
各位同学,今天我们来聊聊FTA里最基础、也最绕不开的东西——符号和建树规则。说实话,我见过不少分析报告,逻辑门用错了,事件定义含糊不清,最后整棵树推下来全是错的。嗯,咱们先把地基打牢。
3.1 事件符号:从顶到底的三个层次
FTA里的事件符号,说白了就三种:顶事件、中间事件、底事件。它们构成了树的骨架。
| 符号类型 | 图形 | 含义 | 我的经验 |
|---|---|---|---|
| 顶事件 | 矩形 | 系统最不希望发生的故障 | 必须唯一,且可分解 |
| 中间事件 | 矩形 | 需要继续往下分解的故障 | 命名要精确,别含糊 |
| 底事件 | 圆形 | 无需再分解的基本故障 | 必须有数据支撑 |
顶事件是整个树的根。我个人的习惯是,顶事件一定要用一句话说清楚,比如“系统启动后30秒内无响应”,而不是“系统故障”——太笼统了,没法往下拆。
中间事件是树的分支节点。它本身也是一个故障,但需要继续往下找原因。我在项目中遇到过,有人把中间事件写成了解决方案,比如“增加内存校验”,这不对。中间事件必须是故障,不是对策。
底事件是树的叶子。它代表一个最基本的、不需要再分解的故障事件。比如“CPU寄存器读错误”、“电源电压低于2.5V”。底事件必须有明确的定义和可获取的概率数据,否则整棵树算不出定量结果。
关键点:矩形框既用于顶事件也用于中间事件,区别在于位置和分解深度。圆形框只用于底事件,不能再有子节点。
3.2 逻辑门符号:故障怎么组合
逻辑门是FTA的“粘合剂”,它决定了子事件如何组合成父事件。我见过最坑的情况,就是把与门和或门用反了,结果整个分析方向都偏了。
3.2.1 与门(AND Gate)
与门表示:所有输入事件同时发生,输出事件才发生。用符号表示就是“∩”。
举个例子:系统死机 = 内存访问冲突 与 看门狗失效。两个条件缺一不可。
我曾经在分析一个嵌入式系统时,发现工程师把“电源断电”和“备用电池失效”用或门连了起来。我说不对,这两个必须同时发生才会导致系统掉电,应该用与门。改完之后,故障概率直接降了两个数量级。
3.2.2 或门(OR Gate)
或门表示:只要有一个输入事件发生,输出事件就发生。用符号表示就是“∪”。
比如:用户登录失败 = 密码错误 或 账户锁定 或 服务器拒绝连接。任何一个成立,登录就失败。
小技巧:与门和或门的区分,你可以这样记——与门是“一个都不能少”,或门是“一个就够了”。
3.2.3 非门(NOT Gate)
非门表示:输出事件是输入事件的相反状态。在FTA里,非门用得相对少,但很关键。比如“系统未响应” = 非(系统正常运行)。
我个人建议,非门尽量少用,因为它会让树变得复杂,而且容易引入逻辑矛盾。能用底事件直接表达的,就别绕弯子。
3.2.4 表决门(Voting Gate / k-out-of-n Gate)
表决门表示:n个输入事件中,至少有k个发生,输出事件才发生。比如“3取2表决门”,就是三个条件里至少两个成立,故障才成立。
这在冗余系统里特别常见。我记得有一次分析一个三冗余飞控系统,用了表决门之后,才发现原来系统在“两个传感器同时故障”时才会失控,单个故障根本没事。这就是表决门的价值。
| 逻辑门 | 符号 | 条件 | 典型场景 |
|---|---|---|---|
| 与门 | ∩ | 全部发生 | 多重防护失效 |
| 或门 | ∪ | 任一发生 | 单点故障 |
| 非门 | ¬ | 状态取反 | 安全条件不满足 |
| 表决门 | k/n | 至少k个发生 | 冗余系统 |
3.3 转移符号:让树别长成“八爪鱼”
转移符号的作用,说白了就是“复用”。当同一个子树在多个地方出现时,你不需要重复画,用转移符号引用就行。
- 转入符号(三角形,箭头向内):表示这里要引用另一棵子树。
- 转出符号(三角形,箭头向外):表示这棵子树被其他地方引用。
我个人的习惯是,转移符号一定要编号,而且要写清楚引用的子树名称。不然到了后期,树一多,你自己都找不到谁是谁。我曾经在一个大型项目里,看到有人用了十几个转移符号,结果编号全是“A1、A2、A3”,最后谁也看不懂。
避坑指南:转移符号不要形成循环引用。A引用B,B又引用A,这棵树就死锁了。我曾经见过一个团队,因为转移符号循环,导致分析工具直接崩溃。
3.4 建树的基本原则与步骤
建树不是随便画个图就完事了。我总结了几个原则,都是踩过坑之后才明白的。
3.4.1 基本原则
- 顶事件唯一性:一棵树只能有一个顶事件。别想着把“系统崩溃”和“数据丢失”放在一棵树里,拆成两棵。
- 逐层分解:从顶事件开始,一层一层往下拆,不能跳级。我见过有人直接从顶事件跳到底事件,中间的逻辑全丢了。
- 完整性:每个中间事件的所有直接原因都要列全,不能遗漏。你想想看,漏掉一个原因,整棵树的结论就偏了。
- 无冗余:同一个底事件不要出现在多个分支里,除非你用转移符号。否则计算概率时会重复计算。
3.4.2 建树步骤
我一般按这五步走,你可以参考一下:
| 步骤 | 做什么 | 注意什么 |
|---|---|---|
| 1 | 定义顶事件 | 具体、可测量、唯一 |
| 2 | 识别直接原因 | 用“为什么”追问 |
| 3 | 选择逻辑门 | 与门还是或门,想清楚 |
| 4 | 逐层分解 | 直到底事件为止 |
| 5 | 检查与验证 | 逻辑是否闭合,有无遗漏 |
嗯,这里要注意:步骤2和步骤3是交替进行的。你识别出一个直接原因,就要马上判断它和父事件是什么逻辑关系。别等全列完了再回头加门,容易乱。
3.5 知识体系总览
下面这张图,把本章的核心内容串起来了。你可以把它当成一个“速查地图”。
这张图把事件符号、逻辑门、转移符号和建树规则串在了一起。你写分析报告的时候,可以对照着检查,看看自己有没有漏掉什么。
总结一下:FTA的符号和规则,说白了就是一套“故障逻辑语言”。学会了它,你才能准确地描述故障是怎么发生的。下一层一层拆下去,直到找到根因。嗯,今天就到这里,回去之后找个小系统练练手,画一棵完整的故障树试试。