In the final minutes of Apollo 11’s descent to the lunar surface, five 1201 and 1202 alarms blared in the lunar module. The computer was overloaded with data, and for a brief moment it looked like Neil Armstrong and Buzz Aldrin wouldn’t land on the Moon. As we know, they did; Apollo 11 got a GO to land in spite of the alarms. What we don’t know is the man whose work allowed the crew reboot the computer and save the landing: Hal Laning.
In April of 1961, NASA first approached the MIT Instrumentation Laboratory (now called Draper) to develop the guidance computer for the Apollo lunar missions. Among the engineers who eventually joined the program was J. Halcombe Laning, who went by Hal. A veteran of missile control systems, Laning had previous worked on a simple guidance system for a Mars satellite. Though this Mars mission was never launched, the idea was for a simple gyroscope-stabilized satellite with an onboard optical sighting system for navigational data points and a digital computer to manage everything. The idea was that the optical system could take in situ measurements and feed the data to the computer for a running check of the spacecraft’s position. It would, in short, be able to self-maintain its navigation.
Though Apollo would have astronauts on board, NASA still liked the idea of a self-managed navigation system. Not only was it a good failsafe to the human pilot, being self-contained on board meant the navigation data couldn’t be hacked by the Soviet Union.
Laning was part of the team that developed the three-layer computer system for Apollo. At the bottom ruling all the low-level instructions was a computer language called basic (all lowercase, not to be confused with the programming language called BASIC, all caps, developed in the 1970s). It was, in essence, an algebraic compiler.
Every line of code in basic equated to one command to the computer. The problem was that the computer was small, low powered, and light so it couldn’t manage all the instructions needed for navigation. Instead, each line of code was equivalent to a one-word instruction, and those words, taken together, became instructions that had to be interpreted by the second layer of the computer.
Running on top of the basic language were two programs of Laning’s creation. First was the Interpreter. This increased the perceived power of the computer by taking more time to calculate more complicated things like details of a midcourse correction burn. The second program that ran over top of the Interpreted was called the Executive. The Executive program determined the order in which each program ran. Taken together, the Interpreter and the Executive were the equivalent of the operating system for the Apollo Guidance Computer. And it wasn’t by accident that Laning named both after human jobs. His idea was that just like people in the lab talk and follow hierarchy so too would the programs in a computer.
But there’s an element to the Executive that made this program unique and vital to Apollo’s success.
In the 1960s, the guiding thought on running programs was to keep them simple like a washer and dryer: each program takes its set amount of time and you run them in sequence. Laning didn’t like that approach. He knew that there would be urgent matters on an Apollo flight as well as tight timing for running necessary programs, so he built an asynchronous element into the computer. It had sequencing and interrupt sequencing elements as well as a timesharing feature. A slice of time was allocated to each program, and the computer could switch between them multiple times a second. Some programs ran constantly — when navigation programs were running there was a costing check every two seconds — but other programs were asynchronous. To the human operator, it looked like the programs were running simultaneously, but the computer was actually swapping between tasks every few microseconds so it only looked simultaneous.
This allowed the computer to give programs priority while keeping resources clear for critical programs at critical moments. The drawback was that it was unpredictable. There was some concern that a bug would keep a program running in a loop. The solution was an auto-restart function that could reboot the computer without the operative system losing the priority system in place.
This is exactly what happened in the final moments of Apollo 11’s landing.
As the crew descended towards the surface, the Executive found that there were no more spaces in the computer to run new programs. This triggered the 1201 alarm signaling “Executive Overflow – No Core Sets” and the 1202 alarm signaling “Executive Overflow – No VAC Areas.” These in turn triggered a software reboot, which was Laning’s failsafe against a bug keeping the asynchronous computer locked in a loop. All jobs were cancelled then restarted without losing their priority order or losing any navigational data. The first reboot didn’t clear up the issue; the alarms kept coming until Buzz Aldrin figured out why.
Aldrin noticed that the 1202 alarm was triggered when they entered Verb 16 Noun 68, a program that would display the range to the landing site and the LM’s velocity. Realizing this command was triggering the alarm, Aldrin asked the ground to call up the data, removing the command from the computer.
In the end, it was Laning’s foresight that let the LM Eagle’s guidance computer reboot in a matter of microseconds while still letting it fly. Without it, it’s possible Apollo 11 wouldn’t have landed on the Moon at all.
Sources: Digital Apollo by David Mindell. The Apollo Guidance Computer by Frank O’Brien. Interviews with Draper engineers who worked on the Apollo Guidance Computer; this video was created with help from Draper, who also approved the full script. Thanks, Draper!
