3. 基于功能框图的水下机器人故障树层级分解

从顶事件到部件级：三层功能故障树的分解逻辑

本例的任务不是重新定义顶事件，而是把已经确定的顶事件“定深巡航任务失败”沿功能失效路径向下展开，形成“顶事件—子系统级中间事件—部件级中间事件”的三层骨架，并检查每一层的逻辑门是否完整、是否存在遗漏分支或错误合并。

分解时遵循一条硬规则：上一层事件必须是下一层事件的直接后果。也就是说，问“这个子系统为什么会失效”时，答案应当落在下一层的部件级事件上，而不是跳到基本事件或跨层混排。三层骨架的作用是先把“功能怎么断”讲清楚，基本事件的失效模式留到后续案例再细化。

功能失效路径的划分依据

对定深巡航任务而言，任务成功需要同时满足四个功能条件：有足够能源、能产生并分配推力、能感知自身深度与姿态、能按指令闭环控制。任一功能链断裂都可能导致任务失败。因此顶事件下设置四个子系统级中间事件，分别对应能源供给失效、推进与推力分配失效、导航与深度感知失效、控制与通信失效。

需要注意两个容易出错的逻辑关系：其一，能源供给失效与推进失效之间是“或”关系还是“与”关系，取决于是否存在备份供电路径；本例按单主供电假设，采用或门。其二，导航感知失效并不必然立即导致任务失败，只有在控制系统无法进入安全深度保持模式时才成立，因此该分支在子系统级下需要增加一个条件性中间事件，避免把“传感器故障”直接等同于“任务失败”。

三层骨架的落地检查方法

骨架画完后，用三个问题逐层自检，比单纯“看起来完整”更可靠。

• 向上可追溯：每个部件级中间事件向上追问“它失效会导致哪个子系统级事件”，答案必须唯一且直接，不能出现一个部件同时支撑两个互斥分支的情况。
• 向下可展开：每个部件级中间事件都应能继续分解为基本事件（如电机绕组短路、驱动器过流、螺旋桨缠绕），若某个中间事件无法再分解，说明它其实已经是基本事件，应下移一层而不是留在中间事件层。
• 门类型可解释：或门表示任一分支失效即导致上层失效，与门表示必须同时发生。本例中 M3 使用与门是刻意设计，因为深度计故障本身不必然导致任务失败，只有在缺乏安全深度保持能力时才成立；若实际系统配有独立备份定深模式，则该分支应改为或门并补充备份路径。

本例骨架的交付形态

将上述三层结构整理为可复核的事件清单，便于后续案例直接引用和细化基本事件。表中“门类型”指该中间事件与其下级分支之间的逻辑关系，“下级数量”用于快速发现单分支节点（单分支通常意味着层级划分有误）。