4. 系统边界与假设条件

故障树这东西，说白了就是一张逻辑因果图。但你别小看它——画得对不对，直接决定了后面的分析靠不靠谱。我见过不少项目，树画得花里胡哨，结果一算最小割集全是错的，白忙活一场。

所以这一节，咱们把建树的规矩掰开揉碎讲清楚。

4.1 建树的基本原则

我个人习惯把建树原则总结成四个字：准、全、简、清。下面一个个说。

原则	核心要求	我踩过的坑
准	顶事件定义必须精确，不能含糊	有次把“电机过热”写成“电机故障”，结果下面一堆无关分支
全	所有直接原因必须列全，不能遗漏	漏了“人为误操作”，割集算出来少一半
简	能用逻辑门表达的，不要绕弯子	有人用三个或门代替一个与门，树乱得没法看
清	层次分明，事件描述无歧义	“开关失效”到底是开路还是短路？必须写清楚

4.2 建树的标准步骤

我一般按五步走。你照着来，基本不会出大错。

1. 定义顶事件——明确你要分析什么故障。比如“反应釜超压爆炸”，而不是“反应釜出问题”。
2. 确定边界条件——系统边界、初始状态、不允许发生的事件。这一步很多人跳过去，结果后面分析范围失控。
3. 逐层分解——从顶事件往下，问“这个故障的直接原因是什么？”用与门或或门连接。
4. 展开到底事件——直到不能再分解为止。底事件必须是可检测、可统计的。
5. 检查与完善——回头看看有没有漏层、有没有逻辑矛盾。

4.3 常见误区——我替你踩过的雷

下面这几个坑，我几乎都掉进去过。你注意绕开。

误区一：顶事件定义太宽泛

比如“系统失效”。这太模糊了——是功能丧失？还是性能下降？还是安全功能失效？
正确做法：“安全阀在超压时未开启”这种具体描述。

误区二：逻辑门用反

把“与门”和“或门”搞混。我记得有一次评审，对方把两个冗余泵的失效用或门连起来，说“只要一个泵坏，系统就失效”。但冗余设计明明是“两个都坏才失效”，应该用与门。

误区三：遗漏共因失效

两个底事件看起来独立，实际上共享同一个电源、同一个操作员、同一个环境条件。如果不处理共因，最小割集会严重低估风险。

误区四：事件描述带歧义

“温度过高”——多高算高？建议写成“温度超过85℃”。
“阀门故障”——什么故障？卡死？内漏？还是无法关闭？

误区五：树画得太深或太浅

太浅：到底事件还是复合事件，没法定量分析。
太深：把螺丝钉的材质都写进去，分析成本失控。
我的经验：到底事件是可更换的零部件级别，或者有历史故障数据的层级，就够了。

4.4 建树流程总图

下面这张图，把建树的完整流程串起来了。你可以把它贴在工位上。

4.5 一个完整的建树示例

咱们拿“灯泡不亮”这个简单例子，走一遍流程。

顶事件：灯泡不亮

边界条件：开关已闭合，电源正常供电

第一层分解：灯泡不亮的原因有两个——
  A. 灯泡本身坏了
  B. 电路不通

这两个是“或门”关系——任何一个发生，顶事件就发生。

第二层分解：
  A 下面：灯丝断裂、灯座接触不良（或门）
  B 下面：导线断路、开关触点失效（或门）

到这层，底事件都是可检测的——灯丝断没断，拿万用表一量就知道。树就建完了。

4.6 建树质量自检清单

每次建完树，我习惯拿这张表过一遍。你也试试。

检查项	通过标准	常见问题
顶事件	唯一、具体、可量化	“系统故障”这种模糊描述
边界条件	明确系统状态和外部环境	漏掉“初始状态”假设
逻辑门	与门/或门使用正确	冗余系统用了或门
底事件	可检测、可统计、独立	底事件还是复合事件
共因失效	已识别并标注	两个底事件共享同一电源未标注
完整性	无遗漏的直接原因	漏了人为因素或环境因素