p technology used in various military and NASA flight programs) and the Singer- Kearfott SKC-2000 (then a candidate for the B-1A program). Both of these machines were judged to require extensive modification before being considered adequate.
To understand the configuration and makeup of the Space Shuttle avionics system, it is necessary to understand the technological environment of the early seventies. In the approximately 16 years since the inception of the system, computers and the associated technology have undergone four generations of change. If the system designers were operating in today's environment, a much different set of design choices and options would be available and, quite possibly, a different configuration would have resulted. This section is intended to familiarize the reader with the designer's world during the formative stages of the system, with the technology available, and with the pressure of factors other than technology which influenced the result.
Although the state of technology was a major factor (and limitation) in the design of the avionics system, the effect of other factors was also significant. These include influences arising from traditional, conservative attitudes, as well as those associated with the environment in which the system was to operate. In any development program, a new approach or technique is correctly perceived to have unknown risks with potential cost and schedule implications and is to be avoided whenever possible. In addition, the designers, the flightcrew, and other operational users of the system often have a mindset, established in a previous program or experience, which results in a bias against new or different, "unconventional" approaches. Finally, the environment in which the system is to function must be considered. For instance, a new technique proposed for a system may not be viable if it requires a major change in the associated ground support complex. In the following paragraphs, a number of subsystem or functional areas are examined in the context of one or more of these factors.
In the early seventies, only two avionics computers under development were considered potentially capable of performing the Space Shuttle task. These were the IBM AP-101 (a derivative of the 4
No suitable off-the-shelf microcomputers were then available (no Z80's, 8086's, 68000's, etc.). Large-scale integrated-circuit technology was emerging but not considered mature enough for Space Shuttle use. Very little was known about the effects of lightning or radiation on high-density solid-state circuitry. Core memory was the only reasonably available choice for the Space Shuttle Orbiter computers; therefore, the memory size was limited by power, weight, and heat constraints. Data bus technology for real-time avionics systems was emerging but could not be considered operational. The U.S. Air Force (USAF) was developing MIL-STD-1553, the data bus standard, but it would not become official until 1975. All previous systems had used bundles of wires, each dedicated to a single signal or function. The use of tape units for software program mass storage in a dynamic environment was limited and suspect, especially for program overlays while in flight. Software design methodology was evolving rapidly with the emerging use of top-down, structured techniques. No high-order language tailored for aerospace applications existed, although NASA was in the process of developing a high-order software language for Shuttle (HAL/S), which subsequently become the Space Shuttle standard.
In all manned space programs preceding the Space Shuttle (Mercury, Gemini, and Apollo), fly-by-wire control systems were used for vehicle attitude and translation control. Although digital autopilots were developed for Apollo spacecraft, analog control systems were also included and considered necessary for backup. Aircraft flight control technology, however, had not advanced beyond the use of mechanical systems, augmented with hydraulic boost on large airplanes. Most aircraft applications of electronics in the flight control system used limited-authority analog stability-augmentation devices to improve aerodynamic handling qualities. Autopilots were also analog devices and also given limited authority. Neither the stability-augmentation function nor the autopilot was considered critical for safe flight when implemented in these configurations. The flight control hardware and subsystems were kept functionally and electrically separate from other electronic systems to the extent possible.
Sophisticated guidance and navigation schemes and algorithms had been developed and used in the Apollo Program; therefore, the technology base appeared adequate for the Space Shuttle in these disciplines. Although a new guidance and navigation challenge was posed by the entry through landing phase, no state-of-the-art advances were deemed necessary.
The pilot input devices in general use for aircraft control were a stick or a yoke/wheel for roll and pitch, and rudder pedals for yaw. When hydraulic boost was used, elaborate sensing devices were included to provide the correct feedback to the pilot. Hand controllers without feedback and with only electrical outputs had been used in previous manned space programs; however, the application did not involve aerodynamic flight. Switches, pushbuttons, and other input devices were typically hardwired to the function, the box, or the subsystem that required the input. Displays were also hardwired, were generally mechanical, and were dedicated to the function served. Off-the-shelf horizontal and vertical situation displays, although electronically driven, utilized a mechanical presentation. Electronic attitude and directional indicator (EADI) technology was emerging but not in common use. Heads-up displays (HUD's) were also just emerging. The concept of multifunctional displays was immature and had never been used in an aerospace application. Many of the display and control design issues associated with management of a redundant system had never been addressed.
A very capable S-band communications system had been developed for use on the Apollo Program; however, it could not serve the data rate, link margins, and coverage requirements forecast for Space Shuttle operations and experiment support. The NASA had led research in digital voice and sophisticated encoding and decoding techniques, but these had never been proven in an operational system. Solid-state radiofrequency (RF) amplifiers capable of power output sufficient for skin-tracking radar were emerging but also not proven. The Federal Aviation Administration (FAA) was considering an upgrade of the Instrument Landing System (ILS) to one using microwave scanning beam techniques capable of meeting Orbiter landing performance requirements, but no realistic conversion schedule existed.
The use of redundant systems to enable operation in the face of failures was common in both aircraft and space applications; however, all previous approaches used primary/backup, active/standby techniques which relied on manual recognition of faults and crew-initiated switchover to the alternate or backup system. Very little was known about the use and management of multiple sensors or other input devices and even less about multiple output devices such as hydraulic actuators. No aerospace project had even contemplated the automation of failure detection and recovery for large systems such as the reaction control system (RCS). The RCS required complex assessments of large numbers of temperature and pressure sensors, correlation with vehicle dynamic response to digital autopilot commands, and a variety of recovery options which depended on factors such as mission phase, propellant quantity, and available thruster configuration. The system which evolved required the use of techniques which rival those of expert systems being developed today.
NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz