混合仿真实验室设备。 图中显示了SDS 9300控制面板，该面板与多台模拟计算机一起对命令模块和登月模块进行了仿真。他们说，在Apollo 11开发控制系统之前的几年，他们认为嵌入式软件可以做的最后一件事：“哈尔会做到这一点”。 实际上，数十个人和数百名支持人员正在执行此操作，但是Hal Laning首先必须弄清楚如何组织众多软件功能，以便可以在航天器的机载计算机上几乎同时地实时执行这些功能，而这种计算机的尺寸和速度有限。 。
哈尔（Hal）的体系结构避免了操作系统的陷阱，在该操作系统中，应该在时间段之间明确划分计算。 由于任务可以任意更改，因此此类系统很难实施。 在开发过程中添加或更改任务时，可能需要更改任务计划。 最糟糕的是，车载计算机的现有操作系统非常脆弱，从某种意义上来说，如果任务花费的时间超过分配的时间，则该操作系统将完全失败。
相反，Leinning开发了一个系统，其中程序功能以“任务”的形式分布，可以执行这些功能所需的任何大小。 每个任务都有一个优先级。 操作系统始终以最高优先级执行任务。 如果执行了低优先级的任务，并在此时分配了高优先级的任务，则低优先级的任务将被挂起，直到高优先级的任务完成。 这样的系统给我们一种幻想，即任务是同时执行的，尽管实际上当然是依次执行任务的。 这样的系统不是确定性的，但是其功能是可以理解的并且可以被验证，并且其增加了可靠性，安全性，使用的灵活性，并且特别是易于开发。
执行程序（
实时操作系统AGC和LGC。大约翻译 ）安排任务的执行，以使每个任务以一组寄存器的形式保留其状态，并在高优先级执行任务时保持状态。 LGC包含八组数组，每组12个寄存器，每个寄存器15位。 一组如此大小的寄存器足以执行许多任务，但是使用解释
器的任务（对于以双精度数字运算的任务使用
内置的解释语言。大约是Transl。 ）执行向量和矩阵计算需要更多空间。 对于此类任务，将分配一个由43个寄存器组成的单独数组。 LGC包含五个这样的阵列（矢量累加器，VAC）。
在维护任务上下文的数组数量有限的情况下，应非常谨慎地启动要执行的任务。 依次执行的功能被合并为一项任务。 在整个着陆阶段以及在引擎开启的情况下，SERVICER的大任务都处于活动状态，其中包括使用加速度计进行导航，运动方程式，引擎的油门控制，船舶位置数据，显示屏上的其他数据以及每个该函数使用了以前的输出。
可用寄存器阵列和VAC的数量将可以排队执行的任务数量限制为八个，其中最多五个可以使用VAC阵列。 在正常操作期间，尽管为一次执行或异步启动的任务可能会导致系统负载波动，但是正在运行的任务数保持不变。
但是，如果启动任务的数量超过完成的数量，则使用的寄存器阵列和VAC的数量会增加。 如果这种情况持续了足够长的时间，它们的数量将用完，并且无法满足启动下一个任务的请求。
我们将在一年前返回，即Apollo 11发射之前，当时我们的软件工程师认为我们已经拥有足够的东西，并且我们被要求编写一种可以在月球上关闭并重新打开的软件，以登陆月球。不会中断着陆过程和其他重要动作！ 这称为“重新启动保护”。 除电源干扰外，其他因素也会导致系统重新启动。 如果硬件认为程序在无限循环中崩溃，或者在读取ROM时发生奇偶校验错误，或者由于其他一些原因，则会发生重新启动。
重启保护是通过在程序中的适当位置注册“航路点”来实现的，其安排方式是使返回到最后一个“航路点”不会引起错误，如下例所示：
NEW_X = X + 1
X = NEW_X显然，如果不注册航路点，则第二次执行此代码将导致X重新增加。
重新启动后，此类程序将恢复其工作。 每个任务都从最后注册的航点开始。 如果队列中有同一任务的多个副本，则仅恢复最后一个。 某些任务没有重要的状态，并且无法防止重新启动。 他们只是消失了。
重新启动保护效果很好。 在我们位于剑桥的混合模拟器的控制面板上，有一个按钮导致AGC重新启动。 在测试软件时，有时我们会随机按下此按钮，几乎希望失败会导致我们遇到另一个错误。 每次触发重新启动保护时，工作都会一直不断而不会停止。
（混合模拟器包含SDS 9300数字计算机和Beckmann模拟计算机，真实的AGC计算机以及用于命令和月球模块的逼真的座舱模型。）
发射前准备阿波罗。铁不仅会导致重新启动，而且如果程序到达计算机不知道如何继续执行程序的地步，可以通过编程方式调用它。 在“警报和中止”模块中的BAILOUT标记下转移控制权时，会发生这种情况。 该呼叫伴随一个错误代码。
如果资源用尽，则执行系统将执行这些操作。 如果由于没有可用数组来保存寄存器而无法设置任务，执行程序将调用BAILOUT，错误代码为1202。如果没有可用VAC，则将调用代码为1201的BAILOUT。
LGC并非将所有功能都作为“任务”执行。 除了它们之外，还有执行高优先级功能的随时可能发生的硬件中断（如果未明确禁止），这些中断被分配给某些设备，包括数字自动驾驶仪，上行链路和下行链路（
发送和接收设备）约有转译（ ）和键盘
的无线电频道上的数据 。
其他中断可用于执行必须在特定时间执行的代码段。 这些功能称为任务，它们是在名为WAITLIST的子例程中调度的。 “任务”的前置时间很短。
虽然计划“任务”具有一定的优先级，但“任务”却计划在特定时间启动。 任务和任务经常被共享。 可以启动该任务以读取传感器读数，该传感器读数应在严格定义的时间进行读取，然后该任务又启动具有特定优先级的任务以处理这些读数。
当哈恩·莱恩（Hal Lane）在1960年代中期设计高管和候补名单时，他从头开始做所有事情，而并不依赖任何示例。 他的原则在今天是正确的。 在执行环境的控制下，通过有限数量的异步过程分配功能，这些执行环境基于时间间隔和优先级进行抢先式多任务处理，所有这些仍然是现代实时计算机系统在空间应用中的基础。
陀螺仪的组装。* * *
为了了解下降期间阿波罗11号警报的根本原因，有必要考虑命令模块的进近程序，这是在月球模块从月球表面升至月球轨道之后进行的。 正如我们在月球着陆时使用着陆雷达来测量相对于月球表面的高度和速度一样，在登月轨道上接近命令模块时也需要使用进近雷达来测量相对于第二艘船的距离，速度和方向。
接近雷达具有几种由模式开关设置的操作模式。 这些模式如下：SLEW，AUTO和LGC。 在SLEW和AUTO模式下，无论LGC如何，雷达都在命令控制下运行。 如果主导航系统发生故障，则可以在起飞和进近过程中使用此操作模式。 在SLEW模式下，雷达天线在其余时间都是固定的，是手动引导的。 当天线对准目标时，可以将模式切换到AUTO（自动跟踪），它将跟踪目标。 接近雷达测量距离和速度，并且天线旋转轴的旋转角度以垂直刻度的形式显示在驾驶舱显示屏和指示器上。 同样，距离和速度数据也进入了中止制导系统（AGS），这是一台只有6144个记忆字的计算机，在登上月球并从月球起飞时复制了主要的PGNS系统。
（三种和解雷达操作模式的名称让一些评论员感到尴尬。应机组人员的要求，在LM-1任务之后和任务登陆月球之前更改了名称。阿波罗11号称为LGC的模式以前称为AUTO。它在Apollo 11上称为AUTO（以前称为MANUAL），SLEW模式的名称保持不变，尽管这丝毫没有造成Apollo 11上的问题，但当时与离散通道33有关的内部LUMINARY文档仍然称为 通过RR AUTO-POWER ON打开接近雷达的LGC基准。）
如果PGNS系统正常工作（实际上是这样），则LGC会控制雷达，在这种情况下，将接近雷达模式开关设置为LGC。 雷达接口的电子装置使软件可以获取有关雷达测得的距离和速度以及天线旋转轴角度的数据，从中可以找到指向目标的方向。 LGC程序使用此信息将LGC驱动到更靠近命令模块的位置。
事实证明，进近雷达在下降期间也可以工作，而这是在阿波罗11号下降期间完成的。 机组人员指示要求在P63阶段开始之前立即打开雷达，并在整个着陆操作中保持在SLEW或AUTO模式。
关于为什么以这种方式将雷达调谐到登陆月球有许多解释。 例如，休斯顿的某些人可能已经通过将雷达数据与预期读数图进行比较来考虑幻想的着陆监视方案。 但是，有一个更简单的解释：仅在着陆前打开雷达是为了在中断过程中发生事故时保持温暖，并且处于自动模式（如果登月舱处于允许您跟踪命令模块的位置）或滑行（在其他时间），以防止天线无用的移动。
图7.
PGNS，ATCA和邻近雷达接口这个问题通常被归因于清单中的一个错误（包括之前的作者）。 这是不正确的措辞，就像调用监视器过早关闭是不正确的
月球模块的delta-V引擎是“计算机错误”，而实际上该错误在文档中。 实际上，Apollo 11接近雷达开关的位置应该不会引起任何问题。 但是从这里您可以在文档中跟踪另一种错误情况。
几年前，在接口控制文档（ICD）上编写了文档，该文档定义了PGNS与ATCA（高度和平移控制组件）电子设备之间的电气接口，该电子接口由建造着陆模块的公司格鲁曼航空公司提供。 ICD确定在两个系统中频率为800 Hz的28V电源电路应在频率上对齐，但并未写明它们应在相位上同步。 实际上，这两个系统与LGC发送的“频率同步”信号频率对齐。 它们具有恒定的相位关系。 但是，这两个电压之间的相位是一个完全随机的变量，具体取决于在Acta之后始终通电的LGC开始发送同步信号的时刻。 这些接口如图2所示。 7
测试LM-3着陆模块时检测到800 Hz相位问题，并记录在案，但从未修复。 结果，当雷达模式开关处于AUTO或SLEW位置时，来自ATCA的800 Hz信号激发了雷达的旋转机构，该信号很可能与800 Hz信号的相位不一致，该信号在CDU中用作转换信号的参考。一种机制，用于将数据转换为计算机数据，并使计算机中的计数器递减（或递减），以告诉程序天线如何旋转。
但是，在Apollo 11上，CDU的工作方式有所不同。 由于它们将单独产生的电压作为参考信号，因此CDU接收到的天线角度传感器信号显示未知角度。 如果相位差接近90或270度，则误差最大，而阿波罗11号显然碰到了这些有趣的点之一。 作为响应，CDU开始以几乎恒定的速度递增或递减LGC计数器，每个角大约每秒6400个脉冲。 每当开关处于SLEW或AUTO模式时都会发生这种情况，而不管是否打开了接近雷达。
LGC中的CDU计数器由在计算机中处理的外部信号递增或递减。 这非常耗时，在这种情况下，每个存储周期为11.7 µs。 如果计数器以最大速度递增，则将花费总时间的大约15％（此杂散时间称为TLOSS）。 我们目前提供的花费时间的保守估计为13％，这与观察到的行为一致。
阿波罗11号飞行之后，格鲁曼公司的工程师进行了测试，以重现飞行中观察到的计算机行为。 他们证实，即使在最坏的情况下，CDU也无法以最大速度发送脉冲。 他们得出的结论是，这些仪表的最大计算机负载（TLOSS）可以达到13.36％。 在模拟过程中，再现了与飞行中类似的错误。 因此，所引用的TLOSS值是Apollo 11计算机负载的最佳记录估计值[Clint Tillman，“当RR在FMES / FCI实验室中处于SLEW或AUTO（不是LGC）模式时，模拟RR-CDU接口”，8月9日， ，1969]
我感谢登月舱制导系统专家George Silver对登月舱进近雷达接口的耐心解释。 在“阿波罗11号”任务中，他发挥了核心作用，在发射时，他在卡纳维拉尔角（Cape Canaveral），然后飞往波士顿，再到剑桥，负责监视从月球起飞的情况。 7月20日，他在电视上观看了月球降落在家里的情况。 他听到警报声，猜测是某事正在占用计算机时间，并回忆起他在测试LM-3系统时看到的一个案例，当时近距离雷达引起柜台的疯狂活动。 经过剑桥飞行任务监视小组的进一步分析后，西尔弗终于在7月21日上午（距月球起飞不到一个小时）与休斯敦的MIT代表取得了联系。
手动控制片段* * *
登月是飞行最激烈的阶段。 着陆控制系统必须以一定的坐标达到目标，并具有一定的速度，加速度，抽动程度（变化/加速度）。 克伦普（Klumpp）将“颠簸”（“ jerk”）的变化率称为“啪”（snap），接下来的两个导数分别称为“ crackle”和“ pop”（pop）。该程序允许船员改变着陆地点，节流阀被连续控制，导航包括使用着陆雷达的测量，图8显示了在选择P63相和接触月球表面之间的典型载荷曲线。
图 8：
着陆期间的负载（模拟器数据）即使在这样的条件下，我们也试图使程序足够快以在TLOSS很大的情况下有足够的时间。 主要限制是在飞行阶段使用的“ average-G”程序中内置了两秒钟的时间。
在此期间，READACCS任务读取加速度计的读数并启动SERVICER任务，该任务使用这些值作为初始数据进行新的轨迹计算迭代，节流发动机，确定飞船的位置并将其显示在显示屏上。在着陆期间，计算机负载的程度只是表明在每两秒钟的时间里有多少时间花在了任务和中断上。在制动阶段，直到着陆雷达看到地面之前，备用时间至少为15％。雷达投入运行后，将开始进行其他计算，这涉及将坐标从雷达参考系统转移到导航坐标系，从而使裕度降低了13％。当显示开始时（动词16，名词68），边距减小到10％或更低。巴兹·奥尔德林（Baz Aldrin）在1202号信号后说：“似乎他在我们进入1668年时出现了”。[16]。当保证金为10％并取消了13％时，LGC没有足够的处理器时间来执行所有必需的功能。由于执行设计的灵活性，并且与刚性架构不同，因此没有灾难。表1.在月球着陆时活动的任务。
表1列出了登陆Apollo 11时处于活动状态的任务。SERVICER的优先级最低，运行时间最长。高优先级的任务可以停止SERVICER，但是交货时间相对较短。由于SERVICER的大小较大，因此优先级较低，因此由于缺乏计算时间而导致故障。由于时间差为负数，当按计划启动的READACCS重新启动并再次启动SERVICER时，SERVICER无法提供答案。由于SERVICER的先前副本未完成计算，因此它没有释放寄存器和VAC阵列，READACCS调用FINDVAC给Executive，以分配新的寄存器和VAC阵列并启动SERVICER。该SERVICER还没有按时完成工作。在短暂的此类操作周期后，寄存器和VAC阵列结束。当以下请求发送给执行人员时，使用代码1201或1202调用了BAILOUT。
图9：不带TLOSS和不带TLOSS的SERVICER操作图
图9显示了SERVICER在强TLOSS下的表现。图10显示了正常操作期间以及在发生重启动期间具有强TLOSS的寄存器和VAC集的比较。
图
10. TLOSS在登月期间对执行人员和候补清单资源产生的影响（模拟器数据在接收来自雷达的速度数据之前从P63阶段开始，到着陆结束[17]。）在P63阶段此事件序列的有趣影响，是问题得以解决。重新启动软件后，仅还原了SERVICER任务的最新副本，并删除了SERVICER的所有不完整副本。此外，他还完成了所有不重要的功能（包括DELTAH监视器）（动词16，名词68）。在P63中出现两次警报后，导致显示从“名词68”切换到“名词63”。重新启动保护系统最初是由于可能的硬件故障而开发的，并通过较大的TLOSS减少了计算负荷。我们开发的实时系统在某些情况下具有容错能力。在P64阶段，情况有所不同。除了通常的运动方程式之外，还添加了其他处理程序，其中包括重新分配着陆点的能力。其他软件功能的时间余量少于10％。警报继续出现。 40秒内出现三个警报1201和1202。每次重新启动软件时，都会清除任务队列，但无法减少负载。任务时间102：43：08，在预见到下一个警报时，Armstrong将自动驾驶仪从AUTO切换到ATT HOLD模式，从而削弱了计算负荷，然后进入半手动P66模式，此时计算机负荷较低。在阶段P66中进行2分20秒的操纵后，登月舱模块坐下。