3. 硬件冗余设计：双机热备、三模冗余、冷备与温备
硬件冗余，说白了就是「多准备几份硬件，防止单点故障」。
我做了这么多年路径规划系统，见过太多因为硬件失效导致整个项目崩盘的案例。
嗯，今天咱们就把双机热备、三模冗余、冷备和温备这几个方案聊透。
3.1 双机热备（Active/Standby）
这是最常用的方案。一台主设备干活，一台备用设备待命。
主设备一旦挂了，备用设备立刻顶上。
工作模式：
- Active（主）： 实时处理路径规划任务，输出控制指令
- Standby（备）： 同步接收传感器数据，但不输出控制指令
- 切换时间： 毫秒级到秒级，取决于心跳检测频率
核心要点： 主备之间必须保持状态同步。否则切换时会出现路径跳变，机器人可能直接撞墙。
我在项目中遇到过一个问题：主备之间通过以太网同步状态，结果网络抖动导致备机误判主机挂了，频繁切换。
后来我加了个「三次心跳丢失才切换」的机制，才稳定下来。
3.2 三模冗余（TMR）
三模冗余，就是三套硬件同时运行，通过「投票」决定最终输出。
说白了，三个大脑一起算，少数服从多数。
典型架构：
传感器数据 → 路径规划模块A → 输出A
传感器数据 → 路径规划模块B → 输出B
传感器数据 → 路径规划模块C → 输出C
↓
投票器（Voter）
↓
最终控制指令为什么用三套而不是两套？
两套系统如果结果不一致，你没法判断谁对谁错。
三套系统，至少能保证两个一致，投票结果可信。
我的经验： TMR 适合对安全性要求极高的场景，比如自动驾驶、航天器导航。
但代价也很明显：成本翻三倍，功耗翻三倍，体积翻三倍。
我曾经在一个无人矿卡项目里用过 TMR。三套工控机同时跑路径规划，投票器用 FPGA 实现。
结果发现一个问题：三套硬件虽然型号相同，但晶振频率有微小差异，导致输出时序不一致。
后来我加了「时间戳对齐」机制，才解决了投票冲突。
3.3 冷备与温备
这两个概念经常被混淆。我简单说清楚：
| 特性 | 冷备 | 温备 | 热备 |
|---|---|---|---|
| 电源状态 | 断电 | 通电但不工作 | 通电且工作 |
| 数据同步 | 无 | 定期同步 | 实时同步 |
| 切换时间 | 分钟级 | 秒级 | 毫秒级 |
| 适用场景 | 非关键任务 | 中等关键任务 | 高关键任务 |
冷备： 备用设备放在仓库里，主设备坏了才拿出来用。
你想想看，这种方案成本最低，但切换时间最长。
我见过一个仓库 AGV 项目用冷备，结果主控制器烧了，等备机从仓库调过来、安装调试，整整花了 4 个小时。
温备： 备用设备通电待命，但不参与实际计算。
它会定期从主设备同步关键数据，比如地图、路径缓存。
切换时只需要加载最新状态，比冷备快得多。
注意： 温备的「定期同步」间隔很关键。
同步太频繁，占用主设备资源；同步太少，切换时数据丢失严重。
我个人习惯设置 1-5 秒同步一次，具体看业务容忍度。
3.4 如何选择？
我总结了一个简单的选择逻辑：
- 预算充足 + 安全要求极高 → TMR
比如自动驾驶、医疗机器人、航天器 - 预算中等 + 需要快速切换 → 双机热备
比如工业 AGV、仓储机器人 - 预算有限 + 允许短暂停机 → 温备
比如巡检机器人、服务机器人 - 预算极低 + 非关键任务 → 冷备
比如教育机器人、简单搬运
避坑指南： 我曾经在一个项目里选了双机热备，但忽略了「切换时路径连续性」的问题。
主设备挂了，备机接管后重新规划路径，导致机器人原地打转。
后来我加了「路径状态缓存」机制，备机接管后直接沿用最后一条有效路径，才解决问题。
嗯，硬件冗余设计就聊到这里。
记住一句话：冗余不是万能的，但没有冗余是万万不能的。
下一章咱们聊聊软件层面的冗余设计，比如看门狗、心跳检测、超时重试这些。