故障模型与失效模式：故障、错误、失效的区别
做路径规划这么多年，我见过太多系统在关键时刻掉链子的情况。有一次在港口AGV项目上，一台车突然停在路中间不动了——不是撞了，是它自己"懵"了。排查下来，发现是传感器数据出了点小问题，但整个规划逻辑就崩了。
这让我意识到，搞路径规划安全，首先得把几个基本概念理清楚。说白了，就是搞清楚系统到底是怎么"坏"的。
故障、错误、失效——三个容易混淆的概念
我习惯用一个比喻来解释这三者的关系：
- 故障（Fault）：系统内部的一个缺陷。比如代码里有个变量没初始化，或者传感器接口虚焊了。它就在那，但不一定马上出事。
- 错误（Error）：故障被激活了，系统内部状态出现了偏差。比如那个没初始化的变量被读取了，拿到了一个随机值。
- 失效（Failure）：错误传播到了系统边界，导致服务不可用。比如路径规划模块因为那个随机值，输出了一条撞墙的路径。
关键点：故障是原因，错误是状态，失效是结果。你想想看，我们做安全冗余设计，目标就是在"故障→错误→失效"这条链上，尽早掐断它。
我在项目中遇到过一种典型情况：GPS模块的电源纹波偏大（故障），导致定位数据偶尔跳变（错误），但路径规划模块没有做数据校验，直接用了这个跳变值，结果车辆偏离路线（失效）。嗯，这里要注意，如果我们在规划层加一个位置合理性检查，这个失效完全可以避免。
单点故障（SPOF）分析
单点故障，说白了就是系统里"一个零件坏了，整个系统就瘫了"的那种节点。做路径规划系统，我最怕的就是这种设计。
举个例子，我曾经接手过一个项目，所有AGV的路径规划都依赖一台中央服务器。服务器挂了，所有车都停在原地。这就是典型的单点故障。
常见的单点故障点包括：
- 单一传感器：只用一颗激光雷达做定位，它坏了你就瞎了
- 单一通信链路：所有指令走一条WiFi，断了就失联
- 单一计算节点：所有规划任务跑在一台工控机上，死机就停摆
- 单一电源：整个系统共用一个电源模块，烧了就全完
避坑指南：我曾经在一个项目中，把所有传感器的数据都通过同一个CAN总线传输。结果总线被一个故障节点占满了，所有传感器数据都传不过去。这就是典型的"共享资源"导致的单点故障。后来我学乖了，关键数据走独立总线，或者加一个总线监控器。
怎么分析单点故障？我建议用故障树分析（FTA）。从顶层失效事件往下推，看哪些底层组件的故障会导致这个失效。如果某个组件出现在所有路径上，那它就是单点故障。
常见失效模式
搞清楚了故障和失效的关系，我们来看看路径规划系统中常见的几种失效模式。这些模式不是我编的，是分布式系统领域几十年的经验总结。
1. 崩溃故障（Crash Failure）
这是最"老实"的故障。组件直接停了，不干活了，也不响应了。比如工控机死机、电机驱动器烧毁。
处理方式相对简单：心跳检测 + 冗余切换。我习惯给每个关键节点配一个看门狗，超过500ms没收到心跳，就认为它挂了，立刻切换到备用节点。
// 伪代码：心跳检测逻辑
while (true) {
if (lastHeartbeat + TIMEOUT < now()) {
// 节点疑似崩溃
switchToBackup(nodeId);
reportFailure(nodeId, "CRASH");
}
sleep(100); // 每100ms检查一次
}2. 遗漏故障（Omission Failure）
组件没崩溃，但该做的事没做。比如路径规划模块该输出路径了，但没输出；或者该响应一个请求，但没响应。
这种故障比崩溃更隐蔽。我遇到过一种情况：规划模块在计算复杂路径时，因为内存分配失败，直接跳过了输出步骤，但进程还在跑。上层模块等不到结果，就卡死了。
我的经验：对于遗漏故障，最好的防御是"超时+重试"。给每个关键操作设置超时时间，超时了就重试或者走降级方案。另外，关键函数一定要有返回值检查，别假设它一定会成功。
3. 拜占庭故障（Byzantine Failure）
这是最"坏"的故障。组件不仅不干活，还给你返回错误的数据，或者故意捣乱。比如传感器被遮挡后输出错误的位置，或者通信模块被干扰后发送乱码。
拜占庭故障最难处理，因为它会"欺骗"你的冗余机制。你搞了三路冗余，结果两路被污染了，投票机制反而选出错误的结果。
| 故障类型 | 行为表现 | 检测难度 | 典型应对 |
|---|---|---|---|
| 崩溃故障 | 完全停止响应 | 低 | 心跳检测、主备切换 |
| 遗漏故障 | 偶尔不响应或跳过操作 | 中 | 超时重试、状态校验 |
| 拜占庭故障 | 返回任意错误数据 | 高 | 数据一致性校验、N版本编程 |
重点：在路径规划系统中，拜占庭故障最常出现在传感器融合环节。比如两个激光雷达给出冲突的障碍物位置，你信谁？我建议的做法是：不要直接投票，而是引入"合理性校验"——检查数据是否在物理可行范围内，是否与历史数据一致，是否满足运动学约束。
举个例子，我曾经处理过一个案例：一台AGV的IMU受到电机电磁干扰，输出的角速度数据严重偏大。路径规划模块根据这个数据判断车辆在急转弯，于是输出一个反向的修正指令。结果车辆开始蛇形走位。这就是拜占庭故障的典型表现——数据看起来"正常"（有值、有变化），但实际上是错的。
处理这种问题，我后来加了一个"数据一致性检查器"：对比IMU数据和轮速计数据，如果偏差超过阈值，就标记为可疑数据，降低其权重。说白了，就是别盲目相信任何一个数据源。
小结
故障、错误、失效，这三个概念搞清楚了，你才能设计出真正靠谱的冗余机制。单点故障分析是基本功，别偷懒。至于失效模式，我建议你记住一句话：崩溃故障靠冗余，遗漏故障靠超时，拜占庭故障靠校验。
下一章我会讲具体的冗余设计方法，包括硬件冗余、软件冗余和信息冗余。到时候我会拿实际项目中的案例来拆解，看看这些理论到底怎么落地。