写点什么

惊心动魄的阿波罗登月:软件和程序员才是幕后的英雄

  • 2019-07-17
  • 本文字数:4157 字

    阅读完需:约 14 分钟

惊心动魄的阿波罗登月:软件和程序员才是幕后的英雄

相信很多人对阿波罗 11 号的故事都已经耳熟能详,但这些故事往往都以宇航员作为主角。这一次,恰逢阿波罗登月 50 周年,我们要重新讲讲这个故事,故事的焦点放在计算机上。在 50 年前惊心动魄的阿波罗登月时刻,可以说:软件、程序员才是幕后的英雄。


虽然阿姆斯特朗凭借着在月球上的人类第一步成为永远的英雄,但马萨诸塞州堪布里奇的一群软件工程师同样功不可没——为了解决阿波罗 11 登陆序列中触发的两项警报,他们经历了一段近乎疯狂的调试。如果当时不能及时给出答案,那么几小时后负责将宇航员送回地球的月球模块(LM)根本无法如期启动。


当时是 50 年前的 1969 年,这代表着一个前所未有的新问题——不仅是因为警报发生在月球上,而且就连软件这一概念本身都刚刚诞生不久。软件工程这个术语正是在阿波罗计划期间被创造出来的。而刚刚获得头衔的软件工程师们,突然就得面对世界上最紧迫的技术难题之一。


阿波罗计划中的软件开发人员无疑是一群开拓者,他们利用如今现代计算机当中常见的各类技术,在 50 年前完成了一个又一个革命性的编程任务。我们可以说,用于运行阿波罗向导计算机(AGC)的软件代表着目前计算机基础科学的一个缩影。通过了解其编写方式与工作原理,我们将能够更好地理解自己面前的这台计算设备。


整个阿波罗计划的成功背后,有超过 30 万名技术人员的努力,有八年间耗资 250 亿美元的付出,一个国家的骄傲完全取决于几行计算机代码——这些代码有 14.5 万行。而今天运行 Facebook 需要大约 6200 万行代码,谷歌需要超过 20 亿行代码。


在深入具体技术细节之前,让我们先来看看这批软件工程先驱者在 1969 年 7 月 20 日那天到底遭遇到了怎样的危机。

惊心动魄的登月时刻

相信很多朋友对阿波罗 11 号的故事都已经耳熟能详,但这些故事往往都以宇航员作为主角。这一次,我们要重新讲讲这个故事,而焦点则放在计算机身上。


一切开始于 1969 年 7 月 20 日得克萨斯州休斯顿时间下午 5 点刚过。当时,阿姆斯特朗与奥尔德林都已经爬进了月球模块(LM),从命令模块(CM)成功脱离,并开启了飞行器向导计算机:这是一台体重达 70 磅的机器,其中包含的集成电路比当时地球上的全部集成电路还要多。



图片来源: NASA


阿波罗向导计算机,位于月球模块中阿姆斯特朗与奥尔德林的座位之间。宇航员通过使用数字键盘输入一些命令以校准计算机,而后即可开启前往月球表面的伟大旅程。



Ralph Ragan(左)和 Eldon Hall 负责领导麻省理工学院实验室的阿波罗项目工作,照片中他们正在阿波罗模拟控制器前检查向导计算机的元件。图片来源:DRAPER。


与同时代的其它机器不同,这台小型计算机不但可以同时处理许多任务,还能选择在多任务出现时选择优先处理哪些任务。


阿波罗计划中配备了两台这样的计算机,一台在指挥舱,一台在月球着陆器上,两台机器运行着几乎相同的软件。但是,为了能安全着陆,月球着陆器还部署了额外的代码。

下午 5:05

当奥尔德林选择阿波罗向导计算机上的程序 P63 启动飞行器的动力下降点火(PDI)序列时,下降过程即告开始。在几分钟之后,计算机将运行一个名为 BURNBABY 的子程序,用于点燃下降引擎,利用计算机的轨道计算控制其推力,从而引导月球模块前往月球表面。



图片来源: NASA


从这时开始,奥尔德林的工作就是观察计算机显示信息并确保其报告的数据与其它数据源一致。阿姆斯特朗则朝着月球模块的窗外望去,努力找寻他已经背诵过无数次、但却第一次真正见到的月球表面地貌特征。


在 PDI 启动的几分钟后,阿姆斯特朗发现了一个叫做 Maskelyne W. 的火山口,但问题是它比正常情况提前 3 秒进入了他的视野。这是个相当危险的迹象,代表着陆过程已经偏离了完美状态。


在阿姆斯特朗向地面控制站汇报了观察结果之后,吉因·克兰兹马上询问地面团队:“要不要继续进行动力下降?”


“FIDO: Go”

“Guidance: Go”

“EECOM: Go”

“Surgeon: Go”


克兰兹马上给查理·杜克下达了“没问题”的指令。杜克是地面上唯一获准与宇航员直接交流的人,他将信息传达给宇航员:“继续保持动力下降。”

下午 5:09

月球模块完成了机动偏航,飞行器开始旋转,阿姆斯特朗的观察窗朝向了背离月球的一侧。虽然机组人员无法肉眼观测,但计算机却不受影响。随着旋转移动,着陆雷达开始指向月球,并测量飞行器与月球表面间的距离。奥尔德林将测得的值与计算机利用轨道力学及惯性传感器计算出的理论值进行比较。这一结果被称为 Delta-H。


奥尔德林报告:“Delta-H 为负 2900 英尺。”任何低于 3000 英尺的值皆为正常区间,因此计算机的任务完成得不错。现在,计算机开始将雷达数据引入计算,以进一步提高结果的准确度。


但就在这一刻,问题出现了。

下午 5:10

阿姆斯特朗报告,“程序报警。”


计算机显示屏上亮起了警报。机组人员不知道这是什么意思,就在他们琢磨的时候,地面控制站陷入了 15 秒的沉默。


在堪布里奇,软件团队也在查看报警信息。有人说道,“执行溢出——无核心设置。”计算机过载了,但没人知道其中的原因。这时另一个人提醒,“有什么东西在占用运算时间。”


在休斯顿,地面团队正在紧张商议到底该中止任务、还是继续着陆。幸运的是,年仅 26 岁的向导官史蒂夫·贝尔斯(Steve Bales)完成了警报编码的查询,并很快得出可以继续登陆的结论。


阿姆斯特朗开始变得不耐烦,“1202 程序警报,我们该怎么办?”杜克回应道,“无视警报,继续着陆。”


尽管警报仍在继续,但计算机的计算并没有受到影响,Delta-H 值也在持续减少——事实证明,计算机一直在正常完成自己的工作。在计算机内部,一项令人难以置信的技术设计使其能够在发生错误的情况下,继续保持运行。


过了几秒钟,引擎按预期降低了飞行器速度,奥尔德林与阿姆斯特朗紧绷的神经终于放松下来。


奥尔德林:“哇哦!减速。”


阿姆斯特朗:“减速按时完成!”


这是本次官方任务记录当中,唯一用到感叹号的时刻。


在堪布里奇,人们也终于松了一口气。减速下降意味着导航与向导系统都在按预期方式运行。


不久之后,计算机自动切换至程序 P64,其中使用的向导方程式并无不同,只是添加了更适合低海拔条件的不同目标。月球模块现在正趋近 3000 英尺位置,但更多麻烦还在后头。



图片来源: NASA

下午 5:14

奥尔德林报告,“程序警报”。这一次警报编号为 1201。


在几分钟的平静之后,1201 号警报再次出现在堪布里奇地面团队的眼前。他们感到一阵天旋地转,但休斯顿地面控制站仍然充满信心。他们能够看到飞行器的遥测数据,知道计算机仍在进行正确的计算。此外,在着陆过程中,特别是目前这个时刻上,中止序列具有巨大的风险。所以只要数据看起来不错,就最好继续保持下降。综合考虑之后,他们给出了继续着陆的指令。


警报一直在怒刷存在感,过了一分钟,1201 与 1202 警报同时亮起。休斯顿非常坚定地在每次警报后给出继续下降的判断。

下午 5:15

在不到 2000 英尺处,计算机显示屏突然一片空白。任务清单上并没有这方面记录,此次事件在任务完全结束后才得到讨论。但这种情况无疑增加了紧张的氛围,因为阿姆斯特朗意识到目标着陆点附近散布着大量巨石。


当显示器终于重新亮起时,又提示新的 1202 警报。但无论如何,计算机一直在默默执行着最关键的向导计算任务。


十七秒后,飞行器距离月球表面约 800 英尺时,问题再次发生。显示屏空白了近两秒钟。这时阿姆斯特朗的心率急速上升至每分钟 150 次。


电光火石之时,阿姆斯特朗做出判断,认为当前着陆点不安全,并决定将计算机切换至程序 P66,即半手动模式。在这种模式下,飞行器的前进方向将不再由计算机向导程序操纵,而是听命于阿姆斯特朗手中的操纵杆。当然,他的每一个动作都将得到计算机软件的辅助,从而提高操作稳定性与准确度。就这样,阿姆斯特朗和计算机一道,操作月球模式驶离了这片巨石散落区。

下午 5:16

故事到这里就基本结束了,接下来是英雄的时刻。阿姆斯特朗驾驶月球模块飞越巨石场,并在燃料仅可维持几秒时成功完成飞行器着陆。


杜克发来语音,“你让我们这帮人紧张死了。现在我们终于又活过来了。”


但软件工程师们没时间放松。1202 与 1201 警报仍然令人不安,团队开始怀疑计算机的运行状况。继续依赖它指挥飞行器上升是否安全?毕竟在宇航员安全返回地球并在海洋中再次着陆之前,谁也不敢提前庆祝。


当时,大多数 NASA 工作人员的第一反应都是计算机可能出现了某种程度的故障。但计算机才是本次故事中的真正主角。它在面对这些警报时决定继续处理最关键的向导方程,从而挽救了宇航员的生命并支撑着他们成功完成使命。

这是警报,而非 Bug

阿姆斯特朗他们看到的警报并不是错误。这实际上只是一条警示,含义是操作系统正在丢弃大量不太重要的雷达测量事件,以确保其能够实时处理优先级更高的着陆任务。今天,我们将此称为优先级安排,而且几乎被广泛应用于所有操作系统当中——从笔记本电脑上运行的 Windows、到手机上运行的 iOS、再到运行着我们网站的 Linux 内核等等。但在 1969 年,这种算法堪称计算机科学领域的绝对前沿。


阿波罗向导计算机开创出一系列全新的软件概念,例如优先级调度,而且其设计者第一次使用“软件工程”来描述自己的工作内容。

英雄落幕?

7 月 20 日登月成功的喜悦并未阻止 11 月的一场抗议活动。当时由于 I-Lab 的军事武器的研究工作,学生和警察在实验室外发生冲突。到 1973 年,麻省理工学院切断了与实验室的联系,之后更是将其更名为查尔斯·斯塔克·德拉普尔实验室( Charles Stark Draper Laboratory),并将所有机密军事研究移到了校外。(备注:阿波罗项目是麻省理工学院获得的第一个大型合同,也是唯一一个授予大学的合同,同时也是唯一一个没有经过竞标的合同。)


大约在同一时间,美国宇航局取消了其最后三次阿波罗任务,结束人类近地轨道以外太空的探索活动,但没有说明何时会重启。


之后大部分电脑被废弃,NASA 也从未公布过阿波罗计划的代码,但这些代码可以在剑桥和华盛顿的博物馆中找到,一些计算机爱好者也发布了在线版本。


50 年前,当着陆器成功落地,一切尘埃落定,上面的机载计算机按既定指令在其 P68 登月确认程序中进行了勾选。软件中嵌入的最后一行没有任何外人可以看到,它说:


“宇航员:现在你已经成功着陆月球。”


原文链接:


https://medium.com/softwares-giant-leap/the-software-that-saved-apollo-11-4fb37dfad652


https://www.wsj.com/articles/apollo-11-had-a-hidden-hero-software-11563153001?mod=rsswn


2019-07-17 16:283901

评论 1 条评论

发布
用户头像
阿波罗计划的代码有 14.5 万行。而今天运行 Facebook 需要大约 6200 万行代码,谷歌需要超过 20 亿行代码。这个数字有意思。
2019-07-17 16:52
回复
没有更多了
发现更多内容

食堂就餐卡系统UML设计

leo

架构第一周学习总结

灰羽零

统一建模语言(UML)

leo

架构师训练营 - 学习笔记 - 第一周

徐时良

极客大学架构师训练营

食堂就餐卡系统设计

knight

【第一周】架构方法

云龙

架构师训练营第一周学习总结

null

[架构师训练营第 1 期]第一周学习总结

猫切切切切切

极客大学架构师训练营

作业一:食堂就餐卡系统设计

Wee权

食堂就餐卡系统设计

灰羽零

架构师训练营第一周总结

赵孔磊

架构师训练营 week 1 作业

陈春亮

极客大学架构师训练营

架构1期第一周作业-系统设计

道长

极客大学架构师训练营

[架构师训练营第1期]第一周命题作业

猫切切切切切

架构设计大作业二

极客李

架构师训练营第一周作业

null

第一周 作业二:架构设计学习总结【未陌】

a d e

学习 总结 架构设计

week01 总结

xxx

ARTS打卡Week 13

teoking

ios

架构师学习笔记【架构师训练营第 1 期】

我听你说……

架构师训练营 - 命题作业 - 第一周

徐时良

极客大学架构师训练营

第一周课后练习

大大猫

极客大学架构师训练营

架构师训练营—第一周命题作业UML

Geek_shu1988

极客大学-架构师训练营第一期-食堂就餐系统设计

Black Eyed Peter

极客大学架构师训练营

极客大学 - 架构师训练营第一期 - 食堂就餐系统设计-学习心得

Black Eyed Peter

极客大学架构师训练营

架构师训练营2期-第一周总结

Geek_no_one

极客大学架构师训练营

第一周学习总结

vitaminc

第一周命题作业

第一周 作业一:食堂就餐卡系统设计【未陌】

a d e

架构设计

架构师训练营—第一周学习总结

Geek_shu1988

架构师 UML

架构师训练营第一周作业

赵孔磊

架构师训练营 week 1 笔记

陈春亮

极客大学架构师训练营

惊心动魄的阿波罗登月:软件和程序员才是幕后的英雄_语言 & 开发_Joe Kutner_InfoQ精选文章