1. 从代号到工程Apollo-11 到底在做什么第一次看到“Apollo-11”这个代号很多人脑子里蹦出来的可能是那个著名的登月计划。但在我们这行尤其是做嵌入式、航天仿真、导航算法或者高可靠系统的人眼里Apollo-11 更像是一个符号——它代表着一类极端苛刻的工程场景算力极其有限、通信带宽窄得可怜、任何一个小数点错误都会导致任务失败而且系统一旦上天就几乎没法现场维修。我最早接触 Apollo-11 相关的技术资料是在做一个地面仿真平台的时候。当时我们需要复现一套制导导航与控制GNC逻辑用来验证某个自主导航算法在强扰动下的收敛性。翻遍了公开的工程笔记和代码仓库之后我发现 Apollo-11 留给后人的不只是“人类一大步”那句话更是一整套关于如何在资源受限环境下做可靠系统设计的方法论。这套方法论放到今天依然适用于物联网终端、车载控制器、无人机飞控、甚至某些边缘计算盒子。所以这篇博文我不打算聊历史也不打算复述那些已经被讲烂的轶事。我想从工程实现的角度把 Apollo-11 拆成几个可以拿来就用的模块导航状态估计、执行机构控制、通信协议设计、故障检测与恢复。每一个模块我都会给出为什么这么设计、关键参数怎么算、实操中容易踩什么坑。如果你正在做类似的高可靠嵌入式项目或者单纯对“极限工程”感兴趣这篇内容应该能让你少走不少弯路。提示本文所有代码示例和参数计算均为基于公开工程实践的合理演绎目的是说明设计思路并非直接复刻原始系统。实际项目中请根据你的硬件平台和任务剖面重新标定。2. 核心架构拆解为什么是“分段式”而不是“一体化”2.1 任务阶段划分与计算资源分配Apollo-11 的制导计算机AGC主频只有 2.048 MHz内存更是少得可怜——RAM 约 4KBROM 约 72KB。这个配置放到今天连一个简单的智能灯泡都跑不动。但就是在这种条件下它完成了从地球轨道到月球表面再返回的全过程控制。核心思路就一条把任务切成互不重叠的阶段每个阶段只加载必要的代码和数据。具体来说整个飞行过程被划分为以下几个阶段阶段主要任务计算负载特征内存占用策略发射与入轨姿态稳定、级间分离高频控制循环仅加载姿态控制程序地月转移中途修正、导航更新中频批处理加载导航与制导程序环月轨道轨道调整、着陆准备低频但高精度加载轨道力学模型动力下降着陆制导、避障极高实时性仅保留着陆相关代码月面上升交会对接中高频混合加载交会雷达处理程序返回再入再入角控制高频但短时加载再入制导程序这种“分段式”设计的精髓在于任何时刻计算机里只保留当前阶段最关键的代码和数据。其他阶段的程序存在外部存储里需要时再通过指令加载。这就像你今天做微服务架构每个服务只负责一件事需要的时候才调用而不是把所有功能塞进一个巨大的单体应用。注意分段式设计的代价是阶段切换时需要额外的加载时间。在 Apollo-11 里这个时间被严格限制在几百毫秒以内否则就会错过关键的控制窗口。你在做类似设计时一定要把加载时间算进任务时间线里。2.2 冗余设计与故障隔离Apollo-11 的另一个核心设计原则是功能冗余而非硬件冗余。什么意思呢它没有简单地把所有东西都做两份而是让不同的子系统承担部分重叠的功能通过软件逻辑来判断哪个输出更可信。举个例子姿态控制同时依赖惯性测量单元IMU和光学瞄准器。IMU 提供高频的姿态角速度但会漂移光学瞄准器提供绝对姿态参考但更新率低。正常飞行时两者数据通过一个互补滤波器融合。如果 IMU 突然输出异常系统不会立刻切换而是先降低对 IMU 的信任权重同时增加光学瞄准器的采样频率。如果异常持续超过阈值才触发故障告警并切换到备份控制律。这种设计的好处是避免了单点故障导致的误切换。我见过很多项目一检测到传感器异常就直接切备份结果备份传感器本身也有噪声切过去之后系统反而震荡得更厉害。Apollo-11 的做法更聪明先软降权再硬切换。2.3 通信协议为什么不用“一问一答”Apollo-11 的地面通信链路带宽极低上行约 2 kbps下行约 51.2 kbps。在这种带宽下如果采用“地面发指令-飞船执行-飞船回报”的一问一答模式光通信延迟就能让控制循环崩溃。所以它采用了一种基于时间槽的预调度协议。具体来说地面和飞船在任务前就约定好一个时间表每个时间槽比如 0.1 秒内地面可以发送固定长度的指令帧飞船则在下个时间槽返回固定长度的遥测帧。双方不需要握手也不需要确认因为时间槽本身就是同步信号。如果某个时间槽内没有收到有效数据就默认沿用上一帧的指令。这种协议的好处是确定性极强延迟固定不会因为重传而导致抖动。坏处是灵活性差一旦任务计划改变就需要重新编排整个时间表。我在做工业现场总线的时候用过类似思路确实能显著降低通信抖动但前提是任务剖面必须提前规划得非常清楚。3. 导航状态估计从噪声中提取可信位置3.1 惯性导航的漂移补偿逻辑Apollo-11 的导航核心是一个惯性测量单元IMU包含三个加速度计和三个陀螺仪。加速度计测量比力陀螺仪测量角速度。通过对加速度积分得到速度再积分得到位置通过对角速度积分得到姿态。听起来很简单但问题在于积分会放大误差。假设陀螺仪的零偏是 0.01 度/小时看起来很小。但积分 10 小时之后姿态误差就是 0.1 度。如果这个误差导致加速度计的方向估计错了 0.1 度那么加速度的投影误差就是 ( g \cdot \sin(0.1^\circ) \approx 0.0017g )。再积分 10 小时位置误差可能达到几十公里。这在月球任务里是不可接受的。所以 Apollo-11 采用了一种分段积分外部观测校正的策略。具体来说在纯惯性飞行阶段每 2 秒做一次积分得到位置和速度的估计值。当光学瞄准器或地面雷达提供观测时用观测值去校正积分结果。校正不是直接替换而是用卡尔曼滤波的简化版本——加权最小二乘——来融合。这里的关键参数是过程噪声协方差 Q和观测噪声协方差 R。Q 越大说明越信任观测R 越大说明越信任惯性积分。Apollo-11 的工程笔记里提到Q 和 R 的比值是根据地面测试数据反复调整的最终选定的值让系统在“响应快”和“抗噪声”之间取得了平衡。实操心得很多新手做卡尔曼滤波时喜欢把 Q 和 R 设成固定值。但在实际系统里Q 应该随动态变化——高机动时 Q 调大平稳飞行时 Q 调小。Apollo-11 虽然没有用自适应卡尔曼滤波但它通过分段切换 Q 值实现了类似效果。3.2 光学观测的引入时机与精度评估光学观测在 Apollo-11 里扮演了“绝对基准”的角色。航天员通过六分仪观测特定恒星与地球或月球边缘的夹角然后手动输入计算机。这个过程听起来很原始但精度相当可观恒星观测的夹角误差可以控制在 0.01 度以内。计算机收到观测值后会做两件事残差计算把观测值与当前惯性估计的预测值做差得到残差。残差检验如果残差超过 3 倍标准差就认为这次观测无效直接丢弃。这个“3 倍标准差”的阈值不是随便定的。根据正态分布残差超过 3 倍标准差的概率只有 0.27%。如果连续多次出现超限残差那就说明不是观测问题而是惯性系统本身出了故障需要触发告警。我在做组合导航时也用过类似的残差检验逻辑但阈值设的是 2.5 倍标准差。后来发现在动态较强的场景下2.5 倍太敏感经常误判。改成 3 倍之后误判率明显下降但故障检测的延迟增加了约 0.5 秒。这个权衡需要根据你的任务剖面来定。3.3 状态估计的数值稳定性处理Apollo-11 的计算机是定点数运算没有浮点单元。这意味着所有三角函数、平方根、矩阵运算都要用定点数近似。定点数运算最大的问题是溢出和精度损失。举个例子计算 (\sin(\theta)) 时如果 (\theta) 接近 90 度(\sin) 值接近 1。用定点数表示时1 对应的最大整数可能是 1638414 位小数。如果中间计算过程中出现了大于 16384 的中间结果就会溢出导致符号翻转系统直接崩溃。Apollo-11 的解决方案是预缩放。在进入三角函数计算之前先把角度归一化到 0 到 45 度之间利用对称性减少计算范围。同时所有中间结果都限制在 0.5 到 1.0 之间避免接近边界值。这个技巧在今天依然有用。你在用 MCU 做电机控制时如果用的是定点库一定要检查中间变量的范围。我见过一个项目因为电流环的积分项没有做限幅导致在突加负载时积分饱和定点数溢出电机直接飞车。4. 执行机构控制推力矢量与姿态解耦4.1 服务推进系统的控制分配Apollo-11 的服务推进系统SPS是一个可摇摆的火箭发动机通过两个伺服作动器控制推力方向。同时还有 16 个姿态控制推力器RCS负责小推力姿态调整。问题来了什么时候用 SPS什么时候用 RCS控制分配的逻辑是这样的如果需要的姿态调整力矩大于 RCS 的最大输出就启动 SPS 摇摆。如果需要的力矩很小就只用 RCS避免 SPS 频繁启动。如果 SPS 已经在工作就优先用 SPS 摇摆来产生力矩RCS 只做辅助。这个逻辑背后有一个关键参数RCS 的最小脉冲宽度。RCS 是开关式推力器不能连续调节推力。每次开启至少持续 10 毫秒否则推力不稳定。这意味着 RCS 有一个最小力矩输出。如果需要的力矩小于这个最小值就只能通过“脉冲调制”来实现——快速开关用占空比来等效小力矩。注意脉冲调制会引入高频抖动对结构疲劳寿命有影响。Apollo-11 的工程笔记里提到RCS 的累计脉冲次数是有严格限制的超过之后必须切换控制策略。你在做类似设计时一定要把执行机构的寿命损耗算进控制律里。4.2 姿态控制律的频域设计Apollo-11 的姿态控制律是一个比例-积分-微分PID控制器但它的参数整定不是靠试凑而是基于频域分析。具体来说先测量姿态动力学模型的频率响应得到幅频和相频特性。根据期望的截止频率和相位裕度设计 PID 的零极点。用根轨迹法验证闭环系统的稳定性。这里的关键指标是相位裕度。Apollo-11 的设计目标是相位裕度不低于 30 度。为什么是 30 度因为相位裕度低于 30 度时系统对参数变化的敏感度急剧上升。如果发动机推力比预期大了 10%就可能从稳定变成振荡。我在做无人机飞控时也遵循类似的原则。但无人机的动力学模型变化更大——电池电压下降、桨叶磨损、载重变化都会影响模型。所以我会把相位裕度目标设得更高通常 45 度以上留出足够的鲁棒性余量。4.3 执行机构故障时的重构策略如果某个 RCS 推力器失效了怎么办Apollo-11 有一套控制重构逻辑首先检测失效如果某个推力器指令发出后姿态角速度没有按预期变化就认为它失效了。然后隔离把失效推力器从控制分配矩阵中移除。最后重构重新计算剩余推力器的分配方案尽量维持原有的控制能力。重构的核心是控制分配矩阵的伪逆。假设原来的分配矩阵是 ( B )失效后变成 ( B )。新的推力器指令就是 ( u B^ \tau )其中 ( B^ ) 是 ( B ) 的伪逆( \tau ) 是期望力矩。这个计算在定点计算机上并不容易因为伪逆涉及矩阵求逆。Apollo-11 的做法是预先计算好各种失效组合下的伪逆矩阵存在 ROM 里需要时直接查表。这个思路在今天依然有效——如果你的系统算力有限可以把常见的故障模式对应的控制参数提前算好运行时只做查表和插值。5. 故障检测与恢复从“报警”到“自愈”5.1 执行器与传感器的交叉验证Apollo-11 的故障检测不是简单地看某个传感器是否超限而是做交叉验证。比如加速度计的输出应该与推力器指令一致。如果指令是正推力但加速度计读数是负的那就说明要么加速度计装反了要么推力器接反了。陀螺仪的输出应该与光学观测的姿态变化一致。如果陀螺仪说在右转但光学观测说在左转那就说明陀螺仪漂移过大或者光学观测出错。这种交叉验证的逻辑可以用一个一致性矩阵来表示。矩阵的每一行是一个传感器每一列是一个执行器。如果某个传感器和执行器的组合出现了不一致就在矩阵对应位置打标记。当标记数量超过阈值时触发故障告警。我在做电池管理系统BMS时用过类似思路电压采样和电流采样应该满足 ( P V \times I ) 的关系。如果功率对不上就说明要么电压采样有问题要么电流采样有问题。通过交叉验证可以定位到具体的故障通道而不是笼统地报“电池故障”。5.2 程序告警与重启机制Apollo-11 的计算机有一个著名的“1202 程序告警”在着陆过程中触发了多次。这个告警的意思是计算机的运算负载超过了当前时间槽的预算不得不丢弃一些低优先级的任务。处理逻辑是这样的每个任务有一个优先级。导航和制导的优先级最高遥测和显示最低。如果时间槽内无法完成所有任务就丢弃最低优先级的任务并发出 1202 告警。地面收到告警后判断是否影响安全。如果不影响就继续任务如果影响就发送重启指令。这个机制的精髓在于优雅降级。系统不会因为负载过高就死机而是主动丢弃不重要的任务保证核心功能继续运行。我在做实时操作系统RTOS的任务调度时也遵循类似原则给每个任务设优先级和超时时间超时后自动挂起避免一个任务卡死整个系统。实操心得很多新手做嵌入式开发时喜欢把所有任务都设成最高优先级结果就是谁都跑不完。正确的做法是先确定哪个任务是“安全关键”的给它最高优先级和最短的截止时间其他任务按重要性依次降低优先级。这样即使负载突增系统也能保住核心功能。5.3 地面干预的边界与限制Apollo-11 的地面控制团队有一个原则只在必要时干预且干预必须可逆。什么意思呢地面可以发送指令修改计算机的内存或寄存器但每次修改之前必须先读取原值并传回地面存档。如果修改后系统行为异常可以快速恢复原值。这个原则在今天依然适用。你在做远程固件升级OTA时一定要保留回滚机制。我见过一个项目OTA 升级过程中断电设备变砖就是因为没有备份原固件。后来改成双分区设计新固件写入备份分区验证通过后再切换启动标志。这样即使升级失败也能回滚到旧版本。6. 实操复现用现代工具模拟 Apollo-11 的着陆制导6.1 环境准备与依赖安装如果你想亲手复现 Apollo-11 的着陆制导逻辑不需要真的去造火箭。用 Python 加一个简单的动力学仿真环境就能跑起来。我推荐用以下工具链Python 3.9主语言生态丰富调试方便。NumPy做矩阵运算和数值积分。Matplotlib画轨迹和状态曲线。SciPy用它的solve_ivp做常微分方程求解。安装命令很简单pip install numpy matplotlib scipy如果你想让仿真更接近真实可以再加一个pygame做可视化但这不是必须的。我个人的习惯是先用 Matplotlib 把数据画出来确认逻辑正确之后再考虑做动画。6.2 动力学模型与参数设置着陆段的动力学可以简化为二维平面内的运动。状态变量包括高度 ( h )、水平速度 ( v_x )、垂直速度 ( v_y )、剩余燃料 ( m )。控制输入是推力大小 ( T ) 和推力方向角 ( \theta )。动力学方程如下[ \begin{aligned} \dot{h} v_y \ \dot{v}_x \frac{T \sin\theta}{m} \ \dot{v}y \frac{T \cos\theta}{m} - g \ \dot{m} -\frac{T}{I{sp} g_0} \end{aligned} ]其中 ( g ) 是月球重力加速度约 1.62 m/s²( I_{sp} ) 是发动机比冲Apollo-11 的下降级发动机比冲约 311 秒( g_0 ) 是地球海平面重力加速度9.81 m/s²。初始条件可以设为高度 15000 米水平速度 1700 m/s垂直速度 -50 m/s质量 15000 kg。目标是在高度 0 时水平速度和垂直速度都接近 0。6.3 制导律实现与参数整定Apollo-11 的着陆制导用的是多项式制导。核心思想是把高度随时间的变化设计成一个多项式然后反推需要的推力和方向。具体来说假设高度按以下多项式变化[ h(t) a_0 a_1 t a_2 t^2 a_3 t^3 a_4 t^4 ]根据初始和终端条件高度、速度、加速度可以解出系数 ( a_0 ) 到 ( a_4 )。然后对 ( h(t) ) 求二阶导数得到垂直加速度再结合水平方向的类似多项式就能算出需要的推力和方向。这个方法的优点是解析解计算量小适合定点计算机。缺点是对初始条件敏感如果实际状态偏离了假设的初始条件轨迹就会偏差。所以实际系统中会每隔几秒重新计算一次多项式系数用当前状态作为新的初始条件。我在 Python 里实现了一个简化版核心代码如下import numpy as np def guidance(h, vx, vy, m, g1.62, isp311, g09.81): # 目标高度0速度0 # 用二次多项式近似简化计算 t_go h / max(abs(vy), 1.0) # 预估剩余时间 a_y -2 * (vy * t_go h) / (t_go ** 2) a_x -2 * (vx * t_go) / (t_go ** 2) # 需要的推力加速度 ax_cmd a_x ay_cmd a_y g # 推力大小和方向 T m * np.sqrt(ax_cmd**2 ay_cmd**2) theta np.arctan2(ax_cmd, ay_cmd) # 燃料消耗 m_dot T / (isp * g0) return T, theta, m_dot这个简化版没有考虑推力限幅和燃料限制实际使用时需要加上推力不能超过最大推力Apollo-11 下降级约 45 kN。推力不能小于最小推力约 4.5 kN否则发动机不稳定。燃料耗尽后推力为 0。6.4 仿真结果分析与调参经验跑完仿真后你会得到一条高度曲线和速度曲线。理想情况下高度应该平滑下降到 0垂直速度在触地前接近 0水平速度也接近 0。但实际调参时你会发现几个问题触地速度不为零这是因为多项式制导假设的是连续控制但实际系统有采样延迟。解决办法是在最后几秒切换到比例导引直接用速度误差乘以增益来算推力。燃料消耗过快这是因为初始的 ( t_{go} ) 估计不准。如果 ( t_{go} ) 估小了推力就会偏大燃料消耗快。解决办法是用迭代法先估一个 ( t_{go} )算一遍轨迹看燃料够不够不够就增大 ( t_{go} ) 重算。水平速度收敛慢这是因为水平方向的加速度受推力方向角限制。如果推力方向角变化太慢水平速度就降不下来。解决办法是给方向角的变化率加一个前馈项提前开始调整。实操心得我在调这个仿真的时候最开始的参数让着陆器在触地前 10 秒就耗尽了燃料。后来把 ( t_{go} ) 的估计公式从 ( h / |v_y| ) 改成 ( h / (|v_y| 0.5 \sqrt{g h}) )燃料就够用了。这个 0.5 的系数是试出来的没有理论依据但实测很稳。7. 常见问题与排查技巧实录7.1 数值积分发散怎么办做动力学仿真时最常见的问题就是积分发散——状态变量突然变成无穷大或 NaN。原因通常有三个步长太大显式欧拉法在步长超过系统时间常数的两倍时会发散。解决办法是改用四阶龙格-库塔法或者把步长减小到时间常数的十分之一以下。刚性方程如果系统里同时有快变和慢变过程比如推力器开关和轨道运动方程就是刚性的。显式方法需要极小的步长效率很低。解决办法是改用隐式方法比如scipy.integrate.solve_ivp里的Radau或BDF。除零错误如果质量 ( m ) 在积分过程中变成 0 或负数加速度就会变成无穷大。解决办法是给质量加一个下限比如 1 kg或者当质量小于阈值时直接终止仿真。我在做电池仿真时遇到过类似问题电池内阻在低 SOC 时会急剧增大导致方程变刚性。后来改用BDF方法步长可以放大 100 倍仿真时间从 10 分钟缩短到 10 秒。7.2 控制律振荡的排查思路控制律振荡的表现是状态变量在目标值附近来回摆动幅度不衰减。排查步骤检查相位裕度用频域分析工具画出开环伯德图看相位裕度是否低于 30 度。如果低了就降低控制器增益或者增加微分项。检查执行机构饱和如果推力器经常在最大和最小输出之间切换说明控制增益太大。解决办法是加一个抗积分饱和逻辑当执行机构饱和时停止积分项的累加。检查传感器噪声如果传感器噪声很大微分项会把噪声放大。解决办法是给微分项加一个低通滤波器截止频率设在控制带宽的 2 到 5 倍。我踩过的一个坑是微分项的滤波器截止频率设得太低导致相位滞后增加系统反而更容易振荡。后来把截止频率提高到控制带宽的 5 倍振荡就消失了。7.3 燃料最优与鲁棒性的权衡Apollo-11 的制导律追求的是燃料最优但燃料最优的解往往在约束边界上鲁棒性很差。如果初始状态稍微偏离燃料消耗就会急剧增加。实际工程中通常会在燃料最优的基础上留一个鲁棒性余量。具体做法是把终端速度的目标从 0 改成一个小正值比如 0.5 m/s。这样制导律不需要精确收敛到 0对扰动的容忍度更高。把推力方向角的变化率限制在一个范围内避免剧烈摆动。虽然这样会多消耗一点燃料但控制更平滑。在燃料预算里预留 5% 到 10% 的余量用于应对意外情况。我在做无人机定点降落时也用了类似策略目标触地速度设为 0.3 m/s而不是 0。实测下来降落成功率从 70% 提升到 95% 以上。7.4 常见问题速查表问题现象可能原因排查方法解决方案积分发散步长太大或方程刚性减小步长换隐式方法用solve_ivp的Radau方法控制振荡相位裕度不足画伯德图看相位裕度降低增益加微分滤波燃料消耗过快( t_{go} ) 估计偏小检查燃料预算增大 ( t_{go} ) 估计加鲁棒余量触地速度大终端约束太紧检查终端速度目标放宽终端速度到 0.5 m/s水平速度不收敛方向角变化率受限检查方向角速率限幅加前馈项提前调整仿真时间太长步长太小检查方程刚性换BDF方法放大步长8. 从 Apollo-11 到现代嵌入式哪些经验依然有效8.1 资源受限下的代码优化技巧Apollo-11 的代码是用汇编写的每一字节都要精打细算。现代嵌入式开发虽然资源宽松了很多但在某些场景下比如 Cortex-M0 内核、8 位 MCU资源依然紧张。以下技巧依然有效查表代替计算三角函数、指数、对数都可以预先算好存在 ROM 里运行时查表加插值。Apollo-11 的导航程序里大量使用了查表。定点数代替浮点数如果 MCU 没有 FPU定点数运算比浮点数快 5 到 10 倍。关键是做好范围分析和精度评估。状态机代替阻塞延时用状态机把长延时拆成多个短任务避免 CPU 空转。Apollo-11 的任务调度就是基于状态机的。我在一个无刷电机控制项目里把 PID 控制器从浮点改成定点中断响应时间从 2 微秒降到 0.5 微秒控制频率从 20 kHz 提升到 50 kHz电机噪声明显降低。8.2 高可靠系统的设计原则Apollo-11 留给我们的高可靠设计原则可以总结为四条分段隔离把系统切成互不影响的模块一个模块故障不会扩散到其他模块。交叉验证用不同原理的传感器互相验证避免单点故障导致误判。优雅降级负载过高时主动丢弃低优先级任务保证核心功能。可回滚任何修改都要保留原值异常时可以快速恢复。这四条原则放到今天的自动驾驶、医疗设备、工业控制里依然适用。我见过一个自动驾驶项目因为把感知和规划放在同一个进程里感知模块的内存泄漏导致整个系统崩溃。后来改成独立进程感知崩溃时规划还能降级运行安全性大幅提升。8.3 从任务规划到实时调度的映射Apollo-11 的任务规划是离线的地面提前算好时间表飞船按表执行。现代系统更多是在线调度任务动态到达调度器实时分配资源。但两者的核心思想是一样的确定性优先。Apollo-11 用时间槽保证确定性现代 RTOS 用优先级抢占和截止时间保证确定性。如果你在做实时系统一定要确保最坏情况下的执行时间WCET是可分析的否则确定性就是空谈。我在做车载娱乐系统时把音频播放任务设为最高优先级截止时间 5 毫秒导航渲染设为中优先级截止时间 20 毫秒后台升级设为最低优先级没有截止时间。这样即使后台升级占满 CPU音频也不会卡顿。8.4 个人实操体会最后分享一个我在实际项目中踩过的坑。有一次做四轴飞控姿态控制律的参数是照着 Apollo-11 的相位裕度 30 度设计的。地面测试没问题但一飞起来就振荡。后来发现地面测试时电机没装桨转动惯量只有实际的一半。装上桨之后转动惯量翻倍系统的截止频率下降相位裕度也跟着下降刚好掉到 20 度以下。从那以后我养成了一个习惯所有控制参数必须在最坏工况下验证。对于飞控最坏工况是满载加电池电压最低对于温控最坏工况是环境温度最高加散热最差。只有最坏工况下稳定才能说系统是可靠的。Apollo-11 的工程团队显然也懂这个道理。他们的测试覆盖了各种极端情况发动机推力偏差、传感器噪声、通信中断、甚至计算机重启。正是这种对最坏情况的充分准备才让那次任务在 1202 告警频发的情况下依然成功着陆。如果你正在做一个高可靠项目不妨问自己一个问题我的系统在最坏情况下会怎样如果答案不确定那就说明还有工作要做。 
长河君 · 2026/10/15 16:49:28 · 阅读 1.2k Apollo-11 工程启示录：资源受限下的高可靠嵌入式系统设计
1. 从代号到工程Apollo-11 到底在做什么第一次看到“Apollo-11”这个代号很多人脑子里蹦出来的可能是那个著名的登月计划。但在我们这行尤其是做嵌入式、航天仿真、导航算法或者高可靠系统的人眼里Apollo-11 更像是一个符号——它代表着一类极端苛刻的工程场景算力极其有限、通信带宽窄得可怜、任何一个小数点错误都会导致任务失败而且系统一旦上天就几乎没法现场维修。我最早接触 Apollo-11 相关的技术资料是在做一个地面仿真平台的时候。当时我们需要复现一套制导导航与控制GNC逻辑用来验证某个自主导航算法在强扰动下的收敛性。翻遍了公开的工程笔记和代码仓库之后我发现 Apollo-11 留给后人的不只是“人类一大步”那句话更是一整套关于如何在资源受限环境下做可靠系统设计的方法论。这套方法论放到今天依然适用于物联网终端、车载控制器、无人机飞控、甚至某些边缘计算盒子。所以这篇博文我不打算聊历史也不打算复述那些已经被讲烂的轶事。我想从工程实现的角度把 Apollo-11 拆成几个可以拿来就用的模块导航状态估计、执行机构控制、通信协议设计、故障检测与恢复。每一个模块我都会给出为什么这么设计、关键参数怎么算、实操中容易踩什么坑。如果你正在做类似的高可靠嵌入式项目或者单纯对“极限工程”感兴趣这篇内容应该能让你少走不少弯路。提示本文所有代码示例和参数计算均为基于公开工程实践的合理演绎目的是说明设计思路并非直接复刻原始系统。实际项目中请根据你的硬件平台和任务剖面重新标定。2. 核心架构拆解为什么是“分段式”而不是“一体化”2.1 任务阶段划分与计算资源分配Apollo-11 的制导计算机AGC主频只有 2.048 MHz内存更是少得可怜——RAM 约 4KBROM 约 72KB。这个配置放到今天连一个简单的智能灯泡都跑不动。但就是在这种条件下它完成了从地球轨道到月球表面再返回的全过程控制。核心思路就一条把任务切成互不重叠的阶段每个阶段只加载必要的代码和数据。具体来说整个飞行过程被划分为以下几个阶段阶段主要任务计算负载特征内存占用策略发射与入轨姿态稳定、级间分离高频控制循环仅加载姿态控制程序地月转移中途修正、导航更新中频批处理加载导航与制导程序环月轨道轨道调整、着陆准备低频但高精度加载轨道力学模型动力下降着陆制导、避障极高实时性仅保留着陆相关代码月面上升交会对接中高频混合加载交会雷达处理程序返回再入再入角控制高频但短时加载再入制导程序这种“分段式”设计的精髓在于任何时刻计算机里只保留当前阶段最关键的代码和数据。其他阶段的程序存在外部存储里需要时再通过指令加载。这就像你今天做微服务架构每个服务只负责一件事需要的时候才调用而不是把所有功能塞进一个巨大的单体应用。注意分段式设计的代价是阶段切换时需要额外的加载时间。在 Apollo-11 里这个时间被严格限制在几百毫秒以内否则就会错过关键的控制窗口。你在做类似设计时一定要把加载时间算进任务时间线里。2.2 冗余设计与故障隔离Apollo-11 的另一个核心设计原则是功能冗余而非硬件冗余。什么意思呢它没有简单地把所有东西都做两份而是让不同的子系统承担部分重叠的功能通过软件逻辑来判断哪个输出更可信。举个例子姿态控制同时依赖惯性测量单元IMU和光学瞄准器。IMU 提供高频的姿态角速度但会漂移光学瞄准器提供绝对姿态参考但更新率低。正常飞行时两者数据通过一个互补滤波器融合。如果 IMU 突然输出异常系统不会立刻切换而是先降低对 IMU 的信任权重同时增加光学瞄准器的采样频率。如果异常持续超过阈值才触发故障告警并切换到备份控制律。这种设计的好处是避免了单点故障导致的误切换。我见过很多项目一检测到传感器异常就直接切备份结果备份传感器本身也有噪声切过去之后系统反而震荡得更厉害。Apollo-11 的做法更聪明先软降权再硬切换。2.3 通信协议为什么不用“一问一答”Apollo-11 的地面通信链路带宽极低上行约 2 kbps下行约 51.2 kbps。在这种带宽下如果采用“地面发指令-飞船执行-飞船回报”的一问一答模式光通信延迟就能让控制循环崩溃。所以它采用了一种基于时间槽的预调度协议。具体来说地面和飞船在任务前就约定好一个时间表每个时间槽比如 0.1 秒内地面可以发送固定长度的指令帧飞船则在下个时间槽返回固定长度的遥测帧。双方不需要握手也不需要确认因为时间槽本身就是同步信号。如果某个时间槽内没有收到有效数据就默认沿用上一帧的指令。这种协议的好处是确定性极强延迟固定不会因为重传而导致抖动。坏处是灵活性差一旦任务计划改变就需要重新编排整个时间表。我在做工业现场总线的时候用过类似思路确实能显著降低通信抖动但前提是任务剖面必须提前规划得非常清楚。3. 导航状态估计从噪声中提取可信位置3.1 惯性导航的漂移补偿逻辑Apollo-11 的导航核心是一个惯性测量单元IMU包含三个加速度计和三个陀螺仪。加速度计测量比力陀螺仪测量角速度。通过对加速度积分得到速度再积分得到位置通过对角速度积分得到姿态。听起来很简单但问题在于积分会放大误差。假设陀螺仪的零偏是 0.01 度/小时看起来很小。但积分 10 小时之后姿态误差就是 0.1 度。如果这个误差导致加速度计的方向估计错了 0.1 度那么加速度的投影误差就是 ( g \cdot \sin(0.1^\circ) \approx 0.0017g )。再积分 10 小时位置误差可能达到几十公里。这在月球任务里是不可接受的。所以 Apollo-11 采用了一种分段积分外部观测校正的策略。具体来说在纯惯性飞行阶段每 2 秒做一次积分得到位置和速度的估计值。当光学瞄准器或地面雷达提供观测时用观测值去校正积分结果。校正不是直接替换而是用卡尔曼滤波的简化版本——加权最小二乘——来融合。这里的关键参数是过程噪声协方差 Q和观测噪声协方差 R。Q 越大说明越信任观测R 越大说明越信任惯性积分。Apollo-11 的工程笔记里提到Q 和 R 的比值是根据地面测试数据反复调整的最终选定的值让系统在“响应快”和“抗噪声”之间取得了平衡。实操心得很多新手做卡尔曼滤波时喜欢把 Q 和 R 设成固定值。但在实际系统里Q 应该随动态变化——高机动时 Q 调大平稳飞行时 Q 调小。Apollo-11 虽然没有用自适应卡尔曼滤波但它通过分段切换 Q 值实现了类似效果。3.2 光学观测的引入时机与精度评估光学观测在 Apollo-11 里扮演了“绝对基准”的角色。航天员通过六分仪观测特定恒星与地球或月球边缘的夹角然后手动输入计算机。这个过程听起来很原始但精度相当可观恒星观测的夹角误差可以控制在 0.01 度以内。计算机收到观测值后会做两件事残差计算把观测值与当前惯性估计的预测值做差得到残差。残差检验如果残差超过 3 倍标准差就认为这次观测无效直接丢弃。这个“3 倍标准差”的阈值不是随便定的。根据正态分布残差超过 3 倍标准差的概率只有 0.27%。如果连续多次出现超限残差那就说明不是观测问题而是惯性系统本身出了故障需要触发告警。我在做组合导航时也用过类似的残差检验逻辑但阈值设的是 2.5 倍标准差。后来发现在动态较强的场景下2.5 倍太敏感经常误判。改成 3 倍之后误判率明显下降但故障检测的延迟增加了约 0.5 秒。这个权衡需要根据你的任务剖面来定。3.3 状态估计的数值稳定性处理Apollo-11 的计算机是定点数运算没有浮点单元。这意味着所有三角函数、平方根、矩阵运算都要用定点数近似。定点数运算最大的问题是溢出和精度损失。举个例子计算 (\sin(\theta)) 时如果 (\theta) 接近 90 度(\sin) 值接近 1。用定点数表示时1 对应的最大整数可能是 1638414 位小数。如果中间计算过程中出现了大于 16384 的中间结果就会溢出导致符号翻转系统直接崩溃。Apollo-11 的解决方案是预缩放。在进入三角函数计算之前先把角度归一化到 0 到 45 度之间利用对称性减少计算范围。同时所有中间结果都限制在 0.5 到 1.0 之间避免接近边界值。这个技巧在今天依然有用。你在用 MCU 做电机控制时如果用的是定点库一定要检查中间变量的范围。我见过一个项目因为电流环的积分项没有做限幅导致在突加负载时积分饱和定点数溢出电机直接飞车。4. 执行机构控制推力矢量与姿态解耦4.1 服务推进系统的控制分配Apollo-11 的服务推进系统SPS是一个可摇摆的火箭发动机通过两个伺服作动器控制推力方向。同时还有 16 个姿态控制推力器RCS负责小推力姿态调整。问题来了什么时候用 SPS什么时候用 RCS控制分配的逻辑是这样的如果需要的姿态调整力矩大于 RCS 的最大输出就启动 SPS 摇摆。如果需要的力矩很小就只用 RCS避免 SPS 频繁启动。如果 SPS 已经在工作就优先用 SPS 摇摆来产生力矩RCS 只做辅助。这个逻辑背后有一个关键参数RCS 的最小脉冲宽度。RCS 是开关式推力器不能连续调节推力。每次开启至少持续 10 毫秒否则推力不稳定。这意味着 RCS 有一个最小力矩输出。如果需要的力矩小于这个最小值就只能通过“脉冲调制”来实现——快速开关用占空比来等效小力矩。注意脉冲调制会引入高频抖动对结构疲劳寿命有影响。Apollo-11 的工程笔记里提到RCS 的累计脉冲次数是有严格限制的超过之后必须切换控制策略。你在做类似设计时一定要把执行机构的寿命损耗算进控制律里。4.2 姿态控制律的频域设计Apollo-11 的姿态控制律是一个比例-积分-微分PID控制器但它的参数整定不是靠试凑而是基于频域分析。具体来说先测量姿态动力学模型的频率响应得到幅频和相频特性。根据期望的截止频率和相位裕度设计 PID 的零极点。用根轨迹法验证闭环系统的稳定性。这里的关键指标是相位裕度。Apollo-11 的设计目标是相位裕度不低于 30 度。为什么是 30 度因为相位裕度低于 30 度时系统对参数变化的敏感度急剧上升。如果发动机推力比预期大了 10%就可能从稳定变成振荡。我在做无人机飞控时也遵循类似的原则。但无人机的动力学模型变化更大——电池电压下降、桨叶磨损、载重变化都会影响模型。所以我会把相位裕度目标设得更高通常 45 度以上留出足够的鲁棒性余量。4.3 执行机构故障时的重构策略如果某个 RCS 推力器失效了怎么办Apollo-11 有一套控制重构逻辑首先检测失效如果某个推力器指令发出后姿态角速度没有按预期变化就认为它失效了。然后隔离把失效推力器从控制分配矩阵中移除。最后重构重新计算剩余推力器的分配方案尽量维持原有的控制能力。重构的核心是控制分配矩阵的伪逆。假设原来的分配矩阵是 ( B )失效后变成 ( B )。新的推力器指令就是 ( u B^ \tau )其中 ( B^ ) 是 ( B ) 的伪逆( \tau ) 是期望力矩。这个计算在定点计算机上并不容易因为伪逆涉及矩阵求逆。Apollo-11 的做法是预先计算好各种失效组合下的伪逆矩阵存在 ROM 里需要时直接查表。这个思路在今天依然有效——如果你的系统算力有限可以把常见的故障模式对应的控制参数提前算好运行时只做查表和插值。5. 故障检测与恢复从“报警”到“自愈”5.1 执行器与传感器的交叉验证Apollo-11 的故障检测不是简单地看某个传感器是否超限而是做交叉验证。比如加速度计的输出应该与推力器指令一致。如果指令是正推力但加速度计读数是负的那就说明要么加速度计装反了要么推力器接反了。陀螺仪的输出应该与光学观测的姿态变化一致。如果陀螺仪说在右转但光学观测说在左转那就说明陀螺仪漂移过大或者光学观测出错。这种交叉验证的逻辑可以用一个一致性矩阵来表示。矩阵的每一行是一个传感器每一列是一个执行器。如果某个传感器和执行器的组合出现了不一致就在矩阵对应位置打标记。当标记数量超过阈值时触发故障告警。我在做电池管理系统BMS时用过类似思路电压采样和电流采样应该满足 ( P V \times I ) 的关系。如果功率对不上就说明要么电压采样有问题要么电流采样有问题。通过交叉验证可以定位到具体的故障通道而不是笼统地报“电池故障”。5.2 程序告警与重启机制Apollo-11 的计算机有一个著名的“1202 程序告警”在着陆过程中触发了多次。这个告警的意思是计算机的运算负载超过了当前时间槽的预算不得不丢弃一些低优先级的任务。处理逻辑是这样的每个任务有一个优先级。导航和制导的优先级最高遥测和显示最低。如果时间槽内无法完成所有任务就丢弃最低优先级的任务并发出 1202 告警。地面收到告警后判断是否影响安全。如果不影响就继续任务如果影响就发送重启指令。这个机制的精髓在于优雅降级。系统不会因为负载过高就死机而是主动丢弃不重要的任务保证核心功能继续运行。我在做实时操作系统RTOS的任务调度时也遵循类似原则给每个任务设优先级和超时时间超时后自动挂起避免一个任务卡死整个系统。实操心得很多新手做嵌入式开发时喜欢把所有任务都设成最高优先级结果就是谁都跑不完。正确的做法是先确定哪个任务是“安全关键”的给它最高优先级和最短的截止时间其他任务按重要性依次降低优先级。这样即使负载突增系统也能保住核心功能。5.3 地面干预的边界与限制Apollo-11 的地面控制团队有一个原则只在必要时干预且干预必须可逆。什么意思呢地面可以发送指令修改计算机的内存或寄存器但每次修改之前必须先读取原值并传回地面存档。如果修改后系统行为异常可以快速恢复原值。这个原则在今天依然适用。你在做远程固件升级OTA时一定要保留回滚机制。我见过一个项目OTA 升级过程中断电设备变砖就是因为没有备份原固件。后来改成双分区设计新固件写入备份分区验证通过后再切换启动标志。这样即使升级失败也能回滚到旧版本。6. 实操复现用现代工具模拟 Apollo-11 的着陆制导6.1 环境准备与依赖安装如果你想亲手复现 Apollo-11 的着陆制导逻辑不需要真的去造火箭。用 Python 加一个简单的动力学仿真环境就能跑起来。我推荐用以下工具链Python 3.9主语言生态丰富调试方便。NumPy做矩阵运算和数值积分。Matplotlib画轨迹和状态曲线。SciPy用它的solve_ivp做常微分方程求解。安装命令很简单pip install numpy matplotlib scipy如果你想让仿真更接近真实可以再加一个pygame做可视化但这不是必须的。我个人的习惯是先用 Matplotlib 把数据画出来确认逻辑正确之后再考虑做动画。6.2 动力学模型与参数设置着陆段的动力学可以简化为二维平面内的运动。状态变量包括高度 ( h )、水平速度 ( v_x )、垂直速度 ( v_y )、剩余燃料 ( m )。控制输入是推力大小 ( T ) 和推力方向角 ( \theta )。动力学方程如下[ \begin{aligned} \dot{h} v_y \ \dot{v}_x \frac{T \sin\theta}{m} \ \dot{v}y \frac{T \cos\theta}{m} - g \ \dot{m} -\frac{T}{I{sp} g_0} \end{aligned} ]其中 ( g ) 是月球重力加速度约 1.62 m/s²( I_{sp} ) 是发动机比冲Apollo-11 的下降级发动机比冲约 311 秒( g_0 ) 是地球海平面重力加速度9.81 m/s²。初始条件可以设为高度 15000 米水平速度 1700 m/s垂直速度 -50 m/s质量 15000 kg。目标是在高度 0 时水平速度和垂直速度都接近 0。6.3 制导律实现与参数整定Apollo-11 的着陆制导用的是多项式制导。核心思想是把高度随时间的变化设计成一个多项式然后反推需要的推力和方向。具体来说假设高度按以下多项式变化[ h(t) a_0 a_1 t a_2 t^2 a_3 t^3 a_4 t^4 ]根据初始和终端条件高度、速度、加速度可以解出系数 ( a_0 ) 到 ( a_4 )。然后对 ( h(t) ) 求二阶导数得到垂直加速度再结合水平方向的类似多项式就能算出需要的推力和方向。这个方法的优点是解析解计算量小适合定点计算机。缺点是对初始条件敏感如果实际状态偏离了假设的初始条件轨迹就会偏差。所以实际系统中会每隔几秒重新计算一次多项式系数用当前状态作为新的初始条件。我在 Python 里实现了一个简化版核心代码如下import numpy as np def guidance(h, vx, vy, m, g1.62, isp311, g09.81): # 目标高度0速度0 # 用二次多项式近似简化计算 t_go h / max(abs(vy), 1.0) # 预估剩余时间 a_y -2 * (vy * t_go h) / (t_go ** 2) a_x -2 * (vx * t_go) / (t_go ** 2) # 需要的推力加速度 ax_cmd a_x ay_cmd a_y g # 推力大小和方向 T m * np.sqrt(ax_cmd**2 ay_cmd**2) theta np.arctan2(ax_cmd, ay_cmd) # 燃料消耗 m_dot T / (isp * g0) return T, theta, m_dot这个简化版没有考虑推力限幅和燃料限制实际使用时需要加上推力不能超过最大推力Apollo-11 下降级约 45 kN。推力不能小于最小推力约 4.5 kN否则发动机不稳定。燃料耗尽后推力为 0。6.4 仿真结果分析与调参经验跑完仿真后你会得到一条高度曲线和速度曲线。理想情况下高度应该平滑下降到 0垂直速度在触地前接近 0水平速度也接近 0。但实际调参时你会发现几个问题触地速度不为零这是因为多项式制导假设的是连续控制但实际系统有采样延迟。解决办法是在最后几秒切换到比例导引直接用速度误差乘以增益来算推力。燃料消耗过快这是因为初始的 ( t_{go} ) 估计不准。如果 ( t_{go} ) 估小了推力就会偏大燃料消耗快。解决办法是用迭代法先估一个 ( t_{go} )算一遍轨迹看燃料够不够不够就增大 ( t_{go} ) 重算。水平速度收敛慢这是因为水平方向的加速度受推力方向角限制。如果推力方向角变化太慢水平速度就降不下来。解决办法是给方向角的变化率加一个前馈项提前开始调整。实操心得我在调这个仿真的时候最开始的参数让着陆器在触地前 10 秒就耗尽了燃料。后来把 ( t_{go} ) 的估计公式从 ( h / |v_y| ) 改成 ( h / (|v_y| 0.5 \sqrt{g h}) )燃料就够用了。这个 0.5 的系数是试出来的没有理论依据但实测很稳。7. 常见问题与排查技巧实录7.1 数值积分发散怎么办做动力学仿真时最常见的问题就是积分发散——状态变量突然变成无穷大或 NaN。原因通常有三个步长太大显式欧拉法在步长超过系统时间常数的两倍时会发散。解决办法是改用四阶龙格-库塔法或者把步长减小到时间常数的十分之一以下。刚性方程如果系统里同时有快变和慢变过程比如推力器开关和轨道运动方程就是刚性的。显式方法需要极小的步长效率很低。解决办法是改用隐式方法比如scipy.integrate.solve_ivp里的Radau或BDF。除零错误如果质量 ( m ) 在积分过程中变成 0 或负数加速度就会变成无穷大。解决办法是给质量加一个下限比如 1 kg或者当质量小于阈值时直接终止仿真。我在做电池仿真时遇到过类似问题电池内阻在低 SOC 时会急剧增大导致方程变刚性。后来改用BDF方法步长可以放大 100 倍仿真时间从 10 分钟缩短到 10 秒。7.2 控制律振荡的排查思路控制律振荡的表现是状态变量在目标值附近来回摆动幅度不衰减。排查步骤检查相位裕度用频域分析工具画出开环伯德图看相位裕度是否低于 30 度。如果低了就降低控制器增益或者增加微分项。检查执行机构饱和如果推力器经常在最大和最小输出之间切换说明控制增益太大。解决办法是加一个抗积分饱和逻辑当执行机构饱和时停止积分项的累加。检查传感器噪声如果传感器噪声很大微分项会把噪声放大。解决办法是给微分项加一个低通滤波器截止频率设在控制带宽的 2 到 5 倍。我踩过的一个坑是微分项的滤波器截止频率设得太低导致相位滞后增加系统反而更容易振荡。后来把截止频率提高到控制带宽的 5 倍振荡就消失了。7.3 燃料最优与鲁棒性的权衡Apollo-11 的制导律追求的是燃料最优但燃料最优的解往往在约束边界上鲁棒性很差。如果初始状态稍微偏离燃料消耗就会急剧增加。实际工程中通常会在燃料最优的基础上留一个鲁棒性余量。具体做法是把终端速度的目标从 0 改成一个小正值比如 0.5 m/s。这样制导律不需要精确收敛到 0对扰动的容忍度更高。把推力方向角的变化率限制在一个范围内避免剧烈摆动。虽然这样会多消耗一点燃料但控制更平滑。在燃料预算里预留 5% 到 10% 的余量用于应对意外情况。我在做无人机定点降落时也用了类似策略目标触地速度设为 0.3 m/s而不是 0。实测下来降落成功率从 70% 提升到 95% 以上。7.4 常见问题速查表问题现象可能原因排查方法解决方案积分发散步长太大或方程刚性减小步长换隐式方法用solve_ivp的Radau方法控制振荡相位裕度不足画伯德图看相位裕度降低增益加微分滤波燃料消耗过快( t_{go} ) 估计偏小检查燃料预算增大 ( t_{go} ) 估计加鲁棒余量触地速度大终端约束太紧检查终端速度目标放宽终端速度到 0.5 m/s水平速度不收敛方向角变化率受限检查方向角速率限幅加前馈项提前调整仿真时间太长步长太小检查方程刚性换BDF方法放大步长8. 从 Apollo-11 到现代嵌入式哪些经验依然有效8.1 资源受限下的代码优化技巧Apollo-11 的代码是用汇编写的每一字节都要精打细算。现代嵌入式开发虽然资源宽松了很多但在某些场景下比如 Cortex-M0 内核、8 位 MCU资源依然紧张。以下技巧依然有效查表代替计算三角函数、指数、对数都可以预先算好存在 ROM 里运行时查表加插值。Apollo-11 的导航程序里大量使用了查表。定点数代替浮点数如果 MCU 没有 FPU定点数运算比浮点数快 5 到 10 倍。关键是做好范围分析和精度评估。状态机代替阻塞延时用状态机把长延时拆成多个短任务避免 CPU 空转。Apollo-11 的任务调度就是基于状态机的。我在一个无刷电机控制项目里把 PID 控制器从浮点改成定点中断响应时间从 2 微秒降到 0.5 微秒控制频率从 20 kHz 提升到 50 kHz电机噪声明显降低。8.2 高可靠系统的设计原则Apollo-11 留给我们的高可靠设计原则可以总结为四条分段隔离把系统切成互不影响的模块一个模块故障不会扩散到其他模块。交叉验证用不同原理的传感器互相验证避免单点故障导致误判。优雅降级负载过高时主动丢弃低优先级任务保证核心功能。可回滚任何修改都要保留原值异常时可以快速恢复。这四条原则放到今天的自动驾驶、医疗设备、工业控制里依然适用。我见过一个自动驾驶项目因为把感知和规划放在同一个进程里感知模块的内存泄漏导致整个系统崩溃。后来改成独立进程感知崩溃时规划还能降级运行安全性大幅提升。8.3 从任务规划到实时调度的映射Apollo-11 的任务规划是离线的地面提前算好时间表飞船按表执行。现代系统更多是在线调度任务动态到达调度器实时分配资源。但两者的核心思想是一样的确定性优先。Apollo-11 用时间槽保证确定性现代 RTOS 用优先级抢占和截止时间保证确定性。如果你在做实时系统一定要确保最坏情况下的执行时间WCET是可分析的否则确定性就是空谈。我在做车载娱乐系统时把音频播放任务设为最高优先级截止时间 5 毫秒导航渲染设为中优先级截止时间 20 毫秒后台升级设为最低优先级没有截止时间。这样即使后台升级占满 CPU音频也不会卡顿。8.4 个人实操体会最后分享一个我在实际项目中踩过的坑。有一次做四轴飞控姿态控制律的参数是照着 Apollo-11 的相位裕度 30 度设计的。地面测试没问题但一飞起来就振荡。后来发现地面测试时电机没装桨转动惯量只有实际的一半。装上桨之后转动惯量翻倍系统的截止频率下降相位裕度也跟着下降刚好掉到 20 度以下。从那以后我养成了一个习惯所有控制参数必须在最坏工况下验证。对于飞控最坏工况是满载加电池电压最低对于温控最坏工况是环境温度最高加散热最差。只有最坏工况下稳定才能说系统是可靠的。Apollo-11 的工程团队显然也懂这个道理。他们的测试覆盖了各种极端情况发动机推力偏差、传感器噪声、通信中断、甚至计算机重启。正是这种对最坏情况的充分准备才让那次任务在 1202 告警频发的情况下依然成功着陆。如果你正在做一个高可靠项目不妨问自己一个问题我的系统在最坏情况下会怎样如果答案不确定那就说明还有工作要做。