★ FEATURED ARTICLE 1. 从一行代码到月球Apollo-11 制导系统的工程遗产1969年7月20日阿波罗11号的登月舱鹰号在燃料仅剩约20秒余量的情况下由指令长手动接管最终降落在静海基地。这个被反复讲述的瞬间背后藏着一个很少被普通开发者讨论的事实那套让人类第一次踏上月球的制导计算机其核心软件由MIT仪器实验室的一群二十多岁的工程师用汇编语言手写而成存储容量以KB计主频以KHz计。而今天这份代码以“Apollo-11”为名被完整开源在代码托管平台上成为无数工程师反复研读的工程标本。我第一次接触这个项目时以为它只是一份历史档案。真正把代码拉下来、逐段读注释、对照任务报告看每个子程序的作用之后才意识到它更像一本“极端约束条件下的软件工程教科书”。它解决的问题——在算力、内存、实时性都逼近物理极限的前提下让一个不可逆的物理过程安全完成——和今天很多嵌入式、航天、工业控制、自动驾驶领域的核心挑战本质上是同一类问题。这篇文章适合几类人看做嵌入式或实时系统的工程师想理解“资源极度受限时如何做架构取舍”对航天软件、安全关键系统感兴趣的技术人以及任何想从一份真实运行过的历史代码里学到可迁移工程方法的人。我会从代码结构、核心算法、执行机制、工程取舍几个角度拆开讲尽量把“为什么这么设计”说透而不是只罗列代码片段。需要先说明一点这份开源代码是阿波罗制导计算机AGC的指令舱与登月舱软件原始形态是汇编清单和扫描件后来经过整理、注释和部分转写。网上流传的版本在细节上可能有差异我下面提到的结构、模块名、数值都基于公开可查的整理版本和任务报告具体到某一行可能与原始清单存在版本出入但工程逻辑是一致的。2. AGC的硬件底子决定了软件长什么样2.1 一台“用绳子和磁芯记忆”的计算机要读懂Apollo-11的代码必须先接受一个反直觉的前提这台计算机没有我们熟悉的任何现代抽象。AGCApollo Guidance Computer的核心存储是磁芯存储器只读部分叫核心绳存储器core rope memory。所谓“写代码”在当年是把铜线穿过磁环、绕或者不绕绕法代表0和1。这种物理写入方式意味着程序一旦“编”好几乎不可能现场修改改一个比特都要重新穿线。所以软件在发布前必须经过极其严苛的验证因为上天之后没有“热修复”这个选项。具体参数上AGC的字长是15位加上1位奇偶校验物理上16位主频大约2.048 MHz但一条指令往往要花多个周期。内存方面核心绳只读存储约36K字word可擦写的磁芯RAM约2K字。对比一下今天随便一个单片机都有几十KB RAM、几百KB Flash而AGC要用2K字RAM完成导航、制导、控制、人机交互、故障检测全部任务。注意这里说的“字”是15位不是现代常见的8位字节。做容量换算时不能直接按字节数对比否则会低估它的紧张程度。这种硬件约束直接决定了软件风格没有操作系统、没有动态内存分配、没有浮点运算单元、没有高级语言。所有计算靠定点数或自定义的缩放整数完成所有内存靠静态分配所有调度靠一个叫执行程序Executive的极简实时内核。2.2 为什么不用浮点一个必须算清楚的取舍现代开发者习惯直接写浮点但在AGC上浮点运算要么用软件模拟慢到无法满足实时性要么根本不做。AGC采用的是定点数加缩放因子的方案每个物理量在程序里都对应一个约定好的比例比如位置用“米”的某个分数表示速度用另一个比例。程序员必须时刻清楚每个变量当前代表什么量纲、范围多大、精度够不够。这个选择背后的逻辑很硬制导周期是2秒一次后来部分任务阶段更快在这2秒内要完成状态更新、导航滤波、制导指令计算、显示刷新。如果用软件浮点一次乘除法可能就要几百个周期根本跑不完。定点运算虽然要求程序员手动管理量纲但每条指令的周期数是确定的、可预测的——这在实时系统里比“平均快”重要得多。我自己的体会是今天做嵌入式如果遇到硬实时约束定点化依然是有效手段。很多MCU有FPU但FPU的中断延迟和上下文切换开销在极端场景下仍然不可忽略。AGC的思路是“把不确定性消灭在编译期”这个原则放到今天依然成立。2.3 执行程序一个只有几十个字的“操作系统”AGC的实时内核叫Executive它做的事情非常有限管理一组作业job按优先级调度处理中断维护等待队列。没有进程隔离没有虚拟内存没有文件系统。所有作业在编译期就确定好了运行时只是按优先级和触发条件激活。它的调度逻辑大致是每个作业有一个优先级Executive维护一个“当前可运行作业”的集合每次调度选最高优先级的执行。作业可以主动让出比如等待某个事件也可以被更高优先级作业抢占。这套机制简单到可以用几百字描述完但它保证了关键任务比如姿态控制永远能及时拿到CPU。这里有个值得借鉴的点优先级设计不是拍脑袋定的而是按任务的时间紧迫性反推的。姿态控制失灵的后果是灾难性的所以它的优先级最高显示刷新晚几十毫秒人眼几乎无感所以优先级低。今天做RTOS任务划分时这个“按失效后果定优先级”的原则同样适用而不是按“谁先写的代码”或者“谁看起来重要”。3. 核心程序模块每个模块都在解决一个不可回避的物理问题3.1 导航从星光和惯性中推算“我在哪”AGC的导航任务叫PGNCSPrimary Guidance, Navigation, and Control System的一部分核心是惯性测量单元IMU加光学观测。IMU提供加速度和角速度积分出位置和姿态但误差会随时间累积。所以宇航员会用六分仪观测特定恒星把观测结果喂给计算机用卡尔曼滤波类的算法修正惯性漂移。代码里对应的模块是导航子程序它要完成读取IMU脉冲、更新状态向量、处理光学观测、计算误差协方差。这里最精妙的是状态向量的设计位置、速度、姿态、加速度计偏置、陀螺漂移等都被纳入一个统一的状态空间滤波器同时估计这些量。这种“把系统误差也当成状态来估计”的思路是今天所有组合导航系统的鼻祖。实操上AGC的导航计算不是连续跑的而是按导航周期触发。每个周期里它先做状态传播用IMU数据外推再做观测更新如果有星光观测。这个“预测-校正”结构和今天自动驾驶里的多传感器融合框架几乎一模一样。区别只在于AGC用15位定点数、2K RAM完成了这套计算而今天我们动辄用浮点矩阵库、几十MB内存。3.2 制导把“去哪”翻译成“怎么推”导航回答“我在哪”制导回答“我该怎么飞”。Apollo-11的制导分几个阶段地球轨道、地月转移、月球轨道、下降、上升、返回。每个阶段有不同的制导律。以最惊险的登月下降为例制导程序要计算着陆点、下降轨迹、推力指令。它用的是多项式制导把下降轨迹参数化成时间的多项式每个制导周期重新计算目标加速度再转换成推力器的开关指令。这里的关键约束是燃料下降舱的推进剂有限制导必须保证在到达目标点时速度归零同时不能提前耗尽。代码里有个著名的1202报警和1201报警就是制导程序在雷达数据异常时触发的执行程序过载告警。当时地面控制中心判断“继续下降”因为报警来自非关键任务被挤掉而不是制导本身失效。这个决策背后是对任务优先级的深刻理解只要最高优先级的制导和导航还在跑低优先级的雷达更新可以丢。提示这个案例常被误读为“计算机快撑不住了”。准确地说是执行程序在按设计丢弃低优先级作业保证关键作业完成。这是优先级调度机制正常工作的表现不是bug。3.3 控制把指令变成姿态和推力控制模块接收制导输出的加速度指令转换成反作用控制系统RCS推力器的点火序列以及主发动机的节流指令。AGC要处理死区、最小脉冲宽度、推力器耦合等现实问题。比如RCS推力器不能无限快开关每次点火有最小持续时间控制算法必须考虑这个约束否则会出现“指令发了但推力没出来”的偏差。这部分代码里能看到大量查表和分段线性化因为定点运算做复杂函数计算太慢工程师把非线性关系预先算好、存成表格运行时插值。这种“用空间换时间”的手法在今天资源受限的MCU上依然是常用技巧。我自己做电机控制时也经常把复杂的磁场定向公式做成查表加插值效果和实时性都比现场算三角函数好。3.4 人机接口DSKY和那些“看起来很简单”的交互DSKYDisplay and Keyboard是宇航员和AGC交互的终端。它只有数字键盘、几行指示灯和数字显示。宇航员输入名词和动词编号来执行操作比如“动词37”是“改变程序”“名词65”是“显示着陆雷达数据”。这套接口的设计哲学是在高压、高噪声、戴手套的环境下交互必须绝对明确、零歧义。代码里对应的模块处理按键去抖、输入解析、显示刷新、报警闪烁。看起来简单但要在2K RAM里维护输入缓冲、显示状态、报警队列还要保证关键报警不被普通显示覆盖实际复杂度不低。这里有个细节报警优先级高于普通显示一旦触发显示会被强制切换。这个设计原则在今天的安全关键系统里依然是铁律——告警不能被任何非关键信息淹没。4. 那些让现代工程师拍案的工程手法4.1 解释器用“伪指令”压缩代码体积AGC软件里有一个解释器Interpreter它定义了一套伪指令每条伪指令对应一组底层操作。程序员写解释器指令运行时由解释器逐条解释执行。这听起来像“虚拟机”但在当年它的目的是压缩代码体积很多重复的计算模式比如向量运算、三角函数用伪指令表达比直接写汇编短得多。这个取舍很有意思解释执行比直接汇编慢但核心绳存储太贵省空间比省时间更重要。而且解释器的伪指令是面向数学运算设计的写起来更不容易出错。今天我们在资源受限设备上用字节码或脚本引擎逻辑是一样的当存储比算力更稀缺时抽象层是划算的。4.2 自检与冗余怎么知道“自己没坏”AGC有自检程序定期检查内存、指令执行、中断响应。更关键的是冗余设计指令舱和登月舱各有一台AGC任务关键阶段可以切换。软件层面关键变量有副本计算结果会交叉校验。如果主副本和备份不一致系统会触发报警并尝试恢复。这种“假设自己会坏”的设计思路在今天的功能安全标准里叫诊断覆盖率和失效模式分析。AGC没有现代的形式化验证工具但工程师用代码审查、数学证明、大量地面测试来逼近同样的目标。我读这部分代码时最大的感受是可靠性不是靠某个神奇算法而是靠无数个“如果这里错了会怎样”的追问堆出来的。4.3 固定优先级调度的边界与代价前面提到Executive按优先级调度这套机制有个必须正视的代价低优先级任务可能饿死。如果高优先级任务持续占用CPU低优先级永远拿不到时间。AGC的应对是高优先级任务被设计成短小、可预测执行完主动让出同时关键的低优先级任务比如某些显示更新有最坏执行时间保证调度器会预留时间片。这个权衡在今天依然存在。用RTOS时如果高优先级任务里写了阻塞调用或者长循环低优先级任务就会出问题。AGC的经验是优先级不是越高越好而是要和任务的时限要求匹配。一个任务如果晚100ms没影响就不该给它高优先级否则它会挤占真正紧急的任务。5. 把Apollo-11的代码跑起来实操路径与坑5.1 获取代码与模拟器环境公开的Apollo-11代码通常以汇编清单和注释版形式存在配套有AGC模拟器。模拟器可以加载核心绳镜像模拟DSKY输入输出甚至能跑完整的登月下降场景。环境准备上主流模拟器支持Linux、macOS部分有Windows移植。依赖一般包括C编译器和基础构建工具。我建议的路径是先跑通模拟器自带的演示脚本看DSKY显示和报警行为再尝试手动输入动词名词执行简单操作最后加载下降场景观察制导输出。不要一上来就啃汇编清单那样容易迷失在细节里。5.2 读代码的顺序从执行程序到应用模块读这份代码我推荐自顶向下先看Executive的调度逻辑理解作业怎么被激活再看中断处理理解外部事件怎么进入系统然后看导航和制导的主循环理解数据流最后才深入具体算法和查表。这样能先建立“系统怎么运转”的框架再填充细节。一个常见的坑是被汇编语法和宏定义劝退。AGC汇编有大量自定义宏和伪指令直接读会很痛苦。建议配合注释版和任务报告一起看注释版会把宏展开、把量纲标出来任务报告会解释每个阶段的物理背景。5.3 模拟器里的“意外”与真实约束跑模拟器时你可能会遇到输入了正确的动词名词但没反应或者报警灯乱闪。这往往不是模拟器bug而是输入序列不符合AGC的状态机要求。AGC对输入有严格的模式检查某些操作只在特定程序阶段有效某些需要先“使能”。这其实是安全设计——防止误操作触发危险动作。另一个坑是时间尺度模拟器可能以真实时间跑也可能加速。做下降场景时如果加速太快人来不及反应如果真实时间一次完整下降要十几分钟。建议先用加速模式观察整体流程再用真实时间体验关键决策点。6. 这份代码对今天做实时系统的启示6.1 资源约束下的架构原则AGC给我的最大启发是约束不是障碍而是设计指南。因为存储只有36K字所以必须模块化、必须复用、必须把通用逻辑抽成解释器因为算力只有2MHz所以必须定点化、必须查表、必须把最坏执行时间算清楚因为无法现场修改所以必须把验证做到极致。今天很多团队做嵌入式资源其实比AGC宽裕得多但架构反而更乱。原因往往是没有把约束当约束内存随便用、任务随便加、优先级随便定。AGC的做法是先把约束写下来再让每个设计决策对着约束解释。这个习惯我觉得比任何具体技术都值得学。6.2 安全关键系统的验证思路AGC的验证没有现代形式化工具但它的思路是穷举关键路径、交叉校验、冗余执行。具体来说关键计算用两种独立方法算结果比对关键变量存多份定期校验关键任务有看门狗超时报警。这些手法在今天的功能安全开发里依然是基础。我自己的经验是不要迷信工具先想清楚“这个模块坏了会怎样”。如果答案是“灾难性”那就必须有冗余、有校验、有降级策略。AGC的代码里到处是这种“如果错了怎么办”的痕迹读起来会觉得工程师很“啰嗦”但正是这种啰嗦救了命。6.3 从历史代码里学“可迁移的判断力”最后说点个人体会。读Apollo-11代码最大的收获不是某个算法而是判断力知道在什么约束下该做什么取舍。比如什么时候该用查表代替计算什么时候该用解释器代替直接汇编什么时候该丢任务保关键路径。这些判断没有标准答案但看多了真实案例自己遇到类似问题时会有直觉。我后来做工业控制项目遇到过一个场景MCU资源紧张但控制周期要求很硬。我参考AGC的思路把复杂补偿算法做成查表加线性插值把任务按失效后果排优先级把关键变量做双副本校验。最终系统稳定运行回头看很多决策都能在AGC代码里找到影子。这大概就是经典工程遗产的价值它不给你现成答案但给你一套思考框架。
阅读完成 · 觉得有帮助？
