www.abc.net.au/science/moon/computer.htm
Back to The Lab homepage The Lunar Module Computer Here's a challenge... Develop a system that can control a 13,000 kg spaceship, orbiting at 3,500 kilometres per hour around the moon, land it safely within metres of a specified location and guide it back from the surface to rendezvous with a command ship in lunar orbit. The system has to work the first time, and minimise fuel consumption because the spacecraft only contains enough fuel for one landing attempt. Do this with a computer that has barely 5,000 primitive integrated circuits, weighs 30 kg and costs over $150,000. In order to store your software, the computer doesn't have a disk drive, only 74 kilobytes of memory that has been literally hard-wired, and all of 4 Kb of something that is sort of like RAM. That's the task that faced Peter Adler and Don Eyles of the MIT Instrumentation Lab who were responsible for developing the software for the Apollo Lunar Module. Their system worked, but almost caused the first moon landing to be aborted in the final minutes before the touchdown. Stark Draper, head of the team that developed the Apollo computers Stark Draper ran the MIT Instrumentation Lab that developed the Apollo Computers - the first to use integrated circuitry. The Apollo mission was conceived at the height of the Cold War. Planners were concerned that the Soviet Union might try to jam any navigational information sent from the ground, so the on-board computers had to be capable of having autonomous command of the spacecraft. The responsibility to build computers that were powerful enough to do the job but light enough to carry to the moon went to Stark Draper and his team at the MIT Instrumentation Lab. The computers that formed the basis of the Apollo Guidance and Navigation System (AGS) were at the bleeding edge of technology in the 1960s. They were the first to use the integrated circuit technology that subsequently gave us desktop computers and so many of the consumer electronic products that fill our lives today. One computer sat in the Command Module, another in the Lunar Module, just above the hatch that astronauts used to get onto the lunar surface. Each computer had two types of memory, erasable and fixed. The fixed memory contained the programs, constants and landmark coordinates using 36,864 terms or words, each of 15 bits length. The erasable memory, which was used to store variable data used in calculations or as registers for logic operations, had only 2,048 15-bit terms. The fixed memory was made from coincident-current ferrite cores woven into a rope with copper wires and sealed in plastic. Software components were encoded into a core according to the 'pattern' of its weave. Each core functioned as a small transformer, with up to 64 wires connected to each core. If a wire passed through a particular core, a '1' would be read. If a particular wire bypassed the core, a '0' would be read. If you wanted to change the software contained in fixed memory, you had to rewire the sealed core to change the bits. The erasable memory was made from similar materials but with a different design. Each core in the erasable memory could be changed using magnets. Turning clockwise to indicate a '1' or anti-clockwise indicating a '0'. In order to use the computer, astronauts used a display and keyboard unit (DSKY, pronounced "disky"), which weighed another ten kilos. This wasn't a QWERTY keyboard, but a number pad along with some special buttons. In order to input a command or action, the user had to press a button marked "Verb", followed by a number that corresponded to the action. To input data, the user pressed the "Noun" button along with a number. Even though it sounds complicated, the interface was elegant and it worked. Although the computer was slow, the operating system it used was well designed. Long before Linux, the MIT team developed a real-time multi-tasking operating system. There were interrupt-driven, time-dependent tasks, such as turning on the LM Descent Engine at the correct time, as well as priority-ordered jobs that dealt with less time-critical things. Each scheduled job has some erasable memory to use while it was executing. As Peter Adler explains, "With so little Erasable memory available, we were forced to use the same memory address for different purposes at different times. Thus, a location whose contents might be altitude-over-the-lunar-surface during the landing stage might have contained the results of a sextant sighting of a navigational star from the alignment program. I think there were some memory locations that were shared seven ways. You can imagine the testing we had to do to ensure that the same memory location was not being used by more than one program at the same time." A DSKY unit for the Apollo computers This Display and Keyboard unit, or DSKY, was the interface for the Apollo computers. The 'Verb' and 'Noun' buttons are on the lower left-hand side of the unit. All of that testing led to a system that was designed to retain crucial information if it needed to reboot, which allowed important command information to be processed even if the computer crashed. A priority-interrupt system always processes the job with the highest priority before moving onto other jobs that have a lower priority. This is different from time-slicing where each program gets a fixed amount of processor time. The two Apollo control programs that managed scheduling were the Executive and the Waitlist. The Waitlist managed up to nine short tasks, that had execution times of four milliseconds or less. Any jobs that took longer were passed to the Executive queue. Every 20 milliseconds the Executive would check the priority list for tasks with a higher priority than the current ones. This allowed the computer to maintain critical tasks, such as running the digital auto-pilot, even if other parts of the software failed or caused problems. On July 20, 1969, Neil Armstrong and Buzz Aldrin had entered the Lunar Module they named 'Eagle' and were descending to the surface. They were about 6,000 feet above the surface and the descent engine was halfway through its final 12-minute burn that would land them safely on the moon, when a yellow caution light lit up on the computer control panel. It was a 1202 error, indicating a memory overload, and the astronauts asked Mission Control for instructions. The overflow had resulted from an unexpected flow of data concerning radar pointing. Because the computer had been programmed to recognize this data as being of secondary importance it would ignore it while doing more important computations. The responsibility for deciding if the error was crucial or not fell to 26-year old Steve Bales, the control room's expert in the lunar module's guidance systems. Jack Garman, supporting Bales from another console, remembered that a similar problem had been tried during a simulation a week or so before, so he reassured Bales that the mission could continue. As Bales recalled later, "I had just started to relax a little bit, if you can call it relaxing, and I heard the program alarm, and quite frankly, Jack, who had these things memorized said, 'that's okay', before I could even remember which group it was in.... In the Control Center any more than three seconds on descent is too long.... Bales told the mission controller that the error could be ignored. The same error repeated itself several times in the following minutes, but did not stop the Eagle from landing. For making the decision to continue, Bales received the US Medal of Freedom along with the three Apollo astronauts. The LM on the moon Peter Adler's work and testing had paid off. As planned, the software rebooted and reinitialized the computer, and then restarted selected programs at a point in their execution flow near where they had been when the restart Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and occurred. As Adler recounts in the Apollo Lunar Surface Journal, "On running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvou...
|
http://csua.com/feed/