3、故障树构建步骤：明确系统边界、定义顶事件、逐层分解、确定底事件
好，咱们进入正题。故障树怎么建？很多人一上来就画图，结果画到一半发现逻辑不通，又得重来。我个人的习惯是——先想清楚四件事：边界在哪、顶事件是什么、怎么往下拆、拆到什么程度为止。这四步走扎实了，后面的分析才靠谱。
3.1 明确系统边界
说白了，你得先画个圈。圈里面是你要分析的系统，圈外面是环境、是其他系统、是人为操作。边界不清，分析就没完没了。
边界定义要回答三个问题：
- 物理边界：系统包含哪些设备？哪些模块？举个例子，分析一个联锁系统，是只考虑联锁机柜本身，还是连信号机、转辙机都算进来？
- 功能边界：系统完成什么功能？不完成什么功能？比如“列车超速防护”这个功能，边界就是ATP系统，别把调度指挥扯进来。
- 环境边界：外部条件怎么假设？温度、湿度、电磁干扰、供电质量……这些是作为底事件，还是作为固定条件？
我踩过的坑：有一次做某地铁信号系统的故障树，一开始没把“人为误操作”划进边界。结果分析到一半发现，很多故障根因其实是维护人员操作不当。没办法，只能回头重新定义边界，把“人因”加进来。嗯，从那以后我学乖了——边界定义阶段，宁可宽一点，别漏了。
3.2 定义顶事件
顶事件就是你要分析的那个“坏结果”。它必须是一个明确的、可观测的、不希望发生的事件。
顶事件的定义原则：
- 唯一性：一次只分析一个顶事件。别想着“系统故障”这种大而全的，要具体到“列车无法在站台精确停车”或者“道岔无表示”。
- 可观测性：顶事件必须能通过某种方式被检测到。比如“信号机显示红灯”是可观测的，“系统内部逻辑错误”就不太好直接观测。
- 可分解性：顶事件要能往下拆。如果顶事件本身就是一个基本故障，那就不用建树了。
我的建议：顶事件最好用“主语+谓语+宾语”的格式来描述。比如“ATP系统未输出制动命令”，比“制动失效”要清晰得多。你想想看，后者太模糊了——是制动指令没发？还是发了但执行机构坏了？
3.3 逐层分解
这是最考验功力的环节。从顶事件开始，一层一层往下问：“这个事件是怎么发生的？”
分解的逻辑门：
| 逻辑门 | 含义 | 举例 |
|---|---|---|
| 与门（AND） | 所有输入事件同时发生，输出才发生 | “电源故障”且“备用电源也故障”，才会导致“系统掉电” |
| 或门（OR） | 任一输入事件发生，输出就发生 | “传感器A故障”或“传感器B故障”，都会导致“速度检测失效” |
| 条件门 | 在特定条件下，输入才导致输出 | “列车超速”且“ATP未干预”，才导致“紧急制动未触发” |
分解的深度怎么把握？我个人习惯是：拆到你能找到具体的、可维修的、有数据的部件或动作为止。比如“继电器触点粘连”可以作为一个底事件，但“金属材料疲劳”就太细了——除非你手头有材料疲劳的失效率数据。
注意：分解过程中最容易犯的错误是“跳跃”。比如从“系统故障”直接跳到“芯片烧毁”，中间跳过了电源模块、接口电路、保护电路……这种跳跃会让故障树漏掉很多中间环节。我曾经审过一份故障树，顶事件是“信号机灭灯”，结果直接拆成了“灯泡损坏”和“电源故障”，完全忽略了点灯电路、继电器、电缆这些中间环节。嗯，这种树建出来，分析结果基本没法用。
3.4 确定底事件
底事件就是故障树的最底层，不再往下分解了。底事件通常分为三类：
- 基本事件：部件本身的故障，比如“电阻开路”、“电容击穿”。
- 未展开事件：暂时不往下分析的事件，比如“人为操作失误”——你可以先标记为未展开，后续再单独分析。
- 条件事件：系统所处的特定状态或条件，比如“温度超过85℃”。
底事件的要求：
- 有数据支撑：底事件最好有失效率数据。没有数据，定量分析就做不了。我一般会从GJB/Z 299C、MIL-HDBK-217或者厂家提供的MTBF数据里找。
- 相互独立：底事件之间不能有依赖关系。比如“电源模块故障”和“电源模块输出异常”就是相关的，不能同时作为底事件。
- 可维修/可更换：底事件对应的故障，在现场应该是能定位和修复的。否则分析出来也没用。
举个例子：我曾经做一个道岔控制电路的故障树，底事件包括“继电器线圈开路”、“继电器触点卡滞”、“电缆断线”、“保险丝熔断”。这些底事件都有对应的维修手册和备件，现场工程师拿到故障树就能直接排查。这才是实用的故障树。
3.5 一个小总结
这四步走下来，故障树的骨架就有了。我个人的经验是：边界定义花20%的时间，顶事件定义花10%，逐层分解花50%，底事件确定花20%。为什么分解花的时间最多？因为这一步最需要你对系统有深入的理解。你想想看，一个对系统一知半解的人，怎么可能把故障树拆得合理？
最后说一句：故障树不是一次建成的。我通常建完第一版后，会找两三个熟悉系统的老工程师一起评审。他们往往能指出我漏掉的故障模式或者逻辑关系。嗯，别怕改，好的故障树都是改出来的。