Artemis II 容错

Source: Hacker News

Communications of the ACM published a fascinating post about how NASA built Artemis II’s fault‑tolerant computer. Below are three key excerpts.

八个模块与多种备份方案

Orion 利用两台车辆管理计算机（Vehicle Management Computers），每台包含两个飞行控制模块（Flight Control Modules），共计四个 FCM。但冗余程度更深：每个 FCM 由一对自检处理器组成。
实际上，八个 CPU 并行运行飞行软件。工程理念基于“静默失效”（fail‑silent）设计。自检对确保如果某个 CPU 因辐射事件产生错误计算，错误会被立即检测到，系统随即作出响应。
“我们可以在 22 秒内失去三个 FCM，仍然能够依靠最后一个 FCM 安全飞行，”Uitenbroek 说。被静默的 FCM 并不会变成负担；系统设计为在飞行中重置、与正在运行的模块重新同步状态，并重新加入整体。

多重冗余与确定性错误检查

“该架构确保每个 FCM 接收相同的输入，运行相同的应用代码，并产生相同的输出，”Uitenbroek 说。每秒都会测量各个 FCM 的漂移，并将其本地时钟重新校准到网络的‘真实’时间。如果某个应用未能满足严格的截止时间，模块会自动被静默、重置并重新同步。
硬件本身也得到强化。系统采用三模冗余（triple‑modular‑redundant）内存，在每次读取时自行纠正单比特错误。甚至网络接口卡也使用两条持续比较的通道，确保通信层的比特翻转会导致静默失效而不是指令损坏。网络本身是三重冗余的，拥有三条独立的平面，所有网络交换机都采用自检策略。

不同类型的冗余

虽然四 FCM 的主系统已经相当稳健，NASA 仍需考虑共模失效——软件缺陷或灾难性事件可能同时影响所有主通道。
为了缓解这一风险，Orion 配备了完全独立的备份飞行软件（Backup Flight Software，BFS）系统。这是不同类型冗余（dissimilar redundancy）的典型例子。它运行在不同的硬件上，使用不同的操作系统，并采用独立开发的、简化的飞行软件。
即使在完全失电的情况下——即所谓的“死总线”（dead bus），Orion 也被设计为能够存活。如果电力恢复，航天器进入安全模式，首先自行稳定，然后将太阳能阵列指向太阳以恢复电力。随后，它会将机身尾部朝向太阳以获得热稳定，随后再尝试重新与地球建立通信。在此类故障期间，机组人员也可以手动操作，配置生命维持系统或穿上太空服。

这些冗余策略成本高昂，但它们展示了在任何高可靠性领域设计容错系统的宝贵原则。