ࡱ> :  !"#$%&'()*+,-./0123456789Root Entry( JrFo*MatOST Fo*Fo*MMMN02kND ( JrMicrosoft Works MSWorksWPDoc9qS;P;PTY2kf""fvfdg\XhXh=/8dXhWtiXhjhTThe Apollo Guidance Computer Eldon C Hall  Invited History Talk B0 About a year ago I saw a cartoon. A boy standing on the descent stage of the Lunar Landing Spacecraft pronounced that the computer in there had only 64 Megs of RAM and stated that was not enough to run Windows 98. Fortunately Apollo Guidance System designers did not feel 64 Megs of RAM were necessary nor feel Windows 98 was required to guide the Apollo spacecraft to a lunar landing. I am going to take you back almost 40 yrs to a time when such numbers were not even part of a computer designers vocabulary. Back to the time when President Kennedy challenged the nation in 1961 with his proposal to land men on the moon. Computer hardware was still in its stone age. Commercial mainframes had only a fraction of 64 Megs of RAM, occupied rooms and required kilowatts of power. Their designs included vacuum tube circuits, magnetic core and drum memories, and punched card input equipment. Fabrication was still primarily hand soldered point to point wiring between millions of discrete electronic components. Component interconnections with printed circuit boards were just beginning to find place in assembly processes. On the other hand, aerospace industry was taking risks with transistor circuits and other advanced technologies in electronic applications. I am sure all of you are aware that government funded programs provided the motivation for aerospace industrys to explore technology frontiers. Commercial applications benefited many years later when the pitfalls were removed. NASA, a rather newly formed government organization, was charged with the task of meeting Kennedy's challenge. NASA engineers assumed the spacecraft would require an onboard inertial guidance, navigation and control system. So, they awarded a development contract for the system in August 1961 to the MIT Instrumentation Laboratory. The Laboratory and Dr. Charles Stark Draper, its director and chairman of MIT's Aeronautics Department, were leaders in inertial guidance technology. Our reputation had developed during the 1950s. Draper was promoting, somewhat unsuccessfully, inertial guidance for the militarys ballistic missiles. Then, in 1956 the Navy initiated the Polaris Project. A project to develop a ballistic missile capable of being launched from a submerged submarine. The missile required a very small inertial guidance system much smaller than anything that was even on the drawing boards. The Navy selected the Instrumentation Laboratory for the project. Late in 1959, the system was ready and flew the first inertially guided Polaris with a digital guidance computer. By 1960, the Polaris guidance system was in production. Drapers team had designed and transferred the technology to a production facility in accordance with the Navys development plan and schedule. Next, the Navy initiated a guidance system improvement program under a more relaxed schedule. Size and weight reduction were important. The Lab was exploring welded cordwood fabrication techniques and integrated circuits as possible approaches. We had a development contract with TI for 64 integrated circuits but, delivery was still years in the future. Welded cordwood looked promising and was selected for the second generation Polaris guidance computer. slide 1 right Prototype second generation Polaris computer Modules were formed by stacking discrete components in a three dimensional array and interconnecting them with welded point to point wiring. The modules plugged into a backplane assembly which had connector pins interconnected with wire wrap. This welded cordwood version of the computer became the Navy's second generation and went into production in the early 1960's. It achieved a significant size reduction over the previous guidance computer which employed printed circuit board type packaging. Both the first and second generation systems served the Navy until integrated circuits became a viable alternative much later in the 1960s. NASA followed the Navy's development plan and made the Instrumentation Laboratory responsible for Apollo's inertial guidance system. Neither NASA nor the Instrumentation Laboratory designers understand the complexity of the task. Inertial guidance requirements for a ballistic missile were understood, but Apollo's requirements and even space guidance theory were virtually unknown. There was nothing similar to an End Item Specification. To little was know. However, there were a few obvious requirements. The system must operate reliably in space for an extended period of time, it must be small and consume very little power, and new for inertial guidance systems, astronauts must be able to operate it while in space. Previous systems required guidance system experts to prepare a system for its mission. Computational requirements for the digital computer were vague and hardware technology applicable to a space mission limited. For example, integrated circuits were still on the horizon. Our development contract with TI had not shown promise. Transistors and diodes were available, but their history left much to be desired. Magnetic core memories, applicable to a missiles environment, were just emerging from laboratories. Multilayer printed circuit board technology was in its infancy. A lot of work would be necessary before these technologies could be considered mature enough for a space application. The Lab had an Air Force development contract to design a small low power computer for space applications and this design seemed feasible for Apollo. It had magnetic core-transistor logic circuits, 512 words of core memory as RAM, and 4K words of core memory operating as ROM. Since the Polaris guidance computer had 12 words, system engineers felt 512 words of RAM should be plenty. Apollo could capitalize on the experience gained with this Air Force development and with the welded cordwood fabrication techniques developed for the Polaris guidance computer. NASA laboratories had preliminary designs for the spacecraft's command module (CM) and moved rapidly to get a spacecraft contractor. However, the method to land the CM on the moon and return it to earth was debated for a year before NASA chose the lunar orbital and rendezvous approach with its requirement for a lunar landing module (LM) which would require another inertial guidance system. slide 2 right Lunar Mission During this first year, guidance system engineers proceeded with the development of the CM's guidance equipment which was required for the trip out to the moon and return to earth. The problems associated with landing had little impact. slide 1 left BL II CM  The elements of the CM's guidance system are an optical system with sextant and telescope, an inertial measurement system, digital computer, and system displays and controls. These were mounted in the lower equipment bay where an astronaut stood while operating the guidance system. The system included two computer displays, one in the lower equipment bay and one on the main display panel which was accessible when the astronauts were in their seats. If we look again at the Mission we can get an overview of the system functions. During the trip out to the moon and return to earth, the astronaut responsible for guidance and navigation makes a series of star angle measurements using the optical subsystem. This is a navigation function similar to a sailor's sextant measurements for a ship's navigation. From these measurements the computer calculates the spacecraft's position and velocity as a function of time, parameters termed the state vector. Additional calculations determine whether these parameters will take the spacecraft to the right point in space at a future time. If not, the astronaut must initiate the guidance function and spacecraft thrust to make a velocity change. The guidance system controls the spacecraft's steering while thrusting. Other system functions included, initializing the inertial measurement unit to establish a coordinate system for the acceleration measurements, operating the optical subsystem in support of the astronauts during star angle measurements, and operating the displays and controls. Requirements for computer operated displays and controls raised sticky design problems subject to many conflicting opinions. Astronauts, human factors experts, system engineers and of course the digital designers had ideas. A major question was how do you take a military pilot, put him in a spacecraft and have him operate a digital computer? Computers were not user friendly. One fundamental difference of opinion concerned the type of displays to be used, analog meters versus digital numeric displays. Astronauts and most system engineers preferred analog because military aircraft displays were analog. But the hardware for numeric displays would be simpler. Hardware simplicity won the debate for the digital designers. A computer driven display and control resulted which had a keyboard and numeric displays. It became known as the DSKY, short for display and keyboard. Astronauts would operate the computer using a set of numeric codes identifying verbs such as display, monitor, load and nouns such as time, star angles, velocity. Even this limited number of guidance system functions were putting a squeeze on the computational capacity of the core-transistor computer proposed just a year earlier. Significant progress had been made. During that year, the computer's and DSKY's form factors, power consumption, and most system interfaces were specified. Module packaging and assemble methods had been developed for the RAM and ROM memories, and various parts of the computer's core-transistor logic circuitry. Experience with memory packaging led us to believe both RAM and ROM could be increased. But, any changes to increase computational capacity would be difficult. Speed was restricted by the core-transistor logic circuits. Looking at the Mission again, LM operations appeared complex and demanding upon the computer's computational capacity. Much more demanding than most of the CM's functions. CM operations were quite varied and as a result would require adequate ROM memory but, computational speed should not be a problem. NASA managers had assumed the CM computer could be reprogrammed for the LM application. This assumption was losing support as LM system engineers expressed concern about the LM's requirements. Fortunately, there were new approaches on the horizon. Integrated circuits became commercially available in 1961. A parallel effort to design an integrated circuit version of the core-transistor computer was initiated. We wanted to explore integrated circuit availability, characteristics and potential advantages. The results were very promising. Logic processing speed could increase. A redesign would open a window of opportunity to double the RAM and triple the ROM, and make architectural changes that would increase computational capacity. The computer's size could be maintained or decreased. Although not obvious at the time, integrated circuits were the first step in a breakthrough which would decrease the point to point wiring in digital computers. Increased power consumption was the only apparent disadvantage. Therefore, in late 1962 we proposed, and NASA approved, a change from the core-transistor logic to integrated circuit logic. The Program's schedule required the computer designers to proceed rapidly. slide 3 right AGC breadboard This rack mounted monster is the integrated circuit version of the Apollo Computer. It was functional in early 1963. A prototype of the CM's main panel DSKY can be seen on the right. Compressing this breadboard into a flyable package was the mechanical designers task. By early 1964 the flight prototype was operational. slide 2 left Flight Prototype The computer's packaging and planned mounting in the command module is visible. Three trays one for the computer's external interfaces and two trays of electronics plugged into a wire wrapped interconnection assembly which provided intertray cabling. Electronic trays, one logic and one memory held the modules and provided module interconnections via wire wrap. Temperature control was by conduction from the trays through thermal fuzz into a water cooled base plate. Space for a complete set of spare modules allowed for redundancy. The computer 's design team was quite conscious of the reliability problems that computers of that vintage were demonstrating. Redundancy seemed necessary. We considered various kinds from repair in flight to two computers operating in parallel with manual switch over. Since failure detection and isolation was necessary to support redundancy, we included failure detection circuits and self test software in the design. Failures can be hard or transient. In our experience a very large percentage of failures were transient. If so a failure detected by these circuits would force the computer to restart its processing, leaving recovery to the software. This failure detection and recovery procedure consumed scarce computer resources and added complexity to the software development, all of which annoyed the software designers. In retrospect there was the question. Did the effort pay off? Apollo 12 was the only mission where the hardware restart capabilities were exercised. The launch vehicle was struck by lighting twice just after liftoff. The strikes induced transient failures in the CM's power system. The computer detected the transients and restarted as intended. A different example of fault tolerance was demonstrated during the Apollo 11 landing. The computer was being overloaded during descent to the surface. The computer's operating system processed tasks according to an assigned priority. In the event of an overload low priority tasks were set aside. Essential tasks were processed on schedule. Mission control personnel were shaken but the computer functioned as designed. LM's functional requirements were putting a squeeze on even this newly designed integrated circuit computer. Primarily, the computer's interfaces could not support the LM's systems, one of which was a very necessary landing radar. Also, guidance system engineers were guessing that the LM computer would need more memory. Pressure was building for a different computer in the LM. NASA's desire for a CM computer which could be reprogramed for the LM application was losing validity. LM requirements were studied and debated until early in 1964 when NASA decided to call a series of meetings with the two spacecraft contractors, Instrumentation Lab designers and various NASA system engineers to resolve the issues. NASA realized top level system integration was necessary. The first ground rule was significant. NASA dictated that the LM and CM computers would be exactly the same with one DSKY type. At this point there were two different DSKY form factors in the CM. Almost as important was NASA's elimination of redundancy at the subsystem level. Backup modes of operation would provide crew safety. A set of functional requirements for each spacecraft evolved and for the computer, a common set of system interfaces were defined that was compatible with each spacecraft. Since the LM functions were more complicated, they dictated the computer's interfaces. The CM followed suit. slide 4 right LM pictorial The results for the LM are visible in this pictorial. slide 5 right CM interfaces In a little more technical format the same computer interfaces are displayed for the CM application. Again we knew significant improvements were feasible. Both RAM and ROM could be increased. Also, Moor's law was taking effect. A logic chip with two logic gates became available. slide 6 right IC schematic The circuits of both were resistor transistor NOR logic, Fairchild's Micrologic. The component's package changed from a TO-47 to a 10-lead flat pack making component attachment compatible with multilayer board technology, another major step forward. The logic density could more than double allowing for increased processing power without increasing the computer's volume. NASA approved and we embarked upon a new design, Block II. So we had two computers in design. Block I, the flight prototype needed to be finished in order to meet the schedule for CM flight tests. NASA's experience with the Gemini missions, indicated all connectors must have protection from the spacecraft's moisture environment. To conform, the Block I computer's case would be redesigned. And what do you know? Case redesign opened the door to an increase in the ROM from 12k to 24K. slide 3 left BL I 100 Block I in its final form with the two DSKYs, one for the main panel and one for the lower equipment bay. Three Block I computers flew unmanned command module missions starting in 1966. From a comparison between Block I and Block II computers we can see significant changes. slide 7 right BL I/BL II comparison (Note the increases: instructions, speed, and interfaces.) The instruction set architecture of the Block II maintained software compatibility with Block I but incorporated architectural improvements which resulted from experience gained during Block I software developments. slide 4 left BL II and DSKY Finally we have the product for lunar missions. The CM had two DSKYs. The LM had one. All three were identical. Flights with Block II computers started in January 1968. Program schedule restraints brought an end to hardware changes. System and software designers had to live with the computational capacity of the Block II computer. Many software routines were paired down or eliminated to fit within the computer's memory capacity and computational speed. Self test, the hardware designer's pride, fell before the ax to make room for more important mission functions. Verifying that software would fit was a major part of the software development and test activity. The following movie was produced in early 1966 for an AGARD lecture series. It opens with an operating computer and DSKY. The computer has only two of the six rope modules installed. These contain the software for the computer's basic operating instructions, DSKY operation, and self test. I will let the narrator explain what is going on. He seems to know more than I do. (start movie) (After cover of DSKY removal) slide 5 left Logic Chip ( After incoming punched card) slide 6 left Logic Module (After I have finished ROM discription) slide 7 left ROM Schematic This schematic will help me explain the ROM operation. Inhibit and set/reset lines select and switch a magnetic core. Their installation has just been completed. Sense line wiring provides the memory. When a single core is switched, a line passing through the core will produce a pulse (a one) a line bypassing the core will produce no pulse ( a zero). The presents or absence of pulses on the 16 sense lines make up the bits stored in one word. If I remember correctly each core stored 6 words. slide 8 left ROM Wiring A close up of the ROM wiring prior to sense line wiring. (Restart movie) (After threading near bottom ) slide 9 left ROM Module Here we see a completed ROM module prior to potting. (After move to RCA ) slide 10 left RAM Module An assembled RAM module prior to potting. (After return to Raytheon ) slide 11 left Trays Opened (movie end) With the Computer opened we can look at a few additional details. The logic tray at the bottom contained, 24 logic, two power conversion and five interface modules. slide 8 right Interface Module The memory tray contains in addition to one RAM and 6 ROM modules, memory selection and driver modules, an oscillator for the guidance system's timing and RAM and ROM memory sense amplifier modules. the sense amplifier modules are typical cordwood construction. Components are mounted in a magnesium frame and are interconnected with welded point to point wiring. . slide 9 right Sense Amp module Each module had sixteen sense amplifier circuits which included an integrated circuit chip similar to an analog operational amplifier. slide 10 right Sense Amp Chip Now the final product as installed in the CM during spacecraft assembly. A computer and one DSKY mounted in the lower equipment bay. The second DSKY on the CM's main panel. slid12 left slide 11 right CM Assembly DSKY  Pictures of the LM mounting is available on the WEB. I have touched on issues which shaped the computer's design but there were more. Several were related to the spacecraft environments, EMC, moisture, changes in cabin pressure, thermal, acceleration, and vibration. Reliability or more correctly component quality and workmanship defects were constant threats. A very troubling quality problem was conductive particles in components. Then there were those Naysayers nipping at our heels. The computer with its 5600 integrated circuit logic gates was an easy target. However annoying they were their function was important. NASA needed watch dogs, they could not risk failure. References Richard H. Battin, An Introduction to the Mathematics and Methods of Astrodynamics, American Institute of Aeronautics and Astronautics, Inc., Reston VA, 1987 Eldon C. Hall, Journey to the Moon: The History of the Apollo Guidance Computer, American Institute of Aeronautics and Astronautics, Inc., Reston VA, 1996 Eldon C Hall, Case History of the Apollo Guidance Computer, Chapter 9 AGARDograph 114 Director E. Keonjian, Technivision Services Ltd., Maidenhead England, 1968 Web reference: www.apolloachives.com Plate 11 "Journey to the Moon" Fig. 34 "Journey to the Moon" Fig. 38 "Journey to the Moon" Figure 57 "Journey to the Moon" Plate 22 "Journey to the Moon" Fig. 94 "Journey to the Moon" Fig. 77 "Journey to the Moon" Fig. 73 "Journey to the Moon" Plate 26 & 23 "Journey to the Moon" Table 10 "Journey to the Moon" Plate 35 & 37 "Journey to the Moon" Plate 6 "Journey to the Moon" Plate 30 "Journey to the Moon" Fig. 63 "Journey to the Moon" Plate 19 "Journey to the Moon" Plate 29 "Journey to the Moon" Plate 28 "Journey to the Moon" Plate 33 "Journey to the Moon" Plate 27 "Journey to the Moon" Fig. 61 "Journey to the Moon" Plate 1 "Journey to the Moon" Plate 39 "Journey to the Moon" +,RScdqr..0 0!>">{>|>??DCyuqujujujujujujujujuZ DCECDDEE6J7JuJvJJJLLcMdMMM7N8NPPYQxtxtxtxtxtxtxtxtxtxtxtZYQZQW]W^W}WxtxtxtptptptltxtxtxtZ}W~WWWWWWWXX X!XFXGXgXhXXXXXXXXxtxtxtxtxtxtxtxtxtxtxtZXXYY0Y1YQYRYrYsYYYYYYYYxtxtxtxtxtxtxtxtZF)+{}  D F oaYYYYYYYYYYYYY  !!%UMgi}EGVfhXZuummmmmmmmmmmmmuummu   Zhtv>@!!)$+$%%q(s(]]SSSKKKKKKKKK   ! s(i*k*,...{.~..../////wwwwwwmmwwwwwK!    / 0 0)2+233u5w588l:n:;;<<]UUUUUUUUUUUUUUU ! <>>>$>&>]>_>n>~>>>>?????@Awwmmccmmmwwwwwmmwww     AA,C.CDBCD6IuIIKcLL7MOYP