Apollo-11制导计算机：36K代码如何实现载人登月

1. 从一行代码到月球Apollo-11 制导计算机到底有多“抠”第一次看到 Apollo-11 的制导计算机AGC参数时我的反应是这玩意儿真的把人送上过月球主频 0.043 MHz内存 2048 字一个字 15 位只读存储器 36K 字全部代码用汇编手写没有操作系统没有高级语言没有浮点运算单元。放在今天随便一个电子表都比它算力强。但就是这套系统在 1969 年完成了载人登月最关键的导航、制导与控制任务。很多人对 Apollo-11 的理解停留在“人类第一次登月”这个历史事件上但如果你是从工程或者软件的角度去翻它的源码会发现这其实是一个极其硬核的实时嵌入式系统案例。它的核心价值不在于“古老”而在于它展示了一套在极端资源约束下如何做架构取舍、如何设计容错机制、如何让软件在硬件随时可能出问题的情况下依然把宇航员活着带回来的完整思路。这篇文章适合几类人看一是对嵌入式开发和实时系统感兴趣的人AGC 是一个教科书级别的资源受限系统设计样本二是对软件工程历史有兴趣的人Apollo-11 的源码在多年前已经公开里面有很多值得玩味的设计决策三是做高可靠性系统的人AGC 的冗余设计和优先级调度机制放到今天的航天、医疗、工业控制领域依然有参考价值。我写这篇的出发点很简单网上讲 Apollo-11 的文章大多停留在“哇好厉害”的层面很少有人把它的软件架构、执行逻辑、故障处理机制拆开来讲清楚。我想从工程视角把 AGC 这套系统里最值得学习的几个设计点讲透包括它为什么这么设计、当时面临什么约束、这些方案在今天看来是否还有意义。2. AGC 的硬件底子为什么 36K 代码能管一艘飞船2.1 内存和存储的真实配置先把这个系统的硬件参数摆清楚不然后面讲软件设计会没有参照。组件规格说明主频约 0.043 MHz时钟周期约 23 微秒内存RAM2048 字15 位/字可读写用于工作变量只读存储ROM约 36K 字15 位/字存储程序代码字长15 位不是 8 位也不是 16 位比较特殊指令类型约 30 条极简指令集浮点运算无硬件支持全部用软件模拟2048 个字的内存是什么概念你今天写一个稍微复杂点的函数局部变量加临时对象可能就超过这个数了。但 AGC 要用这 2048 个字管理飞船的姿态、导航、制导、生命支持监控、发动机控制等所有实时任务。这意味着每一个变量的分配都要精打细算不能有半点浪费。36K 字的 ROM 用来存程序。你可以理解为整个飞船的“操作系统加应用软件”总共只有这么多空间。对比一下今天一个简单的手机 App 动辄几十兆是 AGC 全部代码量的上千倍。2.2 15 位字长的设计逻辑为什么用 15 位而不是 8 位或 16 位这背后有很实际的工程考量。AGC 需要处理的角度、速度、加速度等物理量用 15 位可以表示的范围和精度刚好够用。如果用 8 位精度不够导航计算误差会累积到不可接受的程度如果用 16 位硬件成本会增加而在 1960 年代每一个逻辑门都是真金白银和重量。15 位可以表示 0 到 32767 的整数或者用补码表示 -16384 到 16383。对于大多数导航计算来说这个范围配合定点运算的缩放策略可以满足精度要求。AGC 的软件里大量使用“缩放因子”的概念就是把物理量乘以一个常数后存入整数变量计算完再除回来。这套做法在今天看来很原始但在没有浮点单元的硬件上这是唯一可行的方案。2.3 只读存储器的物理实现AGC 的 ROM 不是今天意义上的芯片而是所谓的“核心 rope 存储器”。每一根线穿过或绕过磁芯代表 0 或 1程序在出厂前就已经“编织”好了。这意味着程序一旦写好物理上就不可更改。这种存储方式的可靠性极高不怕断电不怕辐射但代价是没有任何灵活性。这个细节值得注意AGC 的软件在发射前经过了无数次地面测试和仿真因为一旦上天你不可能像今天推送更新一样去修 bug。所有的逻辑分支、所有的异常处理必须在编织之前就考虑周全。这种“一次写死”的约束反而倒逼出了极其严谨的软件工程实践。3. 执行框架没有操作系统的系统怎么跑起来3.1 固定周期调度一切任务都挂在时间轴上AGC 没有我们今天理解的操作系统没有进程、没有线程、没有动态内存分配。它的执行模型非常简单粗暴一个固定周期的调度器按照预设的时间表依次执行各个任务。具体来说AGC 的调度器以大约 11.7 毫秒为一个基本周期这个数字来自制导周期的需求。在每个周期内调度器按照优先级和固定顺序执行一系列“作业”job。每个作业有固定的执行时间预算如果某个作业超时调度器会记录异常并继续执行下一个。这种设计的好处是确定性极强。你可以在设计阶段就计算出最坏情况下每个周期的总执行时间确保不会超过硬件能力。坏处是灵活性差任何新增功能都必须重新做时间预算分析确认不会打破原有的调度平衡。3.2 优先级设计为什么导航比显示重要AGC 的任务优先级不是随便定的而是按照“如果这个任务失败宇航员还能不能活着回来”这个标准来排序的。最高优先级的是姿态控制和制导计算。飞船在太空中随时可能翻滚如果姿态失控发动机点火方向就是错的后果不堪设想。所以姿态控制任务必须保证每个周期都能执行不能被任何其他任务阻塞。其次是导航更新。导航计算需要处理雷达数据、惯性测量单元数据计算出飞船当前的位置和速度。这个任务的实时性要求也很高但可以容忍偶尔的延迟因为导航误差可以在后续周期中修正。最低优先级的是显示和键盘输入处理。宇航员通过 DSKY显示键盘单元输入指令、查看数据这个交互过程慢一点没关系宇航员可以等。如果系统负载过高显示刷新可以被推迟甚至跳过。这种优先级划分的逻辑在今天的安全关键系统里依然是金科玉律先保证核心控制回路再保证状态估计最后才是人机交互。3.3 中断处理什么时候可以打断当前任务AGC 支持有限的中断。最重要的中断来源是硬件时钟和某些关键传感器。中断处理程序必须极短通常只是设置一个标志位把实际处理推迟到下一个调度周期。这里有一个很值得学习的经验AGC 的中断处理程序不允许调用任何可能阻塞的函数也不允许做复杂的计算。所有中断要做的事情就是“记录事件发生了”然后尽快返回。这种“上半部极简、下半部处理”的模式和今天 Linux 内核的中断处理设计思路完全一致。我在实际做嵌入式开发时也遵循这个原则中断服务程序里只做最必要的事情比如读取硬件寄存器、清除中断标志、设置一个 volatile 变量。复杂的逻辑全部放到主循环里根据标志位来处理。这个习惯能避免很多难以调试的时序问题。4. 冗余与容错当硬件随时可能罢工4.1 双机热备还是冷备Apollo 飞船实际上有两套 AGC指令舱一套登月舱一套。在登月过程中登月舱的 AGC 负责主要的制导和导航指令舱的 AGC 处于监控状态。如果登月舱的 AGC 出现严重故障理论上可以切换到指令舱的系统但实际操作中这种切换非常复杂因为两套系统的传感器和执行机构不完全相同。更常见的做法是同一套 AGC 内部的冗余机制。AGC 的软件设计了大量自检和交叉验证逻辑。比如导航计算会同时用两种不同的算法计算位置如果两个结果差异超过阈值系统会报警并尝试判断哪个算法出了问题。4.2 重启机制1202 报警背后的设计哲学Apollo 11 登月过程中最著名的事件之一就是 1202 报警。这个报警代码的含义是“执行溢出”——调度器发现某个任务没有在规定时间内完成导致后续任务排队。当时的情况是登月舱的会合雷达被意外打开产生了大量数据占用了 AGC 的处理时间。调度器检测到任务超时后触发了重启机制。重启不是简单地重新启动系统而是执行一套精心设计的恢复流程清除低优先级任务的队列保留关键导航数据重新初始化调度器然后继续执行。这个机制的核心思想是当系统过载时主动丢弃不重要的任务保证核心功能存活。1202 报警实际上是一个“优雅降级”的信号而不是致命错误。宇航员和地面控制人员经过训练知道这个报警意味着什么所以没有惊慌。这个案例给我的启发很大。很多系统在设计时只考虑正常流程一旦遇到资源不足就崩溃或者死锁。AGC 的做法是承认资源永远可能不够提前设计好“不够的时候先扔什么”的规则。这种思路在今天的高并发服务、实时控制系统里同样适用。4.3 看门狗与故障恢复AGC 有一个硬件看门狗定时器。如果软件在预定时间内没有“喂狗”看门狗会触发系统复位。复位后软件会从特定的入口点重新开始执行并尝试恢复关键状态。这里有一个细节AGC 的复位不是冷启动而是“热重启”。一些关键变量存储在非易失性存储器或者有备用电源保护的内存区域复位后可以读取这些变量恢复到复位前的状态。这种设计让系统在遇到瞬时故障时能够快速恢复而不是从头开始。我在做工业控制项目时也用过类似的策略关键状态定期写入带电池备份的 SRAM看门狗复位后先读取这些状态判断是继续执行还是重新初始化。这个做法能显著提高系统的可用性。5. 人机交互DSKY 的设计智慧5.1 为什么只有数字键盘和简单显示屏DSKY 是宇航员和 AGC 交互的唯一界面。它有一个数字键盘、几个功能键、以及几行七段数码管显示屏。没有图形界面没有触摸屏没有鼠标。这种极简设计不是技术限制而是可靠性考量。在太空环境中每一个额外的组件都是潜在的故障点。图形显示屏需要更复杂的驱动电路触摸屏在失重和振动环境下可靠性存疑。数字键盘加数码管的结构简单、坚固、易于测试。从软件角度看DSKY 的交互协议也非常简单宇航员输入一个“动词”和一个“名词”比如“动词 06 名词 62”表示“显示当前速度”。AGC 解析这个指令执行相应操作把结果以数字形式显示出来。整个交互过程是确定性的、可预测的。5.2 输入验证与防错AGC 对 DSKY 输入做了严格的验证。如果宇航员输入了一个非法的动词或名词组合系统会显示错误提示拒绝执行。这种验证逻辑在软件中实现确保不会因为误操作导致危险动作。更关键的是某些关键操作需要二次确认。比如发动机点火指令需要宇航员输入特定的确认码后才会执行。这种“双人规则”在软件层面的体现就是关键命令需要两个独立的输入步骤。我在设计任何涉及安全关键操作的系统时都会借鉴这个思路危险操作必须有确认步骤确认步骤不能和初始操作在同一个界面完成最好有不同的输入通道。这样能最大程度避免误触。5.3 显示刷新的优先级处理前面提到显示任务是低优先级的。这意味着当系统负载高时DSKY 的显示可能不会立即更新。宇航员按下按键后可能需要等几百毫秒才能看到结果。这个延迟在正常操作中是可以接受的因为宇航员的操作节奏本来就不快。但在紧急情况下这个延迟可能会让人焦虑。AGC 的设计是即使显示更新被推迟按键输入本身不会被丢弃而是被缓存起来等系统有空闲时再处理。这个细节说明了一个重要的设计原则输入和输出可以有不同的实时性要求。输入不能丢但输出可以等。很多交互系统在设计时把输入输出绑定在一起处理导致高负载时输入响应变慢。分开处理能提高系统的响应性。6. 从 Apollo-11 源码里能学到什么6.1 代码组织模块化在 36K 里怎么做Apollo-11 的源码后来被公开可以在网上找到。翻看这些代码最让我惊讶的是它的模块化程度。尽管只有 36K 字的空间代码依然按照功能划分成清晰的模块姿态控制、导航、制导、显示驱动、键盘解析、故障处理等。每个模块有明确的接口定义模块之间的调用关系被严格控制。这种组织方式让代码可读、可测试、可维护。即使在今天很多嵌入式项目的代码组织还不如 AGC 清晰。我个人的经验是资源越紧张越需要好的代码结构。因为资源紧张意味着你不能靠“加一层抽象”来解决问题每一行代码都要用在刀刃上。这时候清晰的模块划分能帮你快速定位问题、评估修改影响。6.2 注释密度为什么每行代码都有解释AGC 源码的注释密度极高几乎每一行汇编指令都有对应的解释。这些注释不仅说明代码在做什么还说明为什么这样做、相关的物理量是什么、单位是什么、缩放因子是多少。这种注释风格在今天的商业代码里很少见但在安全关键系统里应该是标配。因为这类系统的代码生命周期很长维护者可能不是原始作者没有详细的注释根本无法理解和修改。我在写任何涉及硬件操作或者复杂算法的代码时都会强制自己写清楚这个变量的物理意义是什么、取值范围是多少、为什么选这个缩放因子、如果这个值异常可能是什么原因。这些注释在调试时能救命。6.3 测试与验证地面仿真怎么做AGC 的软件在投入使用前经过了大量的地面仿真测试。这些测试包括正常流程测试、边界条件测试、故障注入测试等。测试用例被精心设计覆盖了各种可能的异常场景。一个值得学习的做法是AGC 的测试不仅验证软件逻辑是否正确还验证软件在硬件故障时的行为。比如模拟某个传感器输出异常值观察软件是否能检测到并采取正确的容错措施。这种“故障注入测试”在今天的安全关键系统开发中是标准实践但在 1960 年代能这样做说明当时的工程团队对可靠性有极高的要求。7. 把 AGC 的思路用到今天的项目里7.1 资源受限场景下的取舍策略AGC 最核心的经验是在资源受限时必须明确什么是最重要的然后围绕这个核心做设计。AGC 的核心是“把宇航员安全送到月球并带回来”所有设计决策都围绕这个目标。在今天做嵌入式或者实时系统时这个思路依然适用。先问自己这个系统最核心的功能是什么如果资源不够哪些功能可以降级或丢弃把这些问题的答案写下来作为架构设计的依据。我见过很多项目在资源规划时“什么都想要”结果每个功能都做得半吊子关键时刻哪个都靠不住。AGC 的做法是反过来的先保证核心功能绝对可靠其他功能能砍就砍。7.2 优先级调度的通用模式AGC 的固定周期调度加优先级队列的模式可以直接搬到很多实时系统里。具体做法是确定系统的最小调度周期这个周期由最紧急的任务决定。把所有任务按照紧急程度排序分配优先级。为每个任务估算最坏执行时间确保一个周期内所有任务的总时间不超过周期长度。设计过载处理逻辑当任务超时时先丢弃低优先级任务保证高优先级任务完成。这套方法在工业控制、机器人、汽车电子等领域都很实用。关键是要在项目早期就做时间预算分析不要等到系统跑起来才发现时间不够。7.3 容错设计的检查清单从 AGC 的容错机制里我总结了一个检查清单每次做可靠性要求高的项目时都会过一遍系统有没有看门狗看门狗复位后能否恢复关键状态关键数据有没有冗余存储冗余数据的一致性怎么保证有没有过载检测机制过载时先丢弃什么关键操作有没有二次确认确认逻辑是否独立于初始操作有没有自检逻辑自检覆盖了哪些故障模式故障发生后系统是继续运行、降级运行还是安全停机这个清单不一定适用于所有项目但至少能帮你系统地思考容错问题而不是等到出事了才临时补救。8. 一个被忽略的细节AGC 的软件是“编织”出来的最后分享一个我觉得很有意思的细节。AGC 的程序不是烧录到芯片里的而是用“核心 rope 存储器”物理编织出来的。每一根导线穿过磁芯代表 1绕过磁芯代表 0。这意味着程序在物理上是一张网修改程序等于重新编织这张网。这个细节让我想到一个问题当软件变得“不可修改”时开发者的心态会有什么不同在 AGC 的时代程序员知道自己的代码一旦编织进去就改不了了所以他们在写每一行代码时都极其谨慎。今天的开发者习惯了随时热更新、随时回滚反而容易写出质量不高的代码。我不是说我们应该回到不可修改的时代但 AGC 的这种“一次写对”的心态值得学习。在提交代码之前问自己如果这段代码永远不能修改我还敢这样写吗如果答案是否定的那就再改改。这个思路在我做关键模块开发时特别有用。把每次提交都当成“最后一次修改”代码质量会有明显提升。