Computers in Spaceflight: The NASA Experience
Figure 3-2. The concept of Triple Modular Redundancy.
- Back -
Computers in Spaceflight: The NASA Experience
Figure 1-2. Locations of key components of the Gemini Guidance System. (From McDonnell Corp., Gemini Familiarization Manual)
- Back -
Computers in Spaceflight: The NASA Experience
Figure 7-9. Hard copy of a display from one of the firing room consoles.
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
Figure 4-4. The intercommunication system used in the F-8 triplex computer system.
- Back -
Computers in Spaceflight: The NASA Experience
Figure 9-3. One of the instructional screens of the Regency system used in training.
- Back -
Computers in Spaceflight: The NASA Experience
Figure 1-6. Manual Data Insertion Unit. (From McDonnell Corp., Gemini Familiarization Manual)
- Back -
Computers in Spaceflight: The NASA Experience
Figure 1-7. Incremental Velocity Indicator. (From McDonnell Corp., Gemini Familiarization Manual)
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
Figure 1-4. Layout of the Gemini Digital Computer core memory. (From McDonnell Corp., Gemini Familiarization Manual)
- Back -
Computers in Spaceflight: The NASA Experience
Figure 3-4. The real-time cycle of the Skylab 16K flight program. (From IBM, Skylab Operation Assessment, ATMDC, 1974)
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
Figure 4-6. A block diagram of the Shuttle flight computer software architecture. (From NASA, Data Processing System Workbook)
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
Figure 4-2. A block diagram of the hardware that makes up the Shuttle Data Processing System. The fifth computer is the Backup Flight System computer.
- Back -
Computers in Spaceflight: The NASA Experience
Figure 4-5. The various computer configurations used during a Shuttle mission. The names of the operational sequences loaded into the machines are shown.
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
- Back -
Computers in Spaceflight: The NASA Experience
FIGURE 5-9. A block diagram of the Viking Orbiter software. This same software structure was used for the Voyager Command Computer Subsystem software (From Kohl, Viking Orbiter Computer Command Subsystem Software)
- Back -
Computers in Spaceflight: The NASA Experience
Figure 5-5. A block diagram of the Viking Orbiter Command Computer Subsystem hardware. This basic dual computer configuration was used for both Viking computers and all three Voyager computer systems. (From Kohl, Viking Orbiter Computer Command Subsystem Hardware)
- Back -
Computers in Spaceflight: The NASA Experience
-
[404] Appendix IV - Mariner Mars 1969 Flight Program Figure IV-1 - This segment of a Mariner programmable sequencer flight program is given as an example of the sort of flexibility gained by adding a memory to the system. The first segment, the Executive, is only seven lines, yet it essentially controlled the software. The remaining code demonstrates a typical subroutine. The entire length of this program was 128 lines.
Computers in Spaceflight: The NASA Experience
Computers in Spaceflight: The NASA Experience
- Chapter Five - - From Sequencers to Computers: Exploring the Moon and the Inner Planets - On to the outer planets -
- [170] Experience and the appreciation of the flexibility of computer processors are the legacy of the computer systems development for the inner planet probes. Consistent and detailed documentation, simple, reliable, and reusable hardware designs, and the practice of many missions contributed to the later and continuing success of Voyager. Just as management experience gained during Apollo applied to the shuttle, JPL's success with Viking made the concurrent development of Voyager and Galileo easier. People like Samuel Deese, who gained practical experience in the 1960s, led subsystem management in the 1970s. Viking's Wayne Kohl went on to Galileo after the Mars landings in a position similar to the one he held on the former project. Both Voyager and Galileo are better projects because of the continuity of techniques and personnel.
-------------------------------------------------------------------------------- /src/Ch2-9.md: -------------------------------------------------------------------------------- 1 | ### Lessons 2 | 3 | What did NASA learn from its experiences with the Apollo 4 | computer system? At the management level, NASA learned to assign 5 | experienced personnel to a project early, rather than using the start of 6 | a project for training inexperienced personnel; many NASA managers of 7 | software and hardware were learning on the job while in key positions. 8 | Also, more participation by management in the early phases of software 9 | design is necessary so that costs can be more effectively estimated and 10 | controlled. 11 | 12 | From the standpoint of development, NASA learned that a more thorough, 13 | early effort at total systems engineering must be made so that 14 | specifications can be adequately set. NASA contractors in the Apollo 15 | program faced changing specifications long after final requirements 16 | should have been fixed. This was expensive and caused such problems as 17 | Raytheon's retooling, memory shortages, and design insufficiencies. 18 | 19 | The realization that software is more difficult to develop than hardware 20 | is one of the most important lessons of the Apollo program. So the 21 | choice of memory should be software driven, and designers should develop 22 | software needed for manned spaceflight near the Manned Spacecraft 23 | Center. The arrangement with MIT reduced overall quality and efficiency 24 | due to lack of communication. Also, more modularization of the software 25 | was needed^[180](#source2)^. 26 | 27 | The AGC system served well on the earth-orbital missions, the six lunar 28 | landing missions, the three Skylab missions, and the *Apollo-Soyuz* test 29 | project. Even though plans existed to expand the computer to 16K of 30 | erasable memory and 65K of fixed memory, including making direct memory 31 | addressing possible for the erasable portion, no expansion 32 | occurred^[181](#source2)^. The Apollo computer did fly on 33 | missions other than Apollo. An F-8 research aircraft used a lunar module 34 | computer as part of a "fly-by-wire" system, in which control 35 | \pagebreakon{63} surfaces moved by servos at the direction of electronic 36 | signals instead of traditional cables and hydraulics. In that way, the 37 | Apollo system made a direct research contribution to the Shuttle, which 38 | is completely a fly-by-wire craft. The most important legacy of the AGC, 39 | however, was in the way NASA applied the lessons it was beginning to 40 | learn in developing ground software to the management of flight 41 | software. 42 | -------------------------------------------------------------------------------- /src/Part3-intro.md: -------------------------------------------------------------------------------- 1 | NASA's ground computer systems are characterized by large 2 | size, by the implementation of real-time programming, and by the use of 3 | many computers connected together. The need for these three attributes 4 | has caused NASA and its contractors to devise new techniques for 5 | computer applications, such as operating systems for mainframe computers 6 | capable of handling real-time processing and sophisticated networking. 7 | Through these developments NASA has had its largest impact on computing 8 | in the commercial world. 9 | 10 | Differences between ground-based computers and on-board computers center 11 | on the relative ease of hardware procurement with the continued 12 | difficulty of software development. On-board computers evolved from 13 | custom-made systems to the largely off-the-shelf Skylab and Shuttle 14 | computers. Ground computers followed a more conventional line, as they 15 | could be, from the beginning, commercially available systems, though 16 | applied to noncommercial tasks. NASA examined many existing computer 17 | systems each time it needed a machine. In fact, the government's bidding 18 | process gave NASA a larger mix of different vendors' equipment than most 19 | commercial enterprises, causing occasional difficulties in connecting 20 | computers together. This problem and that of adapting business machines 21 | to real-time processing were largely solved by software. Contractors 22 | received invaluable experience in large systems development and 23 | networking in the process of achieving NASA's goals. 24 | 25 | Ground-based computer systems are used for preflight checkout and the 26 | launching of space vehicles, controlling both unmanned and manned 27 | missions, creating simulations of rocket flight for vehicle development 28 | and of space flight for crew training, processing telemetry data from 29 | launch vehicles and space probes, and in basic research. In the 30 | following chapters these functions are grouped into launch processing, 31 | mission control, and support tasks. Chapter 7 develops the concept of 32 | launch processing from the manual era to the fully automated Shuttle 33 | flight preparation. The chief result from this effort was a large 34 | integrated network of computers that proved to be highly innovative. 35 | Chapter 8 presents computer systems in both the manned Mission Control 36 | Center in Houston and the unmanned control \pagebreakon{206} centers at the Jet 37 | Propulsion Laboratory (JPL) and Goddard Space Flight Center. In Chapter 38 | 9, the uses of computers in simulations and data reduction are 39 | discussed. 40 | -------------------------------------------------------------------------------- /src/Ch3-4.md: -------------------------------------------------------------------------------- 1 | ### User Interfaces 2 | 3 | NASA and IBM designed the computer system to operate 4 | autonomously. One crewman reported "not much interaction" with the 5 | system at all^[62](#source3)^, but the capability was present 6 | for significant activity if needed^[63](#source3)^. The crew 7 | could enter data and actually make changes in the software through a 8 | keyboard located in the DAS on the ATM Control and Display Console. 9 | 10 | The DAS had only 10 keys and a three-position switch. The keys were the 11 | digits 0--7 (all entries were in octal), a clear key, and an enter key. 12 | The switch could select either power bus one or two, or be off. Above 13 | the DAS was an "Orbit Phase" panel containing a digital readout of 14 | minutes and seconds to the next orbital benchmark. When the first 15 | keystroke of a five-digit command was made, the uplink DCS commands were 16 | inhibited, and the time remaining clock inputs were inhibited, so that 17 | the clock digits could be used for displaying the keystrokes. In that 18 | mode, five digits would be lit instead of four. The remaining four 19 | keystrokes were the data/command inputs^[64](#source3)^. The 20 | display of the keystrokes represented an echo. If the sequence was 21 | correct, the astronaut pressed the enter key, or else he would restart 22 | the input process. Pressing the clear key brought back the digital 23 | clock. The rather limited nature of this command system indicates that 24 | it was intended for sparing use. 25 | 26 | Besides the DAS, one other switch on the control panel related to the 27 | computer system. In the "Attitude Control" area of the panel was a 28 | three-position switch that controlled which computer was in actual use. 29 | It could be set for automatic (and usually was), in which case the 30 | redundancy management software would take care of matters. Alternately, 31 | the crew could purposely select either the primary or secondary 32 | computer. If either of these was selected, then automatic changeover was 33 | inhibited^[65](#source3)^. The switch gave the crew protection 34 | from\pagebreakon{80} 35 |  39 | \pagebreakon{81} failure of the redundancy management software. 40 | Incidentally, the switch was not a common three-position toggle switch 41 | but, instead, required the crew to pull out and rotate the post. This 42 | protected the crew from accidental switching. 43 | -------------------------------------------------------------------------------- /src/Ch2-2.md: -------------------------------------------------------------------------------- 1 | ### MIT chosen as hardware and\ software\ contractor 2 | 3 | On August 9, 1961, NASA contracted with the MIT 4 | Instrumentation Lab for the design, development, and construction of the 5 | Apollo guidance and navigation system, including software. The project 6 | manager for this effort was Milton Trageser, and David Hoag was the 7 | technical director^[11](#source2)^. MIT personnel generally 8 | agree that they were chosen because their work on Polaris proved that 9 | they could handle time, weight, and performance restrictions and because 10 | of their previous work in space navigation^[12](#source2)^. In 11 | fact, the Polaris team was moved almost intact to 12 | Apollo^[13](#source2)^. Despite their experience with aerospace 13 | computers, the Apollo project turned out to be a genuine challenge for 14 | them. As there were no fixed specifications when the contract was 15 | signed, not until late 1962 did MIT have a good idea of Apollo's 16 | requirements^[14](#source2)^. One of the MIT people later 17 | recalled that 18 | 19 | > If the designers had known then \[1961\] what they learned later, or had 20 | > a complete set of specifications been available...they would probably 21 | > have concluded that there was no solution with the technology of the 22 | > early 1960s^[15](#source2)^. 23 | 24 | Fortunately, the technology improved, and the concepts of computer 25 | science applied to the problem also advanced as MIT developed the 26 | system. 27 | 28 | \pagebreakon{30} NASA's relationship with MIT also proved to be educational. 29 | The Apollo computer system was one of NASA's first real-time, large 30 | scale software application contracts^[16](#source2)^. Managing 31 | such a project was completely outside the NASA experience. A short time 32 | after making the Apollo guidance contract, NASA became involved in 33 | developing the on-board software for Gemini (a much smaller and more 34 | controllable enterprise) and the software for the Integrated Mission 35 | Control Center. Different teams that started within the Space Task 36 | Group, later as part of the Manned Spacecraft Center in Houston, managed 37 | these projects with little interaction until the mid-1960s, when the two 38 | Gemini systems approached successful completion and serious problems 39 | remained with the Apollo software. Designers borrowed some concepts to 40 | assist the Apollo project. In general, NASA personnel involved with 41 | developing the Apollo software were in the same virgin territory as were 42 | MIT designers. They were to learn together the principles of software 43 | engineering as applied to real-time problems. 44 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Computers in Spaceflight: The NASA Experience 2 | 3 | **Summary**: Get the book [here](https://github.com/01mf02/computers-spaceflight/releases/download/v1.0/cisf-20181105.pdf). 4 | 5 | This is a cleaned version of the book 6 | "Computers in Spaceflight: The NASA Experience" by James E. Tomayko, 7 | available as PDF from 8 |
Computers in Spaceflight: The NASA Experience
- [7] In the first 25
years of its existence, NASA conducted five manned spaceflight
programs: Mercury, Gemini, Apollo, Skylab, and Shuttle. The latter
four programs produced spacecraft that had on-board digital
computers. The Gemini computer was a single unit dedicated to
guidance and navigation functions. Apollo used computers in the
command module and lunar excursion module, again primarily for
guidance and navigation. Skylab had a dual computer system for
attitude control of the laboratory and pointing of the solar
telescope. NASA's Space Shuttle is the most computerized
spacecraft built to date, with five general-purpose computers as
the heart of the avionics system and twin computers on each of the
main engines. The Shuttle computers dominate all checkout,
guidance, navigation, systems management, payload, and powered
flight functions.
- NASA's manned spacecraft computers are characterized by increasing power and complexity. Without them, the rendezvous techniques developed in the Gemini program, the complex mission profiles followed in Apollo, the survival of the damaged Skylab, and the reliability of the Shuttle avionics system would not have been possible.
- When NASA began to develop systems for manned spacecraft, general-purpose computers small and powerful enough to meet the requirements did not exist. Their development involved both commercial and academic organizations in repackaging computer technology for spaceflight.
-------------------------------------------------------------------------------- /src/Ch1-5.md: -------------------------------------------------------------------------------- 1 | ### The impact of the Gemini digital computer 2 | 3 | The Gemini Digital Computer was a transitional machine. Dale 4 | F. Bachman of IBM characterized it as the "last of a dying breed. It was 5 | an airborne computer, ruggedized, special purpose, and 6 | slow"^[47](#source1)^. Nonetheless, its designers claim an 7 | impressive list of firsts: 8 | 9 | - The first digital computer on a manned spacecraft. 10 | 11 | - The first use of core memory with nondestructive readout. The 12 | machine was designed in an era of rotating drum memories, its 13 | designers considered it a step forward^[48](#source1)^. 14 | 15 | - IBM's first completely silicon semiconductor 16 | computer^[49](#source1)^. 17 | 18 | - The first to use glass delay lines as 19 | registers^[50](#source1)^. 20 | 21 | - Technologically advanced in the area of packaging 22 | density^[51](#source1)^. 23 | 24 | - The first airborne or spaceborne computer to use an auxiliary 25 | memory^[52](#source1)^. 26 | 27 | Development of the Gemini computer helped IBM in significant ways. It 28 | contributed more than anything else to the hardware and software of the 29 | 4Pi series of computers^[53](#source1)^. This series eventually 30 | produced the computer used on Skylab and the AP101 used in the Shuttle. 31 | It also helped to develop IBM's reputation for delivering reliable and 32 | durable spaceborne hardware and software^[54](#source1)^. One 33 | Gemini computer restarted successfully after being soaked in salt water 34 | for 2 \pagebreakon{26} weeks. Another used system went on to NASA's 35 | Electronics Research Laboratory in Boston for use on vertical and short 36 | takeoff and landing projects^[55](#source1)^. Coupled with IBM's 37 | involvement in the real-time computing centers used to monitor Mercury 38 | and Gemini missions, the company established itself as a major 39 | contributor to America's space program as it had been to the military 40 | research and development effort. Out of early military work came 41 | computer systems such as the Harvard Mark I, the 701, and SAGE computers 42 | used in air defense. However, even though identification with the space 43 | program has been maintained through several high-visibility projects, no 44 | significant commercial hardware products resulted as spinoffs. 45 | 46 | For NASA, Gemini and its on-board computer proved that a reliable 47 | guidance and navigation system could be based on digital computers. It 48 | was a valuable test bed for Apollo techniques, especially in rendezvous. 49 | However, the Gemini digital computer itself was totally unlike the 50 | machines used in Apollo. With its Auxiliary Tape Memory and core memory, 51 | the Gemini computer was more like the Skylab and Shuttle general purpose 52 | computers. It is in those systems where its impact is most apparent. 53 | -------------------------------------------------------------------------------- /pfcompat.py: -------------------------------------------------------------------------------- 1 | # Functions added to pandocfilters since version 1.2.2 2 | 3 | import codecs 4 | import io 5 | import json 6 | import sys 7 | 8 | from pandocfilters import walk, elt 9 | 10 | def get_value(kv, key, value = None): 11 | """get value from the keyvalues (options)""" 12 | res = [] 13 | for k, v in kv: 14 | if k == key: 15 | value = v 16 | else: 17 | res.append([k, v]) 18 | return value, res 19 | 20 | def toJSONFilters(actions): 21 | """Generate a JSON-to-JSON filter from stdin to stdout 22 | The filter: 23 | * reads a JSON-formatted pandoc document from stdin 24 | * transforms it by walking the tree and performing the actions 25 | * returns a new JSON-formatted pandoc document to stdout 26 | The argument `actions` is a list of functions of the form 27 | `action(key, value, format, meta)`, as described in more 28 | detail under `walk`. 29 | This function calls `applyJSONFilters`, with the `format` 30 | argument provided by the first command-line argument, 31 | if present. (Pandoc sets this by default when calling 32 | filters.) 33 | """ 34 | try: 35 | input_stream = io.TextIOWrapper(sys.stdin.buffer, encoding='utf-8') 36 | except AttributeError: 37 | # Python 2 does not have sys.stdin.buffer. 38 | # REF: https://stackoverflow.com/questions/2467928/python-unicodeencode 39 | input_stream = codecs.getreader("utf-8")(sys.stdin) 40 | 41 | source = input_stream.read() 42 | if len(sys.argv) > 1: 43 | format = sys.argv[1] 44 | else: 45 | format = "" 46 | 47 | sys.stdout.write(applyJSONFilters(actions, source, format)) 48 | 49 | def applyJSONFilters(actions, source, format=""): 50 | """Walk through JSON structure and apply filters 51 | This: 52 | * reads a JSON-formatted pandoc document from a source string 53 | * transforms it by walking the tree and performing the actions 54 | * returns a new JSON-formatted pandoc document as a string 55 | The `actions` argument is a list of functions (see `walk` 56 | for a full description). 57 | The argument `source` is a string encoded JSON object. 58 | The argument `format` is a string describing the output format. 59 | Returns a the new JSON-formatted pandoc document. 60 | """ 61 | 62 | doc = json.loads(source) 63 | 64 | if 'meta' in doc: 65 | meta = doc['meta'] 66 | elif doc[0]: # old API 67 | meta = doc[0]['unMeta'] 68 | else: 69 | meta = {} 70 | altered = doc 71 | for action in actions: 72 | altered = walk(altered, action, format, meta) 73 | 74 | return json.dumps(altered) 75 | 76 | # the version of pandocfilters defines Image to have only two arguments, 77 | # whereas Pandoc gives it three 78 | Image = elt('Image', 3) 79 | -------------------------------------------------------------------------------- /src/Ch2-3.md: -------------------------------------------------------------------------------- 1 | ### The Apollo computer systems 2 | 3 | The mission profile used in sending a man to the moon went 4 | through several iterations in the early 1960s. For a number of reasons, 5 | planners rejected the direct flight method of launching from the earth, 6 | flying straight to the moon, and landing directly on the surface. 7 | Besides the need for an extremely large booster, it would require 8 | flawless guidance to land in the selected spot on a moving target a 9 | quarter of a million miles away. A spacecraft with a separate lander 10 | would segment the guidance problem into manageable portions. First, the 11 | entire translunar spacecraft would be placed in earth orbit for a 12 | revolution or two to properly prepare to enter an intercept orbit with 13 | the moon. Upon arriving near the moon, the spacecraft would enter a 14 | lunar orbit. It was easier to target a lunar orbit window than a point 15 | on the surface. The lander would then detach and descend to the surface, 16 | needing only to guide itself for a relatively short time. After 17 | completion of the lunar exploration, a part of the lander would return 18 | to the spacecraft still in orbit and transfer crew and surface samples, 19 | after which the command module (CM) would leave for earth. 20 | 21 | With a lunar orbit rendezvous mission, more than one computer would be 22 | required, since both the CM and the lunar excursion module (LEM) needed 23 | on-board computers for the guidance and navigation function. The CM's 24 | computer would handle the translunar and transearth navigation and the 25 | LEM's would provide for autonomous landing, ascent, and rendezvous 26 | guidance. 27 | 28 | NASA referred to this system with its two computers, identical in design 29 | but with different software, as the Primary Guidance, 30 | \pagebreakon{31} Navigation, and Control System (PGNCS, pronounced "pings"). 31 | The LEM had an additional computer as part of the Abort Guidance System 32 | (AGS), according to the NASA requirement that a first failure should not 33 | jeopardize the crew. Ground systems backed up the CM computer and its 34 | associated guidance system so that if the CM system failed, the 35 | spacecraft could be guided manually based on data transmitted from the 36 | ground. If contact with the ground were lost, the CM system had 37 | autonomous return capability. Since the lunar landing did not allow the 38 | ground to act as an effective backup, the LEM had the AGS to provide 39 | backup ascent and rendezvous guidance. If the PGNCS failed during 40 | descent, the AGS would abort to lunar orbit and assist in rendezvous 41 | with the CM. It would not be capable of providing landing assistance 42 | except to monitor the performance of the PGNCS. Therefore the computer 43 | systems on the Apollo spacecraft consisted of three processors, two as 44 | part of the PGNCS and one as part of the AGS. 45 | -------------------------------------------------------------------------------- /history.nasa.gov/foreword.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight:The NASA Experience
[vii] The Editors have taken the unusual step of devoting an entire Supplement volume of the Encyclopedia to a single topic: "Computers in Spaceflight: the NASA Experience." The reason will hopefully become apparent upon reading this volume. NASA's use of computer technology has encompassed a long period starting in 1958. During this period, hardware and software developments in the computer field were progressing through successive generations. A review of spaceflight applications of these developments offers a panoramic insight into almost two decades of change in the computer industry and into NASA's role.
NASA's role is summarized at the conclusion of this volume:
- "NASA never asked for anything that could not be done with the current technology. But in response, the computer industry sometimes pushed itself just a little in a number of areas. Just a little better software development practices made onboard software safe, just a little better networking made the Launch Processing System more efficient, just a little better operating system made mission control easier, just a little better chip makes image processing faster. NASA did not push the state of the art, but nudged it enough times to make a difference."
This report could not be compressed to typical article size without destroying its usefulness and interest. We trust that the readers will find this work to be as fascinating as did the editors.
- Allen Kent
- James G. Williams
-------------------------------------------------------------------------------- /history.nasa.gov/Compspace.html: -------------------------------------------------------------------------------- 1 | 2 | 3 |
11 |
NASA History Office
18 |
19 |
20 |
21 |
22 |
-
39 |
James E. Tomayko 40 | 41 |Wichita State University 42 | 43 | 44 |Wichita, Kansas 45 | 46 |- 47 | 48 |
-
49 |
50 |
- CONTRACT NASW-3714 51 | 52 |
- March 1988 53 |
- CONTRACT NASW-3714 51 | 52 |
56 | 57 | 59 | 60 |
61 |
62 |
73 | 74 |
Updated: July 15, 2005.
75 | 76 | 77 | 78 |Steve Garber, NASA History Web 79 | Curator
80 | 81 |For further information 82 | E-mail: histinfo@hq.nasa.gov 84 |
85 | 86 |-
87 |
- HTML work: Chris 88 | Gamble. 89 |
92 | 93 | 94 | -------------------------------------------------------------------------------- /src/Appendix-IV.md: -------------------------------------------------------------------------------- 1 | \newpageon{404} 2 | 3 | # Appendix IV: Mariner Mars 1969 Flight Program {-} 4 | 5 | \verbatimfont{\tiny\ttfamily} 6 | 7 | ~~~ {caption="Figure IV-1"} 8 | LOC OPC A/TIME B/EVENT SYMB OPC A/TIME B/EVENT 9 | 10 | *COM EXECUTIVE ROUTINE ( 7 WORDS) 11 | *COM 12 | 0 CLJ 35 102 EXC0 CLJ 36 REQM ABORT+EXTRA FE+NAA TESTS, SLEWS 13 | 1 DSJ 126 104 EXC1 DSJ OV ROJ1 OV,M/C,OPT FE TEST,TV PIC CTR 14 | 2 DHJ 125 31 EXC2 DHJ LCH1 CR01 CRUISE AND POST ENCOUNTER EVENTS 15 | 3 DHJ 11 8 EXC3 DHJ CY04 CY01 Y1 CYCLIC GENERATOR 16 | 4 CLJ 256 12 EXC4 CLJ 256 RT01 READOUT TEXT,NF NON SLEW EVENTS 17 | 5 CLJ 2 18 EXC5 CLJ 2 RDIN TEST FOR EVENT ADDRESS READIN 18 | 6 HLT 368 489 EXC6 HLT 368 489 END OF SCAN 19 | *COM 20 | *COM END OF CRUISE CHAIN 21 | *COM 22 | 7 ROJ 2 3 ENDC ROJ EXC2 EXC3 END CRUISE SEQUENCE 23 | *COM 24 | *COM CYCLIC SUBROUTINE FOR Y1 EVENTS 25 | *COM 26 | 8 TAB 10 11 CY01 TAB CY03 CY04 ENTRY----RELOAD CYCLIC TIME 27 | 9 UNJ 0 4 CY02 UNJ 0 FXC4 RETURN TO EXECUTIVE PROGRAM 28 | 10 DATA **** 288 CY03 DATA FILL 0024 CYCLIC TIME STORAGE 29 | 11 DATA **** 288 CY04 DATA FILL 0024 COUNTING LOCATION FOR Q1 ENENLK 30 | *COM 31 | *COM ENABLE FAR ENCOUNTER*ENTRY PT. IS CYEO ( 11 WORDS) 32 | *COM 33 | 20 ADD 48 112 OFE0 ADD OFE4 CZ11 ADD 5HRS TO TIME OF N1(2) 34 | 21 ADD 27 109 OFE1 ADD OFE3 CZ14 ADD F3 EVENT TO CZ14 EVENT TIME 35 | 22 TAB 29 79 TAB OFE5 CGC6 MOD CYCLE GEN FOR OPT FE(CTR) 36 | 23 TAB 30 84 TAB OFE6 CGD4 MOD CYCLE GEN FOR OPT FE(EVENT) 37 | 24 CLJ 16 20 CYE0 CLJ 16 OFE0 TEST FOR OPTIONAL FE(DC-32) 38 | 25 DAJ 71 26 CYE2 DAJ CTR4 CYE3 UPDATE CYCLE GENERATOR (EVENT) 39 | 26 DAJ 69 68 CYE3 DAJ CTR2 CTR1 UPDATE CYCLE GENERATOR (COUNTER) 40 | 27 DATA 0 8 OFE3 DATA 0 0200 STORAGE FOR F3 EVENT (OPTION) 41 | 28 DATA 5 0 OFE4 DATA 5 0000 TIME STORAGE FOR OPTIONAL FE SHFT 42 | 29 CTJ **** 43 OFE5 CTJ FILL ROJ0 COUNT FOR OPTIONAL FE PICTURES 43 | 30 DATA **** 451 OFE6 DATA FILL 3007 DATA FOR OPTIONAL FE PICTURES 44 | *COM 45 | ~~~ 46 | 47 | 50 | 51 | This segment of a Mariner programmable sequencer flight program is given 52 | as an example of the sort of flexibility gained by adding a memory to 53 | the system. The first segment, the Executive, is only seven lines, yet 54 | it essentially controlled the software. The remaining code demonstrates 55 | a typical subroutine. The entire length of this program was 128 lines. 56 | -------------------------------------------------------------------------------- /history.nasa.gov/Ch4-9.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Four - - Computers in the Space Shuttle Avionics System - Conclusion -
- [133] The DPS on the Shuttle orbiter reflects the state of software engineering in the 1970s. Even though the software was admittedly the key component of the spacecraft, NASA chose the hardware before the first software requirement was written. This is typical of practice in 1972, but less so now. NASA managers knew that time and money spent on detailed software requirements specification and the corresponding development of a test and verification program would save millions of dollars and much effort later. The establishment of a dedicated facility for development was an innovative idea and helped keep costs down by centralization and standardization. A combination of complete requirements, an aggressive test plan, a decent development facility, and the experience of NASA, Rockwell, Draper, and IBM engineers in real-time systems was enough to create a successful Shuttle DPS.
- Even as the system took shape, NASA managers looked to the future of manned spacecraft software. Increased automation of code and test case generation, automated change insertion and verification, and perhaps automated requirements development are all considered future necessities if development costs are to be kept down and reliability increased. In the 1980s, a new opportunity for software development and hardware selection presents itself with NASA's long-awaited Space Station. NASA has another chance to adopt updated software engineering techniques and, perhaps, to develop others. Success in space is increasingly tied to success in the software factory.
- [133] The DPS on the Shuttle orbiter reflects the state of software engineering in the 1970s. Even though the software was admittedly the key component of the spacecraft, NASA chose the hardware before the first software requirement was written. This is typical of practice in 1972, but less so now. NASA managers knew that time and money spent on detailed software requirements specification and the corresponding development of a test and verification program would save millions of dollars and much effort later. The establishment of a dedicated facility for development was an innovative idea and helped keep costs down by centralization and standardization. A combination of complete requirements, an aggressive test plan, a decent development facility, and the experience of NASA, Rockwell, Draper, and IBM engineers in real-time systems was enough to create a successful Shuttle DPS.
Computers in Spaceflight: The NASA Experience
Part II : Computers On Board Unmanned Spacecraft
- Chapter Five - - From Sequencers to Computers: Exploring the Moon and the Inner Planets -
- From sequencers to computers: Exploring the Moon and the inner planets.
- Fixed sequencers: "Computers" on Ranger, Surveyor and the early Mariners.
- Programmable sequencers: Mariners to Mars, Venus and Mercury.
- Expanded memory and expanded functions.
- The Star computer.
- Viking computer systems.
- On to the outer planets.
-
- Chapter Six - - Distributed Computing On Board Voyager and Galileo -
- Distributed computing on board Voyager and Galileo.
- Voyager - The flying computer center.
- Galileo - True distributed computing in space.
- Future unmanned spacecraft computers.
-------------------------------------------------------------------------------- /history.nasa.gov/Ch3-6.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Three - - The Skylab Computer System - Conclusions - [82] The Skylab program demonstrated that careful management of software development, including strict control of changes, extensive and preplanned verification, and the use of adequate development tools, results in quality software with high reliability. Attention to piece part quality in hardware development and the use of redundancy resulted in reliable computers. However, it must be stressed that part of the success of the software management and the hardware development was due to the small size of both. Few programmers were involved in initial program design and writing. This meant that communications between programmers and teams were relatively minimal. The fact that IBM produced just 10 computers and really needed to ensure the success of just 2 of those helped in focusing the quality assurance effort expended on the hardware.
- [83] What happened after the manned Skylab program demonstrated the need for foresight and proper attention to storage of mission-critical materials until any possibility of their use had gone away. The dispersal of the verification hardware is understandable, as it is expensive to maintain. However, some provision should have been made for retaining mission-unique capabilities such as actual flight hardware. The destruction of the flight tapes and source code for the software by unknown parties was inexcusable. A single high-density disk pack could have held all relevant material.
- Skylab marked the beginning of redundant computer hardware on manned spacecraft. It was also the first project that developed software with awareness of proper engineering principles. The Shuttle continued both these concepts but on a much larger and more complex scale.
- [82] The Skylab program demonstrated that careful management of software development, including strict control of changes, extensive and preplanned verification, and the use of adequate development tools, results in quality software with high reliability. Attention to piece part quality in hardware development and the use of redundancy resulted in reliable computers. However, it must be stressed that part of the success of the software management and the hardware development was due to the small size of both. Few programmers were involved in initial program design and writing. This meant that communications between programmers and teams were relatively minimal. The fact that IBM produced just 10 computers and really needed to ensure the success of just 2 of those helped in focusing the quality assurance effort expended on the hardware.
-------------------------------------------------------------------------------- /history.nasa.gov/Ch9-1.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Nine - Making New Reality: Computers in Simulations and Image Processing - [270] The computers
discussed so far actually flew in space or worked in direct
support of launches and missions. Yet NASA found numerous uses for
computers in areas somewhat removed from flight operations. Chief
among these are simulations and image processing, which made the
training of crews, development of launchers and spacecraft, and
analysis of image data possible.
- Simulations are used in hundreds of ways in the space program. Simulation programs and hardware test the workings of vehicles and spacecraft, determine the accuracy of flight paths, train controllers, check out designs, and actively contribute to the software development process. Simulations help NASA find out whether its programs and projects will work as planned, lessening the risks for crews and equipment. Especially important are simulations used in crew training and simulations used to test hardware. Both provide models by which to judge the extent and efficacy of NASA's dependence on simulations and to demonstrate the dependency of such simulations on computers.
- Image processing was developed to make the analysis of digital images transmitted by unmanned deep space craft more consistent and fruitful. At first largely driven by the needs of the Jet Propulsion Laboratory's (JPL) scientific community, imaging spread quickly with applications such as Landsat and the Shuttle's imaging radar. From spectacular images of distant worlds to detailed pictures of the neighbor's farm, imaging technology has contributed to the quality of life on earth. Without the use of high-speed computers, the analysis and use of the billions of bits of imaging data would be impossible.
Computers in Spaceflight: The NASA Experience
Part III : Ground Based Computers for Space Flight Operations
- Chapter Seven - - The Evolution of Automated Launch Processing - -
- The evolution of automated launch processing.
- Launch processing in the Saturn era.
- The shuttle launch processing system.
-
- Chapter Eight - - Computers in Mission Control -
-
- Chapter Nine - - Making New Reality: Computers in Simulations and Image Processing -
- Making new reality: Computers in simulations and image processing.
- Crew-training simulators.
- Image processing.
-------------------------------------------------------------------------------- /history.nasa.gov/Ch6-4.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Six - - Distributed Computing On Board Voyager and Galileo - Future unmanned spacecraft computers - [203] Distribution of computers aboard spacecraft has now been done several times. Both Voyager spacecraft inherited command computers from the Viking project. Computers for specific functions such as attitude control and data formatting were added in response to increased requirements. The result was a functionally distributed system of processors. Galileo's project managers also adopted the concept of functional distribution, assigning microprocessors to control attitude and, in the lower-level modules of the Command and Data Subsystem, to connect to engineering and other instruments, including the scientific experiments. Additional innovations on the Galileo spacecraft centered on the development of virtual machine software, which distributes functions over several processors.
- Advancing microprocessor technology makes the continuation of the concept of single function computers more attractive. At JPL, plans are currently under way for the Mariner Mark II, which will be the deep space version of the Multimission Modular Spacecraft developed by Goddard Space Flight Center for earth orbital operations. Using the same concepts of a standard bus and modular equipment, JPL hopes to reduce mission costs to $400 million each, about half the price of Galileo147. The staff is exploring the use of the C programming language, a very powerful tool, for the new spacecraft. Future missions seem certain to use multicomputers, with internal networks similar to Galileo's. In the 15 years since the first primitive programmable sequencers flew with 128 word memories, JPL spacecraft have grown to carry 2,500 times more memory. Progressing from simple counting to complex coordinate transformations in such a short time is remarkable, and the application of computer power to each spacecraft function will make for ever more remarkable gains.
Computers in Spaceflight: The NASA Experience
-
Part III: Ground-Based Computers For Spaceflight Operations Introduction - [205] NASA's ground computer systems are characterized by large size, by the implementation of real-time programming, and by the use of may computers connected together. The need for these three attributes has caused NASA and its contractors to devise new techniques for computer applications, such as operating systems for mainframe computers capable of handling real-time processing and sophisticated networking. Through these developments NASA has had its largest impact on computing in the commercial world.
- Differences between ground-based computers and on-board computers center on the relative ease of hardware procurement with the continued difficulty of software development. On-board computers evolved from custom-made systems to the largely off-the-shelf Skylab and Shuttle computers. Ground computers followed a more conventional line, as they could be, from the beginning, commercially available systems, though applied to noncommercial tasks. NASA examined many existing computer systems each time it needed a machine. In fact, the government's bidding process gave NASA a larger mix of different vendors' equipment than most commercial enterprises, causing occasional difficulties in connecting computers together. This problem and that of adapting business machines to real-time processing were largely solved by software. Contractors received invaluable experience in large systems development and networking in the process of achieving NASA's goals.
- Ground-based computer systems are used for preflight checkout and the launching of space vehicles, controlling both unmanned and manned missions, creating simulations of rocket flight for vehicle development and of space flight for crew training, processing telemetry data from launch vehicles and space probes, and in basic research. In the following chapters these functions are grouped into launch processing, mission control, and support tasks. Chapter 7 develops the concept of launch processing from the manual era to the fully automated Shuttle flight preparation. The chief result from this effort was a large integrated network of computers that proved to be highly innovative. Chapter 8 presents computer systems in both the manned Mission Control Center in Houston and the unmanned control [206] centers at the Jet Propulsion Laboratory (JPL) and Goddard Space Flight Center. In Chapter 9, the uses of computers in simulations and data reduction are discussed.
-------------------------------------------------------------------------------- /src/Ch5-1.md: -------------------------------------------------------------------------------- 1 | \pagebreakon{140} 2 | 3 | One organization more than any other has dominated the 4 | exploration of deep space: the Jet Propulsion Laboratory (JPL) of the 5 | California Institute of Technology. JPL was responsible for the Ranger 6 | and Surveyor series of lunar exploration spacecraft, the Mariner and 7 | Viking Orbiter explorers of Mercury, Venus, and Mars, and the Voyager 8 | and Galileo probes of the outer planets. As a result, the evolution of 9 | on-board computers for deep space operations took place at JPL. 10 | 11 | JPL's chief contribution to computing on unmanned spacecraft was in 12 | leading progress from hard-wired sequencers to programmable sequencers 13 | to digital computers. The Pioneer spacecraft developed mostly at NASA's 14 | Ames Research Center and the Lunar Orbiters used to map the moon in the 15 | 1960s did not carry on-board computers. Like their earth-orbiting 16 | cousins and the first JPL probes, they used sequencing devices to 17 | activate and command experiments. Later the Mariner spacecraft acquired 18 | more autonomy and flexibility by using machines that stored command 19 | sequences in changeable software. Finally, sophisticated spacecraft flew 20 | with special-purpose digital computers. 21 | 22 | Unique in its relationship to NASA, JPL is *not* solely a government 23 | installation in the same way as, for example, the Johnson or Marshall 24 | Space Flight Centers. JPL's personnel receive their pay-checks from Cal 25 | Tech, yet almost every piece of equipment on the site has a NASA 26 | property tag, since, for over a quarter of a century, Cal Tech has 27 | administered contracts that have paid for all research and development 28 | of the many spacecraft originated at JPL. 29 | 30 | Another way in which JPL is unique is its products. Whereas thousands of 31 | earth-orbiting satellites have been launched, less than a dozen each of 32 | Rangers, Surveyors, and Mariners were constructed, and just two Vikings 33 | and Voyagers and one Galileo were sent into space. Not only were few 34 | spacecraft built, but the interplanetary launches were separated by 35 | years and had to be on strict deadlines due to the realities of 36 | celestial mechanics. This created a completely different development 37 | environment than that at other NASA centers. The emphasis on basic 38 | research at JPL has perhaps been stronger than at any other NASA 39 | installation. This orientation and its application in spacecraft forms a 40 | special part of the story of JPL. 41 | 42 | JPL's computer development activities were shaped by its organizational 43 | structures. When a project is started at the Laboratory, an office is 44 | established to house the project manager, key systems managers, and 45 | staff. Offices have come and gone with the projects themselves. The 46 | Ranger office, for example, has been closed for nearly 20 years, whereas 47 | the Voyager office is likely to be open for as long as that. Most 48 | personnel are housed in divisions and sections relating to specific 49 | discipline or system functions, as, in 1984, the "Technical Divisions" 50 | contained sections on "Guidance and Control" and "Spacecraft Data 51 | Systems." When a project office needs a component or service, it 52 | "subcontracts" it to the appropriate technical \pagebreakon{141} sections. For 53 | instance, Spacecraft Data Systems supplies on-board computers, whereas 54 | the Navigation Systems Section does the trajectory calculations needed 55 | for a specific mission. In this way, specialists can be kept busy on a 56 | series of projects over a period of years without depending on a 57 | specific project for their jobs. Competition between sections to develop 58 | related components can also exist, as on the Voyager project, when the 59 | attitude control staff wanted to make their own computer for their 60 | system while the data systems people claimed sole domain over computer 61 | development. Within this setting, JPL has produced high quality on-board 62 | computers that have demonstrated outstanding reliability[^5-1a]. 63 | 64 | [^5-1a]: JPL's roots and its role in NASA receive excellent treatment in 65 | Clayton Koppes' *The Jet Propulsion Lab and the American Space Program*, 66 | Yale University Press, 1982. 67 | -------------------------------------------------------------------------------- /history.nasa.gov/Ch2-9.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Two - - Computers On Board The Apollo Spacecraft -
-
- [62] What did NASA learn from its experiences with the Apollo computer system? At the management level, NASA learned to assign experienced personnel to a project early, rather than using the start of a project for training inexperienced personnel; many NASA managers of software and hardware were learning on the job while in key positions. Also, more participation by management in the early phases of software design is necessary so that costs can be more effectively estimated and controlled.
- From the standpoint of development, NASA learned that a more thorough, early effort at total systems engineering must be made so that specifications can be adequately set. NASA contractors in the Apollo program faced changing specifications long after final requirements should have been fixed. This was expensive and caused such problems as Raytheon's retooling, memory shortages, and design insufficiencies.
- The realization that software is more difficult to develop than hardware is one of the most important lessons of the Apollo program. So the choice of memory should be software driven, and designers should develop software needed for manned spaceflight near the Manned Spacecraft Center. The arrangement with MIT reduced overall quality and efficiency due to lack of communication. Also, more modularization of the software was needed 180.
- The AGC system served well on the earth-orbital missions, the six lunar landing missions, the three Skylab missions, and the Apollo-Soyuz test project. Even though plans existed to expand the computer to 16K of erasable memory and 65K of fixed memory, including making direct memory addressing possible for the erasable portion, no expansion occurred181. The Apollo computer did fly on missions other than Apollo. An F-8 research aircraft used a lunar module computer as part of a "fly-by-wire" system, in which control [63] surfaces moved by servos at the direction of electronic signals instead of traditional cables and hydraulics. In that way, the Apollo system made a direct research contribution to the Shuttle, which is completely a fly-by-wire craft. The most important legacy of the AGC, however, was in the way NASA applied the lessons it was beginning to learn in developing ground software to the management of flight software.
Computers in Spaceflight: The NASA Experience
- Chapter Two - - Computers On Board The Apollo Spacecraft - The Apollo computer systems - [30] The mission profile used in sending a man to the moon went through several iterations in the early 1960s. For a number of reasons, planners rejected the direct flight method of launching from the earth, flying straight to the moon, and landing directly on the surface. Besides the need for an extremely large booster, it would require flawless guidance to land in the selected spot on a moving target a quarter of a million miles away. A spacecraft with a separate lander would segment the guidance problem into manageable portions. First, the entire translunar spacecraft would be placed in earth orbit for a revolution or two to properly prepare to enter an intercept orbit with the moon. Upon arriving near the moon, the spacecraft would enter a lunar orbit. It was easier to target a lunar orbit window than a point on the surface. The lander would then detach and descend to the surface, needing only to guide itself for a relatively short time. Alter completion of the lunar exploration, a part of the lander would return to the spacecraft still in orbit and transfer crew and surface samples, after which the command module (CM) would leave for earth.
- With a lunar orbit rendezvous mission, more than one computer would be required, since both the CM and the lunar excursion module (LEM) needed on-board computers for the guidance and navigation function. The CM's computer would handle the translunar and transearth navigation and the LEM's would provide for autonomous landing, ascent, and rendezvous guidance.
- NASA referred to this system with its two computers, identical in design but with different software, as the Primary Guidance, [31] Navigation, and Control System (PGNCS pronounced "pings"). The LEM had an additional computer as part of the Abort Guidance System (AGS), according to the NASA requirement that a first failure should not jeopardize the crew. Ground systems backed up the CM computer and its associated guidance system so that if the CM system failed, the spacecraft could be guided manually based on data transmitted from the ground. If contact with the ground were lost, the CM system had autonomous return capability. Since the lunar landing did not allow the ground to act as an effective backup, the LEM had the AGS to provide backup ascent and rendezvous guidance. If the PGNCS failed during descent, the AGS would abort to lunar orbit and assist in rendezvous with the CM. It would not be capable of providing landing assistance except to monitor the performance of the PGNCS. Therefore the computer systems on the Apollo spacecraft consisted of three processors, two as part of the PGNCS and one as part of the AGS.
-------------------------------------------------------------------------------- /src/Ch2-1.md: -------------------------------------------------------------------------------- 1 | \pagebreakon{28} 2 | 3 | ### The need for an on-board computer 4 | 5 | The Apollo lunar landing program presented a tremendous 6 | managerial and technical challenge to NASA. Navigating from the earth to 7 | the moon and the need for a certain amount of spacecraft autonomy 8 | dictated the use of a computer to assist in solving the navigation, 9 | guidance, and flight control problems inherent in such missions. Before 10 | President John F. Kennedy publicly committed the United States to a 11 | "national goal" of landing a man on the moon, it was necessary to 12 | determine the feasibility of guiding a spacecraft to a landing from a 13 | quarter of a million miles away. The availability of a capable computer 14 | was a key factor in making that determination. 15 | 16 | The Instrumentation Laboratory of the Massachusetts Institute of 17 | Technology (MIT) had been working on small computers for aerospace use 18 | since the late 1950s. Dr. Raymond Alonso designed such a device in 19 | 1958--1959^[1](#source2)^. Soon after, Eldon Hall designed a 20 | computer for an unmanned mission to photograph Mars and 21 | return^[2](#source2)^. That computer could be interfaced with 22 | both inertial and optical sensors. In addition, MIT was gaining 23 | practical experience as the prime contractor for the guidance system of 24 | the Polaris missile. In early 1961, Robert G. Chilton at NASA--Langley 25 | Space Center and Milton Trageser at MIT set the basic configuration for 26 | the Apollo guidance system^[3](#source2)^. An on-board digital 27 | computer was part of the design. The existence of these preliminary 28 | studies and the confidence of C. Stark Draper, then director of the 29 | Instrumentation Lab that now bears his name, contributed to NASA's 30 | belief that the lunar landing program was possible from the guidance 31 | standpoint. 32 | 33 | The presence of a computer in the Apollo spacecraft was justified for 34 | several reasons. Three were given early in the program: *(a)* to avoid 35 | hostile jamming, *(b)* to prepare for later long-duration (planetary) 36 | manned missions, and *(c)* to prevent saturation of ground stations in the 37 | event of multiple missions in space 38 | simultaneously^[4](#source2)^. Yet none of these became a 39 | primary justification. Rather, it was the reality of physics expressed 40 | in the 1.5-second time delay in a signal path from the earth to the moon 41 | and back that provided the motivation for a computer in the lunar 42 | landing vehicle. With the dangerous landing conditions that were 43 | expected, which would require quick decision making and feedback, NASA 44 | wanted less reliance on ground-based computing^[5](#source2)^. 45 | The choice, later in the program, of the lunar orbit rendezvous method 46 | over direct flight to the moon, further justified an on-board computer 47 | since the lunar orbit insertion would take place on the far side of the 48 | moon, out of contact with the earth^[6](#source2)^. These 49 | considerations and the consensus among MIT people that autonomy was 50 | desirable ensured the place of a computer in the Apollo vehicle. 51 | 52 | Despite the apparent desire for autonomy expressed early in the 53 | \pagebreakon{29} program, as the mission profile was refined and the realities 54 | of building the actual spacecraft and planning for its use became more 55 | immediate, the role of the computer changed. The ground computers became 56 | the prime determiners of the vehicle's position in three-dimensional 57 | space "at all times" (except during maneuvers) in the 58 | missions^[7](#source2)^. Planners even decided to calculate the 59 | lunar orbit insertion burn on the ground and then transmit the solution 60 | to the spacecraft computer, which somewhat negated one of the reasons 61 | for having it. Ultimately, the actual Apollo spacecraft was only 62 | autonomous in the sense it could return safely to earth without help 63 | from the ground^[8](#source2)^. 64 | 65 | Even with its autonomous role reduced, the Apollo on-board computer 66 | system was integrated so fully into the spacecraft that designers called 67 | it "the fourth crew member"^[9](#source2)^. Not only did it have 68 | navigation functions, but also system management functions governing the 69 | guidance and navigation components. It served as the primary source of 70 | timing signals for 20 spacecraft systems^[10](#source2)^. The 71 | Apollo computer system did not have as long a list of responsibilities 72 | as later spacecraft computers, but it still handled a large number of 73 | tasks and was the object of constant attention from the crew. 74 | -------------------------------------------------------------------------------- /src/Ch3-5.md: -------------------------------------------------------------------------------- 1 | ### The Reactivation Mission 2 | 3 | The Skylab Reactivation Mission represents one of the most 4 | interesting examples of the autonomy and reliability of manned 5 | spacecraft computers. The original Skylab mission lasted 272 days with 6 | long unmanned periods. The reactivation mission, flown entirely under 7 | computer control, lasted 393 days. Therefore, the bulk of the activated 8 | life of the space laboratory fully depended on the ATMDCs. 9 | 10 | When it was obvious that the Workshop was going to fall to the earth 11 | long before a rescue mission could be launched, NASA began studying 12 | methods of prolonging the orbital life of the spacecraft. Even though 13 | the atmosphere is very thin at the altitude Skylab was flying, the drag 14 | produced on the spacecraft was highly related to its attitude with 15 | respect to its direction of flight (velocity vector). During most of the 16 | manned mission periods Skylab flew in solar inertial (SI) mode, in which 17 | the lab was kept perpendicular to the sun to provide maximum exposure 18 | for the solar collectors. Momentum desaturation maneuvers were done on 19 | the dark side of the earth to compensate for bias momentum buildup 20 | resulting from noncyclic torques acting on the spacecraft. The SI mode 21 | was high drag, so engineers devised two new modes, 22 | end-on-velocity-vector (EOVV) and torque equilibrium attitude (TEA). 23 | EOVV pointed the narrow end of the lab in the direction of flight, 24 | minimizing the aerodynamic drag on the vehicle. TEA could control the 25 | re-entry, using the gravity gradient and gyroscopic torques to 26 | counterbalance the aerodynamic torque. Only in this way could the 27 | Workshop be controlled below 140 nautical miles 28 | altitude^[66](#source3)^. 29 | 30 | Use of the new modes required that they be coded and transmitted to the 31 | computers in orbit. First it was necessary to discover whether or not 32 | the computers still functioned. Since the ATMDC used destructive readout 33 | core memories, there was some concern that the software might have been 34 | destroyed during restart tests if the refreshment hardware had failed. 35 | On March 6, 1978, NASA engineers at the Bermuda tracking station ordered 36 | portions of Skylab to activate. On March 11, the ATMDC powered up for 5 37 | minutes to obtain telemetry confirmation that it was still functioning. 38 | The software resumed the program cycle where it had left off 4 years and 39 | 30 days earlier. As far as the computer was concerned, it had suffered a 40 | temporary power transient^[67](#source3)^! 41 | 42 | When IBM began to make preparations to modify the software, it 43 | discovered that there was almost nothing with which to work. The 44 | \pagebreakon{82} carefully constructed tools used in the original software 45 | effort were dispersed beyond recall, and, worse yet, the last of the 46 | source code for the flight programs had been deleted just weeks 47 | beforehand. This meant that changes to the software would have to be 48 | *hand coded* in hexadecimal, as the assembler could not be used---a risky 49 | venture in terms of ensuring accuracy. Eventually it became necessary to 50 | repunch the 2,516 cards of a listing of the most recent flight program, 51 | and IBM hired a subcontractor for the purpose^[68](#source3)^. 52 | 53 | Engineers could not test this software with the same high fidelity as 54 | during the original development. They abandoned plans for real time 55 | simulations because they could not find enough parts of any of the 56 | original simulators. Interpretive simulation could be performed because 57 | the tapes for that form of testing had been saved. However, the 58 | interpretive simulator ran 20 times slower than real time, so less 59 | testing was possible^[69](#source3)^. 60 | 61 | IBM approached the modification using the same principles as in the 62 | original production. The baseline software for the reactivation was 63 | Flight Program 80, including change request 3091, which was already in 64 | the second computer. Software changes for reactivation were simply 65 | handled as routine change requests. They placed the EOVV software in 66 | memory previously occupied by experiment calibration and other functions 67 | useless in the new mission. TEA replaced the command and display 68 | software^[70](#source3)^. 69 | 70 | When the software was ready for flight, NASA uplinked it to a reserve 71 | area of memory and then downlinked and manually verified it. If it 72 | passed the verification, engineers gave a command to activate it. The 73 | reprogramming was generally successful. The four people assigned to the 74 | software revision maintained IBM's record of quality throughout the 75 | reactivation mission^[71](#source3)^. 76 | -------------------------------------------------------------------------------- /history.nasa.gov/Ch2-2.html: -------------------------------------------------------------------------------- 1 |
Computers in Spaceflight: The NASA Experience
- Chapter Two - - Computers On Board The Apollo Spacecraft - MIT chosen as hardware and software contractor - [29] On August
9,1961, NASA contracted with the MIT Instrumentation Lab for the
design, development, and construction of the Apollo guidance and
navigation system, including software. The project manager for
this effort was Milton Trageser, and David Hoag was the technical
director11. MIT personnel generally agree that they were
chosen because their work on Polaris proved that they could handle
time, weight, and performance restrictions and because of their
previous work in space navigation12. In fact, the Polaris team was moved almost intact
to Apollo13. Despite their experience with aerospace computers,
the Apollo project turned out to be a genuine challenge for them.
As there were no fixed specifications when the contract was
signed, not until late 1962 did MIT have a good idea of Apollo's
requirements14. One of the MIT people later recalled that
- If the designers had known then [1961] what they learned later, or had a complete set of specifications been available...they would probably have concluded that there was no solution with the technology of the early 1960s15.
-
- Fortunately, the technology improved, and the concepts of computer Science applied to the problem also advanced as MIT developed the system.
- [30] NASA's relationship with MIT also proved to be educational. The Apollo computer system was one of NASA's first real-time, large scale software application contracts16. Managing such a project was completely outside the NASA experience. A short time after making the Apollo guidance contract, NASA became involved in developing the on-board software for Gemini (a much smaller and more controllable enterprise) and the software for the Integrated Mission Control Center. Different teams that started within the Space Task Group, later as part of the Manned Spacecraft Center in Houston, managed these projects with little interaction until the mid-1960s, when the two Gemini systems approached successful completion and serious problems remained with the Apollo software. Designers borrowed some concepts to assist the Apollo project. In general, NASA personnel involved with developing the Apollo software were in the same virgin territory as were MIT designers. They were to learn together the principles of software engineering as applied to real-time problems.
- Fortunately, the technology improved, and the concepts of computer Science applied to the problem also advanced as MIT developed the system.
-------------------------------------------------------------------------------- /src/Ch5-4.md: -------------------------------------------------------------------------------- 1 | ### Expanded memory and expanded functions 2 | 3 | The new sequencer had a 9-bit address field, providing a 512 4 | address limit. Expanding the memory to 512 words did not require a 5 | change in the logic. So JPL added the extra memory for the Mariner 6 | \pagebreakon{147} Mars 1971 orbiter missions. Still, the old fixed sequencer 7 | remained in charge of the Mars orbit insertion burn. After the 8 | spacecraft established orbits, however, the ground control center used 9 | the new sequencer to control the imaging of Mars and its moons. The 10 | expanded memory proved sufficient. Preflight estimates for Mariner VIII 11 | specified 150 words of memory and 225 words for Mariner IX, yet both 12 | grew to over 400 words in flight^[30](#source5)^. 13 | 14 | The mission that used the sequencer to its limits was Mariner Venus 15 | Mercury 1973, or Mariner X. Mission profile called for the spacecraft to 16 | turn its imaging equipment on the earth as it flew toward deep space, do 17 | some studies of the moon in flyby, and then research in the area of 18 | Venus during a gravity assist maneuver that would send it toward 19 | Mercury, where JPL planned three separate encounters with the innermost 20 | planet. 21 | 22 |  24 | 25 | \pagebreakon{148} Due to the more complex mission requirements, the design 26 | team wanted a bigger and better sequencer, but cost constraints killed 27 | any chance of building a new machine^[31](#source5)^. Adrian 28 | Hooke of JPL, one of the project's managers, decided to use planned 29 | memory updates at regular intervals. He also instituted a "suspenders 30 | and belt" approach to reliability. The sequencer would not only carry a 31 | detailed program for the next mission phase but also a constantly 32 | updated bare minimum program to complete the mission if the spacecraft 33 | lost contact with the ground. If a command was not received for a 34 | certain time, then the sequencer would follow whatever commands were in 35 | the backup program. Thus, software moved ahead in leap frog fashion. 36 | During the earth-moon phase the Venus backup was loaded, during the 37 | Venus encounter the backup Mercury encounter sequence was on board, and 38 | so on^[32](#source5)^. Software development was assigned to 39 | three programmers. Ronald Spriestersbach of JPL wrote the near-earth and 40 | post-Mercury sequences, George Elliot of the Boeing Company did the 41 | Venus encounter, and Larry Koga of JPL wrote all three Mercury 42 | encounters^[33](#source5)^. 43 | 44 | During the 1969 missions, most changes and subroutines were hand-coded 45 | and used once. By 1971, the COMGEN ground computer program that produced 46 | memory loads for the Sequencer could develop blocks of commands that 47 | functioned much like subroutines in a standard computer program or 48 | macros in an assembly language program^[34](#source5)^. In 49 | 1973, COMGEN resided in an IBM 360/75 computer that generated the 50 | commands and sent them via the NASA communications net to the 51 | appropriate Deep Space Network station for transmission. By this time, 52 | each station had a command computer, thus ending the voice/manual 53 | era^[35](#source5)^. Another improvement to the Sequencer was 54 | that engineers could do memory checks by comparing a sumword stored in 55 | location 512 to the result of summing the first 511 locations. If a 56 | miscompare occurred, *then* a location-by-location check for error could 57 | be made^[36](#source5)^. 58 | 59 | The improvements both in the Sequencer and in programming and ground 60 | control techniques were not enough to ensure its use beyond the Mariner 61 | series of spacecraft. In spite of the success of the long and 62 | complicated mission of Mariner X, JPL's Hooke complained that memory 63 | limits were too costly due to excessive need for optimization and 64 | constant relocation of subroutines^[37](#source5)^. Besides, the 65 | sequencers, regardless of their full name, were *not* computers. 66 | Spacecraft needed to do on-board computations, to have more room for 67 | software (and, thus, increased flexibility), and to use the central 68 | computer for other functions such as spacecraft health and safety 69 | monitoring done on other manned and unmanned spacecraft. Some missions 70 | intrinsically needed computers, as, for example, the Viking Mars 71 | orbiters and landers and the Voyager outer planet probes. The computer 72 | eventually designed, built, and used for the Viking Orbiter had its 73 | roots in the programmable sequencer, but it also owed some \pagebreakon{149} 74 | concepts, at least in comparison, to a computer built in the research 75 | side of JPL and aimed at the long-duration, complex missions of the 76 | future. The story of that computer research project adds a necessary 77 | perspective for understanding the direction JPL's on-board computer 78 | development took in the 1970s. 79 | --------------------------------------------------------------------------------