NASA Office of Logic Design
A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.
(1) Organization and Type
Spaceborne computer memories are functionally divided into program memory and variable memory sections. Sometimes the memories are physically separate and may even be constructed of different types of devices. In other cases, program and variable storage is incorporated in the same memory, as is generally the case with ground-based computers. The program memory is often either a fixed or a nondestructive read-out (NDRO) memory which contains the program instructions and constants. The variable memory is almost invariably a random-access read-write memory for temporary (erasable) storage of computational results. The size of the program memory is typically five to twenty times that of the variable memory, although the ratio will generally not exceed about ten.
Fixed or read-only memories usually have their contents manufactured into them; thus, changing the contents of a read-only memory requires physical modification of the device. The possible advantages of fixed memories lie in volume efficiency; retention of program following electrical malfunctions, power loss, or program error (sometimes shared by protected core memories); simplicity of construction and operation; and increased reliability (NDRO memories share some of these characteristics). Moreover, a fixed memory offers assurance that the computer program is identical through all phases of testing and in flight. On the other hand, a "read-only" memory requires that program and data be determined well in advance of use; consequently, it places a limitation on the computer's ability to accommodate changes in mission plan such as may be required periodically in most applications.
An example of a fixed memory is the core-rope program memory used in the Apollo guidance computer (ref. 14). This design achieved high density and reliability at a cost of having to procure new memory modules with about a four-week production cycle for program changes. Despite the fact that verification cycles were at least as long as production cycles, and that no launch postponements have yet been caused by this production cycle, the fixed memory has been a controversial issue owing to its potential for causing problems.
Read-write memories are classified as volatile or nonvolatile depending upon whether or not their contents remain intact when power is removed. Read-write memories may also be either destructive readout (DRO) or nondestructive readout. In general, NDRO memories enjoy two advantages over DRO memories. They are less vulnerable to power fluctuations or other interruptions of the read process, since at no time during the reading operation is the information cleared from the memory. Secondly, they can operate at higher speeds since it is not necessary to restore the contents following each read cycle.
As a compromise between reliability and flexibility, some read-write memories are designed so that their contents are electrically alterable only by special equipment; thus, in normal operation they behave as "read-only" devices. The Gemini guidance computer memory was an example. Each 39-bit memory word was divided into three 13-bit syllables; syllables 0 and 1 were multi-aperture NDRO core read-write storage, while syllable 2 was "read-only" after being loaded by ground-support equipment.
In addition to their main memories, many newer computers have "scratchpad" memories, which are small, high-speed memories associated with the calculating circuitry. These memories give additional operating speed to a computer and seem particularly desirable for spaceborne computers since only small segments of the variable memory are likely to be used during any one program subroutine. The size of these memories may be determined by the mission requirements for operating speed since there is some penalty in power, weight, and complexity for scratchpad memory words vs the regular, random-access memory of the computer. These memories are especially popular in larger systems because of their increased operating speed and reduced number of instructions (since two-address systems are generally used). However, the saving in program storage is partially offset since the two-address instructions require a greater word length.
One of the most difficult parameters to specify, and one which has been a constant problem in space vehicle applications, is the memory size or capacity. Basically, memory capacity problems have arisen because the number of tasks assigned to the computer increased substantially as the spacecraft program progressed. Also, the complexity of certain tasks has sometimes been underestimated.
One of the earliest computers to experience memory capacity problems was the original Centaur machine (ref. 45). As the major storage medium, this computer used a magnetic drum, which included a timing track, instruction register, accumulator, multiplier/quotient register, as well as a main memory. In the original design (1959/1960), the main memory consisted of 37 tracks of permanent storage and 3 tracks of temporary storage, at 64 words per track. However, this was found to be inadequate, and in the redesign in 1961/1962, seven permanent tracks and one temporary track were added to the drum. With clever programming, this 3072-word capacity has been adequate to implement G&N tasks, and the Centaur has successfully launched several Surveyor spacecraft to the moon, two Mariner spacecraft to Mars, and an OAO into earth orbit. However, to expand the Centaur's capability for future missions, a new computer was required and is presently in development (ref. 11). The improved Centaur computer will provide not only guidance and navigation, but also flight attitude control, vehicle sequencing, propellant utilization, and telemetry format control.
The Gemini program experience is another example of the problems associated with growing computer memory requirements (ref. 15). These were increased significantly when the ascent guidance mode was added to the computer in May 1962 to provide backup guidance capability for the Titan 2 launch vehicle. Another early addition was the requirement for an orbit navigation mode. These additions, plus numerous small features and improvements to existing programs which required additional memory capacity, occupied all the memory space by January 1963. The programming of the second operational "math" flow in June 1963 revealed that the memory capacity was exceeded by over 700 words, even after significant savings had been achieved by reprogramming. Three solutions were considered for this problem:
- Reduce programming requirements at the expense of accuracy and/or versatility. This approach could have been accomplished by across-the-board reductions in all modes, or by dropping one of the computer modes (rendezvous and orbit navigation were not required for the early spacecraft).
- Provide additional usable memory locations by hard wiring some elementary functions presently programmed. Such an approach would have gained 825 instruction locations.
- Provide an auxiliary tape memory external to the computer under the control of the astronauts. This unit would contain sufficient storage to handle present requirements, as well as any contemplated future requirements.
A combination of the first and third alternatives was eventually adopted. On Spacecraft 2 through 7, the orbit navigation mode was not included. On Spacecraft 8 through 12, an auxiliary tape memory was added to the spacecraft.
The development of the tape memory, begun in mid-1964, was a costly and time-consuming process which could have been avoided if the original design had provided for easy memory expansion. However, when completed, it provided an additional capacity for storage of 85,000 13-bit words and permitted a high degree of computer flexibility, as evidenced by the inclusion of nine operational computer modes in the last four spacecraft. In addition to alleviating the memory capacity problem, the auxiliary tape memory provided a memory reload capability for use in the event of an inflight memory alteration, such as occurred during the flight of Spacecraft 4.
A similar experience was encountered during the design of the Apollo guidance computer. Table 3 presents a chronological summary of the AGC memory growth from 1961 to 1965. Throughout much of this history, at least prior to 1964, the memory growth was due more to demonstration of the feasibility of a larger memory than to well-defined system requirements.TABLE 3.-History of Apollo Guidance Computer Memory Growth
Date Variable Program Remarks 1961 512 4K
Paper design based on inertial navigation requirements. Only executive and similar tasks programmed
1962 1K 12K Original mechanical design. 1963 1K 24K Block I design. Guidance system programming started. 1964 2K 36K
Block 11 design. Redefinition of functional requirements; change to digital autopilot, improved crew displays and controls, and others. Greater speed also required.
1965 2K 36K
Mission programming started.
The Block I Apollo G&N system was conceived about 1962 to furnish position, velocity, and attitude control of the command module using inertial and optical sensor inputs. Outputs were transmitted to an analog S&C system responsible for the direct excitation of control actuators. To meet these requirements, plus a variety of less challenging ones such as telemetry, the Block I AGC design provided a 1K coincident-current core variable memory, a 12K core-rope fixed program memory, eleven instructions, and a 12-Ásec memory cycle.
The Block I computer was used in support of three suborbital unmanned missions and was programmed, but not used, for a manned orbital mission. As these programs were being prepared, it was concluded that more memory and speed resources would be required for the lunar missions.
In 1964, the Apollo G&N system was revised to conform with the lunar module and revised command module designs. Design decisions made at that time are of some interest because of the knowledge gained during the Block I design and checkout. The Block II computer requirements were larger than those of Block I for several reasons. One reason was the decision to incorporate the autopilot function, which was formerly in the analog stabilization and control system, into the AGC. Another was the evolution of the computer's display into a major mission sequencing device. In addition, several new interfaces were defined whereby the computer could deliver data to spacecraft displays and receive data from spacecraft manual controls.
A 50% increase in the fixed memory capacity and a doubling of the variable memory capacity were made without any major impact on the associated circuit techniques. At this stage it was felt that all functions could be performed within these new memory capacities. Not surprisingly, the increased memory resources were committed before the programming was complete, and a large effort was expended to maximize the utilization of the available memory.
A final example of memory capacity growth is the Abort Electronics Assembly computer which provides backup guidance for the Apollo lunar module (ref. 16). In the original design, based on request for proposal (RFP) requirements, 500 18-bit words of memory were determined to be adequate for the required computations. At that time, there were no requirements for variable mission changes since the Abort Guidance System was essentially an attitude reference system. However, due to major increases in system functional requirements, the memory grew to 2,000 words, including 500 words of erasable storage. Additional studies soon revealed that the original guidance scheme was not adequate, and that explicit guidance was required to provide rendezvous via parking orbit or direct ascent. To implement the revised guidance system functions, it became necessary to provide an I/O unit for use by the crew in communicating with the computer, and to increase the size of the memory to a total of 4,096 words, with 2,048 words of hard-wired "read-only" memory and 2,048 words of read-write data memory. A significant by-product of these memory and I/O changes was the required redesign of the AEA power supply.
Home - NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz