Nasa Space Shuttle Avionics System

8/9/2019 Nasa Space Shuttle Avionics System

1/82

Space ShuttleAvionics System

ORIGINALCONTAINSCOLORLLUSTRATIONS


2/82ilI]]


3/82

NASA SP-504

Space ShuttleAvionics System

John F. HanawayIntermetrics, Inc.

Robert W. MooreheadNASA Headquarters

National Aeronautics and Space AdministrationOff ice of ManagementScientific and Technical Information DivisionWashington, DC 1989


4/82

Library of Congress Cataloging-in-Publication DataHanaway, John F.

Space shuttle avionics system / John F. Hanaway, Robert W.Moorehead.

p. cm. -- (NASA SP ; 504)Supt. of Docs. no. : NAS 1.21:5041. Space shuttles--Electronic equipment. I. Moorehead, Robert

W. II. Title. III. Series.TL3025.H36 1989629.47--dc20

For sale by the Superintendent of Documents,U.S Government Printing Office, Washington, DC 20402

89-600316CIP

;!


5/82

PrefaceHE SPACE SHUTTLE avionics system represents asignificant advance in avionics system technology. The

system was conceived in the early 1970's, developedthroughout that decade, and became operational in the1980's. Yet even todayin _]988, it remains the mostsophisticated, most advanced, most integrated avionicssystem in operational use in the aerospace arena. Someof the more significant "firsts" achieved by the systeminclude the following.

It represents the frst successful attempt to incorporatea comprehensive fail operational/fail safe concept inan avionics system.

It pioneered the development of complex redundancymanagement techniques, some of which rival theexpert system approaches emerging today.

It is the first operational aerospace system to use digitaldata bus technology to perform flight-criticalfunctions.

It is the first operational system to utilize a high-orderlanguage to develop and produce onboard software.

It is the first operational aerospace program to makeextensive use of flight software program overlays froma tape memory to expand the effective size of computermemory.

It is the first system to integrate the flight controlfunction with the rest of the avionics functions.

It included the first use of digital fly-by-wire technologyin an operational atmospheric flight application.

It is the first avionics system to use a multifunctioncathode-ray-tube display and crew interface approach.

It is the first avionics system to provide extensiveoperational services to onboard nonavionics systems.

Such pioneering innovations and concepts are remark-able in that they emerged in a design environment whichwould be considered archaic by today's standards. Forinstance, the data processing state of the art has turnedover at least four times since the Space Shuttle design wasconceived. In 1974, there were no off-the-shelf microcom-puters, large-scale integrated-circuit technology wasemerging but immature, and the use of data buses for critical

functions was considered to be radical and of high risk.Prior to the Space Shuttle, aerospace systems were madeup of an essentially independent collection of subsystems,organized along disciplinary lines such as flight control,guidance and navigation, communications, and instrumen-tation. Each subsystem typically had its own dedicatedcontrols, displays, and command and signal paths. TheSpace Shuttle avionics system not only integrated thecomputational requirements of all subsystems in one centralcomputer complex, but introduced the concept ofmultifunction controls, displays, and command/data paths.The overall system design was driven by missionrequirements and vehicle constraints never before encoun-tered in a space program. Significant among these werethe following. The requirement for multiple reuse over a 20-year

period -- The economic and safety-related impactsof aborting after one failure required that the systemhave a two-fault-tolerant fail operational/fail safeconfiguration.

The requirement that comparison of data orperformance from independent systems or componentsoperating in parallel be the primary means of detectingand isolating failures and assessing system operationalstatus-- To detect the second failure in a system, four parallel

strings were required and baselined.--The use of built-in test was excluded wherever

possible as a less reliable fault isolation technique. The requirement for an unpowered landing on a

runway -- The stringent performance requiredprohibited the use of degraded backup systems.

The autonomy requirement -- Large quantities ofinstrumentation data, transmitted to the ground onprevious programs for spacecraft functional assess-ment and subsystem management, had to be processedonboard and made available to the crew in usableforms.

The Space Shuttle vehicle which evolved was anunstable airframe requiring sufficient control authorityto cause structural failure if an erroneously applied

V

PRECEDING PAGE BLANK NOT FILMED


6/82

SPACE SHUTTLE AVIONICS SYSTEM

hardover control actuator command was allowed toremain in effect for as little as 10 to 400 milliseconds.--Full-time stability augmentation was baselined,

direct control modes were excluded, and digitalautopilots were designated to accommodate thewide spectrum of control.

-- Manual intervention or switching of active/standbystrings proved inadequate to overcome the effectsof erroneous hardover commands; therefore, asystem approach was baselined in which hardoverswere prevented through the use of multiple, parallel-operating, synchronized processors and commandpaths to drive force-summing control actuators.

The large size of the Space Shuttle vehicle resultedin the weight of wire, both signal and power, beinga significant proportion of the avionics system weight.-- Multiplexed serial digital data buses were used for

command and data transmission throughout thevehicle.

-- Solid-state remote power control devices were usedto reduce the quantity of power cable needed.

A myriad of other mission, vehicle, and system require-ments influenced or dictated various aspects of the design;however, the basic system concepts were derived from thosedescribed.

The Space Shuttle avionics system which evolved featuresa five-computer central processing complex, which providessoftware services to all vehicle subsystems that require them.Each computer is connected to a network of 28 serial digitaldata buses, which distribute input/output commands anddata to/from bus terminal units located throughout thevehicle. Dedicated hardware components, unique to thevarious subsystems, interface as necessary with bus terminalunit signal conditioning devices. During critical missionphases such as ascent and entry, the system is configuredin four redundant, independent but synchronized strings,each controlling one-fourth of the redundant sensors andcontrol effectors required for th e operation in progress.A backup, simplex software package is installed in the fifthcomputer to be used if a generic error causes failure ofthe total redundant set. During more benign mission phasessuch as on-orbit, the computer complex can be configured,by loading the appropriate software programs, to performa wide variety of mission and payload support functions.

The system includes more than 270 components,depending on the mission, and uses approximately 500 000lines of software code. Although very complex and difficultto describe or understand, the system has proven to bereliable, durable, extremely versatile, and a tribute to themultitudes who contributed to its design, development, andverification.

vi

!!1!lJ]


7/82

ContentsSection

IPage

INTRODUCTIONPurpose of Document ..................................................................... iOrganization ............................................................................. 1Use ....... . ............................................................................. ITHE DESIGN ENVIRONMENTIntroduction ............................................................................. 3Avionics Hardware/Software ............................................................... 3Flight Control ............................................................................ 3Guidance and Navigation .................................................................. 4Displays and Controls ..................................................................... 4Communications and Tracking ............................................................. 4Redundancy Management .................................................................. 4

3 SYSTEM DESIGN EVOLUTIONIntroduction ............................................................................. 5Top-Level Design Drivers/Requirements ..................................................... 5Data Processing .......................................................................... 9Flight Control ............................................................................ l0Backup System ........................................................................... 12Redundancy Management .................................................................. 12Onboard System Management .............................................................. 13Navigation ............................................................................... 15Display and Control ....................................................................... 17Communications .......................................................................... 17USAF Requirements ...................................................................... 19Payload Support .......................................................................... 19Remote Manipulator ...................................................................... 20Power Distribution ........................................................................ 20SYSTEM MECHANIZATION/OPERATIONOverview ................................................................................ 21Avionics System Functions ................................................................. 22Data Processing .......................................................................... 25Display and Control ....................................................................... 35Guidance, Navigation, and Control .......................................................... 38Sequencing .............................................................................. 45System Management/Instrumentation ....................................................... 47Communications and Tracking ............................................................. 49Payload Support Operations ............................................................... 54Electrical Power Distribution and Control .................................................... 56Ground Checkout ......................................................................... 59

APPENDIX -- ACRONYMS/ABBREVIATIONS ..................................................... 61

vii


8/82


Table4-14-II

Figure3-13-23-33-43-53-63-74-14-24-34-44-54-64-74-84-94-104-114-124-134-144-154-164-174-184-194-204-214-224-234-244-254-264-274-284-294-304-314-324-334-344-354-36

TablesData Bus Utilization ......................................................................Guidance, Navigation, and Control Elements . .. .. .. .. ... .. ... .. .. .. ... .. ... .. .. .. ... .. ... .. ..

Figures

Page3039

PageElevon failure effects ...................................................................... 6Four-port actuator ........................................................................ 7Baseline system approach .................................................................. 7Active/standby approach .................................................................. 8Parallel string approach ................................................................... 9System management approaches ............................................................ 14Skewed IMU approach .................................................................... 15Avionics equipment locations ............................................................... 21Avionics functional categories .............................................................. 22Ascent control effectors .................................................................... 23Ascent trajectory ......................................................................... 2324Entry trajectory ..........................................................................Terminal area energy management .......................................................... 25Final approach ........................................................................... 2526Listen mode .............................................................................Memory configurations .................................................................... 27OPS substructure ......................................................................... 27Software architecture ...................................................................... 28GPC memory configuration ................................................................ 2829Data bus characteristics ................................................................... 29Data bus message formats ................................................................. 30Data bus architecture .....................................................................Multiplexer/demultiplexer block diagram .................................................... 31Master events controller ................................................................... 32Engine interface unit ...................................................................... 3334Annunciator display unit .................................................................. 35Data bus control .........................................................................Forward flight deck ....................................................................... 36Aft flight deck ............................................................................ 37Display and control block diagram .......................................................... 38GN&C RM configuration .................................................................. 40Air data system ........................................................................... 41GN&C actuator configuration .............................................................. 4243Typical hydraulic actuator drive ............................................................Main engine throttle control ................................................................ 44RCS configuration ........................................................................ 45OMS configuration ....................................................................... 46Sequencing configuration .................................................................. 46Instrumentation system .................................................................... 47System management configuration .......................................................... 48Orbital communication links ............................................................... 49Atmospheric flight links ................................................................... 49Hardware groupings ...................................................................... 50

viii


9/82

CONTENTS

Figure4-374-384-394-404-414-424-434-444-454-464-474-48

Page50Antenna locations ............................................................

S-band network equipment ...................................................... 51S-band network services ........................................................ 52S-band payload communications .................................................. 52Ku-band radar/communication subsystem ........................................... 53Audio distribution system ....................................................... 54Navigation aids .............................................................. 54Payload interfaces ............................................................ 55Electrical power system (single string) .............................................. 57Essential bus distribution (one of three) ............................................. 58Control buses ............................................................... 59Checkout configuration ........................................................ 59

ix


10/82_IIll


11/82

Section 1 Introduction

Purpose of DocumentThe Space Shuttle avionics system design roots are in theearly 1970's, yet it remains the most sophisticated,integrated, innovative approach to an aerospace avionicssystem in use today -- 16 years hence. It is the intentof this document to trace the origins and evolution of thesystem; to outline the requirements, constraints, and otherfactors which led to the final configuration; and to providea comprehensive description of its operation and functionalcharacteristics. The assumption is made that the readeris familiar with, or has access to, information about thebasic Space Shuttle vehicle configuration and itssubsystems.

OrganizationThe remainder of the document is organized into threesections.

In Section 2 -- The Design Environment, the stateof the electronics and aerospace art in the earlyseventies is assessed. The intent is to familiarize thereader with the environment in which the designevolved.

In Section 3 -- System Design Evolution, the majorrequirements and other factors that led to the SpaceShuttle avionics system configuration are developed.The overall design drivers and constraints are treatedfirst, followed by a subsystem-by-subsystem discussionof the major tradeoffs and design issues that wereaddressed as the system evolved.

Section 4 -- System MechanizationOperationcontains a description of the system and of itsfunctional operation. Each function or serviceprovided is examined from the standpoint of the dataprocessing hardware and software attributes used aswell as of the additional unique avionics subsystemhardware required.

UseThe Space Shuttle avionics system is very large andextremely complex and, therefore, is difficult to describewithout becoming engulfed in details. The approach usedhere is to maintain a top-level perspective by frequentreference to the system block diagram contained in thefoldout located inside the back cover. The reader isrequested to examine the foldout at this time. Note thatit can be extended without interfering with the readingof the document. To facilitate reference to various featuresof the system, letters (across the top and bottom) andnumbers (along the sides) define zones that are used inthe descriptions which follow. References to zones in thediagram will follow the alphanumeric convention (e.g.,[B,3]) to identify locations. To the lower left of the diagram,note the color code legend which indicates the conventionused to identify data buses. Note also that the diagramreflects the physical distribution of equipment in the vehicle.Because of the frequent references made to the diagram,it is recommended that it remain extended while the varioussections, especially section 4, are examined. Even thoughsubsystem and function descriptions may include moredetailed, specialized diagrams and figures, it is veryimportant that the overall perspective be maintainedthrough the use of the system block diagram.

As indicated previously, the document is intended notonly to describe the Space Shuttle avionics system, butto develop the thesis for its configuration and its evolution.For the user not interested in the origins and evolution,section 4 is written to stand alone and may be used asa reference description of system mechanization andoperation.

Acronyms and abbreviations used herein are defined inthe appendix.

In compliance with the NASA's publication policy, theoriginal units of measure have have been converted to theequivalent value in the Syst_me International d'Unitrs (SI).As an aid to the reader, the SI units are written first andthe original units are written parenthetically thereafter.


12/82il IH


13/82

Section 2 The Design EnvironmentIntroductionTo understand the configuration and makeup of the SpaceShuttle avionics system, it is necessary to understand thetechnological environment of the early seventies. In theapproximately 16 years since the inception of the system,computers and the associated technology have undergonefour generations of change. If the system designers wereoperating in today's environment, a much different set ofdesign choices and options would be available and, quitepossibly, a different configuration would have resulted. Thissection is intended to familiarize the reader with thedesigner's world during the formative stages of the system,with the technology available, and with the pressure offactors other than techno!ggy which influenced the result.

Although the state of technology was a major factor(and limitation) in the design of the avionics system, theeffect of other factors was also significant. These includeinfluences arising from traditional, conservative attitudes,as well as those associated with the environment in whichthe system was to operate. In any development program,a new approach or technique is correctly perceived to haveunknown risks with potential cost and schedule implicationsand is to be avoided whenever possible. In addition, thedesigners, the flightcrew, and other operational users ofthe system often have a mindset, established in a previousprogram or experience, which results in a bias against newor different, "unconventional" approaches. Finally, theenvironment in which the system is to function must beconsidered. For instance, a new technique proposed fora system may not be viable if it requires a major changein the associated ground support complex. In the followingparagraphs, a number of subsystem or functional areasare examined in the context of one or more of these factors.

Avionics Hardware/SoftwareIn the early seventies, only two avionics computers underdevelopment were considered potentially capable ofperforming the Space Shuttle task. These were the IBMAP-101 (a derivative of the 4n technology used in variousmilitary and NASA flight programs) and the Singer-Kearfott SKC-2000 (then a candidate for the B-IAprogram). Both of these machines were judged to requireextensive modification before being considered adequate.

No suitable off-the-shelf microcomputers were thenavailable (no Z80's, 8086's, 68000's, etc.). Large-scaleintegrated-circuit technology was emerging but notconsidered mature enough for Space Shuttle use. Very littlewas known about the effects of lightning or radiation onhigh-density solid-state circuitry. Core memory was the onlyreasonably available choice for the Space Shuttle Orbitercomputers; therefore, the memory size was limited bypower, weight, and heat constraints. Data bus technologyfor real-time avionics systems was emerging but could notbe considered operational. The U.S. Air Force (USAF)was developing MIL-STD-1553, the data bus standard, butit would not become official until 1975. All previous systemshad used bundles of wires, each dedicated to a single signalor function. The use of tape units for software programmass storage in a dynamic environment was limited andsuspect, especially for program overlays while in flight.Software design methodology was evolving rapidly withthe emerging use of top-down, structured techniques. Nohigh-order language tailored for aerospace applicationsexisted, although NASA was in the process of developinga high-order software language for Shuttle (HAL/S), whichsubsequently become the Space Shuttle standard.

Flight ControlIn all manned space programs preceding the Space Shuttle(Mercury, Gemini, and Apollo), fly-by-wire control systemswere used for vehicle attitude and translation control.Although digital autopilots were developed for Apollospacecraft, analog control systems were also included andconsidered necessary for backup. Aircraft flight controltechnology, however, had not advanced beyond the useof mechanical systems, augmented with hydraulic booston large airplanes. Most aircraft applications of electronicsin the flight control system used limited-authority analogstability-augmentation devices to improve aerodynamichandling qualities. Autopilots were also analog devices andalso given limited authority. Neither the stability-augmentation function nor the autopilot was consideredcritical for safe flight when implemented in these configura-tions. The flight control hardware and subsystems werekept functionally and electrically separate from otherelectronic systems to the extent possible.

PRECEDING PAGE BLANK NOT FILMED


14/82


Guidance and NavigationSophisticated guidance and navigation schemes and algo-rithms had been developed and used in the Apollo Program;therefore, the technology base appeared adequate for theSpace Shuttle in these disciplines. Although a new guidanceand navigation challenge was posed by the entry throughlanding phase, no state-of-the-art advances were deemednecessary.

Displays and ControlsThe pilot input devices in general use for aircraft controlwere a stick or a yoke/wheel for roll and pitch, and rudderpedals for yaw. When hydraulic boost was used, elaboratesensing devices were included to provide the correctfeedback to the pilot. Hand controllers without feedbackand with only electrical outputs had been used in previousmanned space programs; however, the application did notinvolve aerodynamic flight. Switches, pushbuttons, andother input devices were typically hardwired to the function,the box, or the subsystem that required the input. Displayswere also hardwired, were generally mechanical, and werededicated to the function served. Off-the-shelf horizontaland vertical situation displays, although electronicallydriven, utilized a mechanical presentation. Electronicattitude and directional indicator (EADI) technology wasemerging but not in common use. Heads-up displays(HUD's) were also just emerging. The concept ofmultifunctional displays was immature and had never beenused in an aerospace application. Many of the display andcontrol design issues associated with management of aredundant system had never been addressed.

Communications and TrackingA very capable S-band communications system had beendeveloped for use on the Apollo Program; however, it couldnot serve the data rate, link margins, and coverage require-

ments forecast for Space Shuttle operations and experimentsupport. The NASA had led research in digital voice andsophisticated encoding and decoding techniques, but thesehad never been proven in an operational system. Solid-state radiofrequency (RF) amplifiers capable of poweroutput sufficient for skin-tracking radar were emerging butalso not proven. The Federal Aviation Administration(FAA) was considering an upgrade of the InstrumentLanding System (ILS) to one using microwave scanningbeam techniques capable of meeting Orbiter landingperformance requirements, but no realistic conversionschedule existed.

Redundancy ManagementThe use of redundant systems to enable operation in theface of failures was common in both aircraft and spaceapplications; however, all previous approaches usedprimary/backup, active/standby techniques which relied onmanual recognition of faults and crew-initiated switchoverto the alternate or backup system. Very little was knownabout the use and management of multiple sensors or otherinput devices and even less about multiple output devicessuch as hydraulic actuators. No aerospace project had evencontemplated the automation of failure detection andrecovery for large systems such as the reaction controlsystem (RCS). The RCS required complex assessments oflarge numbers of temperature and pressure sensors,correlation with vehicle dynamic response to digitalautopilot commands, and a variety of recovery optionswhich depended on factors such as mission phase,propellant quantity, and available thruster configuration.The system which evolved required the use of techniqueswhich rival those of expert systems being developed today.


15/82

Section 3 System Design EvolutionIntroductionThe Space Shuttle avionics system is the result of a numberof years of studies, analyses, design tradeoffs, and iterationsconducted by NASA and the Space Shuttle contractors.The design was affected by a variety of requirements andconstraints including those imposed by the Space Shuttlevehicle and its systems, the mission and associated policiesunder which the flights were to be conducted, the USAF,the user community, and the state of technology as describedpreviously. Many features or aspects of the system derivedfrom experience on previous space programs, from theresults of in-house NASA and contractor advanceddevelopment projects, and, in some cases, from arbitrarychoices of the design community. Programmatic aspectssuch as cost, schedule, and the need to settle on a baselineearly in the program also had a strong influence. It is theintent in this section to lead the reader through the mostsignificant portions of this design process. In the discussionto follow, the top-level mechanization drivers which dictatedthe basic system architecture and design approach areaddressed first. Then, the major tradeoffs or design issueswhich led to the particular mechanization aspects orimportant features of the system are examined.

Top-Level Design Drivers/RequirementsDesign drivers which affected or forced the overall systemarchitecture and approach can be grouped into twocategories: mission derived and vehicle derived. In thefollowing subsections, each of these categories is exploredand linked to a particular aspect or aspects of the system.

Mission-Derived RequirementsThe basic Space Shuttle mission consists of lift-off fromthe NASA John F. Kennedy Space Center or fromVandenberg Air Force Base, ascent and insertion into lowEarth orbit, performance of operations in support of variouspayloads, and descent to an unpowered landing on a 4572-meter (15 000 foot) runway. The significant differencesbetween the Space Shuttle mission and those of previousprograms include the requirement for much more complexand extensive on-orbit operations in support of a muchwider variety of payloads and the requirement to makeprecisely controlled, unpowered, runway landings. These

requirements, coupled with the longstanding NASA rulethat a mission must be aborted unless at least two meansof returning to Earth safely are available, had a profoundeffect on the design approach. In previous programs, theconcept of safe return could be reduced to a relatively simpleprocess; i.e., managing a parachute landing in the oceanin the vicinity of recovery forces. Therefore, relatively simplebackup systems were devised; these systems had severelydegraded performance compared to the primary operationalsystem but complied with the mission rule. In the SpaceShuttle mission, however, the entry through final approachand landing maneuvers impose a performance requirementon the onboard systems as severe as that of any missionphase; therefore, backup systems with degraded perform-ance were not feasible. Further, the economic impact offrequently aborted missions on a user-intensive programsuch as Space Shuttle made a system which dictated anabort after one failure completely unacceptable. Therefore,a comprehensive fail operational/fail safe (FO/FS) systemrequirement was imposed. This requirement meant that theavionics system must remain fully capable of performingthe operational mission after any single failure and fullycapable of returning safely to a runway landing after anytwo failures. The FO/FS requirement and the incapabilityof degraded backup systems to achieve a safe return dictatedthe use of multiple avionics "strings," each independentfrom a reliability standpoint but each with equivalentcapability.

Another design constraint, derived from experience onprevious programs, severely limited the use of built-in testequipment (BITE) as a means of component failuredetection. 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 SpaceShuttle selected, method of fault detection was to compareactual operational data produced by a device or subsystemwith similar data produced by devices or subsystemsoperating in parallel and performing the same function.A minimum of three strings is required to guarantee theidentification of a diverging or disabled unit using thiscomparison process, and a fourth string is needed toaccommodate a second failure in the same area. Thecombination of this fault detection, isolation, andreconfiguration (FDIR) approach and the FO/FSrequirement led to the quadruple redundancy which isprevalent in much of the Space Shuttle avionics system.


16/82

SPACESHUTTLEAVIONICSYSTEMA third mission-derivedequirementwhichhad asystemwidempactwasautonomousperation,mandatedbytheUSAFandestablishedsa designoalbyNASAto decreaseperationalostsby reducinghedependenceon groundsupport.To manageSpaceShuttlesystemsonboardequiredhatmuchof thesubsystemelemetrydata,whichhadbeensentonlyto thegroundonpreviousprograms,be processednd providedto the crewinappropriate,sableorms.Becausef thecomplexityndsizeofthesystem,manyoftheonboardystemmanagementfunctionsadto beautomatedo asignificantegreendmechanizedithanappropriatemixofcrewnvolvement,assessment,ndrequiredction,dependingnthemissionphaseandassociatedorkload.

Vehicle-Derived RequirementsThe Space Shuttle is made up of four separate and distinctphysical elements: the Orbiter (including the Space Shuttlemain engines), the external tank (ET), and two solid rocketboosters (SRB's). These elements are arranged for lift-offin a side-by-side configuration, in contrast to the verticallaunch stack of the Apollo and other previous spacecraft.Because only the Orbiter is totally recoverable, most ofthe avionics equipment is contained in this element,although some flight control sensors and control effectorsare located in the SRB's.The Space Shuttle vehicle is an unstable airframe which

cannot be flown manually even for short periods duringeither ascent or entry aerodynamic flight phases withoutfull-time flight control stability augmentation. This factorexcluded any possibility of unaugmented, direct flightcontrol approaches, either mechanical or fly-by-wire.Although briefly considered for postentry aerodynamicflight control early in the program, cable/hydraulic boostsystems were quickly eliminated because of weightconsiderations and mechanization difficulties, and anaugmented fly-by-wire approach was baselined. Analogaugmentation devices were also considered early in theprogram, particularly for entry; however, the wide spectrumof control required and the need to readily adapt toperformance changes as the vehicle evolved discouragedtheir use. Digital flight control systems had been used withgreat success in the Apollo Program, and, although noaircraft system had been flown with one at the time, NASAwas well aware of the advantages of such a system andchose digital flight control as the Space Shuttle baseline.The full-time augmentation requirement, however, placed thedigital night control computation system in the safety-criticalpath and dictated quadruple redundancy in this area.The control authority necessary to meet all the Space

Shuttle vehicle requirements, particularly during ascent andentry, resulted in a situation in which a control actuatorhardover command, issued erroneously, could cause

structural failure and the loss of the vehicle if the commandwas allowed to remain in effect for as little as 10 to 400milliseconds (depending on the mission phase). Figure 3-1 illustrates the problem for one point during entry. Thissituation affected the design in at least two important ways.First, it imposed a requirement for actuator hardoverprevention no matter what the failure condition. Second,because of the reaction time required, it removed the crew,and any reliance on direct manual intervention, fromconsideration in the failure reaction process and dictateda fully automatic redundancy faultdown approach. Theconcept which emerged to prevent hardovers was to usehydraulic actuators with multiple command inputs to thesecondary stage as shown in figure 3-2. These secondary-stage inputs were hydraulically force-summed and theresultant command was sent to the primary or poweractuator. If one of the inputs diverged from the rest (suchas in the case of an erroneous hardover command), theeffect of its secondary-stage output was overpowered bythe other secondary-stage outputs and the control effectorresponded correctly. To make such a system work, however,multiple, independently computed commands to thesecondary actuator inputs had to be provided, or someother scheme to carry the hardover prevention forwardin the system had to be devised.

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

Up

O_0_

t:: "O

LLI .'_'--c/)O

r-"

E_O it-

Up

Failure[ /Recovery

- 1 0 _"0

+5+10+15 I ;I I I I I I II

I-0.5 F i

\'- j--0.5+1+1.5 L [ __/ - Limit load+2/ II I 1 I I I I0 .5 1 1.5 2 2.5 3 3.5

Time, secFIGURE 3-1.--Elevon failure effects.

iii


17/82

SYSTEM DESIGN EVOLUTION

Command inputs

x_

I7

Secondary actuator

Servoamplifiers

i'_ Servovalvesi ]_---i/Feedback_d__, ,' r" I_1_,_'_, .' _s] /.1__,Hydrauliceturn pressure

i _///ll'/.////.,'z "/'//_///_,

' Iv//////_,.,-/////.,_. _,_'mPrimary actuator

FIGURE 3-2.--Four-port actuator.

Sensor _iset

Sensor .._set

(

qmq

"l

I

Computer1

Computer2

Computer3

Com4puter

Servoamplifiers

_>--

-*2 -trFIGURE 3-3.--Baseline system approach.

Actuator Controleffector


18/82


One technique examined (fig. 3-4) would have used anactive/standby approach with the active string supplyingcommands to all actuator inputs. An independent g-limiterand associated switch would be used to detect a structure-endangering situation and call for a manual or automaticswitchover to a hot standby string. Several studies wereconducted using this technique, which appeared promisingat first, but it was eventually discarded because a numberof problems were encountered. These included mechani-zation difficulty and the fact that the measurement cuesvaried throughout and between mission phases.

A second, also initially promising technique investigatedis shown in figure 3-5. Using this approach, the independentstrings would have operated in parallel, but very looselycoupled, with each operating on independent sensor dataand each independently issuing commands to one of theactuator ports. Long-term di,eergence between systemswould be prevented by periodically exchanging state vectorsor other slowly varying information. Any short-term innerloop flight control command divergence would becompensated for with equalization in the actuatorservomechanisms. This technique appeared feasible but waseventually discarded because its mechanization was verydependent on exact knowledge of vehicle characteristicsand 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 conceptunacceptably. Therefore, the current baseline endured,including multiple, active string operation with each stringclosely coupled and synchronized to prevent divergence ofsecondary actuator output commands.

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

The large size of the vehicle also had an impact on theavionics system configuration. Because sensors, controleffectors, and associated devices would be distributed allover the vehicle, the weight of the wire required to carryall the signals and commands necessary for operation ofall system elements became a significant factor. Therefore,the use of multiplexed digital data buses was investigatedand baselined. In addition, similar considerations led tothe baselining of remote power control devices in lieu of

Sensor _L--_q I

Sensor ,__--_-']

Computer1

Computer2

Computer3

Computer4

g-limiterswitchI ServoamplifiersI, %____

"_=_ Actuator Controleffector

FIGURE 3-4.--Active/standby approach,


19/82


dedicated in-line circuit breakers in the crew cockpit area.In summary, the mission- and vehicle-derived require-

ments included the following. No degraded backup systems A fail operational/fail safe approach Use of operational data to detect and isolate failures Quadruple redundancy to isolate a second failure Automatic failure detection and recovery for time-

critical functions Full-time digital flight control Data buses and remote power control devices to save

weight Onboard access to and analysis of subsystem data

for autonomy

Data ProcessingAs indicated in section 2, the state of technology in theearly seventies severely limited the choices available in thedata processing area. In the early stages of Space Shuttledevelopment, a number of computer configurations wereconsidered including options by which flight control was

segregated from guidance and navigation; the guidance,navigation, and control (GN&C) function was separatedfrom other data processing system (DPS) functions; oraerodynamic ascent/entry and space-flight functions weremechanized in different machines. The considerationsdiscussed previously, which led to a tightly coupled,synchronized FO/FS computation requirement for flightcontrol and sequencing functions, drove the system towarda four-machine computer complex. The difficulties involvedin attempting to interconnect and operate multiplecomplexes of machines, possibly of different types andnumbers, drove the configuration toward a single complexwith central, integrated computation. A fifth machine wasadded in the final configuration, primarily because ofuncertainty as to the future computation requirementswhich might be placed on the system. Initially, this computerwas to be used to off-load nonessential mission applications,payload, and system management tasks from the other four.As will be seen, however, the fifth machine eventuallybecame the host for the backup system flight software.

The size of the Space Shuttle computer memory to bebaselined was significantly at issue in the beginning, withestimates running as low as 24k 32-bit words (k = 1024).Sixty-four thousand words of memory were eventuallyselected as the maximum which could be reasonablyincluded considering the state of the art of computer design

Se.sor I

Sensor ,-.,"-!

State vectorexchange

Computer1

Computer2 _-

Computer3

Computer4 J

Servoamplifiers

IIIIII

II

I!

!I

FIGURE 3-5.--Parallel string approach.

Actuator

Equalization

I Control Iffector


20/82


and vehicle weight, power, and thermal constraints.Memory limitations were a continuing problem throughoutthe early development phases and, as soon as technologypermitted, the size was increased to 104k.

The program participants unanimously agreed that a top-down, structured methodology was the proper designapproach for the Space Shuttle onboard software; however,the use of a high-order language and the selection of anoperating system approach were subjects of significantcontroversy. The NASA had contracted for the develop-ment of HAL/S, a high-order language tailored specificallyfor aerospace avionics applications, but the capability ofit, or any other high-order language, to produce code withsize, efficiency, and speed comparable to those of anassembly language program was questioned. The issue wasresolved after a competition, in which representativesoftware routines were coded by different teams -- oneusing HAL/S; the other, assembly language -- showedthat the approximate 10 percent loss in efficiency resultingfrom the use of the high-order language was insignificantwhen compared to the advantages of increased programmerproductivity, program maintainability, and visibility intothe software. Therefore, the use of HAL/S was baselinedfor all software modules except the operating system.

The operating system approaches in contention were asynchronous concept and a concept in which an asynchro-nous, priority-driven scheme was used. The synchronousapproach afforded repeatability, predictability, andvisibility into system operations, all attributes which easetesting and verification, but at the expense of adaptabilityfor future growth. The asynchronous concept would readilyaccommodate growth but was more difficult to verifybecause it was not as predictable or repeatable. The conceptthat was finally baselined for the primary system softwarewas a hybrid approach which incorporated a synchronousforeground executive structure and an asynchronouspriority-driven background. This approach was consideredto be more readily adaptable to any future requirementswhich might arise.

As indicated previously, data buses were baselined forSpace Shuttle vehicle internal signal transmission; however,a number of design issues remained to be settled in thisarea. Based on advanced development work performed inNASA laboratories, a half-duplex, biphase Manchestercode, l-megabit data bus transmission technique had beenselected but questions were raised as to the reliability ofsuch a system to handle critical messages. Techniques forenhancing message correctness statistics were consideredincluding the use of error-detecting codes such as Bose-Chaudhuri-Hocquenghen (BCH) and an echo or answeringconcept. After an analysis of the predicted word and biterror rates indicated that the basic system coding andmessage protocol would provide more than adequate signalreliability, an approach without additional protection was

baselined for all buses except those which interfaced withthe main engine computers. (A design which used the BCHerror-detecting code had already been baselined for thisinterface.) To ensure continued emphasis on performancein this critical area, the data buses and bus interface deviceswere procured as an integrated system from a single vendor.All other vendors whose subsystems used the data bussystem were furnished these standard interfacing devicesand required to install them in their line-replaceable units(LRU's).

The number of computer input/output (I/O) ports andassociated data buses, and their functional allocation, wasalso the subject of much discussion in the early design phase.The total system bus traffic density could only be grosslyestimated initially, and, because of the catastrophic effectson the system of reaching or exceeding the l-Mbit/sec buslimits, provisions for significant growth had to be included.The uncertainty in this area and the desire for functionalisolation resulted in the baseline 24-bus port configuration,the maximum number which could reasonably beaccommodated in the computer I/O processor. Allocationof these buses was based on a combination of factorsincluding criticality, frequency of use, traffic density, andsimilarity of usage or function.

A summary of baselined requirements and approachescovered in this section includes

A central five-computer complex A 64k memory size A top-down, structured approach to software design Use of HAL/S high-order software language An asynchronous, hybrid operating system approach A standardized data bus system procured as a systemfrom a single vendor, with no Hamming-type error

protection A 24 I/O port and bus system, with functions allocated

by criticality and use

Flight ControlThe circumstances which resulted in the choice of digitalfly-by-wire control and the limitations on the use of manualdirect modes have been described previously. Some otherflight control areas which were at issue during the designphase included the following:

Pilot/system response requirements and handlingqualities

Digital autopilot sampling rates and transport lags Sensor and actuator redundancy and location Entry gain scheduling, moding, and reconfiguration Autoland

10


21/82

SYSTEMDESIGNEVOLUTIONSpecifications,equirements,ndextensivereatmentsfresponseharacteristicshichwouldprovidedesiredhandlingqualitiesor all typesof aircraftwereavailablein the SpaceShuttledesignera, but all dealtwithconventionallyoweredircraftoperatingn thesubsonicor low-supersoniclightregimes.Nospecificationshichtreatedthe requirementsor an unpoweredaircraftoperatingoverthe entireorbitalentrythroughandingenvelopewereavailable.n an attempto establishnintegratedetof suchrequirements,ASAconvenedSpaceShuttleFlyingQualitiesSymposiumn early1971to solicitndustrywidenputsandrecommendations.heseweresubsequentlyublishedn a SpaceShuttleFlyingQualitiesSpecificationndusedasaguidelinehroughoutthesystemevelopment.Someof the choiceswhich directly affectedtheperformancendstabilityof thecontrolsystemncludedtheselectionf digitalautopilotsamplingatesandthe

minimumimedelayor transportagallowableetweenthereceiptof inputsfrommanualcontrolsandvehiclemotionsensorsndheissuancefcommandsothecontroleffectors.Becausehesefactorswerealsofundamentaldriversnthesoftwareesign,articularlyntheoperatingsystem,heselectionsadto be madeveryearlyin theprogram,well beforesubstantivedata on airframeperformancendresponseharacteristicsecamevailable.ThedigitalautopilotxperienceasetthetimewasimitedtothatrepresentedytheApollospacecraft,vehiclewhichhadnoaircraftcharacteristics;herefore,hetendencyasto takea conservativepproachndsetthesampleatesveryhigh-- 50 and 100 hertz were typical values proposed.Because rates of this order would have imposed a severestrain on the computer/software complex, the pressure fromthe data processing community was to lower them as muchas possible. The rate finally chosen was 25 hertz, the sameas for Apollo, with a transport lag limit of 20 milliseconds,values which preliminary analysis indicated would providefor the required phase stabilization margins.

The flight control sensors installed in the Orbiter includedrate gyros mounted on the aft payload bay bulkhead andbody-axis-oriented accelerometers located in the forwardavionics bays. The system was configured initially with threeof each, with the tiebreaker in the event of a second failureto be calculated using data from the inertial measurementunits (IMU's), which were located in front of the forwardbays. This concept proved unworkable for the rate gyrosbecause the distance between the IMU's and the rate gyrosand the structural dynamics involved prevented accuratetransfer of the inertial data. The IMU outputs were alsoinitially baselined to break a tie between diverging signalsfrom the body-mounted accelerometers. Again, the conceptproved unworkable even though the instruments werelocated in the same vicinity, and a fourth string of eachsensor was eventually incorporated.

It was also difficult to find an acceptable location forthe rate gyros in both the Orbiter and the SRB's. An ideallocation would have been at the center of gravity, mountedon structure the motion of which represented the true rigid-body rotation about that point. The nearest viable structurewhich reasonably approximated these conditions was theaft bulkhead of the payload bay. Therefore, the initiallocation of the rate gyro assembly was a mount on eachof the four corners of this bulkhead, physically separatedas much as possible for redundancy isolation. Subsequentground vibration tests uncovered local resonances whichmade these locations unacceptable. The mounting locationwas changed twice before the present position at the centerbase of the bulkhead finally proved acceptable. The desirefor physical separation of the redundant sensors wasabandoned in favor of dynamically identical signals to avoidcompromising the redundancy management selection logic.The rate gyro mounts in the SRB's also had to be modifiedafter vibration tests uncovered unpredicted structuralmodes.The hydraulic actuators used to position the engine

gimbals and the aerodynamic control surfaces were triplyredundant input port devices in the initial baseline. It provedto be very difficult to interconnect four computer-generatedcommands to a three-port actuator in a manner whichwould preserve the FO/FS requirement. The moststraightforward solution was to mechanize four input portsand this configuration was eventually selected.

Design of the entry flight control system was a longand difficult process. The Orbiter requirement was uniquein the high-performance aircraft development process inthat the entire dynamic range of the vehicle from hypersonicthrough subsonic speeds would be encountered on the firstorbital flight. In contrast, in the normal aircraftdevelopment approach, the flight envelope is graduallyexpanded in small, carefully controlled steps. The processwas complicated by large data base uncertainties inpredicted aerodynamic performance, including controlsurface effectiveness and other key parameters; in structuralbending information; and in potential interaction betweenthe RCS thrusters and the aerodynamic control surfaces.The control concept which evolved used RCS thrustersexclusively during very early entry, then gradually blendedin the aerodynamic control surfaces as they became effective-- first roll, then pitch, then yaw -- until approximatelyMach 3.5, when the thrusters were totally deactivated.Transitions between control laws, gain changes, etc.,required because of the wide dynamic range, were scheduledon the assumption of best estimates of vehicle controlresponse and performance obtained from the data base,using cues such as altitude, drag, and Mach number derivedfrom the navigation and air data subsystems. Because ofthe data base uncertainties and because the systems usedfor cues had not yet been flight qualified (e.g., the air data

il


22/82

SPACESHUTTLEAVIONICSYSTEMsystem in particular was subject to large calibrationuncertainties), a means for reacting in real time to off-nominal performance had to be provided to the crew. Threeswitches were installed for this purpose, each affording theopportunity to modify the system if anomalous performancewas encountered. One switch opened the automaticguidance loop and reduced the flight control system gainby 6 decibels. Another selected a control law which didnot require the use of yaw thrusters. The third providedthe option of causing the transition from high to low angleof attack to occur either earlier or later than nominal.

Backup SystemAs indicated previously, the Space Shuttle mission was notamenable to degraded backup system mechanizations, and,initially, no backup to the four-computer, four-string, FO/FS avionics configuration was included. Eventually,however, considerations of potential generic software errorswhich could affect all four computers, and concern overthe complexity of the primary system with its closelycoupled, tightly synchronized approach forced a new lookat the possibility of a backup. Constraints imposed on thisinvestigation were that a backup system should in no waydegrade the reliability or performance of the primarysystem, and that no significant crew training impact shouldresult from the mechanization. The result was a conceptwhich used the fifth computer, loaded with unique,independently developed and coded software capable ofsafe vehicle recovery and continuation of ascent or safereturn from any mission situation. A redundant, manualswitching concept was devised by which control of allrequired data buses, sensors, effectors, and displays wastransferred to the single backup computer.

Redundancy ManagementThe Space Shuttle Program pioneered the developmentof modern redundancy management techniques andconcepts. Although previous space programs used backupsystems, they were usually dissimilar and generally degradedin performance with respect to the prime syste m . Themission dynamics for the vehicles in these programs weresuch that active/standby operation with manual switchingwas adequate. Virtually all system functional assessmentwas performed on the ground using telemetry data. Onlyinformation required for immediate switchover decisionsor other such actions was presented to the crew. The SpaceShuttle system, however, presented a much differentsituation to the designer. The FO/FS requirement, the drivetoward onboard autonomy, and the rapid reaction timeswhich prohibited manual assessment and switching werefactors that had never before been seriously considered.In addition, the avionics system was required, for the first

time, to assess the performance and operational status ofand to manage the redundancy included in nonavionicssubsystems such as propulsion, environmental control, andpower generation. As might be expected in such a situation,numerous design issues arose, a number of false designstarts had to be overcome, and a process thought initiallyto be relatively simple proved to be extremely complexand troublesome. Many of these issues are discussed inother sections as part of the treatment of individualsubsystems and functions. Only the more general,comprehensive topics are included here.

The initial concept for managing redundant units wassimply to compare redundant data, discard any input whichdiverged beyond an acceptable threshold, and select themiddle value if there were three good inputs (or the averageif only two were available). The keyword in this sentenceis "simply," for virtually nothing proved to be simple orstraightforward in this process. First, measures had to betaken to ensure that the data set to be compared was timehomogeneous, that each value was valid from a data buscommunication aspect, and that the data were valid in thesense of a tactical air navigation (tacan) lockon. Theselection process had to be capable of correctly handlingfour, three, two, or even single inputs, and of notifyingthe user modules or programs of the validity of the resultantoutput. The fault-detection process had to minimize theprobability of false alarms while maximizing the probabilityof detecting a faulty signal; these two totally contradictoryand conflicting requirements made the selection of thethreshold of failure extremely difficult. The fault isolationand recovery logic had to be capable of identifying a faultyunit over the complete dynamic range to be experiencedin the data, of accounting for any expected unique orpeculiar behavior, and of using BITE when faulted downto the dual-redundancy level. Finally, the system had toaccommodate transients, degrade as harmlessly as possible,and provide for crew visibility and intervention asappropriate.

It soon became apparent that each LRU, subsystem, andfunction would have unique redundancy managementrequirements and would therefore have to be treatedindividually. It also became apparent that, to provide therequired emphasis and expertise, redundancy managementwould have to be treated as a function and assigned toa design group with systemwide responsibility in the area.Some of the more difficult design issues faced by this groupare explored in the following paragraphs.

As indicated previously, the selection of thresholds atwhich to declare a device disabled proved to be a verydifficult process. In an attempt to minimize false alarms,performance within 30, of normal was established as theallowable threshold level for a parameter and V_ 30,as the allowable difference between compared parameters.In most cases, however, the standard deviation r had to

12

il lii


23/82


be derived analytically either because of insufficient testdata or because the hardware test program was notstructured to produce the required information. In someother cases, the system performance requirements precludedoperation with an input at the 3t7 level and the tolerancehad to be reduced, always at the risk of increasing thefalse alarm rate.

Another task that proved difficult was mechanizationof the fault isolation logic for system sensors such as rategyros which, during the on-orbit phases, normally operatedclose to null. Under these conditions, a failure of a unitto the null position was equivalent to a latent failure andproved impossible to detect even with quadruple redun-dancy. It could subsequently result in the isolation of afunctioning device, or even two functioning devices if twoundetected null failures occurred.

The first remedy for this anomaly prevented theerroneous isolation but resulted in a significant increasein RCS fuel usage, caused by frequent switching betweenselected signals which effectively introduced noise into theflight control system. The final solution, which preventedthe anomalous performance, was immensely more complexthan was the original "simple" approach.

The redundancy management design process followedinitially was to treat each system and function individually,tailoring the process to fit, then proceeding on to the nextarea. This compartmentalized approach proved inadequatein a number of areas in which the process cut across severalsubsystems, functions, and redundancy structures. A primeexample is the RCS, which contains propellant tanks,pressurization systems, manifolds and associated electricallyoperated valves, and 44 thrusters used for flight control.The thrusters are divided into four groups, any two ofwhich are sufficient to maintain vehicle control about allaxes in all flight conditions. The other components (tanks,manifolds, valves, etc.) are also structured for faulttolerance. Each of the thruster groups and associatedmanifold valves is managed by one of the four redundantavionics strings. Layered on top of this already complexstructure are the three electrical power buses, whichdistribute power throughout the system; the dualinstrumentation system, which contains a number of thesensors that provide insight into certain aspects of systemoperation; and the displays and controls required for crewmonitoring and management. The redundancy manage-ment logic must detect and isolate thrusters that are failedoff, failed on, and leaking. Depending on the type of failuredetected, the system must command appropriate manifoldvalves to prevent loss of propellant or any other dangerouscondition.

Obviously, a compartmentalized approach to theredundancy management design would have been inade-quate for this system. Even with the comprehensiveapproach, employed by the task group in an attempt to

cover all aspects of system operation, the design has beenrepeatedly refined and augmented as ground test and flightexperience uncovered obscure, unanticipated failure modes.

Onboard System ManagementOne of the goals of the Space Shuttle Program was tolower operating costs by eventually reducing the size andscope of the ground support team required, in all previousprograms, to monitor and assess spacecraft and subsystemperformance and functionality. To accomplish this goal,however, meant that major portions of a task, hithertoperformed by hundreds of specialized experts, would haveto be performed onboard by a relatively small crew alreadybusy with mission operations and experiment support. Amajor challenge facing the Space Shuttle designers,therefore, was to devise an approach which wouldaccommodate the onboard system management require-ment but which would not overwhelm the flightcrew.Further, the design would have to provide initially for fullground support capability with an orderly transition ofthe function onboard as the capability became validatedby flight experience.

It quickly became obvious that the only way to avoidovertaxing the crew would be to automate much of thesystem monitoring and assessment task. Because thecomputational requirements could only be grossly estimatedinitially, the capability of the central computer complexto assimilate the load was questioned. Therefore, a tradeoffstudy was conducted to determine the relative merits ofan integrated approach versus a separate, independentcomputer dedicated to system management. A corollaryissue involved the data acquisition process. On previousprograms, only that information required by the crew tooperate the spacecraft or to respond to emergencies wasmade available onboard; the rest was reduced and analyzedon the ground. The traditional approach to onboardinstrumentation was to install a network of sensors,transducers, pickoffs, and signal conditioners together witha telemetry processor, which acquired, formatted, andmultiplexed data for transmission to the ground. The dataset thus acquired contained all of the information requiredto perform a system assessment, but, because theinstrumentation network was overlayed on and essentiallyindependent of the onboard operating systems, many ofthe measurements were accessible only on the ground. Forthe Space Shuttle, provisions had to be made to makeall required data accessible onboard as well.

Two computation and data acquisition options wereexamined. (See fig. 3-6.) In alternate l, the traditionalinstrumentation system was augmented with the necessarycomputational resources to provide an essentiallyindependent capability. In alternate 2, the data wereprovided to and assimilated in the operating avionics system

13


24/82


Alternate I

I Dedicated _isplay System Hmanagement

computer

Downlinkdata only

_jL_ _eneral-_purpose Idisplays )

Alternate 2

IPCMmaster

unit-T

(Baseline)

IIii _lAvionicssystem

computers

Communication Isystem ]1PCM

masterunit

Data buffersDownlinkdata

Generapurpse Idisplays.,)

System managementdata

I , I I IAvionicssystem

computers

Instrumentationsensors/signalconditioners

Operational sensors/effectors

Instrumentationsensors/signalconditioners

Operational sensors/effectors

FIGURE 3-6.--System management approaches.

14

!1 i]i


25/82


and its computer complex. The difficulties involved inintegrating another computer, the associated controls, andthe required displays into the system discouragedconsideration of a separate approach, and the problemsof providing the necessary additional data to the operatingsystem were also difficult to resolve. The design finallychosen, alternate 2, was to install data buffers in theinstrumentation telemetry processors which could beaccessed by all the central computers and thereby wouldprovide a source for those measurements not alreadyavailable in the operating systems. The system managementfunction was initially relegated to the fifth computer inthe central complex, the one not included in redundant-set operations. As the system matured, however, many ofthe system management functions proved to be critical andwere transferred to the redundant complex.

Means for assessing and condensing the information intoa reasonable set which could be readily assimilated andacted on by the crew remained as another issue. Critical-function management was incorporated into the redundantset, and automatic failure detection and response weremechanized where appropriate.

Overall system monitoring was accomplished bycomparing the sensed valued of selected measurementsagainst preset upper and lower limits, and, dependingon the urgency, either switching to an alternate path orannunciating the situation to the crew for appropriateaction. Cathode-ray-tube (CRT) display pages devised foreach subsystem provided quick and concise monitoringcapability. Other crew assistance features which wereconsidered included switch monitoring to assure that thecorrect system mode and configuration for a givenoperational situation were established, communicationsantenna management controllable either from the groundor onboard to ensure optimum coverage with minimumcrew involvement, and an extensive caution and warningsystem to provide alerts for any abnormal situation.

NavigationSeveral issues and design choices were addressed inarriving at the Space Shuttle navigation system baseline.One of the most controversial was the selection of aninertial measurement system. The two options consideredwere a system with triply redundant, mechanicallygimballed platforms, and a strapdown approach, whichincluded six skewed gyro/accelerometer pairs oriented toprovide multiple fault detection and isolation capability.At the time, several gimballed systems that could meetSpace Shuttle requirements with some modification werein production. Although no six-gyro strapdown systemswere in production, one existing design was fairly mature,and this approach appeared to offer significant advantagesfrom a system redundancy aspect. The final selection of

a gimballed system was based on such factors as maturity,the number of near-production designs available, and thepredicted cost of the respective gyros.

Triple redundancy was baselined in this area becauseearly analyses indicated that a system with three IMU'scould achieve full FO/FS fault tolerance. The first failurein such a system would be detected and isolated in thestandard manner by comparisons among the three units.The scheme proposed to isolate the second failure is shownin simplified, two-dimensional form in figure 3-7. Itinvolved skewing the inertial platform alignment of eachunit with respect to the others so that each gyro andaccelerometer in the system would sense inputs about oralong a unique axis. By this means, an input sensed bya single gyro or accelerometer in one platform could becompared with a composite value constructed fromcomponents along the same axis sensed by a combinationof instruments in the other platform. By making a seriesof such comparisons with different combinations ofsensors, it appeared possible to identify a malfunctioninginstrument. As the system matured, however, and analysesand test data accrued, it became apparent that certainobscure failures at the dual-redundancy level could notbe isolated. Therefore, a number of attempts were madeto raise the redundancy level to four. The problem wascomplicated, however, by the fact that the IMU's andthe star trackers used for their alignment had to bemounted on a common, rigid structural member in alocation which would provide the required optical lookangles and adequate clearance for doors and associatedmechanisms. The location which had been chosen, just

Xl Skewed

I ,_...._ gyro input axes2 _ Y2

Equivalent sensedrotation about Xl

IMU 1 IMU 2FIGURE 3-7.--Skewed IMU approach.

15


26/82

SPACESHUTTLEAVIONICSYSTEMforward of the cockpit with the star tracker door openingsin the upper left area of the fuselage, was optimum butunfortunately did not contain enough volume toaccommodate a fourth unit of the size then available.One alternate location, on the upper corners of theforward payload bay bulkhead, was briefly examined butdiscarded because of alignment problems and thedifficulty in providing an adequate structural mount.Another aIternative, in which an additional IMU wouldhave been mounted inverted under the existing structure,would have forced the relocation of other equipment withexcessive cost. Therefore, the decision was made to keepthe triply redundant baseline but to make every attemptto reduce the probability of exposure to a second failureto an acceptable level, One measure taken was to exploitthe use of IMU BITE to the maximum. This measurealone provided the capability to detect as many as 90percent of all failures. Another technique, used duringentry, was to integrate rate gyro outputs to provide anadditional attitude reference. The result, when consideredin terms of the relatively short periods of exposure duringascent and entry and of the remote possibility that a secondfailure would be of the precise type which would escapedetection, was considered to be a safe and satisfactorysystem.

The selection of an on-orbit navigation system alsoproved to be a difficult process especially in view of theOrbiter autonomy requirement. No operational sensor orsystem which could meet accuracy, coverage, andautonomy requirements was available. The Departmentof Defense (DOD) Global Positioning System (GPS) wasonly in the initial phase of development, and no assurancecould then be given that the project would be completed.Several other concepts were investigated, including onecalled the precision ranging system (PRS), which wouldhave used onboard distance measuring devices operatingwith a network of transponders distributed on the groundat strategic locations around the world and in the vicinityof the landing sites. Several studies conducted showedthat, given the required number and locations oftransponders, a PRS could easily meet all Space Shuttlenavigation accuracy requirements. To adopt such asystem, however, meant that NASA would have to installand maintain the dedicated worldwide network.In another concept, the RF emissions from ground-based radars located around the world would have been

tracked to obtain angular data from which a state vectorcould have been constructed. This system also had promisebut would have required the development of onboardelectronics equipment which was extremely sophisticatedfor the time. The technique finally chosen was to makethe ground-Orbiter-ground communications link coherentand thereby to provide the capability to precisely measurethe Doppler shift in the carrier frequency and to obtain

an accurate time history of relative range rate betweenthe spacecraft and a ground station. From this informa-tion, the vehicle state vector could be constructed. Thesystem was originally mechanized so that the Dopplerinformation could be extracted both on the ground andonboard. Later in the program, the ground was madeprime for on-orbit navigation and the onboard capabilitywas deleted. The realization of autonomous on-orbitnavigation was left to the GPS.

The issues involved with rendezvous navigationconcerned both performance and mechanization. Nodefinitive rendezvous targets or their characteristicsexisted; therefore, radar performance requirements weredifficult to specify. Finally, after much debate, it wasdecided that the capability should be provided to acquirerange and angle data from both cooperative anduncooperative targets and that the performance shouldbe that reasonably available from state-of-the-art solid-state devices. The mechanization finally chosen was toincorporate the radar in the Ku-band communicationssystem, which required a high-gain directable antenna andother components which could service both radar andcommunications functions.

The system selected to provide navigation for thepostblackout entry phase was the DOD tactical airnavigation system network. This choice was made onlyafter much deliberation because tacan performance wasneither documented nor specified above 12.2 to 15.2kilometers (40 000 to 50 000 feet) and the Space Shuttlerequirement extended to an altitude of approximately 42.7kilometers 040 000 feet). Analytic performance predic-tions and laboratory test results indicated that perform-ance would be satisfactory, however, and three off-the-shelf transceivers, modified as necessary to interface withthe onboard data processing system, were baselined.Triple redundancy was considered adequate because ofthe short period of exposure and because the ground couldprovide some assistance if two failures occurred.

The predominant navigation aids in place at the timefor the final approach and landing phase were the FAAILS and the USAF ground-controlled approach (GCA)system; however, both the performance and the coverageprovided by these systems were deemed inadequate forthe type of approach to be flown by the Space Shuttle.The FAA was considering an upgrade to a precisionmicrowave landing system, but no firm schedule existed.Precision microwave systems also under development byDOD would meet Space Shuttle performance andcoverage requirements, and a variation of one of thesewas chosen, again modified to interface with the DPS.Triple redundancy was considered sufficient for thissystem also, both because of the short exposure andbecause the pilot could take over visually under mostexpected conditions.

16

;'1 :I l l


27/82


Display and ControlThe major challenge facing the designers of the SpaceShuttle cockpit was to integrate all the controls anddisplays required for operation of the vehicle and itssubsystems into the space available, within_ the reach andvision of the crew as appropriate for each mission phase.Some of the basic requirements imposed were

Safe return with a single crewman from eitherforward station

Normal operation, except payload management,with a crew of two

Accessibility from the two forward stations of allcontrols and displays required for ascent and entry

Provisions for manual override of automated criticalfunctions

Crew selection of automatic or manual flightguidance and control

Means to annunciate faults in and to command satingof hazardous systems

In addition, the system would have to provide for bothspace flight and aircraft aerodynamic flight, a first in themanned space program. In the early design phases, thecontrols required for these two flight modes were thoughtto be so incompatible that consideration was given toincorporating two separate cockpits, one exclusivelydevoted to and equipped for aerodynamic flight, the otherfor space operations. The program could not afford thecost, complexity, and inefficiency of such an approach,however, and a single, integrated, two-man forwardcontrol station was baselined for both regimes. The aftportion of the upper cockpit, because of visibilityadvantages looking up, aft, and into the payload bay area,was equipped with controls and displays sufficient foron-orbit proximity and payload operations. Despite theintegrated approach, however, dedication of some devicesto one or the other flight regime could not be avoided.The preferred pilot input devices for aerodynamic flightwere a traditional control stick (or yoke/wheel) andrudder pedals. For space flight, three-axis hand controllersfor attitude and translation control were desired. Aftermuch deliberation and many simulations, the decisionwas made to adopt a variation of a side-arm controllerwhich would provide pitch and roll input capability inthe aircraft mode and pitch, roll, and yaw inputs in thespacecraft mode. These devices were located in thestandard aircraft position between the pilot's and copilot'slegs, situated to provide clearance for ejection, a capabilityincluded on early flights. Rudder/brake pedals, activeonly in the aerodynamic mode, were included to provideyaw inputs and to apply the wheel brakes. Other devices

dedicated to aerodynamic flight included the speed brakeand body flap controls. A three-axis translation controllerwas included to provide on-orbit maneuver capability.Most displays served a dual or universal purpose;however, some, such as air data, the radar altimeter, andthose associated with navigation aids, became active onlyafter blackout.The display and control concepts proposed very early

in the program included extensive use of multifunctionCRT's, reformattable control panels, multipurposekeyboards, head-up displays, and limited use of dedicatedswitches and circuit breakers. The technology involvedwas then at the leading edge of the state of the art foraerospace systems, however, and, because it appeared thatmore conventional approaches would suffice, the decisionwas made to use off-the-shelf equipment whereverpossible. The system which evolved, therefore, containsan extremely large number and variety of components.Control devices include toggle, pushbutton, thumbwheel,and rotary switches; potentiometers; keyboards; circuitbreakers; and hand controllers. Displays include circularand vertical meters, tape meters, mechanical talkbacks,annunciators, flight control meters, electromechanicalposition and attitude indicators, digital readouts, andCRT's. The four CRT's in the final design incorporatemultifunctionality but to a much smaller degree than thosein the original concepts.

CommunicationsThe Space Shuttle communications design communitywas faced with a variety of requirements, many conflicting,and many unique to or faced for the first time in theSpace Shuttle Program. The network communicationssystem had to accommodate voice, command, and datatraffic with the NASA Ground Spaceflight Tracking andData Network (GSTDN), with the USAF Space GroundLink System (SGLS), and with NASA Tracking and DataRelay Satellites (TDRS's) in geosynchronous orbit. Thedownlink data to be accommodated ranged from real-time operational telemetry to television to wide-bandpayload/experiment data. Because the Orbiter wouldoperate as an aircraft in atmospheric flight, the systemwould have to provide for air traffic control (ATC) typeinterfaces from postblackout through landing. Alsobecause of the operation in the atmosphere, all antennashad to be either flush-mounted under the thermalprotection system or deployable on orbit and retractablefor ascent and entry. Other factors which influenced thedesign included requirements for communicationssecurity, all-attitude operation, coherent Doppler fornavigation, voice and data links to an extravehicularastronaut, text and graphics uplink, active and passivetracking of satellites for rendezvous, and extensive remote

17


28/82

SPACESHUTTLEAVIONICSYSTEM

control capabilityfrom the groundto reducecrewworkload. In addition, the always overriding requirementsto minimize weight, power, volume, and complexity andto use off-the-shelf equipment were present andcontributed to the system configuration.

The GSTDN and SGLS networks both operate at S-band frequencies with direct ground/spacecraft/groundlink performance requirements similar to those encoun-tered on previous low Earth orbit missions. The TDRSoperates at both S-band and Ku-band frequencies butwith much more stringent link performance requirementsbecause of the distances, look angles, and dynamicsinvolved in operations with a synchronous orbitcommunications terminal. Off-the-shelf S-band trans-ponders which would have allowed operation with eitherground network were available, but none could meet theTDRS link margin requirements. Because the requirementexisted for communications coverage during ascent, on-orbit, and entry phases when out of sight of groundstations and operating with the flush-mounted, low-gainantennas, the decision was made to develop new S-bandhardware which would provide for basic operationalvoice/command/telemetry traffic through either groundnetwork or the TDRS using an integrated onboard system.

The basic Space Shuttle operational network commu-nications requirement called for voice channels (up anddown), an uplink command channel, a telemetry downlinkchannel, two-way coherent Doppler for ground naviga-tion, a ground ranging capability, and provisions forcommunications security. The stringent TDRS linkperformance requirements, exacerbated by the low-gainantennas, drove the system to an all-digital signal designusing time-division multiplexing (TDM) to integrate thevoice and command or data channels into a commonbit stream. An adaptive delta modulation technique usinga modified version of the ABATE algorithm was chosento digitize the voice channels after extensive in-houselaboratory tests showed that this method maintained highword intelligibility with reasonable voice quality atminimum sampling rates in the presence of very highchannel errors. To achieve optimum performance on thesedigital channels, a phase modulation (PM) system wasdeveloped which included one or two voice channelsmultiplexed with an encoded 8-kbps command channelon the uplink or with a 128- or 64-kbps pulse codemodulated (PCM) telemetry bit stream on the downlink.To maintain adequate circuit margins and bit error ratesat these data rates for the Space Shuttle/TDRS link, itproved necessary to develop a 100-watt traveling wavetube power amplifier transmitter and a low-noisepreamplifier receiver, both of which pushed the state ofthe art, and to employ sophisticated error-correctingchannel-encoding techniques. After a series of tradeoffstudies, convolutional encoding and Viterbi decoding were

selected to optimize the link. Phase-shift keying (PSK)was also selected to optimize channel performance witha Costas loop to provide for carrier reconstruction anddata recovery on both forward and return link signals.To provide accurate Doppler data which would allowthe ground control center to determine and maintain theSpace Shuttle ephemeris, the S-band uplink and downlinksignals were made coherent. Range tone turnaround wasincorporated to provide a direct ranging capability atGSTDN stations for ascent and postblackout entry statevector determination. An additional constraint on thesystem was imposed by international agreements whichspecify the maximum allowable power flux densityreceived at the Earth's surface from an orbiting satellite.To avoid exceeding this limit on the TDRS to Orbiterlink, it proved necessary to develop a direct-sequencespread-spectrum signal design using pseudorandom noise(PN) code modulation.

The Space Shuttle/ground direct S-band link was alsorequired to accommodate wide-band telemetry data fromthe main engines during ascent, data dumps from onboardrecorders, payload data (analog data up to 4 megahertz,digital data up to 5 Mbps), and video from the onboardtelevision system. Because these types of data were notamenable to incorporation into the limited-rate PCMtelemetry data stream described previously, a separateS-band system was developed for this purpose usingfrequency modulation (FM) and an independent signalprocessor, transmitter, and antennas.

Initially, the communications and data requirementsof the payload community were either unknown orappeared totally open ended. A major mission of the SpaceShuttle was to service, deploy,