NASA 如何打造 Artemis II 的容错计算机
How NASA Built Artemis II’s Fault-Tolerant Computer
在距离地球25万英里的深空，计算机的任何一秒停机都意味着灾难。本文深入剖析了NASA为Artemis II任务打造的极端容错计算架构。与阿波罗时代依赖机电备份不同，猎户座飞船已由软件全面接管安全关键功能，这迫使NASA在可靠性设计上跨越了传统边界。文章详细揭示了系统如何突破常规三重冗余，采用八CPU并行与“故障静默”设计过滤辐射干扰，并依托时间触发以太网实现严苛的确定性同步。更深刻的洞见在于，系统通过异构冗余构建了独立于主架构的终极后备，甚至能从“死总线”状态自动复苏。这不仅是一项工程记录，更是对深空环境下系统自愈能力与架构纪律的深刻诠释。
远离地球的容错架构
当前 Artemis II 载人登月任务机载的计算机系统与阿波罗时代的系统来自不同的世界。阿波罗宇航员使用一台具有 1 MHz 处理器和约 4 千字节可擦除内存的计算机导航至月球表面，并由更大的固定“绳”内存存储器提供支持。虽然它是 20 世纪 60 年代工程的奇迹，但阿波罗制导计算机的功能范围很集中，并未处于每个系统的控制回路中。关键的环境和电源控制通过手动或机电方式（如开关和继电器）进行管理。
本月的 Artemis II 任务搭载四名乘员绕月飞行，这是 50 多年来的首次，该任务由为太空飞行构建的最具容错能力的计算机系统之一提供支持。与阿波罗不同，猎户座飞船的计算架构管理着该飞行器几乎所有的安全关键功能，从生命维持到通信路由。
当任务距离地球 25 万英里时，失败是不可恢复的。没有用于紧急着陆的跑道，也没有技术人员来更换烧毁的主板。每个子系统必须被设计为能够在没有哪怕一秒停机时间的情况下，幸存于宇宙射线导致的位翻转、辐射引起的闩锁（latch-up）以及硬件故障。
“我们仍然通过架构设计来弥补硬件故障，”Nate Uitenbroek 说道，他是位于约翰逊航天中心的 NASA 猎户座计划软件集成与验证负责人。“除了物理冗余的线路，我们还有逻辑冗余的网络平面。我们有冗余的飞行计算机。所有这些都是为了弥补硬件故障而设置的。”
这种冗余的最大驱动因素之一是太空恶劣的辐射环境，在那里高能粒子会影响航空电子设备并产生“错误答案”，这些错误答案必须从飞行解算中被过滤掉。
八核之力
为了确保这些错误答案永远不会到达航天器的推进器，NASA 超越了传统系统的三重冗余。猎户座使用两个飞行器管理计算机（Vehicle Management Computer），每个包含两个飞行控制模块（Flight Control Module），总共四个 FCM。但冗余甚至更深：每个 FCM 由一对自检处理器组成。
实际上，八个 CPU 并行运行飞行软件。工程理念依赖于“故障静默”（fail-silent）设计。自检对确保了如果 CPU 因辐射事件执行错误计算，错误会被立即检测到并且系统做出响应。
“一台故障计算机会故障静默，而不是传输‘错误答案’，”Uitenbroek 解释道。这种方法简化了比较结果的三重“表决”机制的复杂任务。系统没有比较三个答案以寻找多数，而是使用按优先级排序的源选择算法，在未发生故障静默的健康通道中进行选择。它从优先级列表中第一个可用的 FCM 中选取输出；如果该模块因故障而静默，它就会移动到第二个、第三个或第四个。
这种级别的冗余是专门为深空的严酷环境定制的。NASA 预期在 Artemis II 任务穿过高辐射的范艾伦带期间会发生瞬时故障。
“我们可以在 22 秒内失去三个 FCM，仍然能在最后一个 FCM 上安全度过，”Uitenbroek 说。然而，一个静默的 FCM 不会变成死重；该系统被设计为可以重置，将其状态与运行中的模块重新同步，并在飞行中途重新加入集群。
强制确定性
在计算机科学中，让多个独立计算机锁步运行是一个臭名昭著的挑战，因为轻微的时序漂移或处理器差异可能会导致健康的计算机看起来出现分歧。NASA 通过严格的确定性（deterministic）架构解决了这个问题。
这种架构纪律在现代开发中越来越罕见。Michael Riley 是卡内基梅隆大学软件工程研究所的团队负责人，他此前曾与 NASA 合作为猎户座任务改造风险评估工具，他指出，虽然前几代人在严格的硬件约束下工作，但现代的任务关键型开发是不同的。
“现代敏捷和 DevOps 方法优先考虑迭代，这可能会挑战架构纪律，”Riley 解释道。“结果就是，技术债务不断累积，可维护性和系统弹性受到影响。”
猎户座利用时间触发以太网（time-triggered Ethernet）网络，时间被分配到整个系统。飞行软件在划分为“小帧”（minor frames）的“大帧”（major frames）内运行，由符合 ARINC653 标准的调度器管理。该架构利用时间和空间分区来在这些帧内调度分区，确保输入和输出与网络调度完美对齐。
“这种架构确保每个 FCM 看到相同的输入，运行相同的应用程序代码，并产生相同的输出，”Uitenbroek 说。每一秒，任何单个 FCM 的漂移都会被测量，并且其本地时钟会被重新校准到网络的“真实”时间。如果应用程序未能满足其严格的截止时间，该模块会自动静默、重置并重新同步。
硬件本身也得到了强化。该系统采用三模冗余（triple-modular-redundant）内存，在每次读取时自我纠正单比特错误。甚至网卡也利用两条不断进行比较的流量通道，确保通信结构中的位翻转导致的是故障静默事件，而不是损坏的命令。网络本身具有三个独立平面的三重冗余，并且所有网络交换机都采用自检策略。
终极后备
虽然四 FCM 主系统很稳健，但 NASA 仍必须考虑到共模故障（common mode failures）——理论上可能同时影响所有主通道的软件错误或灾难性事件。
为了缓解这种情况，猎户座携带了一个完全独立的备用飞行软件（Backup Flight Software，BFS）系统。这是异构冗余（dissimilar redundancy）的一个典型例子。它实现在不同的硬件上，运行不同的操作系统，并利用独立开发的、简化的飞行软件。
“它被有意设计得不同，以确保主飞行软件中的共模软件故障不会在备份中也错误地实现，”Uitenbroek 说。BFS 不断在后台运行，如果主计算机发生故障，它会通过源选择自动接管。如果系统发现自己运行在 BFS 上，它可以完成任务的所有动态部分以达到静默阶段，此时乘员可以尝试恢复主 FCM。
Riley 强调，虽然故障静默逻辑至关重要，但它必须与主动监控相配合，以避免灾难性的缺口。
“如果一个软件组件静默故障，除非被另一个组件或看门狗定时器监控到，否则该故障可能无法被检测到，”他说。他说，为了任务保证，错误检测和恢复机制必须在代码库的多个层级中被显式设计并相互关联，以确保行为的一致性。
即使在全功率损失的场景下——被称为“死总线”（dead bus）——猎户座也被设计为能够幸存。如果电源恢复，航天器进入安全模式，在此模式下飞行器首先稳定自身，然后将其太阳能电池板指向太阳以恢复电力。然后，它将其尾部朝向太阳以获得热稳定性，然后再尝试与地球重新建立通信。在这种故障期间，乘员也可以采取手动操作来配置生命维持系统或穿上太空服。
可靠性的未来
从阿波罗到阿耳忒弥斯的转变代表了软件复杂性的巨大飞跃。虽然阿波罗的 AGC 是一项独一无二的成就，但其机械后备方案意味着计算机并不是乘员生存的唯一仲裁者。今天，随着软件管理着每一个热力阀和电源继电器，挑战在于确保软件在宇宙辐射的弹幕中保持同步和有效。
为了达到这种置信度，NASA 现在采用了现代验证工作流。这包括全环境模拟和蒙特卡洛（Monte Carlo）压力测试，以对最坏情况的延迟和通信中断进行建模。高性能超级计算机被用于大规模故障注入，模拟引入灾难性硬件故障的整个飞行时间线，以查看软件是否能成功“故障静默”并恢复。
由于太空飞行技术在历史上催生了商业进步，猎户座的零容忍架构提供了一个未来预览，在这个未来中，主流计算——从自动驾驶汽车到工业电网——可以实现与星际所需相同的始终在线的弹性。
Logan Kugler 是一位驻美国佛罗里达州坦帕市、专攻人工智能的技术作家。15 年来他一直是 CACM 的定期撰稿人，曾为近 100 家主要出版物撰稿。
术语表
| 原文 | 中文 |
|---|---|
| Logan Kugler | Logan Kugler |
| Michael Riley | Michael Riley |
| Nate Uitenbroek | Nate Uitenbroek |
此文章由 AI 翻译