去年年底我们团队内部启动了一个代号“Apollo-11”的复刻项目。目标不是造火箭而是把六十年代末那台飞控计算机的核心运行逻辑用现代工具链重新实现一遍跑通一个完整的“点火、升空、入轨、登月下降、返回”闭环流程。项目资料里几乎没有现成的设计文档只有一堆反汇编出来的老汇编代码、飞控时序图和几本扫描版的操作手册。整个项目做下来最大的感受是这不是在写程序而是在跟一个资源极其吝啬的古老世界对话。这篇博文不聊历史只聊技术聊我们怎么把一个三十万次/秒级别的老式计算机“请”回现代开发环境以及这中间踩过的坑和想明白的事。1. 项目启动前必须先面对的硬约束内存、字长和实时性1.1 为什么现代开发者会被这台老机器“教育”一次做这个项目之前团队里不少人觉得模拟一台老计算机而已用 Python 写个解释器把指令集翻译一遍就能跑。真正进入开发后发现事情远没有那么简单。那台计算机的字长是 15 位加上一个奇偶校验位本质上就是 16 位但是用户可用数据位只有 15 位。这意味着所有数值运算都要在 ±16383 的范围内小心翼翼任何中间结果超过这个范围就会产生溢出或者被截断。更折磨人的是内存。整个系统的可用存储只有几十KB而且分为固定存储和可擦写存储。固定存储用来存放只读的飞行程序可擦写存储用来存放临时变量、导航参数和用户输入。在现代开发环境里我们习惯了随手声明一个全局变量、定义一个结构体但在那个环境下每一个字的存储都要精打细算。我们的模拟器必须忠实还原这种“存储稀缺”的感受也就是在内存分配模块里加入了容量限制和碎片模拟一旦程序在模拟运行期间试图使用超过可擦写内存上限的空间整个系统就会陷入预置的停机程序。这个机制虽然让我们前期调试痛苦不堪但恰恰是最好的约束训练。1.2 实时性不是“快”而是“每毫秒都知道自己在干什么”另一个容易被低估的问题是实时性。现代操作系统里的线程调度、中断优先级、看门狗机制这些概念听起来很成熟但要把它们映射到一台单线程、顺序执行、有固定指令周期的机器上就需要重新理解“实时”的含义。老式飞控计算机没有操作系统只有一个循环调度器它不停地扫描时间计数器一旦时间到了就跳到对应的任务段。我们在模拟器里复刻了这种时间轮询机制一个基准时钟源以大约 10 毫秒为周期刷新任务状态。所有飞行阶段任务包括姿态读取、推进指令输出、显示刷新都必须在这个周期内完成。如果某个任务执行时间超过预分配的时间片系统不会优雅地报错而是直接进入“程序警报”状态。这一点给了我们很大压力因为在现代高级语言里一次 GC 暂停或者一次日志刷盘都可能导致时间片超限而这种问题在高性能服务器上往往是隐匿的在这里却会立刻让模拟飞行失败。表格对比一下我们在设计初期的几个关键约束约束维度老式飞控系统现代服务器环境复刻项目采用的策略字长15位有符号64位浮点使用整型模拟定义专用运算库存储量固定可擦写合计几十KB数百GB内存池限制模拟固定地址空间调度方式固定周期轮询抢占式多任务单线程事件循环严格时间片错误处理程序警报停机异常捕获日志警报状态机记录错误码和阶段输入方式数字键盘角度旋钮键盘图形界面基于命令行和脚本注入参数这个对比表直到项目结束都贴在白板上。每当有人想“加一个功能”时我们先看它是否突破了这些约束一旦违反就得重新设计。2. 核心架构复盘状态机驱动的飞行时序与点火控制2.1 把一整段任务拆成可回滚的阶段整个飞控流程并不是一个大循环而是一个严格的阶段状态机。我们从老汇编代码里梳理出了十几个主要阶段从预启动检查、推进剂增压、一级点火、升空、程序转弯、二级分离、三级点火、绕月轨道修正、登月下降、月面停留、上升返回到最后的再入指令执行。每个阶段都有一组前置条件、一组运行中条件和一组完成条件。阶段切换由“阶段跳转表”决定跳转条件不外乎三种到达某个时间点、惯性测量单元检测到某个速度阈值、地面指挥发出的特定指令。这个设计思想放到今天依然是教科书级别的因为它把复杂流程拆成了一个个可独立测试的小模块。我们重构这套逻辑时直接采用了一张状态跃迁表用配置文件而不是硬编码来维护。比如“一级点火”的前置条件是推进剂阀门压力大于阈值、应急终止系统已解除保险、当前时间在发射窗口范围内“一级点火”完成后通过“加速度达到设定值”这一条件进入“升空阶段”。每个状态还记录了“允许进入”和“禁止进入”两个开关用于故障注入测试。2.2 点火时序里藏着的细节中止判定与推进剂消耗率点火控制看着简单其实是最容易出错的模块。一个完整的点火序列不是单一继电器动作而是一组“先导、预燃、主燃”的精密时序。我们在模拟器里把点火过程设计成了四步打开液氧和燃料的主阀等待泵后压力建立。点火器通电开始燃烧室预燃。当燃烧室压力达到最低工作压力的 120% 时确认主阀锁定。根据加速度传感器的实际读数判断是否进入“上升”阶段如果 5 秒内加速度没有达到预定阈值则触发任务中止。这里有一个特别容易忽略的参数推进剂消耗率。很多人以为只要阀门打开推进剂流量就是恒定的。实际上贮箱内的压力会随液面降低而下降如果不针对剩余量做补偿发动机推力会持续衰减。老程序的做法是在固定时间点读取贮箱压力传感器通过一个查表程序估算剩余推进剂并据此调整混合比。这个查表程序是完全线性的但是在模拟中我们发现当推进剂温度变化时密度会改变导致查表结果偏差 5% 左右进而使入轨速度偏低。我们在项目中做的改进是模拟器里加入了“温度-密度”修正函数代表那个时代工程师如果有多余计算资源可能会采用的补充策略。但这带来新的问题修正函数会增加每次循环大约 2% 的指令数在资源受限的模拟约束下可能导致时间片超限。所以最后我们只能把修正函数从全时段调用改成“每 10 个周期调用一次”用牺牲一点精度的方式保证时序完整。状态机的另一个关键点是“可回滚”。每一次阶段切换前系统都会把关键参数时间、速度、高度、推进剂余量写入固定存储区如果后续某个阶段被判定为异常程序会尝试回到上一个正常状态。这在现代系统里叫“检查点”在当时就是一种朴素的卷回恢复机制。我们花了不少时间保证模拟器能处理“回滚后重新执行”的情况因为状态恢复时会涉及角度、速度等连续量的重复初始化很容易出现毛刺。3. 姿态控制没有高精度陀螺的年代如何把误差压到极限3.1 控制模型的选择比例控制加手工整定姿态控制模块是整个项目中我们学习最多的地方。现代飞控系统通常使用 PID 控制甚至更复杂的现代控制理论但那台老计算机的计算能力根本跑不动连续积分和复杂的矩阵运算。实际上老程序使用的是一种简化版的比例控制搭配死区判断和速率阻尼。换句话说系统不是时刻都在计算“我需要多大的修正力”而是设置了几个误差阈值当姿态角误差大于 5 度时启动全功率反作用喷气。当姿态角误差在 1 到 5 度之间时启动小推力脉冲。当姿态角误差小于 1 度时关闭喷气允许漂移。这种控制方式在工程上非常容易实现但有一个明显的缺陷在阈值边界处容易产生频繁切换也就是抖动。老程序解决抖动的办法很简单——引入了迟滞区间也就是误差从大到小和从小到大的切换阈值不同。例如从 5 度减小到 4 度时关闭大推力但想再次启动大推力需要误差增长到 6 度。这种迟滞设计有效减少了喷气频次也节约了宝贵推进剂。我们在复刻时用了同样的迟滞参数并额外做了一个自动化测试脚本把不同初始姿态角从 0 度到 90 度代入模拟器里跑发现迟滞区间的最佳宽度与喷气比冲、控制周期长度强相关。如果迟滞太窄会出现 10 赫兹左右的抖动如果太宽姿态收敛时间会变长。最后我们选择的参数是角度迟滞 2 度速率阻尼系数通过查表获得控制周期 80 毫秒。3.2 数字积分与有限字长带来的截断误差处理姿态解算中最核心的公式是把陀螺仪输出的角速度积分成姿态角。由于字长有限每次积分都会产生截断误差。如果一个控制周期是 80 毫秒那么 10 秒钟内就要做 125 次积分截断误差会逐步累积。老程序的做法不是单纯做积分而是使用一种“增量式更新”方式单独维护角度余量寄存器避免小角度被直接清零。我们在模拟器里也实现了这个技巧。具体的做法是不用浮点而是把角度值放大到用一个整数表示比如 1 度等于 1024 个计数单位。每次角速度乘以更新周期后加到角度寄存器里如果寄存器高于一个计数单位才更新整角度的部分。这个方法在嵌入式领域其实很常见算是一种“定点数”思路。这里有一个关键细节角速度传感器的值也会被量化。老程序的接口每次返回的角速度变化量是一个 14 位有符号数对应大约 ±20 度/秒。如果实际角速度低于一个最小分辨单位传感器会输出 0导致系统认为姿态没动。这就是“静差”问题。我们的模拟器在底层传感器模型里加入了 1 LSB 的量化噪声结果发现如果不做特殊处理静差会导致最终姿态角误差达到 3 度以上远超安全范围。老程序的解决方案是使用一个“伪随机抖动注入”技巧在每个控制周期向角度寄存器里添加一个小随机值幅度为一个最小分辨率的 1/4。这样做的好处是把量化误差随机化长期统计上平均误差会趋于零。虽然没办法完全消除但最终姿态误差从 3 度降到了 0.8 度以内。这种“用随机化对抗量化”的思路放到今天的位深度转换和传感器融合中依然是非常实用的。3.3 手动操作的优先级问题姿态控制模块还必须处理手动指令覆盖。在项目场景里航天员可以通过手持控制器输入六个方向的喷气指令这些指令的优先级高于自动控制逻辑。如果自动控制正在调整俯仰而用户同时输入了滚转指令系统必须保证手动滚转指令被执行而自动俯仰指令在手动输入期间被挂起但不丢失目标姿态。这在我们的状态机里表现为“控制权抢占”状态。我们在实现时发现如果手动指令持续时间很短小于一个控制周期很容易被调度器忽略导致按钮“失灵”。解决办法是引入一个“指令锁存器”任何手动指令都会被锁存至少两个控制周期确保调度器能在下一个周期看到它。这个细节花了一整个下午调试因为最初我们按照现代事件驱动的方式直接处理瞬态边沿导致许多短按键操作没有触发喷气。4. 地面测试与仿真如何把最复杂的几十分钟完整“跑”一遍4.1 硬件在环与人力在环让真实传感器参与模拟要验证飞控代码是否靠谱最简单的方法是把整个流程放到模拟器里跑一遍。但纯软件模拟有一个问题传感器模型太“干净”了现实世界中的噪声、漂移、非线性都被抹平。为了让测试更可信我们设计了硬件在环测试环境。具体的做法是将模拟器的姿态角输出转换为三轴转台的转动指令转台上的真实陀螺仪再把测量值送回到飞控计算机的输入接口。这个测试环境最大的价值是暴露了计算延迟的问题。我们用的三轴转台响应带宽大约 100 赫兹而模拟器的主循环只有 12.5 赫兹。当姿态角误差较大时转台可能在两个指令之间产生滞后导致飞控系统看到的角速度误差偏大。如果不加入延迟补偿算法系统会误以为喷气过冲反而产生振荡。我们为此选了一个简单粗暴的解决方式在传感器模型里人为增加一个 120 毫秒的延迟模拟真实设备与计算机之间的通信延迟。实践证明这个延迟模型比无线通信模拟器还要管用因为它逼着控制算法显式考虑信号的相位差。老程序在那个时代就已经通过一些“提前角”查表来补偿这种延迟我们复刻时把提前角表直接写进了姿态控制器效果立竿见影。4.2 故障注入清单那些最容易摧毁任务的中场事件测试不能只测“正常流程”。我们对老代码里的故障处理逻辑做了详细梳理整理了一份故障注入清单每一类故障都要在阶段模型里触发并验证恢复策略。我把最重要的几类列在下面加速度计数据瞬断表现为连续 5 个控制周期内数据为零需要切换到备用传感器。推进剂阀门卡滞表现为命令开阀后压力不上升需要在规定时间内触发中止。陀螺仪常值漂移表现为角速度输出始终带有 0.5 度/秒的偏差导致积分姿态角缓慢漂移。通信指令丢失地面控制指令在某个阶段内未收到确认系统应保持现有状态并请求重发。时钟计数溢出时间寄存器达到上限后必须回绕同时不会影响阶段判定。其中时钟计数溢出是我们一开始忽视的坑。时间寄存器是 14 位的最大值是 16383 秒大约 4.55 小时。正常任务总时长超过这个值所以必须处理回绕。如果程序只使用“当前时间是否大于结束时间”来判断阶段在回绕后就会失效。老程序的策略是维护一个任务累计时间使用一个额外的计数寄存器记录回绕次数再结合低位时间做判断。我们在模拟器里仿照这个策略实现了一个“扩展时间结构体”本质上是把 14 位时间扩展成了 32 位无符号整型但底层寄存器读写仍然按 14 位模拟。这个做法保持了老机器的约束特性同时避免了逻辑漏洞。4.3 测试报告里必须包含的数值不只是“成功”或“失败”早期我们做测试只在控制台打印“飞行成功”或者“失败某阶段异常”。后来发现这种输出对定位问题毫无帮助。我们决定参考老系统“遥测数据记录”的方式把每次飞行过程中的关键参数每隔 1 秒记录一行任务完成百分比。当前阶段标识。高度和速度用整数值。姿态角误差俯仰、偏航、滚转。可用推进剂量。累计程序警报次数。故障注入标识。通过这些数值可以画出每一轮测试的“健康曲线”。最典型的一个案例是某一轮测试中所有指标看起来都很正常但推进剂消耗量明显比上一轮多了 6%。我们从记录里发现姿态角误差在某个时间段内反复穿越迟滞区间但没有触发大喷气所以系统一直在用小推力脉冲修正。虽然修正有效但累计脉冲次数过多推进剂消耗就上去了。如果没有秒级遥测记录这个问题根本不可能被发现。从这以后我们的所有测试都必须附上完整的数值序列不能只给结论。这个习惯让整个团队在排查问题上提速不少。5. 从“Apollo-11”项目里提炼出现的工程启示5.1 资源受限是最高效的设计老师现代开发者习惯了一个函数库几百兆、一个环境依赖几十上百个包。但在那个模拟环境中我们被迫一次次精简逻辑去掉一切不必要的中间变量把循环展开、把查询表放在固定地址、把数值范围反复核算。当你的程序跑在只有几十KB内存、每秒钟只能执行几十万条指令的模拟环境里时你会自然理解为什么老代码里会有那么多“魔法数字”和“技巧性分支”。它们不是为了炫技而是为了活下来。我从这个项目里得到的最直接启示是设计系统时先画一条资源底线再谈功能。哪怕你的目标硬件性能很充裕也要想清楚“最差情况下需要留多少余量”。这个思路在后来的生产环境中帮我避免了好几次内存溢出和性能退化。5.2 状态机的健壮性比状态数量更重要飞行时序这类任务非常依赖状态机。理论上状态越多覆盖的场景越完善但状态过多也会导致状态间的跳转关系难以验证。我们在复盘时统计过整个核心状态机有 24 个正常状态和 18 个故障处理状态总共 42 个节点。这个数量在今天的软件工程里其实不算多但难点在于每个状态要维护不同的参数上下文。状态机如果设计得不严谨很容易出现“某状态能进入但不能退出”的情况。老程序的做法是给每个状态预定义“最小停留时间”和“最大停留时间”。最小停留时间防止状态被瞬间跳过最大停留时间防止状态卡死。我们在模拟器里严格执行了这两个约束效果非常好。状态卡死的问题出现时系统会先触发“最大停留时间超限”警报再进入故障处理流程而不是无限等待外部输入。这个经验对现代微服务和工控系统同样适用每个状态都该有超时保护哪怕是“等待外部事件”这种看似无限期的状态。5.3 测试的价值在于注入不确定性如果只按正常流程测试任何系统看起来都很可靠。真正的可靠性只有在异常场景中才能体现。老程序的故障处理路径大多没有经过精心设计更像是一种“边飞边修正”的应急逻辑。我们在复刻过程中发现故障处理路径的可读性远低于正常路径但它们的复杂度一点也不低。如果没有故障注入这些路径可能直到任务结束也不会被执行到。所以我给团队的建议是把测试预算的一半花在故障注入上而不是快乐路径上。哪怕故障注入没有发现新问题它至少能验证系统在异常出现时不会产生“越权控制”或“静默失败”。这一点对任何对安全性有要求的系统都成立。6. 几个让我记忆深刻的小细节与后续扩展思路整个项目做了大概四个月最后阶段我们甚至把老式界面按键的输入方式也搬进了模拟器——一组数字按键加旋转式角度输入。这种交互方式在今天看来笨拙得离谱但也正因为笨拙逼着操作者必须在极短时间内思考清楚再输入指令。这给了我一个反向启发很多系统设计都倾向于把交互做得越来越简单但在高复杂度环境下一种引入约束的交互反而能减少误操作。原因很简单有限的功能按钮迫使操作者遵循预定义流程而自由灵活的通用输入则会给人留下太多“想当然”的空间。扩展方面我们正在做一个有趣的方向把模拟器接入到开源飞行模拟软件中让飞控系统实时驱动一个可视化场景。这样每一次测试飞行都能以三维视角被“看”出来。相比只看数字曲线可视化可以直观发现控制逻辑里一些细微的时序问题比如推进器喷流方向与目标姿态变化的不匹配。另一个更偏底层的扩展是把我们还原的定点数运算库提取出来做成一个独立的开源库。这个库可以用于其他资源受限平台比如裸机微控制器、FPGA 原型验证或极低成本的传感器融合场景。很多现代开发者已经不熟悉定点数的溢出陷阱但只要用过这个库跑几次模拟就会意识到浮点并不是唯一选择。当年那台飞控计算机在地面上被无数工程师反复测试那些测试流程里唯一的“高级工具”就是一张一张检查单。我们把它搬进模拟器后逐渐体会到一种轻盈又沉重的心情轻盈的是今天我们终于可以用高配置的机器和高级语言自由地重构一切沉重的是重构得越逼真就越能感受到那个时代工程师在毫厘之间搏斗的艰难。这个项目的意义不在于复刻一个多少年前的旧程序而在于让我们这些后来者有机会亲手触碰“极致约束下如何设计可靠系统”这个永恒课题。如果这篇复盘能给你哪怕一点启发比如更重视状态超时保护、更敬畏资源边界、更愿意在测试计划里注入不确定性那这次折腾就值了。