Computers in Spaceflight: The NASA Experience

- Chapter Two -
- Computers On Board The Apollo Spacecraft -
 
 
Evolution of the hardware: Old technology versus new block I and Block I designs
 
 
[31] The computer envisioned by MIT's preliminary design team in 1961 was a shadow of what actually flew to the moon in 1969. There always seem to be enough deficiencies in a final product that the designers wish they had a second chance. In some ways the Apollo guidance computer was a second chance for the MIT team since most worked on the Polaris computer. That was MIT's most ambitious attempt at an "embedded computer system," a computer that is intrinsic to a larger component, such as a guidance system. Although the Apollo computer started out to be quite similar to Polaris, it evolved into something very different. The Apollo guidance computer had two flight versions: Block I and Block II. Block I was basically the same technology as the Polaris system. Block II incorporated new technology within the original architecture.
 
Several factors led from the Block I design to Block II. NASA's challenges to the MIT contract and the decision to use the rendezvous method instead of a direct ascent to the moon were decisive. A third factor related to reliability. Finally, the benefits of the new technology influenced the decision to make Block II.
 
Before NASA let the contract to MIT, but after it was known that the Instrumentation Laboratory would be accorded "sole source" status, several NASA individuals began studying ways to consolidate flight computer development. In June 1961, Harry J. Goett of Goddard Space Flight Center recommended that the computers needed for the Orbiting Astronomical Observatory (OAO), Apollo, and the Saturn launch vehicle be the same. He cited an IBM proposal for $5 [32] million to do just that17. On the same day Goett's recommendation, RCA proposed the use of a 420-cubic-inch computer with only an 80- watt power consumption and 24-bit word size as a general-purpose spaceborne computer18 . This proposal got nowhere and NASA's Robert G. Chilton challenged Goett's idea, showing that the expected savings would not materialize. Even though the projected cost of the Apollo computer would decrease to $8 million from $10 million, the OAO development costs would rise from $1.5 million to $5 million19. Ironically, in the same month, Ramon Alonso from MIT met with Marshall Space Flight Center personnel about the use of the Apollo computer in the Saturn20. Although MIT got the Apollo contract and IBM got the contract for the Saturn computer, the idea of a duplicate system did not die. Two years later, when the deficiencies of the Polaris-based system were obvious and the solutions offered by the new technology of the Block II version still unproved, David W. Gilbert, NASA manager for Apollo guidance and control, proposed replacing the MIT machine with the one IBM was building for Saturn21. It did not occur because Gilbert wanted NASA to accept the reprogramming costs, and the existing configuration of the IBM computer would not fit in the space allotted for it in the CM. Nevertheless, MIT would still have to deal with NASA misgivings about the hardware design as late as May 1964, when Maj. Gen. Samuel C. Phillips, deputy director of the Apollo Program, reported on a meeting to discuss the use of the triple modular redundant Saturn launch vehicle computer in Apollo 22.
 
The decision to have a separate CM and the LEM influenced the transition to Block II by providing a convenient dividing point in the Apollo program. The early Apollo development flights were to use the CM only. Later flights would include the LEM. Since Block I design and production had already proceeded, planners decided to use the existing Block I in the unmanned and early manned development flights (all relatively simple earth-orbital missions) and to switch to Block II for the more complex combined CM-LEM missions 23.
 
Reliability was another force behind Block II. Daring early planning for the guidance system, redundancy was considered a solution to the basic reliability problem. Designers thought that two computers would be needed to provide the necessary backup; however, they dropped this scheme for two reasons. The ground had primary responsibility for determining the slate vector (the position of the craft in threedimensional space) in translunar, lunar orbit, and transearth flight24. Moreover, none of the variations of the two-computer or other redundancy schemes could meet the power, weight, and size requirements25. One way to provide some measure of protection is to make the computer repairable in flight. The Block I design, due to its modularity, could be fixed during a mission that carried appropriate spares. At any rate, its predicted mean time between failures (MTBF) [33] was 4,200 hours, about 20 times longer than the longest projected mission 26. But Block I's repair capability became a negative factor when sealing the computer began to be considered more important to reliability than the ability to repair it27. Aside from packaging, overall malfunction detection was improved in the Block II design, further increasing reliability28.
 
The most important reason for going to Block II was the availability of new technology. The Block I design used core transistor logic. It had several disadvantages:
 
 
These disadvantages led MIT to begin studying, as early as 1962, the possible use of integrated circuits (ICs) to replace core transistor circuits. ICs, so ubiquitous today, were only 3 years old then and thus had little reliability history. It was therefore difficult to consider their use in a manned spacecraft without convincing NASA that the advantages far outweighed the risks.
 
To accomplish this, the MIT team chose a direct-coupled transistor logic (DCTL) NOR gate with a three-input element,30 consisting of three transistors and four resistors. NOR logic inverts the results of applying a Boolean OR operation to the three inputs. It took nearly 5,000 of these simple circuits to build an Apollo computer. Using a variety of circuits would have simplified the design since the component count would have been reduced, but by using the NOR alone, overall simplicity and reliability increased31. Also, the time it took the machine to cycle became fixed at 11.7 milliseconds, a double bonus in that speed increased and cycle time was consistent32.
 
Aside from these advantages, MIT believed that the lead time to the first flight would permit reliability to be established and the cost of the ICs to come down33. At the time, the production of such circuits low, and they were more expensive than building core transistor circuits. To place the production rate in perspective, MIT chose the NOR ICs in the fall of 1962 and by the summer of 1963, 60% of the [34] total U.S. output of microcircuits was being used in Apollo prototype construction34. This is one of the few cases in which NASA's requirements acted as a direct spur to the computer industry. When MIT switched to ICs, it kept the Apollo computer as "state of the art" at least during its design stage. It would be hopelessly outdated technologically by the time of the lunar landing 7 years later, but in 1962, using the new microcircuits seemed to be a risk. This view is contested by one member of the MIT team, who later said that the decision "wasn't bold; it was just the easy thing to do to get the size and power and other requirements"35.
 
With the ICs fully incorporated in the Apollo computer and the transition from Block I to Block II complete, NASA possessed a machine that was more up to date technologically. It had double the memory of the largest Block I, more I/O capability, was smaller, and required less power36. Besides, it was also more reliable, which was, as always, the major consideration.

link to previous pagelink to indexlink to next page