NASA Office of Logic Design

NASA Office of Logic Design

A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.

NASA SP-504: Space Shuttle Avionics System

Section 3  System Design Evolution


Top-Level Design Drivers/Requirements

Design drivers which affected or forced the overall system architecture and approach can be grouped into two categories: mission derived and vehicle derived. In the following subsections, each of these categories is explored and linked to a particular aspect or aspects of the system.

Mission-Derived Requirements

The basic Space Shuttle mission consists of lift-off from the NASA John F. Kennedy Space Center or from Vandenberg Air Force Base, ascent and insertion into low Earth orbit, performance of operations in support of various payloads, and descent to an unpowered landing on a 4572- meter (15 000 foot) runway. The significant differences between the Space Shuttle mission and those of previous programs include the requirement for much more complex and extensive on-orbit operations in support of a much wider variety of payloads and the requirement to make precisely controlled, unpowered, runway landings. These requirements, coupled with the longstanding NASA rule that a mission must be aborted unless at least two means of returning to Earth safely are available, had a profound effect on the design approach. In previous programs, the concept of safe return could be reduced to a relatively simple process; i.e., managing a parachute landing in the ocean in the vicinity of recovery forces. Therefore, relatively simple backup systems were devised; these systems had severely degraded performance compared to the primary operational system but complied with the mission rule. In the Space Shuttle mission, however, the entry through final approach and landing maneuvers impose a performance requirement on the onboard systems as severe as that of any mission phase; therefore, backup systems with degraded performance were not feasible. Further, the economic impact of frequently aborted missions on a user-intensive program such as Space Shuttle made a system which dictated an abort after one failure completely unacceptable. Therefore, a comprehensive fail operational/fail safe (FO/FS) system requirement was imposed. This requirement meant that the avionics system must remain fully capable of performing the operational mission after any single failure and fully capable of returning safely to a runway landing after any two failures. The FO / FS requirement and the incapability of degraded backup systems to achieve a safe return dictated the use of multiple avionics "strings," each independent from a reliability standpoint but each with equivalent capability.

Another design constraint, derived from experience on previous programs, severely limited the use of built-in test equipment (BITE) as a means of component failure detection. Many cases of failures in the BITE circuitry, leading to false conclusions about the operability of a unit, had been experienced. The much preferred, and Space Shuttle selected, method of fault detection was to compare actual operational data produced by a device or subsystem with similar data produced by devices or subsystems operating in parallel and performing the same function. A minimum of three strings is required to guarantee the identification of a diverging or disabled unit using this comparison process, and a fourth string is needed to accommodate a second failure in the same area. The combination of this fault detection, isolation, and reconfiguration (FDIR) approach and the FO / FS requirement led to the quadruple redundancy which is prevalent in much of the Space Shuttle avionics system.

A third mission-derived requirement which had a systemwide impact was autonomous operation, mandated by the USAF and established as a design goal by NASA to decrease operational costs by reducing the dependence on ground support. To manage Space Shuttle systems onboard required that much of the subsystem telemetry data, which had been sent only to the ground on previous programs, be processed and provided to the crew in appropriate, usable forms. Because of the complexity and size of the system, many of the onboard system management functions had to be automated to a significant degree and mechanized with an appropriate mix of crew involvement, assessment, and required action, depending on the mission phase and associated workload.

Vehicle-Derived Requirements

The Space Shuttle is made up of four separate and distinct physical elements: the Orbiter (including the Space Shuttle main engines), the external tank (ET), and two solid rocket boosters (SRB's). These elements are arranged for lift-off in a side-by-side configuration, in contrast to the vertical launch stack of the Apollo and other previous spacecraft. Because only the Orbiter is totally recoverable, most of the avionics equipment is contained in this element, although some flight control sensors and control effectors are located in the SRB's.

The Space Shuttle vehicle is an unstable airframe which cannot be flown manually even for short periods during either ascent or entry aerodynamic flight phases without full-time flight control stability augmentation. This factor excluded any possibility of unaugmented, direct flight control approaches, either mechanical or fly-by-wire. Although briefly considered for postentry aerodynamic flight control early in the program, cable/hydraulic boost systems were quickly eliminated because of weight considerations and mechanization difficulties, and an augmented fly-by-wire approach was baselined. Analog augmentation devices were also considered early in the program, particularly for entry; however, the wide spectrum of control required and the need to readily adapt to performance changes as the vehicle evolved discouraged their use. Digital flight control systems had been used with great success in the Apollo Program, and, although no aircraft system had been flown with one at the time, NASA was well aware of the advantages of such a system and chose digital flight control as the Space Shuttle baseline. The full-time augmentation requirement, however, placed the digital flight control computation system in the safety-critical path and dictated quadruple redundancy in this area.

The control authority necessary to meet all the Space Shuttle vehicle requirements, particularly during ascent and entry, resulted in a situation in which a control actuator hard over command, issued erroneously, could cause structural failure and the loss of the vehicle if the command was allowed to remain in effect for as little as 10 to 400 milliseconds (depending on the mission phase). Figure 3-1 illustrates the problem for one point during entry. This situation affected the design in at least two important ways. First, it imposed a requirement for actuator hard over prevention no matter what the failure condition. Second, because of the reaction time required, it removed the crew, and any reliance on direct manual intervention, from consideration in the failure reaction process and dictated a fully automatic redundancy faultdown approach. The concept which emerged to prevent hardovers was to use hydraulic actuators with multiple command inputs to the secondary stage as shown in figure 3-2. These secondary-stage inputs were hydraulically force-summed and the resultant command was sent to the primary or power actuator. If one of the inputs diverged from the rest (such as in the case of an erroneous hard over command), the effect of its secondary-stage output was overpowered by the other secondary-stage outputs and the control effector responded correctly. To make such a system work, however, multiple, independently computed commands to the secondary actuator inputs had to be provided, or some other scheme to carry the hardover prevention forward in the system had to be devised.

Figure 3-1. - Elevon failure effects.

Figure 3-2. - Four-port actuator

The multiple, independent command technique which was eventually baselined is shown in figure 3-3. It relied on parallel, multiple-string operation and tight synchronization of the entire system to prevent divergence of the commands. This approach was considered, initially at least, to be excessively complex and difficult to verify; therefore, several alternate approaches were investigated and eventually discarded.

Figure 3-3. - Baseline system approach.

One technique examined (fig. 3-4) would have used an active/standby approach with the active string supplying commands to all actuator inputs. An independent g-limiter and associated switch would be used to detect a structure-endangering situation and call for a manual or automatic switchover to a hot standby string. Several studies were conducted using this technique, which appeared promising at first, but it was eventually discarded because a number of problems were encountered. These included mechanization difficulty and the fact that the measurement cues varied throughout and between mission phases.

Figure 3-4. - Active/standby approach

A second, also initially promising technique investigated is shown in figure 3-5. Using this approach, the independent strings would have operated in parallel, but very loosely coupled, with each operating on independent sensor data and each independently issuing commands to one of the actuator ports. Long-term divergence between systems would be prevented by periodically exchanging state vectors or other slowly varying information. Any short-term inner loop flight control command divergence would be compensated for with equalization in the actuator servomechanisms. This technique appeared feasible but was eventually discarded because its mechanization was very dependent on exact knowledge of vehicle characteristics and these, at the time, were in a constant state of flux. Further, no guarantee could be made that some future vehicle modification would not perturb this concept unacceptably. Therefore, the current baseline endured, including multiple, active string operation with each string closely coupled and synchronized to prevent divergence of secondary actuator output commands.

Figure 3-5. - Parallel String Approach

Precise vehicle sequencing requirements also drove the system toward coupled, synchronized digital operation. These sequences included events such as Space Shuttle main engine (SSME) and SRB ignition, launch pad release and lift-off operations, SRB and ET stage separation, etc. These events are of the type which must occur within milliseconds of the correct time, but must absolutely be prevented from occurring at any other time. The baseline system approach, defined previously for flight control, also served the sequencing requirements for multiple, independent, simultaneous inputs and properly timed arm and fire sequences.

The large size of the vehicle also had an impact on the avionics system configuration. Because sensors, control effectors, and associated devices would be distributed all over the vehicle, the weight of the wire required to carry all the signals and commands necessary for operation of all system elements became a significant factor. Therefore, the use of multiplexed digital data buses was investigated and baselined. In addition, similar considerations led to the baselining of remote power control devices in lieu of dedicated in-line circuit breakers in the crew cockpit area. In summary, the mission- and vehicle-derived requirements included the following.

Home - NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz