Kick-started by John F Kennedy’s legendary speech, the Apollo space programme was the incredible story of the efforts of over 400,000 people, all aligned towards achieving the goal of landing a man on the moon. We always remember the massive Saturn rockets (still the most powerful space rockets ever produced) and the skill and dedication of the Apollo astronauts who piloted these machines. Yet at the pivotal moment of the first moon landing on the Apollo 11 mission, it was ingenious software design that allowed the systems to cope with the unexpected and continue to function.
On the 20th July 1969, as the lunar lander descended towards the surface, Armstrong and Aldrin had left the rendezvous radar switched on. This was smart astronaut thinking – it meant they could abort the landing and quickly reacquire the orbiting command module if something went wrong. The radar was generating data and sending it to the guidance computer as a steady stream of interrupts. Normally this would be fine, but during this critical part of the mission the guidance computer was maxed out trying to manage navigation and the descent engine.
Unable to cope with it’s tasks, the computer system overloaded and issued a 1202 program alarm. This flashed up on the astronauts display and a warning buzzer sounded in the cabin, no doubt significantly raising the stress levels of the astronauts who already had the expectations of the world on their shoulders. During this tense time the astronauts had to wait for Mission Control to interpret the error code and decide whether it was a threat to the mission. The error code was looked up to mean ‘Executive Overflow’. The problem was completely unexpected because although the astronauts had followed exactly the same procedure in the simulators back on the ground, the rendezvous radar switch was a dummy – no radar was actually connected so the computer didn’t receive data, preventing it from becoming overloaded.
So how did the guidance computer software save the say? Well, it was written using a revolutionary scheduling system that could not only multi-task but understood the priority of the tasks it was assigned. In the event of an overload, it could ignore lower priority tasks and focus on what was essential. Lower priority tasks could be flushed and restarted when CPU time became available again. This is precisely what the Apollo 11 guidance computer did – essentially it self-recovered. NASA took a calculated risk that the landing would not be put in danger, and despite the 1202 error occurring a few more times during the descent, the guidance computer continued to do it’s job, and shortly afterwards Buzz Aldrin and Neil Armstrong were walking on the surface of the moon.
The technology aspect of this story sounds familiar because today pretty much every computer and even smartphone has well executed multi-tasking, but this software was written in the mid-sixties at a time when programs had to be stored on core rope memory – or lol memory as NASA used to call it!
It would be twenty years later before the ground-breaking Commodore Amiga brought multi-tasking into peoples homes with it’s AmigaDOS OS and Workbench GUI. The Amiga was famous for being able to run multiple simultaneous tasks at once while remaining highly response to the end user; often more so than modern day Window machines. Stay tuned for an Amiga post coming soon 🙂
Previously in this series: Apple capitalises on NextStep in a big way