Artemis II 容错

Source: Hacker News

概览

Artemis II 的飞行软件运行在高度冗余的架构上，旨在抵御辐射引起的错误、硬件故障，甚至是全功率丢失。系统强调“fail‑silent”行为、确定性错误检查以及异构冗余，以防止共模失效。

摘录 1 – 八个模块与多种备份情景

“Orion 使用两台 Vehicle Management Computers，每台包含两个 Flight Control Modules，总计四个 FCM。但冗余程度更深：每个 FCM 由一对自检处理器组成。实际上，八个 CPU 并行运行飞行软件。工程理念基于‘fail‑silent’设计。自检对确保如果某个 CPU 因辐射事件产生错误计算，错误会被立即检测到，系统随即作出响应。

‘我们可以在 22 秒内失去三个 FCM，仍然能够依靠最后一个 FCM 安全飞行，’Uitenbroek 说。被静音的 FCM 并不会成为负担；系统设计为在飞行中重置、与运行中的模块重新同步状态，并重新加入群组。”

摘录 2 – 多层冗余与确定性错误检查

“该架构确保每个 FCM 接收相同的输入，运行相同的应用代码，并产生相同的输出，”Uitenbroek 说。每秒都会测量任意单个 FCM 的漂移，并将其本地时钟重新校准到网络的‘真实’时间。如果应用未能在严格的截止时间内完成，模块会自动被静音、重置并重新同步。

硬件本身也得到加强。系统采用三模冗余（triple‑modular‑redundant）内存，在每次读取时自行纠正单比特错误。即使是网络接口卡也使用两条持续比较的通道，确保通信层的比特翻转导致的是 fail‑silent 事件而不是指令损坏。网络本身是三重冗余的，拥有三条独立的平面，所有网络交换机都采用自检策略。”

摘录 3 – 异构冗余

“虽然四个 FCM 的主系统已经相当稳健，NASA 仍必须考虑共模失效——软件缺陷或灾难性事件可能理论上同时影响所有主通道。”

为了缓解这一风险，Orion 搭载了完全独立的 Backup Flight Software (BFS) 系统。这是异构冗余的典型例子：它运行在不同的硬件上，使用不同的操作系统，并采用独立开发的、简化的飞行软件。

即使在全功率丢失的情形——称为“dead bus”——Orion 也被设计为能够存活。如果电力恢复，航天器进入安全模式（safe mode），稳定后将太阳能阵列（solar arrays）指向太阳以恢复电力，将尾部（tail）指向太阳以获得热稳定，然后尝试重新与地球建立通信。在此类故障期间，机组人员可以手动配置生命支持系统（life‑support）或穿上太空服（space suits）。

要点

• 多层次冗余（处理器、内存、网络）提供了对辐射诱发错误的韧性。
• 确定性错误检查和自动静音/重置保持系统同步。
• 异构冗余——不同的硬件和软件堆栈——防御共模失效。

虽然如此广泛的冗余会带来显著成本，Artemis II 的架构仍为在其他高可靠性领域设计容错系统提供了宝贵经验。