NASA Artemis II 容错计算机系统设计
Artemis II 任务的 Orion 飞船计算架构——从 Apollo 时代 1MHz/4KB 到现代深空容错系统的演进。
核心挑战
- 任务距离地球 25 万英里，失败不可恢复
- 高能粒子导致宇宙射线位翻转（bit flips）和辐射诱导闩锁（latch-ups）
- 没有备用跑道，没有技术人员更换主板
- 软件现在管理每一个热阀和电源继电器（Apollo 时代有机械备用方案）
冗余架构：The Power of Eight
NASA 超越了传统三重冗余，采用八重并行：
2 × Vehicle Management Computers
└── 各含 2 × Flight Control Modules (FCM)
└── 每个 FCM = 自检处理器对（self-checking pair）
└── 共 8 个 CPU 并行运行飞行软件
Fail-Silent 设计：
- 自检处理器对确保辐射事件导致的错误计算能被立即检测
- 故障计算机会"静默失败"，而非传输错误答案
- 简化了三取二投票机制：使用优先级排序的源选择算法，从健康通道中挑选输出
恢复能力：
- 可在 22 秒内失去 3 个 FCM，仍安全依赖最后一个
- 静默的 FCM 不会变成死重：系统会重置、重新同步状态、重新加入组
确定性执行
多独立计算机同步运行是计算机科学的 notorious 挑战。NASA 的解决方案：
- 时间触发以太网：时间在整个系统中分发
- ARINC653 兼容调度器：飞行软件在"major frames"内运行，分为"minor frames"
- 时间和空间分区：确保每个 FCM 看到相同的输入、运行相同的应用代码、产生相同的输出
- 每秒测量漂移：任何 FCM 的本地时钟重新校准到网络"真实"时间
- 错过严格截止日期 → 自动静默、重置、重新同步
硬件加固：
- 三模冗余内存：每次读取时自纠正单比特错误
- 网络接口卡：双通道流量持续比较
- 三重冗余网络平面
- 所有网络交换机采用自检策略
终极备用：备份飞行软件（BFS）
应对共模故障（软件 bug 或灾难性事件同时影响所有主通道）：
- 异构冗余：不同硬件、不同操作系统、独立开发的简化飞行软件
- 有意设计得不同，确保主软件的共模故障不会在备份上重现
- BFS 持续后台运行，主计算机故障时自动接管
- 进入 BFS 后可完成所有动态任务，到达静止阶段后机组可尝试恢复主 FCM
全失效场景：Dead Bus
即使完全断电：
- 电源恢复后进入安全模式
- 飞船先稳定自身
- 太阳能板对准太阳恢复电力
- 尾部对准太阳保持热稳定
- 尝试重新建立与地球通信
- 机组可手动配置生命维持系统或穿太空服
验证方法
- 全环境仿真
- Monte Carlo 压力测试，建模最坏情况延迟和通信中断
- 高性能超级计算机大规模故障注入，模拟整个飞行时间线中引入灾难性硬件故障
对 Agent 系统的启示
| NASA 原则 | Agent 系统对应 |
|---|---|
| Fail-silent | 错误静默而非传播（tool error handling） |
| 确定性架构 | 可重现的执行环境（容器化、 pinned dependencies） |
| 异构冗余 | 多模型验证（不同模型交叉检查） |
| 持续漂移测量 | 可观测性与健康检查 |
| 自动重置与重新同步 | 自恢复 agent loop |