Advanced Vehicle Automation and Computers
Aboard the Shuttle
Dennis Jenkins

Events affecting the choice of computer systems for the emerging Space Shuttle can be traced back to the Apollo era. Before the first piloted Apollo flight, NASA was working on defining an orbiting laboratory ultimately known as Skylab. Even on Earth, Skylab was impressive—basically a gutted and modified Saturn S-IVB upper stage, the laboratory was a fully equipped orbiting research facility that encompassed more than 10,000 cubic feet. At one end, beyond an airlock module that would allow Apollo Command Modules to ferry crews and supplies to the laboratory, was the Apollo telescope mount—a 12-ton observatory holding instruments that allowed the crew to make detailed studies of the Sun. Not only would the Sun be a primary object of study during the Skylab missions, but it would also supply all of the laboratory’s power, a first for the U.S. crewed space program.¹

About 10 percent of this power was dedicated to a revolutionary computer system. Called the attitude and pointing control system (APCS), the system was primarily responsible for controlling the attitude of the laboratory along all three axes, which was particularly important to the Sun-observing experiments. The APCS represented the first opportunity to employ a truly dual-redundant digital computer system aboard a spacecraft. While Gemini and Apollo used complex redundant circuitry inside their single computers and were backed-up by ground-based systems at Mission Control and hand-calculated solutions from the astronauts, the APCS included two identical onboard computers. One functioned as the primary unit, the second as a backup—each machine fully capable of performing all the necessary functions. If system redundancy management software detected deviations from preselected criteria, it could automatically command the primary computer to relinquish control to the backup. Such a switchover could also be commanded by the astronauts or from the ground.²

Unlike the special computers devised for the cramped quarters aboard Gemini and Apollo, the computers for Skylab had not been custom-built. The central processing unit (CPU) of each computer was from IBM’s 4Pi series of processors, effectively a miniaturized and hardened version of the System/360 computers developed by IBM in the early 1960s. The IBM 4Pi computers were also used in several military aircraft programs, such as the Republic F-105 Thunderchief and the Boeing B-52 Stratofortress, among others. The 4Pi model chosen for Skylab was the TC-1, adapted for use on Skylab by the addition of a custom input/output assembly to communicate with the unique sensors and equipment aboard the laboratory.³

The use of tested, off-the-shelf technology proved so successful with Skylab that it became a standard NASA policy for subsequent programs. But in many respects, the choice was somewhat problematic. As had been the case with Apollo (and would occur again with the Space Shuttle), the hardware decisions were made first, long before the software specifications had been finalized. For Skylab, the hardware choice was made in October 1969, but the software specification document was not issued until the following July. In trying to meet the program specifications, IBM produced software modules that ranged from 9,000 to 20,000 words of code—but the maximum capacity of the ferrite-core memory used in the TC-1 was only 16,000 words. As a result, IBM engineers had to request numerous deviations from the specifications in order to make the software fit into the available memory without losing any critical functionality. Despite these obstacles, IBM delivered the final release of the software on 20 March 1973, two months before the scheduled launch of the laboratory.⁴

As a further guarantee of reliability, an auxiliary system called the memory load unit (MLU) was added in 1971 to provide a backup. Should the software be inadvertently erased from the core memory, the entire package could be reloaded from read-only tape stored on the MLU. In theory, this could also give Skylab the capability to reload only selected parts of memory, allowing different programs to be swapped in and out of memory as required to support various experiments or other tasks. This capability was apparently never exploited, but it served as a model for the future Space Shuttle.⁵

The success of the APCS aboard Skylab helped set the stage for a major expansion of the computer’s role in piloted space flight. Building on Skylab’s foundation of redundancy management software and dual computers, NASA had already decided that the Space Shuttle would be the most automated vehicle in history. George Mueller had made this clear early in the Phase A studies (see page 80). That the expanded use of computers would have inevitably happened with or without the experience of APCS is undeniable. However, computers were still new and largely unknown devices in the early 1970s, before the advent of relatively inexpensive microprocessors and personal computers. IBM had traditionally been NASA’s only spacecraft computer supplier and was at the heart of these decisions. Early on, during the Phase A studies, IBM had teamed with several of the airframe contractors, most notably North American Rockwell, to supply computers and software for the upcoming Space Shuttle. Although it was not cast in stone, it was largely assumed that IBM would produce the hardware and software regardless of the ultimate selection of an airframe contractor.

The fully reusable Phase B vehicles were more aircraft than spacecraft, although they combined the most demanding requirements of both worlds. Not only would the flight control system have the usual responsibilities for figuring out how to make a high-speed^* aircraft stable at high speeds and controllable during landing, but it would also have the additional need to control the vehicle onorbit and during reentry. In an era of mainly mechanical flight control systems, this was asking for quite an advancement.⁶

But a computer-based fly-by-wire (FBW) control system could probably do this. Fly-by-wire systems were not new—the German A-4 (V2) rocket used one during World War II; the Avro CF-105 Arrow used one in 1958; the X-20 Dyna-Soar would have used one; and to some degree, each of the U.S. crewed capsules and the lunar lander had used them. But these were all analog systems, inherently limited in what they could do by a lack of processing power, and usually (but not always) backed up by some kind of mechanical system. In 1972, NASA Dryden began research flights with the first aircraft equipped with a digital fly-by-wire (DFBW) control system.^† This system eliminated the direct mechanical or hydraulic control linkage from the pilot’s control stick to each control surface (although the aerosurface was still moved by a hydraulic actuator). Instead, the stick provided inputs to a computer that determined how each control surface should be moved to generate the required motion. To demonstrate this system, NASA Dryden modified a Vought F-8 Crusader, at first using a digital computer from the Apollo Command Module, and later using three AP-101s, the same computer selected for Space Shuttle. The first flight with the AP-101 was on 27 August 1976, and 169 missions were flown before the last flight on 16 December 1985. The F-8 was also used to validate the control laws used in the Space Shuttle flight control system before the atmospheric flight tests^.7

Choosing a computer for Shuttle was an interesting task in itself. The logical choice at first appeared to be the Autonetics D-216, a 16-bit computer with 16 kilowords of memory that cost approximately $85,000 each. This was the computer being used in the North American B-1A prototypes, but the small word size and limited memory led Space Shuttle officials to continue their search. A meeting on 5 October 1972 to discuss proposed modifications to the DFBW F-8 brought to light two computers that could possibly be used on Shuttle. The 32-bit Singer-Kearfott SKC-2000 had floating-point arithmetic (unusual in those days) and could be expanded to 24 kilowords of memory.^‡ Its major drawbacks were that it used 430 watts of power, weighed 90 pounds, and cost $185,000 each. During November 1972, the Shuttle program "discovered" the IBM AP-101, a variant of the same 4Pi computer that had flown on Skylab. This 32-bit machine had 32 kilowords of memory and a floating-point instruction set, consumed 370 watts of power, weighed slightly less than 50 pounds, and cost $87,000 each.⁸

It should be noted that no off-the-shelf microprocessors (no Z80s, 80x86s, 680x0s, etc.) were then available, and large-scale integrated circuit technology was emerging but years away from maturity. Since little, if anything, was known about the effects of lightning or radiation on high-density solid-state circuitry, ferrite-core memory was the only reasonably available choice for the orbiter computers. Therefore, memory size was limited by the power, weight, and heat constraints associated with core memory.⁹

However modest the final Space Shuttle was compared to the early Phase A/B studies, the role of its onboard computers was the most ambitious yet for any aircraft or spacecraft. When the RFP for the Phase C/D orbiter contract was released, it contained language that essentially removed the flight software from the prime contract and created a direct link between NASA and the software developer. NASA felt that it needed to keep tighter control on the software development effort than would have been possible in a once-removed subcontractor arrangement.¹⁰

A separate contract was issued to IBM for the development and verification of the most complicated computer software yet attempted. The initial $6,618,500 18-month contract was awarded on 25 September 1973; it covered the design and maintenance of the primary avionics system software (PASS), the creation of appropriate tools for developing the software, and the design and development of the Avionics Development Laboratory (ADL) and the Shuttle Avionics Integration Laboratory (SAIL) at JSC.¹¹

Interestingly, although NASA had removed the software, the orbiter contract still contained provisions for Rockwell to supply the computer hardware. Rockwell subsequently awarded IBM a $15 million contract for a version of the AP-101B coupled with a newly designed input-output processor (IOP). The computer was already being used in the Dryden DFBW F-8 program, and in fact, the Shuttle program had provided Dryden with over $1 million in funding for the DFBW program to assist in perfecting the machine. As in Skylab, each CPU was coupled with a uniquely developed IOP that provided communications with the various systems aboard the Space Shuttle.¹²

Data bus technology for real-time avionics systems was emerging but could not be considered operational, and the first digital data bus standard, Mil-Std-1553, would not be officially approved by the Air Force until 1975. All previous onboard systems had used bundles of wires, each dedicated to a specific signal. The sheer weight of the wiring would be unacceptable, and Space Shuttle elected to adopt a sort of preliminary version of the -1553 data bus during late 1974.¹³

The use of mass storage (magnetic tape) for software programs in a dynamic environment was limited and suspect, especially for program overlays while in flight (the MLU had flown on Skylab but was not used operationally to load overlays). Software design was evolving rapidly with the emergence of top-down, structured techniques, but no large-scale flight-critical systems had yet been developed and qualified using this methodology.¹⁴

It had been decided as early as Phase A that a computer system would be required to control the vehicle during all phases of flight. In fact, the final Orbiter configuration was an inherently unstable flight vehicle, incapable of even rudimentary control without the help of the onboard computer systems. Therefore, even more so than on Skylab, the computer system had to be completely reliable. That ideal was achieved through a novel approach to full redundancy, an advancement of the dual system used on Skylab. On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority^§ would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.¹⁵

With the principle of redundancy solidly established, the remaining challenge was to actually write the software. The huge expense and difficulties suffered in the development of software for Apollo caused NASA to take a hard look at what language to use for Shuttle’s software. Most of the software for Apollo had been meticulously coded in assembly language, which required the programmer to pay close attention to the machine-instruction set and to sequences of addresses in memory. To give programmers greater flexibility, NASA urged the use of a high-order computer language for Space Shuttle.¹⁶

A variation of a the HAL language, called HAL/S, was created specifically for the Shuttle project by Intermetrics, Incorporated, a Massachusetts company founded in 1969 by five M.I.T. programmers who had worked on developing software for Apollo. The name was a tribute to computer pioneer J. Halcombe Laning, who had invented an algebraic compiler in 1952 that ran on the M.I.T. Whirlwind—the first real-rime computer. The ‘S’ appended to the name has been variously explained as meaning “subset” (of what is unclear) or "Shuttle," and it is left to the reader to determine which is most fitting.¹⁷

Looking a lot like FORTRAN syntactically, what set HAL/S apart from other languages of the era was its ability to schedule tasks according to priority levels defined by the programmer. This capability would be the source of constant battles between IBM, who used the capability extensively, and Rockwell, who shunned its use for the backup software. Distilled from the best programming techniques of the era, HAL/S defined strict access rules that allowed various segments of the program to interact only as the program’s author intended. But the language’s greatest distinction may have been that it featured specific statements for real-time computing. Several programs could appear to share computer resources simultaneously, allowing both the crew and the many automated systems controlled by the computer to respond to rapidly changing events inside and outside the spacecraft without any knowledge of each other.¹⁸

The capabilities of HAL/S, specifically the ability to schedule tasks on a priority basis, caused the infamous scrub of the first Space Shuttle launch. At approximately T–20 minutes, the backup computer alerted the ground-based Launch Processing System that it had not been able to synchronize itself with the redundant set of primary computers. As it turned out, a minor programming error that had survived thousands of hours of testing allowed the redundant set to begin processing information 40 milliseconds earlier than it should have. The basic problem stemmed from the difference in programming techniques between IBM and Rockwell. The Rockwell-authored backup software was time-sliced, or synchronous—it dedicated a specific slice of CPU time to each processing task and executed those tasks in a fixed order. The IBM software was priority-interrupt-driven, or asynchronous—it performed computations on demand and in strict observance to a predefined order of importance. Rockwell and IBM had disagreed over the relative merits of the two techniques for two years, although in the end, it really did not matter. Once the bug had been discovered, it became a rather trivial matter to fix it. In fact, it was rather ironic that the problem occurred on STS-1, since engineers later estimated that the problem would have occurred on just one out of every 67 launches.¹⁹

The STS-1 software development effort had released 17 interim versions during a 31-month period starting in October 1977 and culminating in December 1980 with the STS-1 flight release. Although full software functionality was provided after the ninth release in December 1978, an additional eight releases of the software were necessary to accommodate continued requirements changes, and the discrepancy corrections inherent in a large, complex, first-of-a-kind software system.²⁰

As anyone who has ever used a computer knows, software is seldom error-free. A statistical average for software used in critical systems (flight control, air traffic control, etc.) shows that programs average 10–12 errors for every 1,000 lines of software code. This was clearly unacceptable to NASA for use on the Space Shuttle. As a result, NASA forced one of the most stringent test and verification processes ever undertaken on IBM for the primary avionics system software.²¹

The result achieved by the 300 IBM programmers, analysts, engineers, and subcontractors was impressive. An analysis accomplished after the Challenger accident showed that the IBM-developed PASS software had a latent defect rate of just 0.11 errors per 1,000 lines of code—for all intents and purposes, it was considered error-free. But this remarkable achievement did not come easily or cheap. In an industry where the average line of code cost the government (at the time of the report) approximately $50 (written, documented, and tested), the Primary Avionics System Software cost NASA slightly over $1,000 per line. A total of $500 million was paid to IBM for the initial development and support of PASS.²²

The Backup Flight System

The initial design of the orbiter flight control system comprised a quad-redundant computer complex that handled flight-critical functions. Systems management and most non-avionics functions were contained in a fifth computer that was not considered flight-critical. This concept was well into development when a blue-ribbon panel was asked to review all aspects of the upcoming atmospheric flight tests. One of the conclusions reached by the panel was that an unnecessary risk was being taken by not providing a backup flight control system for the first atmospheric flights. This decision was based on the relative complexity of the redundant-set computer synchronization scheme being implemented by IBM, and on the lack of a direct manual flight control capability in the orbiter.²³

To protect against a latent programming error existing in the primary avionics system software that would render the Space Shuttle uncontrollable during a critical flight phase, NASA decided to develop a backup flight system (BFS). This system would have its own set of requirements and would not reuse any of the code being developed for PASS. To ensure that the BFS was as independent as possible, NASA contracted with Rockwell to write it, and even different development environments and configuration management systems were specified. Nevertheless, like IBM, Rockwell elected to use HAL/S as the programming language, although the BFS tends to use a programming approach other than PASS.²⁴

The BFS was chartered to protect against a software fault in the most sophisticated flight software system ever implemented. One of the drivers towards using a BFS was the fact that it would take an estimated 10,000 years to test every possible branch in the primary flight software’s 500,000 words of code. This, obviously, was not feasible. And at this point, the concept of “error-free” software did not exist, since this declaration came only after extensive analysis of the performance of PASS during 25 flights and tens of thousands of hours of ground-based testing.²⁵

Initially, BFS was to be a very simple system installed for ALT only, capable of bringing the orbiter in for a landing on one of the lakebed runways. The BFS would be deleted once confidence had been gained in the primary flight system. The word “simple” is very important because one of the primary concerns that was driving the development of the BFS was NASA’s inability to properly verify the large amount of software being developed for PASS. The approach taken for the BFS was to develop a very simple and straightforward software program and then test it in every conceivable manner. The result was a program that contained only 12,000 words of executable instructions, including the ground checkout and built-in test for the computer. The actual flight control portion of the software consisted of approximately 6,000 words. The remainder was for the systems management functions that still had to be performed by the fifth computer, along with the backup autopilot functions.²⁶

While the BFS was being written for the ALT flights, NASA was also considering extending its use to the orbital flight tests. Although some of the PASS software would have been demonstrated during the ALT flights, a great deal more of it would not have been exercised. Therefore NASA extended the Rockwell contract to include a rudimentary ability to operate during the critical flight phases (ascent and reentry) of the OFT flights. No onorbit capability would be included, except for the ability set up a de-orbit burn and fire the OMS engines.

After this decision, it was expected that the BFS would be deleted after the completion of the OFT flights. The expectation was that after OFT, the entire Shuttle design, including the PASS, would be proven safe for operational use; therefore, the BFS would no longer be needed. Close to the end of the OFT, however, an examination of the number of changes being included into the PASS resulted in a decision to keep the BFS for the foreseeable future. It was concluded that the quantity of changes in PASS (for mission enhancements, correction of known errors, etc.) would continue to present a risk for unknown PASS software errors, and that BFS should therefore be available if needed.²⁷

The BFS has never been required to demonstrate its capability. A proposed onorbit engagement and orbital maneuvering system engine burn was deleted in 1982 from the list of flight test requirements. This change was mainly the result of a busy test schedule during the orbital flight test series, but it also indicates the level of confidence that NASA has in the BFS. However, between 18 March and 15 April 1977, the DFBW F-8 conducted eight flights at NASA Dryden that used the BFS software package during practice landing approaches.²⁸

^*Actually, the flight velocities proposed by the Phase A and B designs had not been achieved by any aircraft, including the research rocket-planes at Edwards, making total guesswork out of the flight software requirements.

^†A month earlier, the Air Force had begun testing a modified F-4 that is usually called the first FBW aircraft. The F-4’s claim to fame was that it was the first FBW aircraft without a mechanical backup system, but it used an analog FBW system as opposed to the NASA F-8’s digital system.

^‡In addition to having much more memory in modern computers, memory is also much less expensive today. Adding 8,000 words (32 kilobytes) of memory to the SKC-2000 cost $15,000, or $1.88 per word. Today it is not even possible to buy such a small quantity, but 100 times as much (32 megabytes) costs about $25.

^§If the system ends up with a two-to-two vote, it displays a warning message to the crew advising the activation of the Backup Flight System (BFS).

¹Understanding Computers: Space, editors of Time-Life Books (Alexandria, Virginia: Time-Life, unknown date).

²Understanding Computers: Space.

³Understanding Computers: Space.

⁴Understanding Computers: Space.

⁵Understanding Computers: Space.

⁶Understanding Computers: Space.

⁷For an excellent history of the DFBW F-8 program, see James E. Tomayko, Computers Take Flight: A History of NASA’s Pioneering Digital Fly-By-Wire Project, NASA SP-2000-4224 (Washington DC: NASA, 2000).

⁸Computers Take Flight, pp. 89–93; John F. Hanaway and Robert W. Moorehead, Space Shuttle Avionics System, NASA SP-504 (Washington DC: NASA, 1989), pp. 5–6.

⁹Space Shuttle Avionics System, p. 3.

¹⁰Understanding Computers: Space.

¹¹Don J. Green, NASA News Release 73-126, “JSC Awards New Avionics Contract to IBM,” 25 September 1973.

¹²Computers Take Flight; Understanding Computers: Space.

¹³Space Shuttle Avionics System, p. 3.

¹⁴Understanding Computers: Space.

¹⁵Understanding Computers: Space.

¹⁶Understanding Computers: Space.

¹⁷Understanding Computers: Space; Space Shuttle Avionics System, pp. 8–10.

¹⁸Michael J. Ryer, Programming in HAL/S (Pasadena, California: Intermetrics/JPL, September 1979), passim; Understanding Computers; Space Shuttle Avionics System, pp. 8–10.

¹⁹Case Study, “The Space Shuttle Primary Computer System,” Communications of the ACM 27, No. 9 (September 1984): 871–900.

²⁰William A. Madden and Kyle Y. Rone, “Design, Development, Integration: Space Shuttle Primary Flight Software System,” Communications of the ACM 27, No. 9 (September 1984): 918.

²¹Edward J. Joyce, “Is Error-Free Software Achievable?” Datamation (15 February 1989): 53–56; B. G. Kolkhorst and A. J. Macina, “Developing Error-Free Software,” IEEE AES Magazine (November 1988): 25–31; A. J. Macina, Independent Verification and Validation Testing of the Space Shuttle Primary Flight Software System (Houston, Texas: IBM, 28 April 1980), passim.

²²“Design, Development, Integration,” p. 918.

²³“Is Error-Free Software Achievable?,” pp. 53–56; “Developing Error-Free Software,” pp. 25–31; Independent Verification, passim.

²⁴Edward S. Chevers, “Shuttle Avionics Software Development Trials, Tribulations, and Successes: The Backup Flight System” (paper presented at the Space Shuttle Technical Conference (CR-2342) at JSC, 28–30 June 1983), pp. 30–37.

²⁵“Trials, Tribulations, and Successes: The Backup Flight System,” pp. 30–37.

²⁶“Trials, Tribulations, and Successes: The Backup Flight System,” pp. 30–37.

²⁷Computers Take Flight, pp. 107–108.

²⁸“Trials, Tribulations, and Successes,” pp. 30–37.

Updated April 5, 2001
Steven J. Dick, NASA Chief Historian
Steve Garber, NASA History Web Curator
For further information, e-mail histinfo@hq.nasa.gov

Designed by Douglas Ortiz and edited by Lisa Jirousek
NASA Printing and Design