spageshuttle low cost/risk ^vionjcs study€¦ · cable set -1 set remote control coupler - 2 sets...

B35-43RP-26CONTRACT NAS 9-11160

MODIFICATION 9S

SPAGESHUTTLELOW COST/RISK

^VIONJCS STUDY

FINAL REPORT12 November 1971

MSC-03818

GRU(VltVIAI\l'|BOEirsiG

https://ntrs.nasa.gov/search.jsp?R=19720011222 2020-05-03T02:47:31+00:00Z

SPACE SHUTTLELOW COST/RISK

AVIONICS STUDY

FINAL REPORT12 November 1971

GRUMMAN/BOEING

PHILCO FORD

INTERMETRICS

GE

RCA

RADIATION, INC.

SPERRY

LITTON

EASTERN AIRLINES

HAMILTON STANDARD

BENDIX

X83)

3

DEVELOPMENT SCHEDULE

FHF Subsystems Design

Qual Tests

Mk I Subsystems Design

Mk I Qual Tests

Mk II Subsystem Design

Mk 11 Qual Tests

'72 '74 I 76 '78 '80 '82 I '84

A AFHF FMOF

Mkl

AFMOFMkl I

For the purpose of pricing the life cycle costsof the low cost avionics system, we examined all WorkBreakdown Structure elements that contain anyavionics related effort.

In addition to the basic "onboard" avionicsand electrical power systems, the vehicle WBS in-cludes the analytical, testing, and integrationeffort for these systems. The design and pro-curement of special test equipment and main-tenance and repair equipment is included in SystemsSupport.

The Program Management associated with theabove efforts has also been included.

The Flight Test WBS includes flight testspares and all labor and materials associated withthe operations and maintenance of the avionicssystems throughout the horizontal flight testprograms.

Operations includes the same type of effortfor the operational phase based on the trafficmodel specified by Technical Directive GAC-4.

SHUTTLE AVIONICS WBS

'

1 1Orbiter Booster

j1

Avionic HardwareOn-Board Software

Elect. Pwr SystemSystems Integration

Systems Engineering

Systems SupportManagement

Other Subsys Interfaces

SpaceShuttle

1

Main Eng Fit Test

'ype of Effort

• Maintenance

• Spares

• Fit Test Support• Data Acquisition• Data Reduction

1Ops

MaintenanceSpares

Launch SupportMission SupportData Acquisition

Data Reduction

To provide NASA with costs which may becompared between contractors and between alter-nate configurations, we made every attempt tostandardize costing "ground rules" and assump-tions.

The accompanying table summarizes thekey assumptions that were used.

These ground rules and the program masterand sub system schedules were supplied to thesubcontractors who estimated specific equipment,to assure uniformity of response.

Several subcontractors indicated that therecould be substantial savings realized through alearning curve, but this impact cannot beassessed at the present time.

10

KEY COSTING ASSUMPTIONS

• Constant 1970 Dollars

• No Learning Curve

• Cost Through G&A • No Fee/Profit Included

• Fleet Size - Orbiter 2 + 3 Booster 2 +2

• Traffic Model per Tech Directive GAC-4

• Commonality - Development Charged to Orbiter• Hardware to Each Vehicle

• Detail Costs for Recommended Configuration Only

The costs of the hardware for the first two

flight articles are included in the Mk I column for

the orbiter and the DDT&E column for the booster.

Orbiter Mk II includes only those development

changes for the additional or unique Mk II hardware

and software.

"Production" includes the costs associated

with the 3rd, 4th, and 5th orbiter, and 3rd and 4th

Flyback booster. In the case of the orbiter it in-

cludes the Mk II hardware for these three vehicles,

but not the retrofit Mk II hardware for the first two

flight articles. (Retrofit costs have been included in

this study in another WBS, and do not appear on

this chart.)

12

LOW COST AVIONIC EQUIPMENT, $M

GN&CData Mgmt

Instrumentation

TelecomDisplays &ControlsSubsys Integ

Software

Total Avionics

Elect. Power

(Subtotal)

Total Vehicle

OrbiterDDT&E

Mkl

40.1

23.6

22.2

12.6

31.7

24.9

36.7

191.8

71.2

Mkll

——

— .

6.3

5.0—

10.7

22.0

285.0

Prod.3Veh

15.111.1

6.511.8

13.7

18.3-

76.5

17.5

94.0

379.0

FlvbacDDT&E

26.24.7

12.5

1.1

6.23.56.7

60.9

59.0

119.9

( BoosterProd.2 Veh

6.81.17.60.5

3.01.90.4

21.3

10.0

31.3

151.2

Ballistic BoosterDDT&E

3.7

3.7

.5

4.2

Prod.

46 Veh

67.1

67.1

.6

67.7

71.9

13

This chart summarizes the "onboard" hardwareand software costs.

Alternate booster configurations are shown.The orbiter configuration is the same for eitherbooster. Both development and production costsare shown for both vehicles.

Comparison has been made with the Phase Bbaseline. This base line has been adjusted from thefinal report to reflect the addition of the fifthorbiter and fourth booster.

14

LOW COST AVIONICS AND PWR COSTS - DDT&E/PROD

1057

$M

10-

8-

6-

4 -

2-

n

Bstr<

Orb.<

163*1 Uw

Prod. _ _ .

-*• '*Prod

^390DDT&E

V 53° ^31

432x DDT&E

120

94__

"285

^

68 -^H451

.»•_ ^m

94

285"

-4-4

Phase BR-S-IC BRB

"Adjusted for Three (3) Product/on Orbiters.

This chart compares the low cost avionics con-figuration to the Phase B on an annual fundingbasis.

To achieve a better comparison, the Phase

B baseline Option A was respread to conform tothe present program schedule. This respread showsthe "double hump" characteristic of the Mk I/

Mk II concept with delayed production articles.

The total area under the curve is that

shown in the previous chart.

16

LOW COST AVIONIC AND POWER ANNUAL FUNDING

$M

140-

120-

100-

80-

60-

40-

20-

$64MA

v FMOFMkl

FMOFMkll

B W/5-Yr Delay (DDT&E to FMOF $822M)

HO(Mkl/ll)/FlybackBstr(DDT&E to FMOF $485M)

HO (Mk I/ID/BRB•v (DDT&E to FMOF $369M)\

\ \v x \ \\\ v x *~ •-*.

\X ^^".V^ N

CY 72 73 74 75T76 77 ' 78 79 80 81 82 83 84

FY ' 73' 74 ' 75 ' 76 ' 77 ' 78 ' 79 ' 80 ' 81 ' 82 ' 83 ' 84 '

17

The weight increase of the low cost-risk

avionics over the Phase B avionics is due to the use

of existing hardware, dedicated computers (aero-

flight control, air data, primary and data acquisition

controller), conventional power conditioning and

distribution, and data busing for data acquisition

only. In addition, degraded and dissimilar backup

capability has been provided.

The R-SI-C booster avionics utilizes much of

the same hardware as the orbiter to take advantage

of the cost savings achieved by commonality. The

higher booster weights are due to the additional

surface controls, the stability augmentation, the

greater number of air breathing, and rocket engines

required for a larger vehicle.

The BRB avionics is a reduced complement of

equipment because it is unmanned and recovered in

the ocean. An additional 75 Ib of avionics onboard

the oribiter is required to interface with the BRB.

18

WEIGHT COMPARISON, MK I

16-1

12-

I8-

4-

Avionics• GN&C• D&C• Communication• Data Management• Operational Instrumentation

4510

5302

Conv

Booster

Orbiter

8840

Avionics(890)

7710

f. Cony & Dist/,

Dist

1700

7785

PhaseB R-S-IC BRB

WHAT DID WE LEARN?

Cost Savings Can Be Achieved By:

• Using Existing Hardware to

- Reduce Cost Risks

- Reduce Developmental Costs

- Achieve Production-Run Cost Breaks

- Minimize Support Costs for Life of Equipment

• Maximizing Orbiter-Booster Commonality

• Specifying New Equipments to MIL Quality Standards

• Basing Redundancy on Cost Effective Analysis

• Minimizing Software Complexity-Reduce Cross Strapping & Computer-Managed Functions

• Utilizing Compilers & Floating Point Computers

• Evolving the Design as Dictated by the Horizontal Flight Test, Mk Iand Mk II Schedules

Peak Funding Reqmts can be Minimized by Growing the System CapabilityFrom That Needed for Horizontal Flight Test Reqmts Through Mk I & Mk II.

20

UNMANNED FLIGHT TEST

OBJECTIVE: Man Rate Vehicles for Vertical Flight Test Program

MISSION PHASES: Boost, Orbit, Reentry, Landing

ASSUMPTIONS & GROUND RULES:

• Minimum Impact to Mk I Hardware

• All Objectives Can Be Accomplished in One Orbit

• Unmanned Landing Capability Demonstratedin Horizontal Flight Test Program

• No Special Ground Tracking or Support Equipment Required

• No Single Failure Shall Result in Mission Failure

• Weight is Not Constraint

• Launch at Cape Kennedy

• Landing Site Restricted to Edwards or White Sands for the Orbiter

• Launch Abort Requires Range Safety Destruct

21

The block diagram shows the unmanned flighthardware required and how it interfaces with theMk I avionic equipment. The switching functionsare provided by two Program Couplers similar tothe Program Coupler developed for the unmannedLM flights. The two couplers provide a total capa-bility of 256 switching functions which is adequatefor the presently identified 208 functions plus somegrowth capability. The Program Couplers are es-sentially relay matrices controlled either by an auto-matic sequence under computer control or bydirect commands via uplink from the ground. Onecoupler is provided for the switching functionsassociated with the space portion of the flight andis under direct control using the existing S-bandcommand link. The second coupler provides theswitching functions associated with the atmosphericportion of the flight and is under direct control ofa UHF command link provided especially for theunmanned flight.

A remote control coupler has been provided

in order to obtain remote flight control capabilityduring the atmospheric portion of the flight. Thecoupler receives commands from the computerfor automatic flight control and from the UHFcommand link for remote control. The remotecontrol coupler provides commands to the aerody-namic flight control computer and the auto throttleand auto braking electronics to control the vehicle.

A Range Safety Receiver and Decoder is pro-vided to activate a destruct system which will destroythe vehicle upon ground command. This systemmust be secure in order to prevent accidental activa-tion but must also be reliable to insure operationin the event of an emergency.

The booster modifications necessary for anunmanned flight are essentially the same as for theaerodynamic portion of the orbiter system. Thelower half of the diagram defines the avionics changesnecessary for unmanned booster flight .

22

UNMANNED FLIGHT CONFIGURATION BLOCK DIAGRAM

i 1 r'i S-Band . i S-Band |

Uplink Decoder

Space ControlFunctions

— ~ —Mark I Baseline EquipmentSpecial Equipment for UnmannedFlight

ORBITER SPACE , Primary

ORBITER AERO/BOOSTER ~* ComputerNewSoftware

Range SafetyRcvr/Decoder

DestructS/S

23

This chart time phases the delta costsassociated with an unmanned launch of theorbiter.

The higher cost curve represents anunmanned orbiter launched with a flybackbooster which is also assumed to be un-manned. The lower curve represents an un-manned orbiter launched with a ballisticbooster which, by definition, is designedto be unmanned.

Note that these costs cover only the"on board" "black boxes" associated withunmanned flight. Launch, ground tracking,and automated landing complexities havenot been costed for either hardware orsoftware impact.

The additional hardware for the unmannedconfiguration has been estimated based on similardevelopments on other programs. The followingtable gives a breakdown for the orbiter and boostermodifications.

Orbiter

Program Coupler - 4 setsDigital Command Decoder - 3 setsUHF Command Link - 2 setsAuto Throttle Electronics - 2 setsAuto Braking Electronics - 2 setsPower Distribution Panel - 1 setCable Set -1 setRemote Control Coupler - 2 setsRange Safety Destruct System - 1 set

Booster

Program Coupler - 2 setsDigital Command Decoder • 2 setsUHF Command Link - 2 setsAuto Throttle Electronics - 2 setsAuto Braking Electronics - 2 setsPower Distribution Panel - 1 setCable Set -1 setRemote Control Coupler - 2 setsRange Safety Destruct System -1 set

24

UNMANNED VERTICAL FLIGHT TEST

$M

Considerations Not Costed:

• Cable Interface Technique

• Landing Site Requirements

• Remote Landing Technique

(Ground Control vs Chase Plane) Both Flyback Booster& Orbiter UnmannedS14.7M

Unmanned Orbiter &BRBS8.4M

72 ' 73 ' 74 ' 75 ' 76 ' 77I* Y

72 ' 73 74 75 ' 76FY

77 78

25

The Grumman/Boeing Low Cost/Risk Avionicsaccomplished the separation of functions by selectionof dedicated hardware for many critical functionsrather than the adoption of a complete inflexible"firewall" approach. Physical separation into twodedicated crew stations was considered but discardedin favor of selective functional separation. Thispermits the retention of an economical two-mancrew, without relinquishing the essential backupthey provide for each other.

A sharp cleavage is maintained, however,throughout the Avionics Subsystems between theaircraft and spacecraft equipment mechanization,through the use of separate dedicated systems. Thisapproach permits FHF and subsequent early flight

tests to proceed without being saddled with thenecessity of providing, and operationally maintain-ing, an additional complex spacecraft system withaccompanying software not relevant to this portionof the test program. As indicated, the primary flightcontrols, communications and landing aids are servedby separate equipments. The Power DistributionConditioning and Control, battery, data acquisition,some G&N common mode functions such as the IMU,primary computer and the associated display and con-trol functions are common for both flight regimes.Major deviations from the separation concept includethe use of a modified conventional aircraft electro-mechanical FDAI display to include a spacecraftattitude display mode and also the dual purpose useof the sidearm controllers.

26

ORBITER SEPARATION OF FUNCTIONS MK ILOW COST/RISK SYSTEM

Subsys

FlightControl

Guid&Nav

Airplane

• Dedicated AeroDigital Autopilot

c Elect. Backup System• ABES Control Elect.

• Subsonic AirData Sensors/Computer

• AHRS(FHFonly)

Common

• MSFN• IMU• Pri Computer• TACAN

Spacecraft

• Dedicated SpacecraftDigital Autopilot

• ACPS, OMS, MPSControl Elect.

• Hypersonic AirData Sensors

• Optical Tracker

27

ORBITER SEPARATION OF FUNCTIONS MK I-LOW COST/RISK SYSTEM (Cont)

Subsys

Telecom&RFAids

Dis-plays&Con-trols

DataMgmt

ElectPower

Airplane

• UHF-ATC• Microwave Scanning

Beam

• Dedicated ABES,APU, Caution& Warning, MSB,C-Band Altimeter

• APU-Generator

Common

Displays & Control• Primary Flight• ECLS• Pwr Dist

• Data Acq

• Power Dis-tribution, Con-ditioning &Control

• Battery

Spacecraft

• USB

• Dedicated QMS,ACPS, MPS, FuelCells, Caution &Warning.

• Fuel Cells

29

The present baseline achieves lower program

cost/risk than our Phase B configuration by reducing

the onboard equipment complexity through a more

judicious mix of ground and vehicle task responsibility

assignment. Increased reliance oh the ground mission

control center for mission and systems management

and a more active role in spacecraft navigation func-

tions relieves some of the higher cost associated with

developing complete vehicle autonomy. Similarly,

detailed checkout, troubleshooting, and trending is

assigned to the vehicle launch center.

Onboard, the system control is primarily re-

legated to manual tasks, with automation retained

basically only for time critical reconfiguration re-

quirements.

30

ORBITER ON-BOARD FUNCTIONAL CAPABILITY SUMMARY

Function

Mission Mgmt

Systems Mgmt

FltOynMgmt(Guidance)

Phase B

• PrimarilyAutonomous

• Checkout toLRU

• AutomaticReconfig


Low Cost/Risk System

FHF

None

• Caution &Warning

• ManualReconfig

• ManualSubsystemControl

• AutonomousAttitude &Heading only

Mkl

• PrimarilyGround

• Caution &Warning

• ManualReconfig

• ManualSubsystemControl

• GroundUpdate

Mkll

• CrewScheduling

• ContingencyPlanning

• ReentryScheduling

• Checkout toLRU

• Computeraided Re-config &SubsystemControl


31

ON-BOARD FUNCTIONAL CAPABILITY SUMMARY (Cont)

Function

Displays&Controls

DataAc-quisition

Tel-met ry

COMM

Phase B

• Multi-PurposeDisplays, ManualEntry Keyboards,Side Arm Con-trollers

• MultiplexedData&CommandBus

• Continuous Gndlink via TORS

• ATC• Continuous

Gnd Link viaTORS

• Intervehicle


FHF

• Dedicated AeroD&C

• Multi-FuncSide ArmControllers

• Data Acqbus

• GSE databus

• Overlay DFILink

• ATC• FLT Test Site• Chase Plane

Mkl

• Dedicated Aero& Space D&C

• Multi-FuncSide ArmControllers

• ExpandedCapacityData AcqSys

• Periodic GndLink viaMSFN

• ATC• Periodic Gnd

Link viaMSFN

Mkll

Same as Mk 1Plus• Multi-Purpose

OBC-CRTDisplay

Same asMkl

• ContinuousGnd LinkVia TORS

Same AsPhase B

32

ON-BOARD FUNCTIONAL CAPABILITY SUMMARY (Cont)

Function

FlightControls

Nav

Landing

Phase B

• CentralizedMultiplexedFly-By-Wire

• Combined A/C& S/C Computer

• Primary GndArea Nav &Tracking

• AutonomousCooperativeRendezvous &Orbital Nav

• Autoland


FHF

• DedicatedA/C Auto-Pilot,Hardwired

• IndependentA/C Elec-trical Backup

• AutonomousAttitude &Heading only

• VFR Landing

Mkl

• Separate A/C&S/CHardwired Auto-Pilots

• Independent A/CElectricalBackup

• PrimarilyGround

• PilotControlInstrLanding

Mkll

• Same as Mk 1

• PrimarilyGround

• AutomaticControlInstrLanding

33

The low cost shuttle avionics system has beenbased on a fail-safe (FS) configuration as a minimum,in accordance with SOW requirements. Where feas-ible, degraded backup modes have been utilized toachieve fail-safe capability without the addition ofoperational redundancy.

The approach used in determining the redun-dancy levels for the recommended configuration hasbeen as follows:

• A minimum configuration was defined foreach subsystem that is fail safe for crewsafety equipments (operational or function-al redundancy) and single thread for mis-sion success equipments

• Redundancy was added selectively to thisminimum configuration where economical-ly justifiable, so as to reduce total programcosts. Abort cost savings were traded offagainst the cost penalty of additional re-dundancy (weight and equipment penaltycosts).

Two models were employed in performingthese tradeoffs; a cost-effectiveness model, and apayload effectiveness model. Where the abort costsavings for the program exceeded the costs of theadditional redundancy, the decision was made to addthe redundancy. Based on these economic criteria,redundancy decisions were made on each equipment

36

individually, resulting in the addition of redundancyselectively to the minimum configuration. As canbe seen by referring to the tables of Equipment Op-erational Redundancy for each subsystem, in somecases no redundancy was added, in others one oreven two equipments were added above that in theminimum (FS) configuration.

Grumman has developed computer programsand nomographs for exercising the Cost and PayloadModels, which, in addition to mechanizing the basiccalculations, also permit sensitivity analyses and pa-rametric studies to be made in an efficient manner.

The program cost savings for each programphase, (Mk I and Mk II), and each booster (R-S-1Cand BRB), were computed for each redundancy lev-el, FS, FO/FS and F02/FS as well as the selectiveredundancy established by both the Cost and Pay-load models as follows:

ASavings (from FS)=(ANo of Aborts)(Mission Cost)-(AW)(Co^)-(AEquipment Cost)

(No. of Vehicles)As shown in subsequent tables, both models

resulted in the highest overall program savings, andyielded approximately the same results.

The impact of maintenance costs due to theadditional redundancy was also examined duringthis study and found to have a negligilbe effect ontotal program cost savings.

LOW COST AVIONICS STUDY

RELIABILITY REQUIREMENTS

• Fail-Safe (FS) Configuration Minimum

• Degraded Backup Redundant Modes Permissible

REDUNDANCY RATIONALE

• Baseline Subsystem Design Satisfies:

FS Minimum, Worst Mission Phase

• Add Redundancy When Economically Justifiable

- Minimize Total Program Costs

o Savings-Reduce Abortso Penalties-Hardware

-Weight-Maintenance

37

Orbiter Cost/Payload Model Parameters

The accompanying table identifies the missionparameters utilized in the cost/payload redundancyselection models. These values utilized in the asso-ciated computer programs, i.e., number of vehicles,number of flights, payload weight and mission dura-tion for both the Mk I and Mk II phases of the mis-sion are in accordance with NASA SOW requirements.

Cost sensitivities to weight change and missioncosts have been derived based on Operations Analy-sis considerations as follows:

Weight Cost Sensitivity

The values indicated represent the increase intotal program cost for placing into orbit each poundof inert weight added to the orbiter. Consequently,these values are dependent on the phase of the pro-gram (e.g., Mk I or Mk II) and the booster employed(R-S-1C or BRB). A fixed payload has been assum-ed in these calculations, therefore the orbiter mustgrow for any additional weight added to the vehicle.It should be noted that for the orbiter during theMk I phase, fixed engines have been assumed, whilefor the Mk II phase rubberized engines have been

assumed.

Further for the R-S-1C, only the orbiter growsfor additional weight added, while for the BRB boththe booster and ovbitet grow. For the R-S-1C, theweight penalty is not severe, since excess lift capa-bility exists (e.g. R-S-1C is oversized for the orbiterand therefore does not have to grow). For the BRBhowever, since it is an optimized vehicle, the weightpenalty is severe because the BRB must grow (rub-berized) to accommodate increased orbiter weight.

Mission Cost

Among the more significant elements of mis-sion costs included in the values indicated for Mk Iand Mk II for both boosters are: orbiter/boosterfuel; ground operations; MSFN support, and orbiterbooster refurbishment (materials + labor) costs.

In addition to normal refurbishment costs,costs associated with orbiter TPS ablatives refurbish-ment (Mk I only) and BRB recovery and refurbish-ment such as tank cleaning/valve replacement havebeen included.

Costs associated with launch delays have notbeen included in the mission costs. v

38

COST/PAYLOAD MODEL PARAMETERS, ORBITER

Mkl Mkll

No. of Vehicles 2 3 + retrofit 2 Mk I's

No. of Flights 99 346

Payload, K Lbs 25 65

Mission Time, Days 7 7

R-S-IC BRB R-S-IC BRB

Wt Sensitivity, SK/Lb 9.0 21.7 16.5 32.4

Mission Cost/Fit (1), SM 6.6(2)14.0(2) 4.3 12.0

(1) Includes Orbiter/Booster Fuel & Refurbishment Costs & Mission Operations Costs

(2) Includes Orbiter Ablatives Refurbishment

39

Additional redundancy shows significant costsavings compared to the baseline minimum configura-tion (FS). For the Mk I, HO/R-S-1C shuttle systemthese savings range from $154M to S166M. The largestcontributor to these savings results from the reduc-tion in anticipated mission aborts (28 for the mini-mum configuration). While the immediate applica-tion of an FO/FS approach provides the reduction,the selective redundancy approach using the CostEffective Model or the Payload Effective Model fur-ther optimizes program costs indicating savings ofseveral million dollars.

As might be anticipated, the additional redun-dancy significantly enhances crew safety reliability,RCS as well as providing the improvement in mis-sion success, RMS-

40

REDUNDANCY SELECTION TRADEOFF, Mk I, HO/R-S-IC

Min Config (FS)

Cost Model

Payload Model

FO/FS

F02/FS

RCS

.99427

.99997

.99984

.99977

.99999

RMS

.71939

.99824

.98234

.99054

.99954

No. of

Aborts

27.8

0.2

1.7

0.9

0.1

AWt/

Veh, Lb

-

1415

720

1305

2611

AEq Cost/

Veh, $M

-

1.60

1.23

1.39

2.78

Cost

Savings, $M

-

166

163

163

154

ASavings (From FS) = (A No. of Aborts) (Mission Cost) - (AW)

(A Eq Cost) (No. of Vehicles)

RMS = '>robaD'''tY °f Mission Success

Rpe= Probability of Crew Survival

Lb

41

The Mk II, HO/R-S-1C shuttle system has evengreater sensitivity to the improvement in anticipatedcosts as a function of redundancy due largely to thesignificantly greater number of missions planned ascompared to those for the Mk I system. The full ad-vantage of the large reduction in potential aborts isinhibited by the greater sensitivity to the increasedweight penalties, $16.5 K/lb vs. $9.0 K/lb for theMk I. Therefore, this sensitivity to the weight pen-alty makes the FQ2/FS even less attractive whencompared to the selective redundancy approach.

42

REDUNDANCY SELECTION TRADEOFF, Mk II, HO/R-S-1C

Min Config (FS)

Cost Model

Payload Model

FO/FS

F02/FS

RCS

.99427

.99997

.99997

.99977

.99999

RMS

.71939

.99824

.99824

.99054

.99954

No. of

Aborts

97.1

0.6

0.6

3.3

0.2

AWt/Veh, Lb

-

1415

1415

1305

2611

AEq Cost/

Veh, $M

-

1.60

1.60

1.39

2.78

Cost

Savings, $M

-

387

387

378

364

ASavings (From FS) =(ANo. of Aborts) (Mission Cost) - (AW) (—— I -


"MS = Viability of Mission Success

RQO= Probability of Crew Survival

43

The application of the selective redundancyapproach for the Mk I, HO/BRB shuttle systemconfirms the conclusions reached from the pre-vious tables relating to the shuttle configurationsemploying the R-S-1C booster. However, thesensitivity to mission costs (cost of an abort)which are higher for the BRB, increase the costsavings substantially when redundancy is applied.These savings range from $326M to $35 3M with thecosts associated with the large weight penalty ofthe FQ2/FS causing the spread of $27M.

44

REDUNDANCY SELECTION TRADEOFF, MK I, HO/BRB

Min Config (FS)

Cost Model

Payload Model

FO/FS

F02/FS

RCS

.99427

.99997

.99984

.99977

.99999

RMS

.71939

.99824

.98234

.99054

.99954

No. ofAborts

27.8

0.2

1.7

0.9

0.1

AWt/Veh

—

1415

720

1305

2611

AEq Cost/Veh, SM

-

1.60

1.23

1.39

2.78

Cost

Savings, $M

-

353

347

346

326

CostASavings (From FS) =(A No. of Aborts) (Mission Cost) - (AW) (-j-jj-


RMS = ProDability of Mission Success

RCS = Probability of Crew Survival

45

Savings associated with the additional re-dundancy become even more significant whenexamiining the Mk II, HO/BRB shuttle config-uration. The basic savings in program costs areover $ IB.

46

REDUNDANCY SELECTION TRADEOFF, MK II, HO/BRB

Min Config(FS)

Cost Model

Payload Model

FO/FS

F02/FS

RCS

.99427

.99998

.99997

.99977

.99999

RMS

.71939

.99840

.99824

.99054

.99954

No. ofAborts

97.1

0.6

O.S

3.3

0.2

AWt/Veh. Lbs

-

1428

1415

1305

2611

AEq Cost/Veh, $M

-

1.65

1.60

1.39

2.78

ACost

Savings, $M

-

1108

1107

1079

1070

A Savings (From FS) = (A No. of Aborts) (Mission Cost) - (AW) (—) -Lb


RMS = Probab'l'tv °f Mission Success

Rrc = Probability of Crew Survival

47

The equipments which perform the guidance,navigation and flight control functions are con-sidered necessary for either crew safety (CS) ormission success (MS).

In general, equipments which have been identi-fied as necessary for crew safety require a minimumconfiguration of two in order to be fail safe (FS).Mission success equipments require a minimum config-uration of one. The quantity identified as "requiredadditional redundancy", based upon the operationalredundancy model (ORM), when added to the mini-mum configuration, results in general in the GAC rec-ommended configuration.

The following was used for operational redun-dancy selection:

• Each of the flight control equipments is nec-essary for crew safety during de-orbit andlanding

• The fly-by-wire flight control system (FEWPCS) and the direct electrical manual back-up FCS were each considered necessary formission success. An alternate assumption,to consider a crew safety FBW FCS withouta backup FCS, was discarded. This accountsfor the apparent discrepancy indicated inthe table by note D.

• Where additional redundancy was indicatedas necessary for equipments which exist ineach crew station, the redundancy was addedto each in order to maintain identical stations

• Future analysis will reconsider the recom-mendation to use three IMU's rather thanfour as indicated. Either a decrease induty cycle or an increase in reliability re-sults in a model recommendation of onerather than two additional IMU's.

• Either the lower or the upper rudder surfacesand a right and left elevon surface were con-sidered sufficient for crew safety

• The actuator configurations considered andrecommended require some clarification.Each actuator was assumed to be an indepen-dent non-redundant channel. Based upon theadjusted weight, cost and MTBF provided forthe ORM, the computer analysis indicatedthe need for proper operation of two of fourprime elevon actuators for MS and one offour for CS, and two of four rudder and oneof two speedbrake secondary actuator for MSand one of four for CS

As functional and backup operational modes areidentified, and as the design and configuration develop,and as the mission rules are established, these assump-tions, along with the reliability models and recommend-ed levels of redundancy, will be updated and refined.

48

FLIGHT CONTROLS G&N SUBSYSTEM,EQUIPMENTOPERATIONAL REDUNDANCY

EquipmentName

IMUPri Computer

ME Cont & ME TVC Elec

Contr: OMES, Sptark, Rudd,Aero

Reentry AD, AD Computer,AD Sensors, Sec Act Elev

TTCA & Rotat SS

G&N Sensors -

Rate Gyro & Accel

FBW PCS

Oir Man BU FCS

Sec Act Rud& Spbrk

Prim Act Rud & Spbrk

Aerospace Cont Elect

Prim Actuator Elev

ACPS Cont Elect

MinimumConfig(FS) (A)

212

2

221

(E)

2

(E)

2

Req'dCS

1"01

1

1100

}l)

11011

Req'dMS

212

2

2201

H2

o'12112

Additional Redundancy

Cost Model

MklR-S-1C

221

1

0

BRB

221

1

1101111111

1

MkllR-S-1C

221

1

0

1

1

BRB

221

1

0

Payload Model

MklR-S-1C/BRB

211

1

1101111

>11

1

MkllR-S-1C/BRB

221

1

1i011111111

GACRecomm.Config

' 3 IB)33

4(C)

34(C)

122(0)

22

,322

3

Notes: A. Minimum Configuration Quantities Are for Each Equipment

B. Tentative Value; Further Analyses Are Planned Concerning the No. of IMU

C. Denotes Total Quantity for Both Crew Positions

D. Refer to Text. Three Units Will Be Utilized

E. Refer to Text.

49

The concepts and assumptions which were thebasis for this analysis were two-fold. First, it was as-sumed that all of the data processed by each RAU andDAC was essential for mission success, i.e., a loss ofany piece of data/information would require termina-tion of the mission. This assumption is most conser-vative, for undoubtedly, a portion, yet to be deter-mined, of the data processed by each RAU/DAC willnot be required for mission success. It was also as-sumed that loss of all data would not affect crewsafety, i.e., the crew would be able to effect a safeabort without the Data Acquisition Subsystem.

Secondly, an RAU/DAC was considered as a

single channel, non-redundant entity. The weight,cost, MTBF, etc. provided for the operational redun-dancy model were adjusted accordingly. The resultsof the computer analysis indicates that each RAU no.1 through no. 6 and the DAC should be made redun-dant as a cost effective measure.

The Mass Memory operational redundancy cal-culation indicates that the addition of two units isthe most cost effective approach, for a total of threemass memories. Future analyses are planned con-cerning this finding.

SO

DATA MANAGEMENT SUBSYSTEM,EQUIPMENTOPERATIONAL REDUNDANCY

EquipmentName

Mass MemoryData Acq Contr*

Remote AcqUnit 1*Unit 2*Unit 3*Unit 4*

UnitS*Unit6*

Computer

MinimumConfig

HO G&N

Req'dCS(FS)

00

000000

Req'dMS


Cost Model

Mkl

R-S-1C

21

111111

BRB

21

111111

Mkll

R-S-1C

21

BRB

21

Payload Model

Mkl

R-S-1C/BRB

11

111111

Mkll

R-S1C/BRB

2

1

GACRecommConfig

3(c)

2

222222

Notes: A. A Portion of the Data Processed by Each RAU/DAC Is Not Required for MissionSuccess. The Model Assumes All Data Is Required

B. The Minimum Configuration Consists of Single Channels.

C. Tentative Value, Future Analyses Are Planned Concerning The No. of Mass Memory • Units

* Denotes a Single Channel

57

Functions

The crew safety functions of the Telecommuni-cations Subsystem (TCS) are voice link, for all missionphases, and landing aid for the landing phase. The re-maining functions of the TCS are mission success re-lated rather than crew safety, except for the VHP bea-con and the flight recorder, whose functions are notnecessary unless the vehicle has crashed.

Minimum Configuration

Obiter voice links with the ground are estab-lished with either dual redundant S-band or UHFequipment, together with an internally redundantsignal processes and audio center. During ascentand orbital mission phases, primary communica-tions with the ground MSFN is achieved at S-band.UHF provides a functional backup during thesemission phases and is prime during atmosphericflight. Furthermore, UHF is compatible with mostMSFN, ATC and world wide ground stations, thusenhancing voice communications coverage. Ade-.quate fail safe voice communications is providedvia UHF and S-band.

The most important function of the CommandDecoder is to provide to the computer, via the S-bandlink, information to update the inertial navigation sys-tem prior to re-entry. Since the same data can betransmitted by voice link and inserted into the com-puter by the crew by means of the keyboard, the Com-mand Decoder is not a crew safety item.

The TAC AN Transceiver provides rendezvouscapability in the orbital phase, and conventionalTACAN navigation functions (range and bearing to aknown site) in the post re-entry phase. The rendez-vous function does not impact crew safety, and thepost re-entry navigation can be accomplished, althoughin a degraded manner, by using the voice link to pro-vide navigation cues.

The Ku-band Microwave Scanning Beam (MSB)Transceiver/Decoder provides the alignment and glideslope landing aid information to the crew for the land-ing phase. This function affects crew safety, and thefail-safe requirement is met by providing duplicateequipment. The C-Band Altimeter provides height-above-terrain data to the crew and is used as a confi-dence check on the MSB. In the event of an abort toan alternate landing site which does not provide MSBcompatibility, the altimeter becomes an essential in-strument in landing safely. The altimeter is not in-cluded in fail-safe considerations since it comes intoplay only after the first failure has occurred. The an-tenna systems are considered to be fail safe, sincefailure results in degraded but acceptable antenna pat-tern coverage.

Recommended Configuration

The recommended configuration has been derivedfrom the minimum configuration by adding redun-dancy where economically justifiable.

52

TELECOMMUNICATIONS SUBSYSTEM,EQUIPMENTOPERATIONAL REDUNDANCY

EquipmentName

S-Band Ant Sys •

S-Band Sw/Tplxr

S-Band Xcvr

UHF Ant Sys

UHF Ant Sw

UHF Xcvr

TACAN Ant Sys

TACAN Ant Sw

TACAN Xcvr

C-Band Ant Sys

C-Band Alt

Ku-Band Ant Sys

Ku-Band Xcvr

Sig Processor

Audio Center

Cmd Decoder

Beacon &Recorder

MinimumConfig.

. (A)(A)

(A)(A)

'(A)

(A)

(A)

(A)2

2211ea

Req'dCS(FS) (B)

0000012

2200

Req'dMS

0012

2210


Cost Model

MklR-S-1C

0010010010000

1110

BRB

00100100100001110

MkllR-S-1C

0010010010000

1110

BRB

00200100100001110

Payload Model

. MklR-S-1C/BRB

0010010000000

1110

MkllR-S-1C/BRB

00100100100001110

GACRecontmConfig

1121121121112

332

,1ea

Notes: A, Indicates Fail Safe Characteristics Inherent in Design

B. Voice Link and Landing Aids Are the Only Crew Safety Functions

53

The EPS is composed of two electrically isolated,independent fail safe sections (left and right sides)with each section servicing one half the vehicle. Eachsection is designed to be fail safe as a minimum. Crewsafety primary equipments are powered from oneEPS section and the backups from the other section.

The application of cost-effectiveness criteria tothe minimum configuration resulted in no additionalredundancy required. Because of the degree of func-tional redundancy, a substantial portion of the EPScomponents can fail before an abort becomes neces-sary. The components required to permit a safe abortare:

Either one of two fuel cells and one of twoinverters or one of four APU/generators andone of two forward TR's

• And one of two aft T/R's (because of theisolation scheme, only a T/R can be poweredby any given APU/Generator.

Loss of both fuel cells prior to completion ofthe-orbital phase necessarily results in a missionabort. Since the APU hydrazine fuel supply is sizedfor the aerodynamic flight phases, totaling a fewhours, sufficient fuel for generating electrical powerfor sustained orbital operations is not available.

The major role of the emergency batteries is tosustain vehicle loads during system re-configuration,in the event of failure of a prime power source.

54

ELECTRICAL POWER SUBSYSTEM,EQUIPMENTOPERATIONAL REDUNDANCY

Equipment

APU/Gen

Fuel Cell

Inverter

Battery

Battery Chgr,

Xfmr/Rect/Fwd

Xfmr/Rect/AttRegulator

Minimum

422

(A)

(8)242

Req'dCS(FS)

422

240

Req'dMS

422

2. 4

2


Cost Model

Mkl

R-S-1C

000

000

BRB

000

000

Mkll

R-S-1C

000

000

BRB

000

000

Payload Model

Mkl

R-S-1C/BRB

000

000

Mkll

R-S-1C/BRB

000

000

RecommConfig

42222242

Notes: A. Battery Required Only for Emergency Situations

B. Battery Charger Operates Only to Maintain Battery Full Charge Condition

55

The Instrumentation Subsystem consists of sen-sors and associated signal conditioning electronics nec-essary to provide vehicle measurements information tothe crew and/or ground. It also includes a Flight Re-corder with its associated electronics, and two DataLog Recorders.

A general conceptual analysis has been perform-ed. It has been assumed for this study that most sen-sors will have no significant adverse effect on crewsafety (CS) or mission success (MS). In future studiesa number of measurements will be identified as nec-essary for mission success and a portion of these MSmeasurements will also be required for crew safety.The recorders and associated electronics and non-crit-ical sensors and conditioners have been omitted fromthe CS and MS reliability models. No instrumentationequipment has been included in the reliability opera-

tional redundancy model.

It is intended, by design and/or configuration, toeliminate any adverse effect on CS and MS for all crit-ical measurements. Future studies will determinerecommendations for operational redundancy. A re-liability model will be completed for MS and CS foreach mission Phase Mil boost, orbital operations, anddeorbit/landing, respectively.

Finally, it should be noted that there is no mis-sion success model for Phase III, since it is assumedthat during the down phase, the optimum missiontermination path would already be employed. There-fore, all equipment would be configured for the safereturn of the crew and only a crew safety model isvalid for Phase III.

56

INSTRUMENTATION SUBSYSTEM,EQUIPMENTOPERATIONAL REDUNDANCY

EquipmentName

Fit Recorder

Data Log

Recorder

Signal Condtnrs

Critical

Non Critical

Sensors:

Critical

Non Critical

Electronics

Fit Recorder

MinimumConfig

1

2

2ea1ea

2ealea

1

Req'dCS(FS)

0

0

TBD0

TBD0

0

Req'dMS

0

0

TBD0

TBD0

0


Cost Model

Mkl

R-S-1C

TBD

TBD

BRB

Mkll

R-S-1C BRB

Payload Model

Mkl

R-C-1C/BRB

Mkll

R-S-1C/BRB

fc

GACRecomm

1

2

TBD1

TBD

1

Note: The Identity and Number of Critical CS/MS Signal Conditioners and Sensors Will beDetermined as the Design Develops. Additional Redundancy and GAC RecommendationsWill Be Determined in Subsequent Studies.

57

Program penalty costs for both program phases,Mk I and Mk II, and for each booster, R-S-1C andBRB, were calculated as a function of redundancy lev-els. Costs were computed for each redundancy level(FS, FO/FS, FQ2/FS) in addition to the selective re-dundancy determined by the Cost/Payload models.Reference to the histograms shows that the FS (min-imum) configuration results in program penalty costsof the order of 10 to 20 times those of the Cost/Pay-load configurations. The FO/FS and FO/FO/FS con-figurations incur penalty costs ranging from 20% to60% greater than those for the Cost/Payload config-urations.

The recommended configuration was developedfrom the FS (minimum) configuration as follows:

Redundancy allocations were evaluated inde-pendently for the Mk I and Mk II programs, since theoperational/vehicle parameters vary for each program.

Each program was evaluated using both the Cost andPayload models to determine the economically op-timum level of redundancy. The results of eachevaluation were virtually identical, i.e., where differ-ences existed, engineering judgement was applied todetermine the final configuration.

The differences in cost among the various con-figurations result from the interplay of three costfactors:

• Abort Costs: Expected number of abortsX cost per mission

• AEquipment Costs: The cost of the addi-tional equipment due to the redundancyadded above the FS configuration

• AWeight Costs: The weight of the addition-al equipment X Penalty cost per pound

58

COSTS VS REDUNDANCY LEVELS R-S-1C

430i

Cost, SM

Cost = Baseline Abort Cost - ACost Savings

= = Mkl

=Mkl l

FS(Min) Cost Payload FO/FS FO/FO/FS

Redundancy

The FS configuration has the minimum redun-dancy, and consequently, the lowest reliability andthe highest number of aborts. Since this is the mini-mum configuration, there are no associated equip-ment and weight penalties; the total FS penalty costis solely due to abort costs.

The FO/FO/FS configuration has the maxi-mum redundancy, and consequently, the lowestabort costs. The high redundancy level incurs themaximum equipment and weight penalty costs.

The FO/FS configuration has a lower penaltycost than FO/FO/FS since the higher associated a-bort costs are more than offset by the reduction inthe equipment and weight penalties.

The Cost and Payload configurations yieldpenalty costs which are essentially equal, and aswould be expected, the lowest of all the configura-tions evaluated. In these configurations, redund-dancy is allocated in accordance with economiccriteria rather than arbitrary rules, as is the casewith the other configurations. The differences be-tween the Cost and Payload configurations stemfrom the criteria used for adding redundancy. ThePayload model optimizes the probability of pay-load delivery to orbit and reduces the effective pay-load by the weight of redundancy added; the Costmodel minimizes the total program costs and main-tains a fixed payload and allows the vehicle togrow as redundancy is added.

60

COSTS VS REDUNDANCY LEVELS, BRB

1180-

1140-•

420-

Cost, $M

380-

100-

60-

20-

Cost = Baseline Abort Cost - ACost Savings

I

I =Mkll

FS(Min) Cost Payload FO/FS FO/FO/FS

Redundancy

61

JswaiSASans

MAJOR DECISIONS

• Aerodynamic Flight Control Computer

• Aerodynamic Flight Control Computer •

• Flight Control Back-Up

• Guidance & Navigation Computer

• Crew Size

• Data Bus

• Power Distribution, Condition &Control

• Displays & Controls

Dedicated vs Integrated

Digital vs Analog

- Flv-by-Wire vs Mechanical

- Integrated vs Dedicated

- Two vs Three

- Acquisition Only vs Acquisition & Command

- Conventional vs Solid State

- Dedicated vs Integrated

65

The horizontal flight test aerodynamics PCSconfiguration is effectively decoupled from spaceflight controls. This approach reduces developmentrisk for FHF and offers the potential for deferment ofspace equipment costs if desired.

Orbiter and R-S-IC, booster are similar withapproximately 57% commonality. Both use a com-mon digital primary flight control incremental com-puter. The booster has a dissimilar backup in theform of a hard Stability Augmentation System. Theorbiter uses a direct electrical analog backup basedon the inherent stable airframe characteristics of thePhase B orbiter. (Augmentation may be necessary

for HO Orbiters if wind tunnel tests indicate stabili-ty enhancement is necessary.)

An interim attitude and heading reference sys-tem is included for the horizontal test program topreclude need for inertial platforms in the earlyphases of the test program. Rate gyros, linear accel-erometers and air data sensors provide basic informa-tion required for augmentation and autopilot mech-anization. The microwave scanning beam systemis added late in the test program for IFR landings.If unmanned vertical flight test is required, the aero-dynamic portion of the flight is tested and evaluatedduring the horizontal test program.

66

FLIGHT CONTROLSFHF

LinearAccel(3 Axis)

DigitalFlightControlComptr

3

Vehicle

Orbiter

Booster

Common(Orb & Bstr)

Key

67

For Mk I and II, the basic aerodynamic control

system for the horizontal test program is supplement-

ed with the addition of space flight hardware and

software. These include: the IMU's and Primary

digital computer; the control electronics for ACPS

control; main engines, and in the case of the orbiter,

the OMES control electronics. At this point the in-

terim attitude and heading reference used for hori-

zontal testing is removed.

If unmanned vertical flight test is required, ad-

ditional equipment is necessary. Space and aero

flight couplers are added to perform functions nor-

mally accomplished by the crew. Either direct com-

mands via up link or sequential commands from the

onboard computer are possible. The aerodynamic

flight portion will have been tested and proven

during horizontal testing. Either ground and/or air-

borne (chase plane) control would be provided for

approach and landing.

Auto land capability will be incorporated in

Mk II with IFR for Mk I and late horizontal flight

test. The need for hypersonic air data for entry and

transition is currently under evaluation.

68

FLIGHT CONTROLS$$&$& MARK I & MARK II

CrewControlSensors

BodyRateGyros(3 Axis) 3

LinearAccel(3 Axis)

AirDataComptr

3

1 PrimaryComptrSpaceFit Cent

tIMU

^Display

•* Display 1

r•^ Display

»

-¥

•*-fr

»>

W$fa

HDigitalFlightControlComptr

J'

• Display

1

--»

F

AeroControlElect.

3

ABEElect.

3

ACPSMainEngine&TVCControlElect. 3

Vehicle

Orbiter

Booster

Common(Orb & Bstr)

Key

R^V777A

CZH

• • •

69

A digital primary flight control computer

backed up by a dissimilar redundant analog system is

recommended. The digital approach offers many ad-

vantages over analog, e.g., accommodates change

easily via software, has a wider dynamic range, is

lighter, cheaper, more precise, and can use existing

equipment and software specifically designed for

control applications. The prime disadvantage of the

digital approach is the question of software devel-

opment risk. This could be a problem using a gen-

eral purpose machine and developing software from

scratch.

The Grumman/Boeing recommendation is to

use an existing Variable Digital Incremental Com-

puter. This machine is specifically designed for con-

trol system applications and has been flight tested on

707 and 727 autoland systems. Programming is

simple and is analogous to programming an analog

computer. Supporting software in the form of as-

sembly and simulation programs exist. This combi-

nation of advantages offers a significant reduction in

software development risk.

70

SYSTEM ARCHITECTURE, MAJOR DECISIONS

DIGITAL AERO FLIGHT CONTROL COMPUTER

ADVANTAGES OVER ANALOGA. Easier to Accommodate Changes

(Boeing SST Experience With.Analog A Major Risk Factor)

B. Can Easily Accommodate WideRange of Performance Require-ments. (Analog Autopilot MayPush State-Of-Art)

C. Better Control of Tolerances,Errors and Limits; EspeciallyImportant In Auto-Recon-f igurable Systems (FewerNuisance Interrupts)

D. Simpler Interface With G&NDigital Computer

E. Common Equipment on Or-biter and Booster (AnalogWould Require 2 DifferentDevelopments) ReducesGSE, Spares, etc.

DISADVANTAGES COMPARED TO ANALOGA. Most Aero Flight Control Experience is

With Analog Implementation

B. Software Development Problems

C. Although Experience With Digital Equip-ment is Minimal Several Programs Will HaveGained Experience:

• F-14 Digital Wing Sweep Program• NASA F-8 With Apollo Computer• Boeing DASH 80 Auto Land• Boeing 727 Auto Land

71


DEDICATED AERODYNAMIC FLIGHT CONTROL COMPUTER FORORBITER AND BOOSTER

ADVANTAGES

A. De-Couple Risk (CentralComputer Not Required forHFT Program)

B. Forces Software Modularization

C. Provides Greater SoftwareVisibility

D. Simplifies Test Programs

E. Uses Existing Hardware

DISADVANTAGES

A. May Add Weight to Final System

B. Less Flexibility

C. More Software Packages

72


FLY BY WIRE

ADVANTAGESA. Saves Weight A.

- Orbiter 342 Lb- Booster 760 Lb

B. Booster • Is Unstable and B.Cannot be Flown by CableSystem Without an ElectronicStability AugmentationSystem

C. Control Column Not Required.(Benefit to Orbiter Cockpit)

D. Less Concern About VacuumWelding: Bearing Lubrication;Press. Vessel Penetration, ETC.

E. Secondary Weight Savings Can BeSubstantial for Control ConfiguredVehicle, i.e., Reduced Tail andControl Surface Areas, Loads, Power

DISADVANTAGESHas Never Been Completely Done for A/C.(All Spacecraft Are Fly by Wire and Some A/CPartially, i.e., F-111, F-14 Spoilers)Susceptible to Total Electrical System Failure.(Total Electrical Failure Could be CatastrophicFor Many Other Reasons- Depending onWhere the Failure Occurs in the Mission.Loss of APU Results in Loss of HydraulicPower)

73

Past experience has shown that this particulartrade study generates considerable "emotional" as wellas technical discussion. The Grumman/Boeing studieshave attempted to filter out the emotional/subjectiveconsiderations and have concentrated on technical/objective factors.

Inclusion of a mechanical cable system in an PCSdesign implies basic airframe stability. That is, for anunstable airframe, a manual mechanical cable systemwithout electrical stability augmentation would be ofno value. Candidate mechanical longitudinal and di-rectional flight control system designs for the boosterare schematically represented in the accompanying illus-trations. All major mechanical components (cable,control stick, trim actuators, etc.) are identified. Thetotal weight for a mechanical system of this type forthe orbiter is 481 Ib. Inherent to the design of anymechanical cable system are the following problems:

• Cockpit pressure seals• Mechanical jamming• Friction• Hysteresis.

When considering large and long vehicles, such as theorbiter and booster, these mechanical system problemsare aggravated even more.

In recent years, a distinct trend away from mechan-ical systems and toward fly-by-wire (FEW) controlsystems has been observed. High performance militaryaircraft, such as the F-lll and F-14 have fly-by-wirecontrol for their spoiler surfaces. In addition, the AirForce F-4 680J program and NASA FRC F-8 programare two experimental fly-by-wire test programs that arecurrently underway.

Taking into consideration specific orbiter andbooster control system performance and flying qualitiesrequirements, a triply redundant digital primary fly-by-wire control system has been baselined for both vehicles.Concern over common mode failures led to the inclu-sion of a dissimilar backup PCS. Since the orbiter isinherently stable, two design options were available forthe backup PCS: 1) mechanical cable system or, 2)direct manual analog electrical command, i.e. electricalanalog of mechanical cable system. .

74

FLY-BY-WIRE (PITCH AXIS ONLY SHOWN)

75

The backup FEW system positions the aerody-namic control surfaces proportional to cockpit con-troller displacements. Implementation of the dualsystem is via dedicated hardware and direct wirecable runs up to the actuation subsystem. Thebackup system is integrated into the prime systemto provide minimum engage/disengage transientswith maximum isolation. A separate dedicatedpower system supplies ac and dc power to thededicated components. Integral failure detectionand isolation, along with pilot warning, is providedto indicate backup system status.

This dual redundant manual direct PCS weights139 Ib and requires 298 w of power. When comparedto the mechanical system on a cost and weight basis,the choice of the direct electrical analog commandconfiguration as the orbiter backup PCS is clearlyjustifiable. The major objection raised with respect toemploying a backup FBW system has been concernover complete loss of electrical power. This concernis felt to be unwarranted based on data obtained fromEastern Airlines and Boeing experience with loss ofelectrical power in its commercial fleet to 1969. Onefailure per 1,600,000 flight hours with almost negligi-ble effects clearly indicate that loss of electrical powerthrough lightning strikes or any other phenomenon

should not be used as an argument against baselininga complete FBW PCS. Eastern Airlines data augmentsthe Boeing data by indicating that their experiencereports only ten lightning strikes per million flighthours with no reported power losses. An additionalfallout advantage of going FBW for both the primaryand backup PCS is that only one type of pilot rota-tional controller (side stick) is required. If a backupmechanical system had been incorporated instead, acockpit control stick would also have to be privided.

The basic booster airframe is unstable and as aresult requires a stability augmentation fly-by-wirebackup PCS.

The concept of using FBW/stability augmenta-tion control techniques provides some very interestingvehicle structural/aerodynamic design options. Forexample, an airframe such as the orbiter, could bepurposely designed to be unstable (e.g., reduced wingarea) in order to save vehicle weight (possibly thou-sands of pounds). Reliance would then fall upon theFBW/stability augmentation system to improve thebasic airframe performance/stability. This approachto airframe design is referred to as "control configuredvehicle."

76

FLY-BY-WIRE:WITH AERO MECHANICAL BACK-UP

1 — ^GSN

| Computer

9

'

»

-»

L,

Computer

Win Safe

Computer

I^

i:

>i

TVCElex

ACPS

I "n

I

1

TVCAct.

ACPS

1 •=]

$^

77

The spacecraft Guidance Navigation and Controland Data Management Systems development will beperformed in phases corresponding to the vehicledevelopment. First horizontal flight (FHF) will usethe C-band radar for ground controlled area/landing

functions and a limited data acquisition systemwhich contains the caution and warning (C&W)

function.

Data controllers control the flow of data

from the remote acquisition units (RAU), perform

C&W processing, format and control the flow ofdata to the telemetry and the flight recorder. The

RAU's as presently sized will have the capabilityfor handling 96 bi-level and 96 analog signals.

They will also include integral standard signal con-ditioning.

Upon completion of the first phase of thehorizontal flight test program both subsystems willbe expanded as required to meet flight test ob-jectives.

78

GN&C AND DMSFHF

")-* Display

Jusl DstpAcq&:&wlontrolle

. RAU .1

i e

RAU .3

;

—

RAU1

RAU3

'

. •""•"

!

C&W&Display

FitRcdr

Telemetry

> G S E

DFIlataController

-

-

Rau1

RauS

+ DFIRcdr

> OFIp FMRcdr

- ) S-Band* } FM» J Xmtr

DFIAnalogFM

79

The systems added for Mk I include the threeinertial platforms single threaded to three primary(general purpose) computers. The inertial platformshave four gimbals to avoid the imposition ofattitude restrictions on the vehicle through allmission phases. The array of navigation aids addedto the Mk I avionics provide the potential for fullyautonomous guidance and navigation operations;however, ground tracking (i.e., MSFM for space-craft operations and C-band for area navigationthrough approach) is incorporated leaving openthe option to include autonomy through softwaremodifications later in the program.

Navigation aids which can meet requirementsfor several mission phases were selected. TACANis utilized for post-blackout area navigation andrendezvous ranging. The Multi-Mode OpticalSensor (MMOS), a fixed-base device, was selectedas a low-cost, highly reliable system to perform

in-orbit IMU alignments and rendezvous with theoption to include horizon sensing capabilityas a viable means for performing orbit navigation.The Crew Optical Alignment Sight (COAS) is addedfor line-of-sight control functions during terminalrendezvous and as a back-up inertial system align-ment device. The Microwave Scanning Beamsystem is interfaced to the primary computers forconditioning the information required for manualIFR landings.

A data log recorder interfaced to the datacontroller is added and the data acquisition sys-tem is expanded to meet the full vehicle require-ments for subsystem reporting and management.Two data entry keyboards (with displays (DEK)are added and the data controller is interfacedwith the primary computers to increase thecrews ability to perform their system manage-ment function.

80

GN&C AND DMS

8

^D^S

N^

TACAN

Ku-BandMSBXcvr&Decoder

^

•••

J

IMU 3

C-BandAlt

DEK

1 x-+ Display 1

Vehicle

Orbiter

Booster

Common(Orb & Bstr)

Key

F^^7777A ...

^^^^

r*

"rimaryComputer

GN&C,Space FitControl :DMS)

^Space ControlElectronics

^ Fit ControlComputer

DataLog

f I Rcdr

'

Acq&C&Wlontrolle

. "AU ,

I .'• i i

I

. RAU .

r 1

6

—

'

. ' '

[* "RAU

: :

9

C&W&Display

FitRcdr

Telemetry

fc DFIRcdr

A DFIw FMRcdr

GSE

DFIDataController

-

Rau1

Rau5

_ } S-Band

» j Xmtr

DFIAnalogFM

81

GN&C and DMS Mark II

The Mk II GN&C and DMS are essentiallyidentical to Mk I in terms of architecture.

Those autonomous functions which will re-place MSFN during Mk II are orbit navigation us-ing the TDRS plus an option of using the FixedBase Optical Tracker (MMOS) in a back up mode.

The rendezvous maneuvers will be computedbased on MMOS and TACAN data. Terminalarea maneuvers (i.e., area navigation and landing)will incorporate the FAA version of MSB (i.e.,MSL) and an option for autoland, depending onHFT Mk I flight test results.

RAU's and the ground based Data Ac-quisition Controller used for ground checkoutduring Mk I are incorporated into the onboarddata acquisition system^ This provides essentiallyonboard checkout capability to an LRU.

The primary computers are expanded toincorporate 48K of memory and interface withtwo mass memories (tape) and two multi functiondisplays (MFD). Mass memory will be used forstorage of G&N, configuration management,mission support, subsystem checkout, and MFD/programs.

82

GN&C AND DMSIMARK II

TACAN

Ku-BandMSBXcvr&Decoder

Vehicle

JOrbiter

Booster

Common(Orb & Bstr)

IMU

C-BandAlt

•+ Display

^^m

1

•*•

r*

DEK

*PrimaryComputer

(GN&C.Space FitControl 3DMS)

Memory

,1 8 i^ Space Control

Electronics^Flt Control

Computer

DataLog

Key

Dual DataAcq&C&WControlle

:-X-:Y> jSvHTOvAvX-XvX-:^^^

83


G&N FUNCTION IN CENTRAL COMPUTER VS. DEDICATED NAVIGATIONCOMPUTER (INS AND COMPUTER PACKAGE)

CENTRALIZED (ADVANTAGES)

A. Increased Flexibility

B. Reduced Weight. Power andVolume

C. Failure Monitoring Can BeAutomated

D. In-Orbit Alignment Inter-faces Simplified

E. Reduces Ground SupportEquipment, Spares, etc.

DEDICATED NAV (ADVANTAGES)

A. Existing INS/Computer Packages CouldSave New Software Development

B. Could Readily Be Available for FirstHorizontal Flight

C. Would Reduce Software Managementand Verification Costs

84

COMPUTER MEMORY SIZING

DM/G&N

FitControl

Data Acqc&w

Air DataComputations

MassMemory(Mission &PayloadSupport)

Phase B

Orbiter

40K

8K

In DM/G&N

In DM/G&N

128K

Booster

40K

8K

In DM/G&N

In DM/G&N

FHF

Orbiter

-

2K(Equiv)

4K

2K

Booster

-

2K(Equiv)

4K

2K

Mk

Orbiter

32K

2K(Equiv)

4K

2K

Booster

24K

2K(Equiv)

4K

2K

Mkll

Orbiter

48 K

2K(Equiv)

4K

2K

128K

Booster

SameAsMkl

SameAsMkl

SameAsMkl

SameAsMkl

All Numbers 32-Bit Words

85

Crew station displays and controls subsystemrequirements were established consistent with low-cost implementation economies being considered inboth the avionic and nonavionic subsystems. Func-tional requirements for the displays and controls sub-system were established through extensive review ofall on-board operational subsystem requirements. Par-ticular emphasis was placed on the operational cri-ticality of each functional requirement and the asso-ciated crew procedures. Human engineering consid-erations and pilot experience were key factors in es-tablishing panel arrangements and determining crewsize. MSFN availability, particularly during launch,was utilized to reduce crew work load. Hardware se-lections were made based on functional characteris-tics, cost, risk, and reliability. All avionic and non-avionic D & C requirements are traceable throughcomputerized measurement and command lists and

controlled by subsystem functional set drawings (sub-system functional schematics). Full-scale flat planarrangement boards and quarter scale mockups wereutilized to establish crew station panel arrangementsand geometry.

The selected design approach for the Mk I andMk II crew stations utilizes a two man crew in a side-by-side arrangement. Aircraft and spacecraft func-tions are integrated in a common crew station to re-duce panel area and weight. Primary flight displaysand controls are duplicated to optimize crew equip-ment interfaces and reliability while providing a oneman emergency return capability from either flightposition. The normal systems monitoring functionsare integrated into the side and center flight consoles.Critical subsystem functions are centrally locatedwithin the reach of both crewmen.

86

DISPLAYS & CONTROLS -FHF

Hvdmnd Ckt'ito Subsystem &Data Acq Network

87

For the FHF test program, only those displaysand controls required to monitor and control aero-,dynamic subsystems are included in the crew sta-tion. The Mk I/II crew station design is modularsuch that a high degree of flexibility is providedto insure maintenance of all components, and thepractical separation of aircraft and spacecraft displayand control functions while minimizing any con-straints on the FHF test program. With the excep-tion of the primary flight displays and controlsrequired for both aerodynamic and space flight,this separation of functions is maintained.

All commands originating in the crew station

are hardwired to the subsystem functions under crewcontrol. Flight data displays are hardwired to datasources. Subsystem and C&W data, with the excep-tion of the data required for vehicle initialization,is collected via a redundant data collection networkconsisting of RAU's (Remote Acquisition Units)located throughout the vehicle.

Approximately 695 data points are accessibleto the crew in the orbiter vehicle via the Mk Idedicated displays. Measurement redundancyis provided for subsystem status data utilizing thetwo keyboards normally used to input commandsto the GN&C computers.

88

DISPLAYS & CONTROLSMARK I

Hardwired Ckt'ito Subsystem &Data Acq Network

Vehicli

Orbiter

Booster

Common(Orb & Bttrl

K«V

R lTTTTh

CZZ]

89

The Mk II vehicle offers a high degree of auton-

omous on-board crew operation, management and

checkout of vehicle subsystems. To enhance the

crew's role consistent with operational requirements

of the Mk II vehicle, two CRT displays and a micro-

film viewer are added to the crew station for display

of subsystem and expendables status, and the display

of corrective action procedures following a sub-

system failure. Data will be presented in sufficient

detail to allow the crew to isolate subsystem mal-

functions to the LRU level.

90

DISPLAYS & CONTROLS -MARK II

Vihicli

Orbitlf

Booster

Common(Orb & Bitrl

Key

K^S7777*

' '

• • •

91

Displays and controls for FHF include:

• Aero flight displays & autopilot controls/SAS

• Primary and secondary aero flight controls

• ABES instruments and controls

• APU's & hydraulic system displays and

controls

• Auxiliary systems and controls

• Partial communication subsystem controls

• Partial ECS displays and controls

• C&Wdisplays

• Fire controls for ABES and APU's

• Timers

• Lighting controls

• CB panels

92

FHF ORBITER DISPLAYS & CONTROLSSUBSYSTEM

93

Displays and controls for MKI include the follow-ing additions required for space flight:

• Data entry keyboards

• Main propulsion subsystem displays and

controls

• ACPS displays and controls

• QMS displays and controls

• Rendezvous and re-entry displays and

controls

• Fuel cell and inverter displays and

controls

• Spacecraft ECLSS displays and controls

• Space GN&C controls

• System abort displays and controls

• C&W for space functions

• Pyro and system separation controls

(external tanks, etc.)

• External doors and compartment status

displays

• Payload deployment and retrieval

94

MK I ORBITER DISPLAYS & CONTROLS SUBSYSTEM

95

Displays and controls for MK II include thefollowing additions:

• Two CRT MFD's for on-board checkout

• Microfilm display for malfunction pro-

cedure and textbook data

• Display and controls for docking

• Controls for TDRS comm link, and ex-

tended EVA communications

• Payload monitoring and control

96

MK II DISPLAYS AND CONTROLS SUBSYSTEM

1. FLIGHT IM5T PNL2. FLIGHT IN5T PHI(SPACEMODE.)3. EXT ENVIRONMENT4. TTCA/ACA MODE SEL '5. TANK 8ATT S£L6. EXT TANK H/0 JETTISON7. NAV/COMM PNLS8 INSTRUMENTATION RCDR PNLS9. INT/EXT LIGHTS10. QMS/MAIN EN6INE START

II.WOSE WHEEL STEARINS

12. PAYLOAD DOORS CONTR PNL13. EVENT TIMER CONTR PNL14. BOOSTER MONITOR.15. FIRE WARN SYSTEM16. MISSION OISPL CONTR PNL17. ACPS E.XPEN STATUS16. CRT DISPLAY"!

B. CRT 015 PLAY '2If). CABIN TEMP/PRESSII. CAUTION ANNUNCIATOR22.QMS STATU5/ISLN

23. AIR BOTH ENG 5TATU524. HYDOAULIC STATUS25. ABORT PNL

26 ENG CHAMBER PRESS27. MAIN PROPULSION ISLN26 UICOOFILM DISPLAY

34 COMPUTER DISPLAY35. WAV CONTR PNLS36. COMM CONTR PNLS37 FUEL'CELLCRYO ISLMtCONTR35 PWR DISTROBUTION ISWICONTR39. APU SYS I5LNICCWTR

DRAG CHUTE COWTRAERO MODE YAW I BRAKES CONTR

LOG GEAR/GEAR CCWP SrAT/ANTI-SKID 4Q MASTER LIGHTING CONTR PNL30 AERO SURFACE POSIND/RUHJERrciM 41 ACPS SYS STATUS tISLN31. ACPS CMDt CONTR MODE PNL 42. ECS CONTR PNL31 AIR ERTH ENG CONTR 43 THRUST TRADITIONAL CONTR ASSY

33. SAS/CMD -AUTO PILOT .44. ATTITUDE CONTR ASSY

97

Common equipment have been utilized, where

practical, in the orbiter and booster crew station

designs. Typical examples of common equipmentinclude flight director attitude indicators, horizontal

situation indicators, air data displays, multipurpose

altimeter, C-band altimeter, turn and slip indica-

tors, engine instruments, data entry keyboards, and

subsystem instruments.

98

MK I BOOSTER DISPLAYS & CONTROLS SUBSYSTEM

rO EftJ

99

The Grumman/Boeing Mk I/II low cost base-line system designs utilize dedicated flight instru-ments rather than the multipurpose CRT displayspreviously proposed during Phase B. The rationalefor this basic change evolves from the importanceplaced on reducing initial development costs. CRTdisplays, such as the EADI flight display, offerfeatures not attainable with dedicated instruments:e.g., format flexibility, integrated primary flightdata, better resolution and accuracy. Displays ofthe EADI type have been used in Grumman air-craft, which include the A-6A series, the F-l 11,and the F-14. Such a display was included in theSST design by Boeing. Of these and the many otherdesigns which exist, none are directly suitable for aspace shuttle mission. The space shuttle, because ofits unique requirements, represents additional devel-opmental costs. These costs together with pilotreluctance to accept an EADI without mechanicalinstrument backups makes the EADI less attractivefor a low-cost development program.

100


DEDICATED MECHANICAL FLIGHT INSTRUMENTS VS. ELECTRONICDISPLAYS CRT'S

ADVANTAGESA. Two-Man Flight Crew Feasible With Con-

ventional Instruments (AdditionalBooster Simulation Required)

B. Pilot Confidence Suggests Flight CRTDisplays Be Backed Up by Con-ventional Instruments

C. Minimum Development With Conven-tional Instruments/Parallel Develop-ment Program for CRT Displays NotCost Effective

DISADVANTAGESA. Flight Data Decentralized on

Several Instruments RequiringMore Panel Space

B. Reduced Display Flexibility(Scale, Format)

C. Data Processing Required/Instruments Can Not Be DrivenDirectly From Sensors in AllCases

101

Conclusion:

Feasibility of an integrated two-man flightcrew established

Rationale:

• All D&C'S for all flight modes physicallycontained in a two-man crew station

• Panel size comparable with current large aircraftaircraft

• Cockpit geometry per Mil Spec. 1333

• Total required panel area can be furtherreduced through optimized time-sharingof panel space for non-contiguous flightmodes, i.e. orbital vs. ferry

The use of off-the-shelf D&C hardwarereduces crew training and operationaltask demands thru confidence and famil-iarity with standard equipment

Integrated orbital/atmospheric crewstation arrangement:

- Will enhance crew operations particu-larly for the coordination requiredduring the transition phase

- Will allow a more optimized one-manemergency return capability

- Will not constrain FHF

Primary flight display & control techniquesdemonstrated by simulation

102

HARDWARE SUMMARY DISPLAYS AND CONTROLS

FitSubsysDisplays/Instr

Data EntryDisplayKeyboards

Sys ConfigSubsysControl

Phase B

• Orbiter- 4CRTMDS• 16S/S

Inst- Microfilm

Disp.• Booster

- 4 CRTMDS20 S/SInstr

2 CRT/Keyboards

KeyboardsFor S/SControlSw's forVehicleInitialization

FHF• Orbiter

54 Fit &S/S Instr

• Booster- 57 Fit &

S/S Inst

None

DedicatedDevices

Mkl

• Orbiter- 82 Fit &

S/S Instr

• Booster• 63 Fit

&S/SInstr

2 CRT/ Key-boards(Simplified)

No Change

Mkll• Orbiter

- Min Change- 20BCMFD- Microfilm Disp

• Booster- No Change

No change

No Change

103

HARDWARE SUMMARY DISPLAYS AND CONTROLS (Cont)

Caution &Warning

PrimaryFitControls

Phase B

Annunciators,MasterAlarm, &Tone

• Orbiter- Side Arm

ACA&TTCA

- Pedals- Throttle

Trim• Booster

• Side ArmACA

- CombinedThrust

- ThrottleTrimPedals

FHF

No Change

No Change

Mkl

No Change

No Change

Mkll

No Change

No Change

105

This FHF telecommunications subsystem is re-quired for First Horizontal Flights (FHF) to supportthe demonstration of vehicle performance within theatmosphere, for the substantiation of airframe per-formance, such as takeoff, subsonic maneuvers, low-energy approach, and landing. The flights will be con-ducted with the aid of chase aircraft within line-of-sight of test site telemetry and radar tracking systems.UHF voice transceivers, an S-band DFI transmitter,and C-band/L-band transponders support these func-tions, respectively. Landing will be conducted underVFR (visual flight rules) and is supported with the aidof a C-band altimeter and ground control using thevoice link. In the event add-on requirements evolveduring the FHF program (aircraft ferry to alternatetest site, high energy landing, etc.), the additional tele-communications capabilities necessary — for example,area navigation - will be fulfilled with strap-on equip-ment.

The telecommunications subsystem adoptedfor FHF is common for the orbiter and reusablebooster.

106

TELECOMMUNICATIONS -FHFV V

| FHF Only |

Vihicta

Otbitn

Boaaw

Commoo(Orb & Brtrl

Kr,

R^ l

&Z2

CD

• • •

707

This Mk I telecommunications subsystem is forboth atmospheric and space flight. Initial objectives willbe a test program to demonstrate the performance ofthe vehicle and the Mk I telecommunications subsys-tems which evolve into a fully operational system.During Mk I horizontal flight tests, area navigation(TACAN), landing aid (MSB) and ATC communica-tion capabilities will be demonstrated. These testswill be augmented with L-band ATC and C-bandtransponders (similar to FHF) to satisfy ground com-merical and range instrumentation tracking require-ments and are removed prior to Mk 1 FMOF.

During Mk 1 vertical test program, communica-tions and ranging'with MSFN will be demonstrated.Operational and DPI telemetry will be accommodatedvia the USB (orbiter only) and S-band FM trans-

mitter, respectively. Rendezvous ranging with co-operative targets is accomplished with TACAN (usedin area navigation) in an air-to-air ranging mode.

During operational flights, the DPI transmitterscan be removed; however, they have the inherentcapability of transmitting TV (LCRU quality) shouldthe requirement evolve. In addition, the inherentcapability of the dual UHF ATC transceivers willallow communications with Apollo EVCS.

The Booster Mk I telecommunications subsys-tem is identical to the orbiter with the following ex-ceptions: it has no unified S-band communications,includes C-band transponder for tracking, has only theC-SCAN version of the MSB system, and has twoC-band altimeters.

108

TELECOMMUNICATIONS -RfcH? MARK I

V

Vehicle

Orbitar

Booster

Common(Orb 8 Bstrl

Key

re\537777A\ 1

. . .

SW SW C-BandAlt

Ku-BandMSBXCVR & ~^Dl€odet 2 ComBUtar/

A A J. 4 DisplayT T T T+ •> Computar/Displays i ..,.,. 1 ,.

UHFXCVRATC

1

J

Computer

2

LBandTacanXCVR

2

'* 1Computer/Display

Audio

2

I iHeadset/ PeyloedMike

vCvs>v\

Beacon

con ^J

109

This Mk II telecommunications subsystem is forboth atmospheric and space flight. Initial objectives aresimilar to the Mk I subsystem. The booster telecom-munications subsystem remains the same as for Mk I;however, added to the orbiter is a VHP TDRS termin-al and EVA capability. The later is accomplished withthe UHF ATC transceiver operating in a full duplexmode utilizing a wideband secure voice channel capa-bility.

110

TELECOMMUNICATIONS -II

V V'

Comptitar/Dilpliy

Vehicle

Orbiter

Booster

CommonlOfb & Bltt)

Key

Rs5SS7777%

[=3• • •

Vehicle ,

Orbiter

Booster

Common(Orb S 6m)

Key

F? ?lT7//~/\\jf£zA

\ 1

AudioCentir

2

Rcdr Bflicon

VHFBeacon

Hndtn/ PeyloadMike

111

Integrated vs. Overlay DPI Telemetry

Full overlay DPI telemetry (RF hardware) wasselected for the booster and partial for the orbiter.An overlay approach enables the removal of DPI tele-metry antennas and transmitters from the vehicles forthe operational flights. The resulting weight reductionprovides increased payload capability with minimumvehicle scar. The orbiter DPI is partial overlay sinceits telemetry transmitter shares (frequency multi-plexed) the orbiter S-band communications antennas.This approach minimizes orbiter antenna quantitiesand enables multifunction considerations for thistransmitter during operational missions; for example,TV or payload support.

Area Navigation/Landing Aid

Of the several area navigation/landing aids com-pared, the TACAN/Microwave Scanning Beam (MSB)

combination was selected. Primary reasons for thisdecision is that both equipments are available, pro-vide adequate performance, do not depend on com-plex software processing, and enhance pilot confidencebecause of existing similar applications.

TACAN is a multifunction equipment (used ina rendezvous mission) and interfaces with numerousexisting ground and shipboard stations located through-out the world.

The MSB has been demonstrated in high glide-slope and flared landings, both applicable to the shut-tle, and is functionally compatible with the FAA mi-crowave landing system (MLS).

Rendezvous Ranging Aid

TACAN was selected as an rf rendezvous aid be-cause it has existing air-to-air ranging capability, ismultifunction (area navigation), has adequate per-formance, available off-the-shelf hardware, and rela-tively low cost. Furthermore, it has been demon-strated in military aircraft refueling operations in theair-to-air ranging mode and incorporates existingdigital interfaces.

112

SYSTEM ARCHITECTURE, MAJOR DECISIONS:TELECOMMUNICATIONS

KEY ISSUE DECISION

• Integrated vs Overlay DPI Telemetry • Overlay- Payload Advantage- Minimum Scar

• Area Navigation/Landing Aid-TACAN/MSB • TACAN/MSBvs PRS vs VOR/DME/ILS vs Ground Precision - Minimum RiskRadar - Pilot Confidence

- Computer Decoupled- Demonstrated

• Rendezvous Ranging Aid-TACAN vs S-Band • TAG ANvs ATC vs PRS - Multi-Function Use

- Demonstrated (Mil) Applications- Adequate Range, Accuracy

113

Orbital Communications/Navigation

Unified S-Band (USB) and VHP TDRS com-munications/navigation with the ground were con-sidered. Based upon the use of existing ground MSFNfacilities, which is assumed not chargeable to the shut-tle program and proven capability, the USB was se-lected for Mk I.

The implementation of the USB equipment con-sidered transceivers from the LM, CSM, ERTS, andSGLS programs. Selection of the LM transceiver wasmade because it is available in the existing inventory(which minimizes program cost), fully compatible withthe signal processor, man-rated, and satisfies link mar-gins without a power amplifier. The Mark II avionicswill have an interface with the TDRS at VHP. Thiswill be the primary link to the ground while the USBwill be a backup, since MSFN is expected to phasedown. The VHP TDRS terminal will allow narrow-band voice or data transmission and turnaround rang-ing from the ground. Should wideband data or TV berequired through the TDRS, then a Ku-band terminalis necessary.

Antennas/Radomes

Three key issues related to antennas/radomesare flush-mounted versus protruding, high versus mod-erate temperature antennas, and ablative versus re-

usable radomes.

Flush-mounted antennas are selected for boththe orbiter and booster because they have the minimum impact on the vehicle thermal protection sys-tem, result is no aerodynamic drag, and require lessmaintenance.

Moderate temperature antenna designs, withhigh-temperature insulating radomes, are utilized sincethey enable the use of conventional materials and ex-isting design techniques. The vehicle thermal protec-tion system design requirement to protect the bond-line of the vehicle aluminum structure to a maximumtemperature of 300° F may enable the use of modifiedoff-the-shelf antennas.

The radomes (rf windows) selected for Mk I or-biters are ablative (SLA-220) types because they arecompatible with the vehicle ablative (SLA-561) TPS.Ablative radomes are low risk because they have beensuccessfully used on numerous reentry vehicles atheating rates equal to and much greater (>10 times)than those expected on the space shuttle. The ra-domes for Mk II vehicles will be ceramic types similarin material to the vehicle's Mk II external insulationTPS. The booster radomes may be identical to theorbiter if cost studies for detail designs show thatcommon antennas/radomes are cost effective.

114

SYSTEM ARCHITECTURE, MAJOR DECISIONS:TELECOMMUNICATIONS

KEY ISSUE DECISION

Orbital Communications/Navigation-S-Band * S-Band USB

USB vs TORS

Antennas/Radomes Flush Mounted vs Pro-truding High/Moderate Temperature WithAblative/Reusable Radomes

- Utilize Existing Ground Facilities- Proven- Low Cost

• Flush Mounted, Moderate TempAblative Radomes (Mk I)Reuseable Radomes (Mk II)

— Compatible with TPS— Existing Design Techniques

115

This diagram shows bulk power transmissioncircuitry and switching requirements only and doesnot indicate power distribution/control/protection toutilization equipment; nor does it indicate the neces-sary control-logic/control-circuitry or protective func-tions incorporated for source, source transmission lineand bus protection. The use of the circuit protectorsymbol (A) does not necessarily indicate a specifictype of protective device (thermal/magnetic circuitbreaker, remote control circuit breaker, fuse, limiter,solid-state power controller etc.) but serves to indi-cate a requirement for circuit protection at that point.

During ground operations, 115/200V-30-400Hz power is supplied through an external power re-ceptacle at the external power panel. The externalpower panel includes an External Power Monitor(XPM) which monitors external power quality (volt-age, frequency, phase sequence etc.) and supplies pow-er for the external power contactors. Since the ex-ternal power contractors can only be energized by ex-ternal power, during flight operations the EPS is con-figured into two essentially independent systems thatare physically, electrically, and thermally isolated sothat single or multiple faults occurring on one systemwill not affect or be propogated to the other system.Alternating current power sources are not parallelled,since parallelling involves additional circuit complexityand switchgear/protection requirements which tend todegrade reliability. Since parallelling circuitry is notprovided, inadverdent parallelling is avoided in the de-sign and implementation of the system control logic.

A Generator Control Unit (GCU) is providedfor each generator, which:

• Monitors and controls the generator output• Provides for generator protection in conjunc-

tion with current-transformer packages• Provides for generator transmission line and

bus fault detection and protection in con-junction with current-transformer packages

• Provides power for operation of the associa-ted generator contactors

Each fuel cell is controlled by a Fuel Cell Con-trol Unit (FCCU) which:

• Monitors and controls the operation of the fuelcell

• Provides protection for the fuel cell, fuel celltransmission line and fuel cell lines in con-junction with line current sensors

• Provides power for operation of the associatedfuel cell contactors

The inverters (Inv 1, Inv 2) are integrally moni-tored, controlled and protected. They also providepower for operation of the associated contactors.Inverter line and bus protection, is provided by linecurrent-transformers in conjunction with associatedtime delay/logic circuitry.

Transformer-rectifier (T-R) output voltage ismonitored by its associated contractor which will notpick-up unless the T-R output exceeds the minimumspecified voltage, T-R bus fault protection is providedby line current sensors with associated time delay/logiccircuitry.

116

POWER SYSTEM

II

117

The baseline power generation subsystem (PCS)

for the orbiter satisfies the total electrical and hydrau-

lic power requirements of the onboard system and sub-

system utilization equipments with FO/FS system

redundancy. The PCS consists of a combination of

power sources, i.e., fuel cells, auxiliary power units

(APU), and batteries. The fuel cells supply prime

electrical power during orbital operation. The APU's

supply electrical and hydraulic power during the

transitional phases, both proceeding and after the orbi-

tal phase. The batteries are utilized to provide emer-

gency electrical power during all mission phases. Elec-

trical and hydraulic power for the ferry mission is sup-

plied by the APU's modified for JP/air operation.

Each fuel cell is sized to supply the total vehicle load

during orbital operation so that the mission is not af-

fected by the loss of one fuel cell. In the event of loss

of both fuel cells; the APU's are activated and elec-

trical power is supplied by the generators through a

power cross-tie between the forward and aft busses.

Each generator is sized for total vehicle load.

Utilization of ac generators permits minimum

conversion losses due to the high percentage of ac pow-

er required.

Hydraulic power is generated by constant speed,

variable displacement pumps driven by the APU

turbine. Each of the four APU's drive two pumps, with

with a total of four pumps required for safe return.

The hydraulic system pressure is 3000 psi.

118

ELECTRICAL POWER SYSTEM BASELINE

• Two H2/02 Fuel Cells @ 28vdc, 7 KW Continuous/1 OKW Peak

(Fwd Fuselage) (Note Below)

• Two Secondary Ni-Cd Batteries @ 28 vdc, 36 AH (Fwd Fuselage)

• Four N2H4Aux Power Unit (APU) Generators @ 115/200 vac,

3 Phase, 400 Hz, 15 KVA ( Aft Fuselage)

• Dedicated Apollo CSM Cryogenic Tanks for Fuel Cell Ho and On

and EC/LSS 02

• Dedicated Titan IMC N2H4 Tanks With LM A/S Helium Tanks for

Pressurization

• Power Transmitted at 115 vac and Power Distributed to Loads at

115 vac and 28 vdc

• Power Conditioning - Max Use of Existing Commercial/MlL/Space

Equipment, Located in Pressurized Cabin Area

• Power Control - Max Use of Conventional Electromechanical

Switches, Relays, Circuit Breakers, etc.

(Note: Mk I - 2000 Hr Life: Mk II - 5000 Hr Life)

119

The primary electric r jwer system for the orbit-er is significantly different from conventional aircraftand/or spacecraft power systems. These differencesresult from the nature of the vehicle mission and therequirement to reduce the possibility (and the rate ofoccurrence) of total loss of electric power during anymission phase - with emphaiss on the minimization ofeven momentary power interruptions during criticalphases of the mission.

Electric power is derived from three distinctpower source systems:

• For ground operations, 115/200V-30-400Hz power is supplied from external source (s)

• During all flight phases, except orbital opera-tion, 115/200V-30-400 Hz power, conform-ing to MIL-STD-704A, is supplied by APUdriven generators

• During orbital operations, 28 vdc power issupplied by H2/O2 fuel cells, with Ni-Cdbatteries for emergency and peak power re-quirements

Hydrazine APU fuel is stored in dedicated TitanIIIC RCS tanks. Pressurization for the APU fuel tanksis provided with high pressure ambient storage ofgaseous helium. Three LM A/S helium tanks areutilized for this purposes. The APU's and APU fueland pressurization storage are located in the aft sec-tion, behind the payload module.

The H2 and 02 reactants for the fuel cells arestored in dedicated cryogenic tankage. Four hydrogen andand three oxygen Apollo CSM tanks provide the totalfuel cell requirement in addition to the EC/LSS oxygenrequirement. The fuel cells, fuel cell reactant storageand batteries are located in the forward fuselage, aftand below the pressurized compartment.

720

POWER GENERATION - KEY FEATURES

• APU's Supply All Electrical and Hydraulic Power During All Mission

Phases Except Orbital Operation

- Fuel Cells Sized for Orbital Load

• Four APU's @ 210 shp Each

- Two 45 gpm Pumps and One 15 KVA Gen per APU

- Hydrazine Monopropellant APU

• Two Fuel Cells @ 7 KW Each

- Mk I Shuttle Fuel Cell

• Two Secondary Ni-Cd Batteries

- 36 AH Skylab A/WI Battery

121

V

UlK

This chart depicts the flow of events in the

development cycle for the vehicle flight software

and is an idealization of the shuttle flight software

project. The timing and phasing of the critical re-

views - PRR, PDR, CDR and FSRR. and their

relationship to other major project events are

shown. The Software Development Plan outlined

is idealized in the sense that the shuttle flight

software will be implemented with a phase de-

velopment. Software will be developed for First

Horizontal Flight (FHF) and for Mk I and Mk II

Manned Orbital Flights. For each of these software

developments, there is a set of the above reviews

and the associated project events.

One significant review is the Preliminary

Design Review (PDR). This review is involved

with obtaining the concurrence and approval of

the preliminary software design. Preliminary soft-

ware design must be based on stable functional

requirements, algorithms, and control laws, etc.

The availability of stable functional requirements

at this stage of the program is a prerequisite to an

orderly software development. Final software design

is concluded with the Critical Design Review (CDR).

The preliminary scheduling of these major

reviews for the phased flight software development

are indicated.

124

SOFTWARE DEVELOPMENT PLAN

SOFTW»fl£ SUPPOOF SYSTEM INTf G

i SPECS FOB TEST DAT*REDUCTION PROGRAMS

125

Successful development of the Space Shuttle

software requires a comprehensive management

effort. The shuttle software for the low-cost

avionics system is a multi-project operation de-

manding control and visibility of all software

elements.

To ensure technical, cost, and development

success for the Shuttle Program, it is necessary for

all these projects to be properly coordinated and

managed.

The accompanying chart indicates some of the

planning factors that must be considered in drafting

detailed management plans for the Phase C/D efforts.

In the future, these planning factors will be cate-

gorized into immediate and long-range management

tasks. The creation of the Software Management

Plan will be an iterative process reflecting the level

of detail required at various stages in the software

development cycle.

126

SOFTWARE MANAGEMENT PLAN• Identification and Definition of Major Software Elements• Identification of Contractor, Associate Contractors and Subcontractors for Shuttle

Avionic Software Development• Software Element Interface and Commonality Management Plan ,• Identification of Government Resources to Be Applied to Program. Coordination of

All Program Resources Between Government, Contractor, Associate Contractors andSubcontractors

• Monitoring of Various Software Development Activities• Status Reviews and Progress Reporting System• Acceptance Testing and Software Certification of Individual Software Elements• Software System Integration Plan for Avionic Software Elements, i.e.,

- Phased Integration of On-Board Software Through ASDL and IATL- Integration With Pre-Flight Ground Support Software .- Integration With Post Flight Ground Support Software- Integration of Flight Test Software

• Certification of Flight Software• Post Acceptance Support

- Configuration Control •- Documentation Control- Operations Software Maintenance- Identification of Government Resources Committed to Post Acceptance Maintenance

• Identification of Critical Milestones for All Major Software Elements

127

The Software Development Flow Graph in-dicates the role of simulation and test facilitiesin the software development. The Shuttle Programrequires specialized real-time and non-real timesoftware to perform the following functions:

• Non-real time software to develop, verify,and modify algorithms and control laws

• Real-time software to functionally verifythe control laws in a simulation environment(Full Mission Simulation Laboratory - FMSL)

• Non-real time interpretative simulation soft-ware to assist in flight program coding anddebugging (Avionics Software DevelopmentLaboratory, ASDL)

• Real-time software to verify the hardware/software interfaces on a subsystem func-tional level (Integrated Avionics Test Labora-tory, IATL)

The flight software development process from

algorithm development to end-item delivery is aniterative process as illustrated in the chart. Thesignificant point of the graph indicates that inorder to avoid the major "glitch" path, emphasisshould be given to development of stable algorithms,verified control laws, and a validated ASDL facilitybefore the "code/debug" effort commences. Thephased flight software effort (for FHF, Mk I andMk II) will greatly increase the likelihood ofachieving this goal in that modular software develop-ment phasing will minimize the major software glitchprospect.

NOTE:Software Development cost figures, i.e., S17.5M foralgorithm and control law verification and S19.2Mfor development and verification phases. Total Mk Isoftware costs of $36.7M are exclusive of facilityequipment costs and operating personnel, but ratherrefer to costs associated with software efforts only.Mk II software efforts add $10.7M for OBC andMCC software efforts required.

728

SOFTWARE DEVELOPMENT FLOW GRAPHProgramSpecification

AlgorithmFormulation

iControl LawVerification(FMSL)

V. fcf

Code/Debug ^InterpretiveSimulation(ASDL)

7

SubsystemHdw/Sftw Verif ic(IATL)/(FCHTL)

Off-Line SimulationsDesign Phase

Development & Verification ^1Phases Ij.

End ItemFSRR

129

The Avionics Software Development Labora-tory (ASDL) will be required for flight softwaredevelopment and verification. Software verifica-tion includes software-to-software and software-to-flight computer integration and precedes thesubsystem/system integration effort utilizing theIATL.

The ASDL facility actually contains fourfunctional areas-one for each of the following flightsoftware development efforts:

• Air Data Computer Flight Software

• Flight Control Computer Flight Software

• Data Acquisition Computer Flight Software

• Primary Computer Flight Software

Though not baselined as a result of this study,the following additional ASDL capabilities will beinvestigated for ASDL application:

• Commercial time-shared computer

• Terminals with interactive operations

Such capability may be particulaily effectivefor the detailed module coding and debugging stagewhere it can be assumed that many coding tasks arebeing carried out concurrently by many individuals.Programmer effectiveness is enhanced by significantimprovements in turnaround time. Extensive utili-zation of such a capability during software integra-tion and test, in conjunction with a full simulationcapability, is an area of further investigation.

Functionally, the ASDL facility will contain:

• Programming languages and assemblers/compilers

• A software simulation system (i.e., DigitalSimulation Software Support System)

The utilization of a high level language com-piler will apply to the Primary GN&C flight softwareonly.

130

FLIGHT SOFTWARE DEVELOPMENT AND VERIFICATIONFACILITY NEEDS (ASDL)

Programming Language & Compiler

• Code Generators for Flight & Ground Computers

• Compile Time Diagnostics, Compile Control Cross Reference Listings

Flight Software Development Facility

• Commercial Time Shared Computer

• Terminals With Interactive Operation

• Software Simulation System

131

The Digital Simulation Software SupportSystem will vary in capability with each ASDLfunctional area. The chart shows the general capa-bilities required for the ASDL to be utilized for thePrimary GN&C flight software effort. The ASDLfunctional areas will require the same general capa-bilities with varying levels of detailed complexityappropriate to each particular flight softwareeffort.

The next step in establishing the detailedcapabilities of the ASDL will be to investigateavailable support software, particularly in the areasof the "flight computer instruction simulation" andthe "run time diagnostics and debugging aids". Notonly will the availability of support software be animportant selection criteria for the onboard flightcomputers but also the selection of the "host" groundcomputer for execution of the "Digital SimulationSupport System". Implicit in the investigation ofsupport software will be a trade study to establishthe cost and schedule advantages of a Decentralizedvs. Centralized ASDL facility to support the fourflight software efforts.

132

DIGITAL SIMULATION SOFTWARE SUPPORT SYSTEM(ASDL)• Flight Computer Instruction Simulator

• Run Time Diagnostics & Debugging Aids

- Edited Dumps

- Source Language Trace

- Timing Checks

- Breakpoints

• Environment Simulation

- Vehicle & Aerodynamic

- Universe

- Subsystems Interfaced to Primary Computer, Other Computers, IMU,Displays, Controls

• Functional Simulation of Computer Interfaces

- Air Data, Incremental Digital Control, Data Acquisition

• Simulation Test Generation Support Software

• Recording & Post Run Editing Support Software

133

To appreciate and properly utilize the costsindicated on the chart, it is necessary to understandthe groundrules and constraints that apply.

Rather than initially presenting an all inclusiveFlight Software cost figure, it is perhaps more ad-vantageous to start with the costs for the code/debug effort first.

The projected cost of onboard code/debugsoftware effort (for FHF and Mk I) is $6.3M. How-ever, this estimate assumes the ideal conditions ofwell-defined algorithms and control laws at CPCEIPart II approval and additionally, that no majorchanges causing software redevelopment will beimposed during the development cycle. However,.experience indicates that total software developmentcosts, in many cases, approach almost twice the an-

ticipated development costs under ideal conditions.

This cost estimate reflects.only the coding/debugging and the related costs of production andoperations phases for FHF and Mk I and does notinclude algorithm development, control law verifica-tion, ASDL and IATL software build-up costs.

The estimates were based on the followingsoftware development efforts:

• For FHF: The Air Data, Flight Control andData Acquisition flight software efforts

• ForMkI : The Primary GN&C softwareeffort and the Data Acquisition flight soft-ware effort associated with enhanced on-board checkout processing.

134

ONBOARD SOFTWARE COST SUMMARY, $K(FHFand MK I)

• AvionicsProgramming 2,400

Production 900

Operations 3,000

Total 6,300 (Idealized Cost)

• Assuming Stable Verified Control Laws

• Computer Machine Costs Not Included

• Algorithm Development Not Included

• Control Law Verification Not Included

• Software Development Experience Factor (Multiply Ideal Cost by 2)

135

The estimated cost of total avionics softwaredevelopment exclusive of GSE related software isS47.4M. This does not include the costs associatedwith computer hardware or machine time utilization.The estimates were based on the following softwareefforts (as related to the development cycle):

• The development, verification and modifica-tion of algorithms and control laws usingnon-real time software techniques

• The functional verification of control lawsutilizing real-time software techniques ina simulation environment (i.e., the build-upand utilization of a Full Mission SimulationLaboratory, FMSL)

• The code/debug flight software effort in-cluding:

- F H F a n d M k I

- Mk II software development which is anincremental increase from Mk I incorpora-

ting significant additional OBC functionsand mission management functionsto be mechanized in flight software

Flight software verification/certificationutilizing the Integrated Avionics Lab-oratory (IATL). The IATL costs reflectIATL build-up and flight software ver-ification/certification

Flight test software will be required duringthe shuttle "flight test" program to aidin evaluating and/or demonstrating the avi-onics systems under test. Although thedefinition of the shuttle reduction require-ments has not been established, it waspossible to generate a possible softwareestimate based on solid E-2C experience(a total avionics system was evaluated onthis program) and the F-I4 instrumenta-tion system.

136

AVIONICS SOFTWARE COST MATRIX, $K

Category• Onboard Software (6,300 X 2)

• Avionics Software Development Lab (ASDL)

• Integrated Avionics Test Lab (IATL)

• Flight Test Software

Subtotal (FHF.Mkl)

Subtotal (Mk II)

$12,6003,420

2,280

925

19,225

10,700

137

• Algorithm Development I 17

• Control Law Verification )

Total Software $47,425

• Computer Machine Costs Not Included

• Facilities Operating Personnel Not Included

• Flight Test Includes Only Avionics System Testing

Memory size estimates of the GN&C baselinesoftware functional components with estimates ofthe storage impact on the Primary computer werebased on actual figures taken from an Apollo CommandModule Computer Program. The estimates for thecorresponding shuttle Primary computer program arerounded to the next 500 words; each word representsan equivalent AGC word of 15 bits plus parity. Theestimates as presented were derived by comparingthe equivalent Apollo and Orbiter GN&C functionsand making a positive or negative adjustment to theApollo word count depending on a judgement of thescope and complexity of the shuttle function.

138

SIZE AND SPEED ESTIMATES

Based on 15-Bit Word Size

Mission Control Programs

• Prelaunch

• Boost

• Orbital Coast• Rendezvous

• Deorbit

• Transition & Landing

General Purpose Programs

• Orbital Mechanics

• Navigation

• Digital Autopilot

• System Function

Variables

AGC

580

480

9090

20803030-

4010

9304090

12410

367002050/38750

GIM&C

1000

2500

9500

4500

3500

2500

5000

1500

7000

11000

48000

4500/52500

139

Before the memory estimate of the previouschart can be extrapolated into real memory require-ments, several additional factors must be taken intoconsideration:

• It is recommended that the PrimaryComputer tasks be implemented in a HigherOrder Language. This is likely to result ina 20%-40% increase in the volume of machinecode over an all-assembly language ap-proach

• The Apollo program is the result of a longperiod of development during which theAGC's limited memory and execution timewere fully exploited. A shuttle memorysize estimate should add another 10%-20%over the equivalent Apollo word count toallow for this fact (i.e., the shuttle Primarycomputer will not have limited memory andsize restrictions)

• A pad must be added to any software es-timate derived from such a comparison asassumed here. A 25%-50% increment shouldbe allowed after the above efforts have beenaccounted for

Accounting for the 32-bit word length, as re-commended, will decrease the word count 50%-60%of the extrapolated 15-bit total, due to half-wordinstruction and floating-point arithmetic economics.

It should be noted that although 50K, 32-bitwords are baselined for Mk II the resident on-board GN&C program will be somewhat reduced.This is accomplished by utilizing overlay techniqueswith serial execution of the various mission phases.This technique will also be used for the enhancedMk II onboard checkout (OBC) and the additional •"mission control processing (MCC) required. Seriousconsideration for mass memory in the Mk I baselineis under study in order to provide overlay processingof Mk I GN&C functions as well as enhanced OBCprocessing.

140

SIZE AND SPEED ESTIMATES (CONT)

.Modify ing .Factors

• HOL Implementation 15,000;, ~ • Non-Optimum Code Sharing . 5,000

• PAD 20,000

40,000

Total: Function Sizing Plus Modifying Factors .

"'. ' : . . . " 52,50040,00092,500 15-Bit Words

Accounting for 32-Bit Word Implementation

Equivalent Words: 46,250 (Half as Many Words, Twice asMany Bits)

Inefficiency Factor: 5,000 , ;

5^250 V ' - . . . .

Grand Total 50,000 32-Bit Words

..14,1

The period just prior to landing may present themost critical speed loading requirement for thecomputer. At this time the computer may be re-quired to perform all of the following four functions.

• Correct Position, Velocity by IncorporatingRadio Data - Assuming an eleven state filterand an update interval of 5 seconds, 30,000fixed-point equivalent adds (E-adds) perupdate was estimated for the computationalburden. Accounting for the once per fivesecond duty cycle yields 6,000 "E-adds"per second.

• Processing of IMU Data - The Delco MagicIII computer has approximately the sameadd speed, but half the multiply speed,as the AGC. We presume that it is 80% asfast as the AGC. In processing Carouseldata it runs at about 75% duty cycle. TheAGC can process about 44,000 "E-adds"per second. We therefore estimate thatthe processing of IMU data will require:

.8 x .75 x 44,000 = 27,000 "E-adds"/second

Computation of Desired Heading, Elevation,and Roll, and Control of Pitch, Yaw, and RollRate- Based on AGC experience, it is reason-able to expect an update rate of ten persecond and a doubling in complexity. Thesefunctions, therefore, are estimated to re-quire about 20,000 "E-adds" per second.

Computations for display should not re-quire more than another 10,000 "E-adds"per second.

Totals Item 1 6,000Item 2 27,000Item 3 20,000Item 4 10.000

63,000 (Fixed-pointequivalent addsper second)

142

COMPUTER SPEED REQUIREMENTS

Period Just Prior to Landing

TASKS

Item 1 Correct Position, Velocity by Incorporating Radio Data

Item 2 IMU Data Processing (One IMU Only)

Item 3 Compute Desired Attitude, Attitude Errors

Item 4 Display Desired Attitude, Attitude Errors

.743

Floating-point operations, if performed by hard-ware, are typically about twice as slow as single-pre-cision fixed-point adds. Algorithm implementation,utilizing floating-point operations, degrades approxi-mately 10% when attendant fixed-point operationsare accounted for, based on a preliminary analysisusing the IBM 4ir AP-1 characteristics. However, theestimates for items 2, 3 and 4 (below) involved extrap-olating computation time based on executing similarcomputations in other computers. It is likely that only50% of the operations in items 2, 3, and 4 will actu-ally involve operations that should be done in floating-point. Item 1 on the other hand should be done essen-tially completely in floating-point.. Therefore, toextrapolate to a machine that executes floating-pointarithmetic at about a 10% speed disadvantage, the-following table estimates the fixed-point equivalentadds per second speed requirement: (reference chart)

Item 1Item 2Item 3Item 4

Total

6,60028,35021,00010,50066,450 (fixed-point equivalent adds

per second)Finally, based on the aforementioned preliminary

analysis, software floating-point is about 10 timesslower than fixed-point arithmetic operations. In thiscase, the numbers would total as follows:

Item 1Item 2Item 3Item 4Total

60,000135,000100,00050,000

345,000 (fixed-point equivalent addsper second)

We now invert these numbers to obtain thefixed-point add time required for the shuttle com-puter:

• Case 1 - Everything in fixed-point arithmetic16 microsec. add time

• Case 2 - Floating-point hardware15 microsec. add time

• . Case 3 - Floating-point software3 microsec. add time

Floating-point hardware is, therefore, baselined for theGrumman/Boeing Avionics System. Although theabove analysis is somewhat immature, it clearly showsa significant margin of safety in computer timingutilization (approx. 15% utilized).

144

COMPUTER SPEED REQUIREMENTS (CONT)

TOTALS

Casel: " All Fixed Point Operations

16_ jusee Fixed Point Add Time

Case 2: Floating Point Hardware

15 ysec Fixed Point Add Time

Case 3: Floating Point Software :

-\; ; , ''-3psec''Fixed Point'Add Time '"'

1.45

During the study period, Grumman investigated

the technical and cost benefits that would be derived

from utilizing several cost reduction techniques. The

net effect of these measures is implicit in the cost

analysis.

The following charts summarize the technical

aspects of these cost reduction measures considered

during the study.

146

AVIONIC SOFTWARE COST REDUCTION ANALYSIS

• Centralized/Distributed Computer Systems

• Application of High Order Language Compiler

• Application of Floating Point

• Software Cost Drivers

• Software Development Risks

147

In the course of the Avionics Study, several com-puting configurations were examined. The systemselected and baselined is distributed with four com-puting centers, as follows:

• Primary Computer (PC). The navigation,guidance, and control computations, sensorprocessing, OBC and mission control func-tions

• Air Data Computer (ADC). The air datasensor processing

• Flight Control Computer (FCC). Thedigital flight control and inner loop auto-pilot functions

• Data Acquisition Controller (DAQC). Rea-sonableness tests and limiting checking ofdata from remote acquisition units.

The distributed approach was selected basedon the groundrule of phased development (FHF,Mk I and Mk II) and advantages obtained in minimi-zing peak annual funding.

The technical rationale leading to the choice ofa distributed system is as follows:

• The distributed system leads to a high degreeof software modularity in that separatefunctions are virtually self-contained

• The separation of the computing functionsinto distinct computers permit a higher de-gree of verification independent of systemintegration

• Separation of functions forces early defini-tion of system interfaces which can lead tooverall cost savings

• The distributed approach permits bettermanagement visibility on cost and schedulematters

• The distributed system is highly compatiblewith the phased approach to avionics de-velopment.

The following advantages of the centralized ap-proach were assessed from the viewpoint of compati-bility with the groundrules of the low-cost avionicsstudy:

• • More-flexibility and adaptability to changeis offered by a centralized system. In a dis-tributed system, the major interfaces arecemented in hardware

• A greater burden is placed on the systemsintegration function

• Less equipment is added to the vehiclewhich leads to a lesser number of failuremodes and "back-up" cases.

• A pitfall of defining system interfaces be-fore system requirements, which can hap-pen with distributed systems is avoidedwith the centralized approach.

148

CENTRALIZED/DISTRIBUTED COMPUTER SYSTEMSSOFTWARE IMPACTS

• Distributed System Selected

- Air Data Computer

- Incremental Flight Control Computer

- Data Acquisition Computers

- Primary On-Board Computer

• Rationale

- Software Development Management Is Improved by the Separation of DisciplinesInto Specialized Groupings

- Software Fault Isolation Is Enhanced During System Checkout and Verification

- Distributive Approach Permits Parallel Development of Separated Avionic Functions

149

The use of a higher order compiler language(HOL) is baselined for Shuttle software development.Primary reasons for this recommendation are: 1. toenhance communications among many contributors,cooperating toward a common goal, and 2, to reducethe amount of necessary verification by preventingthe occurrence of certain classes of errors in the firstplace. Both reasons contribute significantly to a re-duction in overall software development costs.

An Improvement in Communications

In this context communications are meant toinclude requirements and specifications, descriptions,all forms of documentation, methods of configura-tion and change control, management visibility andthe technical exchanges, written and oral, that mustoccur among engineers, analysts, and programmers.Additional significant factors are included on thechart.

Reduction in Verification Effort

The production of software can be divided intotwo phases: preparation and verification. Anymethod which can ease the verification burden willreduce overall cost and improve reliability. An

organized approach to the prevention of errors issuch a method, and a HOL can be instrumental inprevention. That this assertion is true can be seenby comparing the probability of error when usingassembler and compiler coding techniques. Addi-tional major advantages of a compiler language arethe-ability to perform extensive checking at compiletime and the opportunity to structure and modula-rize programs.

Compiler Disadvantages

The skilled assembly programmer producesbetter assembly language code than HOLwould in theorgininal coding phase. But, following the inevitablepatching of programs during first system checkout,the HOL (which regularly recompiles the model) gen-erated Code has suffered less deterioration in codingefficiency. The overall effect is that HOL programefficiency is not appreciably degraded compared toassembly language program. Typically, real-timecontrol and I/O interface programs require specialcode to function effectively. HOL is not well suitedfor this purpose. Therefore, real-time systems codedin HOL will inevitably have assembly language sec-tions.

150

HIGH ORDER LANGUAGE COMPILER APPLICATION

• Advantages of Higher Order Language Compiler:

- Clearness and Readability of Higher Level Language Improves CommunicationsBetween Problem Definers, Software Designers and Programmers

— Better Enforcement of Standards and Conventions

— Better Documentation (Automatic Flow Chart Generators)

— Easier to Learn, Write, Understand, and "Think-In"

— Easy to Modify and Debug - Better Detection of Problems and Clerical Errors

— Operate on System Model at a Higher Level of Abstraction

— Easy to Vary System Model

- Reduction in Verification Effort by Elimination of Certain Errors

• Disadvantages:

- All Real-Time Control Module Can Not be Written Completely in a HigherLevel Language

- Programmer is Usually Prohibited From Applying Whatever Knowledge HeMight Have of the Object Machine

- Efficiency of Object Code Execution Usually Lower Than Assembly Language

757

During the course of the study, the utilizationof floating-point vs fixed-point computation was ex-amined. Implementation of fixed and floating-pointwas evaluated by examining hardware and softwaremechanizations.

The results clearly indicate that cost reduction(approximately 10%) is obtained by utilizing hard-ware floating-point for the Primary computer.Floating-point hardware was selected over softwarebased upon the timing utilization advantages offered.

Emplementation of a high order languagecompiler is also improved by the availability offloating-point instructions in the object computer.

152

FLOATING POINT APPLICATION

• Advantages of Floating Point Arithmetic:

- Scaling Analysis Greatly Eased

- Simplifies Program Development

- Eliminates Error

- Simplifies Program Changes and Maintenance

- Increased Feasibility of Utilizing Higher Level Languages

- Memory Requirements Lessened

• Disadvantages:

- Increased Hardware Costs

- Increased Computational Time Requirements

— Software Floating Point

— Hardware Floating Point

Hardware Floating Point Application Selected;

153

The study attempted to identify those itemswhich could impact the development cycle andwhich would tend to act as high cost drivers.These items were culled from the experiencegained from Apollo by Grumman/Boeing and itsassociates and from the Grumman experience onthe F-14A, E-2C and A-6E Projects.

Both the number of delivered softwarearticles and the number of software impactinghardware configuration changes directly bear onthe software development costs. Every majorchange to an established software article precip-itates a complete testing and verification cyclefor the system software.

A significant cost driver is "Man-Ratingvs Interim Operational Capability" and dealswith the introduction of the astronaut into theonboard processing loop. This cost driver refersto changes to the program to satisfy uniqueoperating mode requested changes, rather thanto changes that modify or expand the softwarecomputational functions. To offset the effectsof this cost driver, it is recommended that theman-machine interfaces be defined early in theprogram and be treated with the same rigidity asany other interface.

The remaining cost drivers are summarizedon the chart and are self-explanatory.

154

HIGH COST DRIVERS-SOFTWARE

• Number of Delivered Software Articles

• Number of Hardware Configuration Changes

• Orderly Development/Avoid Saturation, Peak Loading

• Man Rating vs Interim Operational Capability

• Adequacy of Computer Size, Speed

• Adequacy of Support Software

• Failure Detection/Switchover/Configuration Management

755

Software development by its very nature providesrisks because its delivered form is a unique end-item.This fact is particularly true of Shuttle avionics soft-ware since no directly related effort (even Apollo)provides applicable off-the-shelf software. Individualhardware elements may each be truly shelf items;however, their combination interfaced to a computercauses a unique configuration for software implemen-tation. The chart indicates some of the more signifi-cant risks in avionics software since they are dependentupon early decisions in the development cycle.

• Computer Speed/Size - The selection of theflight and ground computers of necessitymust be made early in the program. It is,therefore, important to base these selectionsupon carefully derived processing estimates inorder to avoid redesign of software or themore serious reprocurements of larger, fasterprocessing capability. The risk associatedwith under-sizing memory and speed is one ofincreased costs and program delays caused bymajor redesign activities

Hardware Incompatibility - The mix ofequipments required for onboard functionsintroduces hardware/software compatibilityproblems. Interface design and the coordina-tion of the proper interchange between hard-ware systems, computing hardware, andexecutable software represents an importantdevelopment risk. The Integrated AvionicsTest Laboratory (IATL) and its ability toexercise all subsystems, and their interfaceswith the flight software shall provide themeans to minimize risk. An orderly and rig-orous system checkout of all combinations ofsubsystem functions is required to establishhardware/software compatibility

Level of Autonomy - The level on onboardautonomy required for checkout representsa significant development risk. The greaterthe amount of independent autonomy on-board compared to ground dependency, thegreater the development risks. Criteria ofcrew safety and mission criticality must berigorously applied to minimize this risk

156

SOFTWARE DEVELOPMENT RISKS

• Speed/Size

• Level of Autonomy

- OBC

- MCC

• Software Reliability

757

It should be recognized that this report does

not conclude the software requirements effort for the

Low-Cost Avionics. Many areas of additional activity

have arisen as an outgrowth of this study. Some of

the more (Dressing of these are outlined. The past

experience of Apollo and of the other Grumman

flight software efforts indicates that the software

activities can never be started too early. The bulk of

the high cost and risk drivers outlined in this report

can be offset by proceeding with these software inves-

tigations now.

158

AREAS FOR FURTHER INVESTIGATION

• Selection of Flight Computers

• Definition of Simulation Facility Requirements

• Redundancy, Failure Recovery Implementation

• Definition of Data Interfaces Between Computers

• First Layout of Software for Flight Computers

• Define Software Configuration Management Plan

• Executive Structure

• Software Reliability

• Utilization of KSC Facilities for Flight Test

759

NOI1VU931NISW31SAS

MAJOR ELEMENTS OF ORBITER DESIGN DEVELOPMENT TEST & EVALUATION PLAN

System Design System Development System Operations

Scientific Computing(Non-real Time)

System Simulation(Real Time)Dual Seat Motion BaseBreadboard TestingElectrical \„ . ,. > Test BenchsHydraulic

Avionics Software Develop-ment Lab (FHF & FMOF MkI, Mk II)Full mission Simulation Lab(FHF & FMOF)

Flight Control/HydraulicTest Lab (FHF)Integrated Avionics TestLab (FMOF Mkl, Mkll)

ASDL (FHF, FMOF, MKI, MKII)

FMSL (FHF)

FCHTL (FHF)

IATL (FMOF, Mk I, Mk II)

762

LOW COST AVIONICS INTEGRATED DESIGNDEVELOPMENT TEST SCHEDULE

Dual Seat Motion Base(DSMB)

72 | 73| 74 | 75 | 76 | 77 ,78 , 79 , 80, 81, 82 , 83 , 84• Design & Fabrication

^^•Engineering Simulations

Full MissionSimulator Lab.(FMSL)

iDesign & Fabrication•^•Engineering Simulations

FMSL + FCHTL iFHF 6 DOF Tests (Phase II)FlightTest SupportFMOFFCS Tests

Flight Control/Hydraulic Test Lab(FCHTL)

FHF 6 DOF Tests (Phase I)! Flight Control System Design Evaluation Tests

f Design & Fabrication

Integrated AvionicTest Lab(IATL)

i Design & Fabrication••FMOFMk I 6 DOF Tests

^•••FMOF Operations Support••MklJ Avionics Installation

^^Mk II 6 DOF Tests

163

Software development is an iterative process ofanalysis design, verification and modification. Thisflow graph serves to indicate the ordered repetitive

process of flight program software development. Thisrepetitive process is necessary since the software re-

presents a potential single-point failure during itsdevelopment cycle, in an otherwise redundant

system.

164

SOFTWARE DEVELOPMENT FLOW GRAPH

ProgramSpecification

Algorithm

Control LawFormulation(FMSL)

Code/DebugInterpretiveSimulation(ASDL)

Flight ComputerHdw/Sftw Verific(IATL)/(FCHTL)

Off-Line SimulationsDesign Phase

Major Glitch

Development & VerificationPhases

End ItemFSRR

165

• Existing GAC facility

• 3 DOF motion capability, roll-pitch-heave

• 6 DOF virtual image displays

• 6 DOF all math model hybrid computingfacility (GAC/NASA)

• 2 seat cabin mockup with functional con-trols and displays

TEST CAPABILITIES AND OBJECTIVES

• Full aero capabilities from 400K alt totouchdown

• conceptual design and design trade-offs• Flying/handling qualities evaluation

• Displays and controls evaluation

• Flight control system design evalua-tion

• Guidance and navigation system designevaluation

166

DUAL SEAT MOTION BASE SIMULATOR

2 CRT & Pancake Windows(ONE For Each Window)

3D OF HydraulicMotion Device

2-Place CrewEnclosure

TV Camera

Range Drive'

Electronics Console

ToComputers

767

• Avionics - math modeled

• Non-avionics - math modeled

• Flight controls - math modeled• Controls & displays - simulated/flight

hardware

TEST CAPABILITIES AND OBJECTIVES

• Full mission, 6 DOF, man-in-the-loopsimulations

• Design constraints and requirements• PCS algorithm and formulation• G&N algorithm and formulation

• Controls and displays formating and trade-offs

• Flying/handling qualities evaluation

168

FULL(FMSL)

MISSION SIMULATION LABORATORY

Pancake Window & CRT

Display

Terrain Model

3-Axis Gantry

TV Camera &3DOF OpticalHead

Operating &Monitor Console

169

• Avionics - FHF flight set

• Non-avionics - math modeled

• Flight controls - flight set

• Controls & displays - flight type/simulated

• Dimensionally true structural mockup (aft 70 ft)of flight control surfaces, actuator hinge points,hydraulic distribution system and FHF avionics

ships set with 6 DOF dynamics capability

• Phase I testing - Design evaluation testing of PCS.Subsystem avionics integration tests. Subsystem6 DOF verification tests.

• Phase II testing - FCHTL & FMSL integrated for

FHF combined subsystem hardware/software ver-ification and mission performance certification.

• Flight test operations support - FHF flight testanomily and engineering change proposal investiga-tions

170

HYDRAULIC EQUIPMENT ARRANGEMENT ON FCHTL

Nose Gear Hydraulic SysForshortened for DemandTests

171

• Avionics - Mk & Mk II ships set• Non-avionics - math model• Flight controls - flight type/math model

• Controls & displays - Mk I & Mk II ships set

TEST CAPABILITIES AND OBJECTIVES FOR FMOF

MKI&MKII

• Hardware/software verification

• Malfunction and reconfiguration studies

• Avionics system hardware interface evaluation

• Avionics to Non-avionics system hardware interfaceevaluation

• Avionics system performance verification• Mission performance verification

• Final crew training, max one week• FMOF flight test operations support, real time and

post-flight• FMOF flight test anomaly and system modification

evaluation

772

LOW COST AVIONICS INTEGRATED DESIGN DEVELOPMENTTEST TOTAL COST ESTIMATE

| 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84

FCHTL 46 91 66 45

FMSL 17 67 45 39

FMSL + 65 65 65FCHTL

DSMB 25 27 13

IATL 89 75 60 60 85 60 32

Totals 88 185 125 84 154 140 125 60 85 60 32 S24.53M(Man Yrs)

Material 2.5 3.5 2.75 2.0 5.0 3.5 2.0 1.0 1.5 1.5 0.5 S25.75MO&M($M)

Program Total S50.28M

173

zUJ

II

Operational

GSE C/0

Required for vehicle management- Operation (turn ON/OFF)- Redundancy selection (system level)— Caution/Warning surveillance70% of operational measurements requiredto monitor and operate non-avionic sub-systems

Required for pre/post-flight requirement tofault isolate to the lowest replaceable assem-bly— Additional data points are needed, over

and above operational, to fault isolatebeyond system level

62% of GSE c/o points required for avionicssubsystems LRU fault isolation- Maximum potential for pre/post-flight

checkout transfer to vehicle for Mk II(checkout autonomy) configuration inavionics subsystems

Dedicated DPI

• Dedicated development measurements areadded to meet specific test objectives. Se-lected operational data points are used inconjunction with dedicated DPI for verifica-tion of vehicle system performance

Measurement sizing data contained in this docu-ment have been generated over the period of the lowcost study and therefore minor differences in summa-tion tables exist. Effort has been made to referencethe baseline measurement list data on each table andto use the most current information available forsizing purposes.

Measurement list configuration control docu-ments will be in effect for the orbiter/booster vehi-cles. A continuing effort of update and refinementwill be expended in order to provide essential sizinginformation for the Data Acquisition Systems and toprovide vehicle system configuration.

776

<*»* V« r c *

ORBITER/BOOSTERMEASUREMENT REQUIREMENTS

Operational DedicatedDPI

GSE C/0

FHFOrbiter

Booster

334

400

700

1056

«730

«800

MklOrbiter

Booster

1050

650

967

1760

1596

1350

MkllOrbiter

Booster

1060

650

389

200

1596

1350

177

Phase B vs Low Cost Avionics - Comparitive Mea-surement Data

The Phase B measurement requirements weresized to fault isolate to the LRU for pre/post-flightcheckout purposes.

The low cost avionics measurements derivationreview resulted in a comparable total number of mea-surements required (2818 vs 2652) to accomplish thesame level of fault isolation. Sequential studies wereperformed that identified the following operationalmeasurements:

• Those required by the crew, inflight, tooperate the vehicle systems

• Identified critical measurements to be moni-tored for system fault detection

• Provide the crew with sufficient data to en-able system redundancy selection

A second phase of the investigation was initi-ated to identify measurements that are required, inconjunction with operational measurements, to faultisolate to an LRU for pre/post-flight checkout. Tominimize the total number required, operationalmeasurements were used as a baseline for systemlevel fault detection and measurements added tofault isolate to an LRU.

A subsystem measurement comparison willevidence a considerable difference in total measure-ment numbers. In many cases, these differences aredue to a basic design change in the measured sub-system (i.e., EPD).

178

LOW COST AVIONICS SYS, ORBITER MEASUREMENTCOMPARISON (PHASE B vs LOW COST AVIONICS)

Subsystem

Aux Mech SystemsCryo & Prop. TanksElect Pwr DirtElect Pwr GenHydraulicsTurbo Jet Prop.ECS/Life SupportOrbit Man. Prop.Primary Prop.Attitude Control Prop.Structure & Thermal ProtectionCrew ProvisionAero SurfacesPayloadGN&CFlight ControlsTelecommunicationsInstrumentationData Management"Primary Prop. Recorded Measurments**TPS & Structural Recorded Measurements

Subtotal

Total

Phase B

(150)12695164651231672362772538924(75)13102(210)163_

2383(435)

2818

Operational

302439761769462868»10918"_67261794882800(244)(12)

1056

GSE-623939-6-6896332----17069284—47

1596

1596

2652

179

ORBITER/BOOSTER VEHICLE CHECKOUT

FHF

ONBOARD Onboard checkout functions con-CHECKOUT sist of status monitoring to a veh-CAPABILITY icle function accomplished by pro-

grammed limit checking of data.ThJs will be mechanized along thefollowing lines:• A large percentage of the avionic

equipment present in the firsthorizontal flight vehicle is ofrecent commercial or military de-sign, and incorporates some de-gree of built in test capability.

• Programmed limit checkingprovided by the data acquisitioncontroller.

• The caution and warning displaypanel and dedicated displaysprovides crew and/or groundcheckout personnel with statusdisplay

While in flight, the above capabilitywill display system status, detectfailures, isolate to a functional path,assist in redundancy management,and provide telemetry and record-ing of data. During ground checkoutthe onboard capability will be usedas an adjunct to the process of main-tenance, repair, and preflight ac-ceptance testing.

MklAt the time of the first mannedorbital flight, onboard checkout willprovide expanded status monitoringand fault isolation to include sys-tems added for the orbital mission.

• Onboard fault isolation will beimproved by the addition ofmore sophisticated techniquessuch as cross correlation of datafrom redundant subsystems and"time rate of change reasonable-ness tests

As orbital missions are extended andinsufficient communications cover-age creates a need for greater vehi-icle autonomy, ground based check-out functions will be added to thevehicle as needed. For ground check-out, the onboard capability will func-tion as an adjunct to maintenanceand acceptance testing.

MkllDuring the Mk II program,there will be a gradual trans-fer of checkout authorityfrom the ground complex tothe vehicle, accomplished ona subsystem by subsystembasis. The vehicle will evolvetowards semi-autonomouscheckout, with the evolutionbased upon flight, operationaland ground test experiencegained in earlier programphases.

In the Mk II configuration, theGSE data acquisition control-ler formerly part of the CSE,will become part of the vehicledata acquisition system. Thischange, along with increasedcomputer capability, will per-mit increased onboard isolationto the equipment replaceableassembly. Additionally it willprovide automation of check-lists, and command initiatedself-test during flight.

180

ORBITER/BOOSTER VEHICLE CHECKOUT (Cont.)

GROUNDBASEDCHECKOUTEQUIPMENT

FHF

Ground checkout equipment will berequired for two functions:

• As a supplement to the onboarddetermination of system "Go/No-Go" status, permitting a greaterdepth of test

• To provide fault isolation to anequipment replaceable assembly,

• since the onboard checkout willusually isolate only to a func-tional path, and built-in-test inindividual equipments will notisolate to black box in all cases

• Onboard non-redundant GSERAU's and a ground based dataacquisition controller will acquireand condition GSE measurementsrequired for fault isolation to theequipment replaceable assembly.

Mkl

The ground checkout complex willperform a semi-automated checkoutof the vehicle, and in the event of amalfunction will fault isolate tothe equipment replaceable assem-bly. As orbital flight experiencepermits, ground based checkout func-tions will be gradually transferred tothe vehicle, and more autonomousvehicle functions will be progres-sively proved out.

M k l l

The ground checkout equip-ment will continue to func-tion as a tool in the mainte-nance and preflight checkoutof the vehicle providing:

• A greater depth of testthan the onboard function,to assure isolation to thereplaceable assembly incases where the OBC orBIT are limited

• Testing of the vehicle andits systems by exercisingthem in an "end-to-end"

• Trending analyses of vehi-cle systems

• Control of service equip-. ment and other GSE

181

Dedicated/Integrated Instrumentation

Dedicated DFI

Accommodates low (PCM) and high (FM)frequency data requirement.

• Advantages— Qualification, procurement, installation

and data reduction independent of oper-ational programs

- Maximum flexibility to respond to vari-ous requirements as identified

- Generally lower black box costsper measurement channel.

• Disadvantages- Normal implementation techniques im-

pose weight/penetration penalties forelectrical harness

— No operational application for develop-ment equipment after flight test pro-gram completion

Integrated DFI/OFI

Accommodates operational requirements, (dis-play, caution and warning, TM), low frequency DFIand high frequency data (FM).

• Advantages— Optimized (weight and data handling

techniques) to recover both operationalmeasurements and development data.

• Disadvantages- Type and data requirements (frequency)

of DFI measurements preclude a practicalintegrated system being proposed thatwill be cost effective.-- FM data recovery is not required for

the operational configuration andwould represent a major portion ofthe integrated system.

- Necessary flexibility of developmenttest program would impose an un-warranted impact on operational datarecovery requirements.

Common Hardwire (Recommended Concept)

Use operational hardware when possible to re-cover DFI data. High frequency DFI data (FM) isrecovered with dedicated DFI equipment.

• Advantages- Reduced program procurement and

qualification costs— Return to inventory as operational spares

for further cost effectiveness- Reduced impact of conventional DFI

electrical harness weight and penetrations- Maintains flexibility for modification in

a development program• Disadvantages

- Allocation of DFI measurements must bemade within type and range limitationsof operational equipment thus it may re-quire some unique implementation forspecial data recovery requirements.

182

DEDICATED/INTEGRATED INSTRUMENTATIONDATA RECOVERY SYSTEMS

OPERATIONAL, DEVELOPMENT, AND GSE CHECKOUT(MK I CONFIGURATION SHOWN)

183

DEDICATED/INTEGRATED INSTRUMENTATION CONCLUSIONS

The evaluation of dedicated vs integrated in-strumentation systems indicates that common datarecovery system hardware used for operational andselected (low frequency) development requirementswill be effective in simplification of procurement prac-tices and implementation techniques thereby yieldingon overall reduction in program costs.

Implementation of a common data recovery sys-tem (RAU) is extended to the GSE checkout require-

ments to resolve the immediate problem of GSE ac-cessibility (i.e., numerous GSE cables to black boxconnectors) enhancing the total preparation cycle re-quired for pre/post-flight checkout. Common GSEequipment will substantially reduce the integrationimpacts associated with transferring fault isolation tothe lowest replaceable assembly requirement fromground dependence on Mk I to near atonomy in theMk II configuration. Transferral will be an evolution-ary process and minimal vehicle impact is expecteddue to the existence of compatible hardware installa-tion.

184

(MEASUREMENT REQUIREMENTS

The following tables break down measure-ments required for checkout of the low costavionics orbiter. These are in two groups:

• Operational measurements required to deter-mine that vehicle systems are functioningproperly

• GSE measurements required to troubleshoota malfunctioning system or systems, to per-mit isolation of a defective replaceable as-sembly

Within each group, measurements have been summa-rized by system into categories:

• Analog values to be measured• Digital values• Discrete events

Additionally, for each system, we have estimated thetypical sampling rate, and the worst case (or maxi-

mum) sampling rate which will be required of thedata acquisition hardware. i

The measurements presented in these two tableswere obtained by experienced spacecraft checkout !personnel in consultation with cognizant Grumman .design engineers for the various orbiter systems, and 'are of interest to the support effort for the following'purposes:

• Overall measurement counts and their analog/digital/discrete subsets are indicative of therequired capacity for the checkout system, jThus, in estimating the technical scope ofour four alternate concepts, we have used \these dimensions to "size" the ground check-out system

• Estimated sampling rates are indicative of therequired bandwidth'and general form for thedata acquisition system and its correspond-ing checkout system interface .

18,5

SHUTTLE OPERATIONAL MEASUREMENTS REQUIRE-MENTS (ORBITER VEHICLE) EXCLUDING GSEMEASUREMENTS

AuxiliaryCryogenics ft Propulsion TankageElectrical Power Distribution

Electrical Power Generation

Guidance, Navigation & ConuolHydraulicsTurbojet Propulsion

Date ManagementEnviron Control/Life Support

Navigation Aid!Primary PropulsionAttitude Control Propulsion

Struct & Thermal ProtectionTelecommunications

Crew ProvisionsDisplay & Control

Instrumentation

Aero SurfacesFlight ControlPayload Deployment & RetrievalOrbit Maneuvering System

Total ..

•Accounted for in Other Entries

TotalMaes

30303898611757274628

*3121043020

"•

86

8772

1049

Analog

32

24SI381344243314

0168

SBIS110016

39SO

582

Dig

00002003000000300---

IS24

Disc-rete

27281447204

130

13140

14446156007-

487

443

Telmetry

30000

61170

27080000000-6

297

185

SPSSampl'gRate(Max)

110101

TBD100

1100

1100-

1001t

Clock-_

11

SOt

IOO/

SPSSempl'gRateITyp.l

1111

TBO11

10011-101t1-_

11111

• Maturiment tW 1

186

SHUTTLE GSE MEASUREMENTS REQUIREMENTS(ORBITER VEHICLE) USED FOR SYSTEMFAULT ISOLATION

AuxiliaryCryogenics ft Propulsion, Tankage

Electrical Power DistributionElectrical Power Generation

Guidance, Navigation & Control

HydraulicsTurbojet PropulsionData ManagementEnviron Control/Life Support

Navigation AidsPrimary Propulsion

Attitude Control PropulsionStruct & Thermal ProtectionTelecommunicationsCrew Provisions

Display & Control

Instrumentation

Aero Surfaces

Flight Control

Payload Deployment & RetrievalOrbit Maneuvering System

Total . *"

TotalMeas

.6239

•

170•

647

*•96

416-84

••••

686•64

1670

Ami

05039

0

10300200

96416-

790000

3600

641209

Dig

0-00

1

-50000000

38

Bh-creta

0

1200

6500

200000-00000

32600

423

Telm-Mry

0

000

-

000000000

SPSSamprgRiu(M»)

11_

1--

Clock--11-1--1_

1-1

10R

SPSSampl'gRan(Typ)

11_

1--

Clock

-11-1--1-

1-1

'"Accounted for In Other Entries

"•Meisuramant List Raf 2.5 Oct 1971

187"

This chart is intended to convey a conceptualunderstanding of the relationship between orbiter orbooster systems, GSE, etc. The interface concept isthat nearly all vehicle measurements will be trans-mitted to the checkout equipment in two PCM paths;one from the onboard Data Acquisition Controller, theother from the portable GSE Data Acquisition Con-troller. There will be uplink stimuli and certain atypi-cal system measurements which will not be suitablefor transmission in the PCM stream, so that tentativeprovisions have been made for about 100 hard wires.

In addition to the PCM and hard wire interface,the new equipment concept provides a receiver foracquisition of telemetred measurements, and also pro-vides a playback unit to make information from theon-board recorder available to the checkout system.(This permits trend analysis, evaluation of vehicle sys-tems which cannot be operated on the ground, diag-nosis of "intermittant" problems, etc.)

The interface between the checkout system andmechanical, fluid, and gaseous/propellant supportequipment is tentatively defined as the UTE standarddigital interface mechanized by ground support inter-

face units (GSIU's) which are part of the UTE equip-ment. As the program develops, this tentative con-cept should be examined to see whether the serviceequipment should be so modified to adapt to thecheckout equipment, or vice versa.

The major change in interface from Mk I toMk II occurs when the GSE Data Acquisition Con-troller becomes part of the vehicle, and the onboarddata management system becomes more autonomous.To the degree that this permits more onboard check-out, ground requirements decrease.

The most significant feature of the vehicle toground interface as it is now visualized is that thenumber of connect points are minimized in the inte-rest of expeditious checkout. If all of the requiredmeasurements had to be acquired by hard lines, therewould be a lengthy connection process with inherentcable and connector reliability problems. It is diffi-cult to imagine meeting peak flight schedules if theground checkout system were to be burdened withthese problems. By contrast, the present interfaceconcept offers a rapid and reliable means for gettingon and off the vehicle.

188

ORBITER/BOOSTER GROUNDCHECKOUT INTERFACE (MKI)

(PCM) OperationalMeasurements

Support

To Cen-tralDataFacility

Modems

1

(2). Displav* Contro

Aux DataModule

MaK MMemory ™Module

& (8)1 Modules

Fila)dule5 Data

(3) Module

RecordePlaybac

Haid CopyModules

(2)

1

Controller

RecorderPlayback

MBeoffo

k lcomes PartVehiclerMkll

<

GSIU's(2)

— *

^+

(Mech)

Fluid SupportEquipment

Gas SupportEquipment

189

Comparison of the Phase B configuration withthe low cost avionics configuration leads to the con-clusion that a change to low cost avionics will notmaterially affect vehicle turn-around. Assuming thatthere are 30 available working days from recovery tolaunch, our preliminary analysis indicates that theavionic servicing will consume less than 6% of this

. time, so that other vehicle servicing requirements,notably those associated with engines and thermalprotection system will continue to be of more signifi-cance.

The 6% value was arrived at as follows:

• From reliability analysis, the overall avionicfailure rate is given as 12.439 x 10^ perhour. For a 168 hour mission, we wouldtherefore expect a mean of 2.08 failures atthe time of recovery

• From experience, it is known that the rateof maintenance actions will exceed the rateof avionic system failure. This is true be-cause:

— It is normal for a certain number of non-defective avionic black boxes to bechanged as part of the troubleshootingprocess

— Some avionic failures occur during thecheckout process

(To account for the above factors, and alsoto allow for some degree of uncertainty inthe reliability data, we have (conservatively)allowed a safety factor of ten between fail-ure rate and maintenance action rate forpurposes of this analysis. This leads to anestimate of 20.8 mean maintenance actionsper mission.)

• We assume that each maintenance action willhave an associated mean-time-to-restore offour hours, which includes verification offailure, fault isolation, removal, replacement,and verification tests to ensure that the as-sociated problem has been corrected. Thisfour hour value is consistent with aircraftavionic practice

• Assuming a series-parallel repair process suchthat 2/3 of the above maintenance actionsoccur in parallel and the remaining 1 /3 areconstrained to occur in series, we estimate avehicle mean-time-to-restore of 27.8 hours,or 1.74 days, based on a two-shift operation.This is just under 6% of the available 30 days

190

UTE DEPLOYMENT SCHEDULE

Ute Sites

Hardware Development Lab

Software Development Lab

Orbiter Factory

Booster Factory

Space Environ Sim Lab (T/V Tests)

l/ortiral Pit Tact Qitp fl PUP! 1)

X/prtiral Fit Tpct *\ifp (I PUP! II)

Vertical Fit Test Site (Level 1)

Vertical Fit Test Site (Level 1)

72 74 76 78 80 82 84 86 88 90 92i I i i i i i i i i i

IM

•^1MB

H— M• •11

1i i

I

1

4— — —, ^^^1^^^^^^^^^^^^^^1

191

Development measurements- Verify vehicle system performance

— Not used for real-time safety-of-flight

Measurement source

- Selected OFI Transducers or OFI/CU interface

— Dedicated DPI Transducers— Data Management system

Data recovery

- All DPI PCM and FM data on-board recorded

• DPI PCM 100% telemetered• DPI FM 30% telemetered (most critical

parameters)-cockpit selection of transmitteddata

General philosophy

— Share RAU& CU basic design with oper. instru.and GSE

- Use F-14 FM system designs

- DFI pre-flight C/O thru use of dedicated C/0carts

752

FLIGHT TEST INSTRUMENTATION, DPI MEASUREMENTREQUIREMENTS

Configuration

Mk(FHF)(OrbiterNo. 1)

Mkl(Orbiter No. 2)

Mkll(Orbiter No. 3)

Oper MeasUsedfor DPI

216

898

SOI

DedicatedDFIMeasmts

700

967

389

TotalDFI,Measmts

916

1865*»

890"

No. of DFIMeasurements:

RecordedOn-Board

424*

1865

890

Tele-metered

424

S58

172

No. of DFI MeasurementsRequired For:

HorizFit

916

606

142

Vertical Fit

Boost/Ascent

N/A

1477

760

Orbit

N/A

828

246

Entry

N/A

1331

S10

* Worst-Case Single Mission Requirement

* Total DFI Measurement Requirement; Final SystemTo Be Sized By:

1. Signal Patching or Reprogramming2. Total System Recording, Data Reduction Strip-Out

193

• Transducers/sensors for DPI utilization— Utilize commercial equipment off-the-shelf

for the horizontal flight articles unique require-ments; i.e., same approach used for militaryaircraft test programs

— Utilize oper instru transducer designs for ded-icated DPI measurements, when feasible toaffect hardware commonality/lower procure-ment cost (fewer buys)

- Trade measurement requirements vs common-ality to reduce transducer types and ranges

- Normalized output of DPI dedicated low-leveltransducers by category/type to simplify sys-tem calibration

— Redundant transducers are installed only formeasurements in non-accessible locations

• Data acquisition system (PCM)- Data from dedicated DPI or OFI transducers

is conditioned and acquired by standard RAUdesign

- DPI transducers not compatible with standardRAU are pre-conditioned by dedicated signalconditioning (15-20%)

- Operational data required for DPI merge isobtained via OFI/CU - DFI/CU digital interface

- DPI CU outputs a parallel PCM stream for on-board recording (1" dig. tape @ 30 min. recordtime) and a serial PCM stream for telemetering

- Data channel scan sequence, gain and rate arecontrolled by the CU which allows a flexiblesystem capable of expansion

• Data acquisition system (FM)— Operational data required for recording will be

conditioned by DPI due to bandwidth require-ments

- Standard IRIG proportional bandwidth & con-stant bandwidth VOC's will be utilized. (13tape tracks, 1" tape, track bandwidth 500KHz)

- When required, one tape track will be used forwideband data (acoustic)

• Telemetry- The system will merge the serial PCM stream with

one FM multiplex via pre mod mixer A; FM onthe baseband & PCM on a sub carrier.

— The second pre-mod mixer (B) will combine twoadditional FM multiplex

- Each composite signal will deviate an S-bandsolid state transmitter. The transmitters will becombined by a diplexer and the resultant signalwill be transmitted

— A demodulator will be required on the ground tostrip out each data stream

- Any three FM multiplexers may be selected be-fore or during flight.

• Time code system- Standard IRIG-B time code format- Modulated IKC for FM recording - SLO code also

available- BCD digital time is supplied to CU for DPI time

on PCM recording and TM— Time code will be synced with vehicle time

•^Calibration sequencer _- All data channels will contain either a voltage

substitution or series/shunt RC stimulus- Activation of stimulus maybe accomplished by

either cockpit control or during check-out by thededicated check-out cart.

194

DPI SYSTEM BLOCK DIAGRAMOper Data From OFI CU

Oper Xducers

Ml & Mil DMS-GN&C Eval Data

*_

InputstoFMDAS

Ded DFIXducers

I S-Bandl— Trant. J

OperXducers

Acoustics^—

•Remote Acquisition & Conditioning Unit

DFIRAU's

CalSequencer& Control

1DedicatedSignalCond

Wide BanVCO's

«-H

. VehTime

1 ,

(Mod. IRI

»•

d

ning Unit

r

TimeCode Gen

G-8)|

FMMultiple(VCO's)

i <

AnalogTapeTransport

(

i

-¥

r»

1+

t

rre-mooMixer

A

-

Pro-Mod.Mixer

B-

Cockpit

TimeDisplay(Set & Reset)

CalSequencerInitiate

FM-MuxSelectionforTM

&-uanaTrans-mitter

1 Di

S-BandTrans-mitter

ChInii(R<

195

Dedicated DPI check-out carts

- Modify design of existing check-out carts usedpresently for F-14 test A/C

— Transportable carts permit system C/O &validation at sub-assembly and assembly facil-ities as well as launch site

— Carts truly transportable - approximately 10' x2.5'x 6.5'

- Dedicated C/O carts permit DPI system C/Oindependant of operational C/O

— C/O cart contains commercial off-the-shelfhardware

— C/O via hardline or RF transmission

196

S-BandRcvr

Scope

CHECK-OUT CART BLOCK DIAGRAM

\

Flight Test Instrumentation, DPI

Hard Line Coax

| Hard Line Coax

CalibrationSequenceInitiator

DVM

Coax PatchSig. Distrib.

ACVTVM

Counter

PowerReg & Dist

PCMDecomProgrammablevia Card

(FM Data)

SwitchableDiscrim PBW

CBW

SpectrumAnalyzer

*MiniComputer

i

(

k

i — »

^_

b Printer(Column)

I/OTypewriter

PaperTape Reader

* Limit &Cal Check

797

861

ssSueip sui9}sA~s ojgnp s}U9ui9Jinb9J iu9ui9jnsB3iu oj ssSuBqo

jouiiu XJUQ 'suiajsXs JJEJOJIB PUB sosdssqj yoddns oj sjusuisjnsBsiu 950 Til Wi

JU31U33EUBUI

:JDJ siuajsXs JJEJOJIB PUByoddns o) s}U3Ui9jnsE3ui

-ojd

SHOUBA SUIMOJJSjiqao sqj jiod

p Suunp 3[Oii[3A 3ij] jo uops3JES JDJ smsjsXs }q3?u IJEJOJIB [BUOIJE

sqj jaoddns 0} sjusuisjnsESiu

isssEqd-pj 3qi Suunp jusiusSBUEUi

-dns oj psjinbsa SJE s;u3iu3jnsE3iu

•p3)U3lU3[dlUI U33q

sEq uoijEjnSijuoosj ;Bqj UIJIJUOD oj PUE uotjBjnSij-uoosj [EnuBui pus oijBiuojnB juauiajduii oj XJESSS

-O3u s9.inn.Bj 3}Bpsi PUB psjsp 01 AjinqEdED pJEoq-uoqj SplAOjd SJ9J9lUBJBd 9S3q} JO }U9U19JnSB9^ -S9SBqd

uoissiiu snouBA Suunp 8uijo;iuoui gouEuuojjgdPUB snjBjs Joj XJBSSSDSU sjgjgiuejEd jo ju9iu9JnsB9iu

661

9501Zl

frtt

008Z88»6£ ' '19Zi9

,..81

601.89

8Z9t69a9i6E

«0£

II IN

JSOJZl

WZS6iI8W6Z19Zl9-

..81

601.89

8Z9»

. 69

119L6CnOE

I1IA1

ttC-

KtIM96i19-

9• ---

. -

-

6169aezn-

oedHJ

JBJOlS)U3UI

•ajnsea i papjoaay |BJn»omjs 5 Sdi..s)uauiajnsea|/g papaooay -dojj AJBUJUJ.

luauia6eue|/\| BJKQuoiiBluaiunj)su|

suoiiBOjunuiuiooaiaiSIOJJUDJ jijBiij

08NDpeogAe,)

saoopns ojayUOISIAOJJ majQ

uojioajoj,) leuijaqi 9 ajnjomis•doy |OJjuo3 aph)juv

•dojj AJBUIJJJ•dojj -uei/tj iiqjQ

uoddns ajn/S33•dajj lap aqjni

s3i|nejpAHuag JMJ 'joaoJS1Q JMJ 133)3

. S)|UBI -doy ig ojAgsuiaisA; qia|/\| xny

uiaisAsqns

siN3iAi3ansv3i/\i a3iiaao

Equipment: Transducers/Sensors, Dedicated SignalConditions. Flight Recorders and Remote AcquisitionUnits (RAU)Transducer/Sensors

• Environmentally compatible with installationlocation

— Benign environmental sensor installationrequirements will be implemented withoff-the-shelf spare qualified or deltaqualified commercial transducer sensors

- Unique implementation problem areas

-- Special Design will be required for thefollowing measurements due to envi-ronmental factors: Quantity gagingCryogenics consumables and discrete 'switches and fire detection sensors

Integral RAU Signal Conditioning

• Accepts "standard" measurements in a rawdata format and converts directly to a serialdigital word for further data processing

• Wide range of standard sensor interface in-puts (resistance thermometer, strain gage,thermocouples, rpm, synchro/phase shiftLUDT, parallel digital words and precondi-tioned 0 to 5 vdc)

Dedicated Signal Conditioning

• Provide normalization for unique measure-ments that are unacceptable to the RAU in-put requirements

• Normalize data for cockpit display require-ments

- Quantity (capacitance, rf, or pressure)- Volume/temperature (LOH)— Angular velocity (wide range rpm)

• Design Requirements

— Unique electrical input/output matching— Unique packaging (Hostile environments)

Data Recorders (3 Types)

• Flight Recorder (AR1NC 573 Data)- 4 voice channels, locator beacon, data- Mod comm/mil unit

• Maintenance Recorder (Boost and re-entrydata)

— Main Propulsion Data During Boost andThermal Protection environmentalhistory

- Space Qualified

• Telemetry Recorder (data log)

— Telemetry Compression— Space Qualified

200

OPERATIONAL INSTRUMENTATION SUBSYSTEM MK I/MK II. -Opr InstrSubsys— __

| "A • Analog0 • Digital

207

Sensor/Signal Redundancy Philosophy

Critical functions will be implemented to assurethat at least two isolated data recovery paths exist todefine the subsystem function status. Functionalstatus will be acquired using one or both of the fol-lowing techniques:

• Simple Redundancy - Two sensors imple-mented at the same point in the system torecover the same data, i.e., two pressures,two temperatures, etc. This method will beused in cases where the second technique,Functionally Related Measurements, is in-adequate to provide basic redundant data

• Functionally Related Measurements - Dif-ferent types of measurements, pressure,quantity, temperature, that are functionally

related and can be used to deduce systemstatus in the event any single measurementchannel fails - (i.e., quantity of gas andP/T using Boyles law)

Sensed information for critical measurementswill be processed through separate data channels andpresented to the crew as two separate pieces of in-formation. For example, a discrete piece of data isdisplayed to the crew via a caution and warning lightwhich can be verified through a related measure-ment via a dedicated display.

Redundancy for Ease of Maintenance

In cases of severe impact concerning accessibility,redundancy will be implemented if cost/weight ef-fectiveness can be demonstrated for specific measure-ments.

202

LOW COST AVIONICSINSTRUMENTATION

Functionally Related Measurementjr

Series Req

VehicleTankage

OFI

Orifice

CheckValves

Subsystem Status = Predicted Valve +QJ or ?2 (Known Differences)

Simple RedundancyVehicleTankage

IsolationValve

Subsystem Status = Predicted Valve +PA and/or PA'

203

X

JO

M

Life cycle cost estimates for the candidate avi-onics system must be supplemented by cost impacton the shuttle program due to added weight, etc. Es-timating uncertainty and cost risk must be evaluatedto make an effective decision.

206

COST RELATIONSHIPS

• Complex & Esoteric Techniques Not Possible Within Time Constraints

• Utilized Engrg Estimates for Life Cycle Cost Categories as Supplied by GrummanTeam Members

• Utilized Guideline CER's for Impact Cost Determination

Example:

Cost of Abort = Cost of Mission

207

In addition to avionics system life cycle costs,

the shuttle program costs are also increased due to the

impact of avionic system characteristics on shuttle de-

sign and expenditures.

208

IMPACT COST AREAS

• Weight Penalty Costs to Orbiter & to Booster

• Cost of Mission Abort Attributable to Avionics System Failures

• Cost of Launch Delays Attributable to Avionic System Failures

205

Probability distributions for input cost and risk

driving parameters serve to reflect estimating uncer-

tainty by allowing for a range of estimated parameter

values. Risk is reflected by distribution skewness

and variance.

2)0

*s-s2 =

COco>_i<Z

,1/

o

JD

2a.

1datoeU

:tcO9

'

I•n•aCDU

-

a>U w>c c

fc g.st» E 31,2:1CO ^ v.

a£ «^ + 5

SI

•c£aje.£be

>

Ol

E „,CD S

«« eO <j~ 3,35

s.«°2S'S

*

r>ton.

_E

+ttou

5LLJ

!_(/>O)

*^

eu

-*

09

a.

CDCO

^eittu

-^

)

\ *^0 g 1El i09 w t-

V tt °-

c^5

E09

tt

CO.cuCOIU^O

£2O9*rf

«>*

£O9

CO

09

CD en. SEtta >•

CJCO

MONTE CARLO SELECTION PROCESS

Existing Computer Program Allows:

• Development of Beta Distributions for Inputs

• Monte Carlo Sampling of Beta Distributions

• A Capability for Repetitive Sampling of the Alternative System InputDistributions

213

The result of our study is a comprehensive com-puterized technique which supplies point estimates ofcost and probability distribution reflecting risk anduncertainty.

274

RESULTING COST DISTRIBUTIONS FOR CANDIDATEAVIONICS SYSTEMS

0.3-i0.2-

0.1-

0

b

f\250 350 450 550

Life Cycle Costs, $M

150 250 350

Impact Costs, $M

500

Total Costs, $M

275

The magnitude of the resulting costs can be

more accurately determined as input parameter values

are improved. However, relative measures of risk are

apparent from the current results. "Spaced proven

hardware" is clearly less risky than the proposed

centralized configuration, as can be seen in its rela-

tively narrow cost spread and variance. The Grumman

baseline system successfully combines the best attri-

butes of both to achieve a configuration with risk as

small as that for "space proven hardware."

216

RISK ANALYSIS SUMMARY

0.25-

0.20-

0.15-

0.10

0.05

Probability DistributionAbout theExpected Value

Recommended System

Space Proven

Centralized

Cumulative Probability DistributionsAbout theExpected Values

-100 -75 -50 -25 0 25 50 75 100

$M

-100 -75 -50 -25 0 25 BO 75 100

277

Similar risk analyses should also be applied to

computer subsystems. Utilizing this risk analysis

technique will allow selection of a low-cost subsys-

tem with a hardware/software mix which minimizes

cost risk.

218

APPLICATION OF RISK ANALYSIS TO ORBITER COMPUTERSUBSYSTEM

• Identify Candidate Configurations (Federated vs Integrated)

• Determine Pertinent Impact Cost Parameters for Computer Subsystem

- Weight, Power Reqmt, Reliability (Mission Abort/Delay), etc.

• Collect Data for Life Cycle Cost & Impact Cost Parameters With:

- High, Low, & Mode Reflecting Cost Estimating Uncertainty

- Beta Distribution Skewness & Variance Reflecting Risk

• Exercise Computerized Risk Analysis Model Resulting in Cost-ProbabilityDistributions for Candidate Computer Subsystems, Allowing Selection ofCandidate with the Associated Hardware/Software Mix which MinimizesCost Risk

219

Identification and collection of input param-

eter distributions for the computer subsystem hard-

ware and software and the application of our Monte

Carlo risk and uncertainty model to this problem

will allow for a quantitative measure of computer

subsystem risk.

220

COMPUTER SUBSYSTEM LIFE CYCLE COST DISTRIBUTIONS *- Federated

Integrated

Prob Prob

Prob

HW DOT&E $

Prob

HW Prod $

SW DDT&E $

Prob

LCCS SW Prod $

Prob Prob

HW Oper $

'Similar Curves for Impact Costs

SW Oper $

22?

xuoddnsQNnoao

Ground rules describing major schedule mile-

stones are derived from NASA documentation.

The assumption regarding support of first hori-

zontal flight by Contractor personnel is based upon

a combination of experience on other programs and

the maintenance concept associated with first hori-

zontal flight.

Flight schedules are in accordance with Tech-

nical Directive GAC 4.

The assumptions that all launches will be from

one site and that maintenance operations at that site

will be conducted on a two-shift basis are based upon

considerations of minimum support hardware adequate

to the maintenance workload implied by the flightschedule. Similarly, the assumption that Level II

maintenance will be conducted at the launch site was

made to minimize logistic problems which would re-sult from remote Level II maintenance.

224

GROUNDRULES AND ASSUMPTIONS

• First Horizontal Flight Supported by Contractor Personnel

• First Horizontal Flight Program - June 76 Through Jan 78

• Nik I Program - Sept 78 to Sept 89

• Mk II Program - Sept 83 to Dec 91

• Level II Maintenance Conducted at Operating Site

• All Launches (Mk I and Mk II) From One Site

• Flight Schedule in Accordance With Technical Directive GAC4

225

The use of existing DTE/FTE and commercial

test equipment for support of first flight aircraft is

a normal procedure on aircraft programs. Use of this

concept for the Shuttle program would remove the

GSE from a critical path leading to first flight and is

considered desirable for that reason. Secondly, this

concept is implemented at minimum expense. Thirdly,

as the normal GSE becomes available, it can be phased

into the program gradually with minimum difficulty

of implementation, since the horizontal flight equip-

ment remains available during the transition.

226

MAINTENANCE CONCEPT FOR FIRST HORIZONTAL FLIGHT

• Level I

- Interim Line Test Sets and Procedures (Factory Test Equipment, CommercialTest Sets, Breakout Boxes)

- Mechanical Systems Maintained With Approved GSE

- Gradual Phase-In of Mk I Maintenance Concepts and Equipment

• Level II:

- Maximum Use of Existing Support Equipment and Factory Test Equipment

- Mechanical Systems Maintained With Approved GSE

- Gradual Phase-In of Mk I Maintenance Concepts and Equipment

227

We have considered those possible combinations

of GSE which are most likely to be implemented for

the Shuttle program. Cost projections derived for

each of the four competing GSE concepts are for the

life of the Shuttle program and, essentially, contain

all of the major life cycle cost elements which will

be encountered over the projected 20-year program,

with the exception of NASA costs for operating the

support system. (NASA costs are considered later,

by means of a relative estimate of labor required to

operate each of the four conceptual systems.)

With respect to costs given in the accompany-

ing chart, the most significant findings are as follows:

• Minimum costs are obtained with new check-

out equipment

• Maximum costs will be encountered if exist-

ing ACE equipment is used in the beginning

of the program, followed later by the intro-

duction of new equipment

To obtain a realistic evaluation of the four

competing concepts, it is necessary to consider the

relative values of NASA manhours required for the

operation of each of the conceptual systems.

225

GSE CONCEPTS CONSIDERED

• Use ACE for Mk I Support, Followed Concept A *- $510.4Mby New Equipment for Mk II (Mk ILevel II With Existing GSE)

• Use New Equipment for Total Pro- Concepts +~ $458.7Mgram (Mk I and Mk II, Level I andLevel II)

• Use ACE For Total Program at Concept C ^ $466.9WILevel I, With Existing Test ,Equipment at Level II

• Use ACE for Total Program at Concept D ——*- $494.8M: Level I, With Existing Test

Equipment at Level II, But .Modify the Method of Test- (

ing (Use ACE More Auto- '•••<: matically) : ; ,

Note: The above projected costs are for contractor activities and do not includeNASA costs for operating personnel.

223

Total estimated support costs were 458.7 mil-lion dollars, including Grumman, Boeing, and G. E.estimates for all equipment and services associatedwith a 20-year concurrent program.

If the Phase B estimate had been made on thesame terms, and for a program of equal length, thena 394.6 million dollar estimate would have resulted.Comparing this Phase B normalized value with thelow cost avionic estimate, the low cost vehicle con-figuration should lead to a support cost increase of64.1 million dollars over the 20 years of programlife. (An increase in support program costs would beexpected to follow as a consequence of reduced on-board checkout in the vehicle, particularly in view ofthe fact that labor, not GSE acquisition cost, is themajor driver of support life cycle cost.)

Some discussion of the normalization of PhaseB support costs is in order at this time:

• In the Phase B estimate, it was assumed thatcheckout equipment would be governmentfurnished. Thus, there were no ACE or newequipment costs in that estimate. To permitcomparison between the Phase B and lowcost study estimates, we must go back andnormalize the Phase B estimate by addingthe cost of new equipment

• Another normalization is required to convertthe above resultant into a 20-year programcost. This was accomplished by adding 1986through 1991 costs from the low cost studyinto the Phase B estimate to obtain the finalnormalized value

230

OVERALL SUPPORT IMPACT OF LOW COST AVIONICS

Phase B Study (Normalized) Support Costs FromSupport Costs Low Cost Avionic Study Incremental Change

S394.6M S458.7M +S64.1M(For Concurrent Program

231

This chart is an explanation of the cost elements

contained in the low cost avionics support cost estimate.

All costs associated with the major ground checkout

system (UTE) are treated as subcontractor costs and

have been derived in detail in a separate cost package

from General Electric.

software required for testing of Orbiter systems, for

publications, and for maintenance and support of

ground equipment and facilities. (Note: Applications

programs distinguish themselves from General Electric

software costs, which are for preparation and main-

tenance of the checkout system compiler/executive.)

Grumman costs presented are associated with

development, manufacture, modification, etc., efforts

relative to non-UTE support equipment. Additionally,

Grumman costs are included for applications program

Boeing costs contained in this estimate are those

which were estimated as required for Booster support

and are of the same categories as those included for

Grumman.

232

COST ELEMENTS

• General Electric Cost Package

-ACE, ACE Modified, and New Equipment (UTE) Costs- Hardware and Software Development, Equipment Manufacture- Maintenance and Operating Costs Including Site Readiness

• Grumman Costs

"—Support Engineering Development and Sustaining Effort for GSE, DTE, FTE- Manufacture and/or Modification of GSE, DTE, and FTE - (Excluding ACE

or New Equipment)- Software Development, Maintenance, and Control - Applications for Vehicle

System Tests and Data Reduction)- Publications Costs, Including Operations Updating- Maintenance and Support of Ground Equipment and Facilities - (Operations

Support)

• Boeing Costs

- Same Categories as the Above Grumman Costs

233

The accompanying chart shows projections ofNASA manhours required to staff each of the fouralternative support systems over the life of the shut-tle program. For a realistic tradeoff, the dollar costsof the preceeding chart should be considered alongwith the "ownership costs" implied by operatingmanhours. From this frame of reference:

• Concept B is the most economical choice

• Concept D ranks second in desirability

• Concepts C and A are comparatively expensive

Projected operating manhours were developedby using the number of checkout stations, numberof years of operation for each, a two-shift operationfor each, and typical staffing levels appropriate toeach of the four alternative concepts under consid-eration:

• For concept A, we used ACE staffing formanual checkout (as in concept C) followedby introduction of the new equipment, with'a 60-man staff, later in the program

• For concept B, we estimated that a two-shift operation of new automatic checkoutequipment would require only 60 men.This is a conservative estimate; depend-ing upon operating philosophy, the actualsystem could require a smaller staff

• For concept C, we assumed that ACE stationswould be used with an "Apollo" checkoutphilosophy, which would lead to a two-shift staff of 140 men

• For concept D, we estimated that a moreautomatic mode of operation for ACE wouldreduce the above staff by approximately 46%.From past studies of the Apollo checkouteffort, we believe this is a conservation esti-mate of staff reduction

234

PROJECTED NASA OPERATING PERSONNEL

• Concept A- 9.7M Manhours

.•Concepts- 4.8MManhours

, , . . ; . . : - . - . • Concept C - 14.8M Manhours

• Concept D - 7.7M Manhours

235

Concept A requires a transition from ACE to

new checkout equipment at a time when Shuttle

operations are intensive. This could present oper-

ational difficulties in getting the new system "on-line"

without compromising vehicle turn-around or mis-

sion availability. At the same time, concept A is

potentially the most expensive approach to Shuttle

support. For these reasons, it was eliminated from

the tradeoff.

Concept B is clearly the most economical ap-

proach, and does not suffer from the technical dis-

advantages of A or C. It was selected for use in the

low cost avionics study.

Concept C assumes essentially manual oper-

ation of ACE, as in the Apollo program. In view of

planned Shuttle mission schedules are implied vehicle

turn-around-times, it is doubtful that manual testing

is fast enough to suit the application. Again, from

the cost frame or reference, concept C is expensive.

We therefore eliminated concept C.

Concept D is slightly more expensive that B, but

overcomes the transitional and test time disadvantages

of A and C. Although it was not selected, we believe

its merits further study,along with B, as a candidate

for eventual implementation.

236

TRADEOFF

• Concept B Is the Cheapest of the Alternatives, Both to Implement and to Operate

• Considering Implementation and Operating Costs, Concept D Is the Next MostDesirable

• Concepts A and C Are Both Relatively Expensive, by the Above Criteria

237

Support Cost Distribution By Year For Concept B

This curve represents the probable yearly distribu-tion of the 458.7 million dollars estimated for supportof the low cost avionics configuration under concept B;it was developed on the basis of development, manu-facture, and operation cost spreads extrapolated toinclude G.E., Grumman, and Boeing costs.

Support Cost Distribution By Year For Concept D

The next curve is a similar projection of con-cept D support costs by year.

Comparison

The smaller concept B life cycle costs peak in1975-76 at approximately 38 million dollars per year.By comparison, concept D costs peak later, at approxi-mately 41 million dollars per year.

Significantly, D takes about two years to reachits average funding level of about 25 million dollars peryear. On the other hand, B reaches its average valueof 23.5 million dollars per year in about ten monthsfrom go-ahead, giving it the appearance of a "crashprogram."

238

SUPPORT COST DISTRIBUTION BY YEAR

SO-.

40-

30-SM

I ' I72 74 76

New Test EquipmentConcurrent Program(Concept B)

I ' I ' I ' I78 80 82 84

1 ' I ' I86 88 90

239

SUPPORT COST DISTRIBUTION BY YEAR

$M

ACE With Modified TestingConcurrent Program(Concept D)

, ' I ' I ' I72 74 76 78

, ' I ' I ' I ' I80 82 84 86 88 90

241

At this point, our best judgement is that the

risks, life cycle costs, peak yearly costs, and staff

levels implied by concepts B and D should be the

subject of further study. As the program develops,

concepts B and D should receive further consideration

for a number of reasons:

• Technical risk was not closely evaluated.

We assume that either ACE or new equip-

ment could be developed in the available

time

With respect to ACE, it is not at all certain

that equipment of 1963 design can be re-

furbished and maintained in operation eco-nomically in the 1985 to 1991 technology.

If it should become necessary to replace

ACE with something new at that late date

in the program, there would be a substantial

and unprogrammed cost increase

This above tradeoff was based largely upon

life cycle costs. As we will show later, con-

cepts B and D show significantly different

peak costs and yearly cost distributions

242

CONCLUSION

• Concept B Appears Most Desirable, But Requires Further Study

•Technical Risk?

- Peak Yearly Costs?

• Concept D Merits Further Study

- Could Have Lower Peak Costs and Less Technical Risk

- Practicality of Using 1963 Equipment Beyond 1985?

243

W31SASVIVO

QNOOUO

The ground data system associated with missionoperations represents a significant cost factor in theshuttle avionics development. The low-cost avionicsapproach requires a reduction in the onboard datasystem capability. Four baseline configurations for alow-cost avionics system were evaluated to determinethe degree of impact in program cost of accomplishingcertain types of data processing and evaluation usingthe ground data system of the MSFN and MCC. Theapproaches evaluated in this process used 1) commer-cially available avionics equipment, 2) space and mili-tary avionics equipment, and 3) newly developedavionics equipment. A fourth configuration consistedof a recommended system which is a combination toproduce the best low-cost approach to the problemsolution.

246

STUDY OBJECTIVES

• To Examine the Characteristics of Each Baseline System & Determinethe Impact on the Ground Data System

To Establish the Support & Differentials for Ground Data System Supportof Each Avionics Package ' " .

247

STUDY APPROACH

The approach used to develop the ground datasystem cost impact is given below.Develop a Ground Data System Baseline

A ground data system exists which will be mod-ified to support space shuttle. The Manned Space-flight network and Mission Control Center can beaccurately predicted for configuration for 1 January1974 (SKYLAB completion). Factors such as an in-tegrated network (MSFN plus STADAN), and a TORS,DOD (SGLS), and a MCC terminal system and database were also considered in the missions operationsbaseline.Determine Common Evaluation Criteria

Evaluation criteria was established to insurethat each configuration was weighted equally. Cri-teria was established using functions which are subjectto a ground-onboard trade-off or which are currentlybeing accomplished by ground data systems. Criteriawas established in systems management, trajectorymanagement, aeromedical management and missionmanagement.Establish Groundrules and Assumptions

The groundrules and assumptions were consistentwith the baseline. Special groundrules for cost criteriaincluded 1) Maintenance and operations cost of the

MSFN and MCC would not be charged to the shuttle;2) engineering, hardware and software developmentand implementation associated with supporting theshuttle would be charged to the shuttle cost.Major Cost DriversTechnical areas were defined which would contributesignificantly to cost impacts if implemented.Develop Ground Data System Concept

Each configuration was evaluated and require-ments developed. A ground data system concept wasgenerated for each configuration from these require-ments.

Determine Technical Impact for Each ConfigurationThe requirements and concepts were placed in

matrix form and compared for hardware and softwareimpacts; A delta for each configuration was estab-lished.

Provide Cost Comparison for Each Configuration

A baseline cost was established for engineeringand software for the configurations.Recommend a Level of Autonomy

A group of functions were evaluated to deter-mine their impact on ground data system processing.Those which produced the largest ground systemimpact were recommended.

248

STUDY APPROACH

• Develop Ground Data System Baseline

• Determine Common Evaluation Criteria

• Establish Ground Rules & Assumptions

• Develop Major Cost Drivers for Ground Data System

• Develop Ground Data System Concept for Each Configuration

• Determine Technical Impact on the Ground Data SystemBaseline for Each Configuration

• Provide Cost Comparison for Ground Data System Support ofEach Configuration

•.>- • Recommend a Level of Autonomy for a Realistic SpaceShuttle Program

249

Tracking and Data Acquisition Systems Other Than ExistingSystems

Unified S-band provides the primary trackingand data acquisition interface for the MSFN. Whilecertain sites have other capabilities, deviation from theprimary interface would result in upgrading each MSFNsite to satisfy the requirement.Polar Oribt Missions During Flight Qualification TestingPrior to TORS

Launches from the ETR using expendable or re-coverable boosters generate a complex launch program.The Mark I.vehicle can be supported as required fornominal launch azimuths. Polar missions during thesystem development and test phase would increasethe need for ground data system interface. Integra-tion of the MSFN and STADAN will partially alleviatethe problem of extended periods of limited contact.Use of the TDRS will eliminate the problem. If a highlevel of ground support is required for the Mark IShuttle, the polar missions should be deferred untilTDRS availability or less ground dependency must bedesigned into the vehicle. The alternative is to im-

. plement more sites in the network.Noncompatible Shuttle Telemetry System

The ground data system has a flexible capabilityto interface vehicle data types using the reprogram-mable decommutator. Should the limitations of thesesystems be exceeded in bit rate or format structure,then a significant impact would exist throughout thenetwork. The baseline systems provided a compatible51.2 KBPS data interface and an experimental (DPI)data link not exceeding the capability of the sites.

Use of a Command Technique Other Than Apollo

The command technique developed for Apollohas been proven through mission use. To introducea different method of command between the groundand the vehicle would require the development andvalidation of the new technique at considerable pro-gram expense. The need for command capability(word length, etc.) beyond the current capability hasnot been identified.Degree of Utilization of TDRS

The TDRS will become operational duringMark II. This system adds the flexibility of "anytime access" to the ground data system. The con-sideration for use of ground data system for extensiveprocessing functions becomes paramount. The TDRScan provide an integrated system but the degree ofintegration between vehicle and ground will havesignificant cost impacts.

Integration of DOD and NASA Acquisition SystemsInformation was consolidated concerning the

DOD and NASA systems. Inspection of these capabil-ities indicates that integration of these facilities into acommon network would provide an additional costto the program.

Transmission of Secure Data Through MSFN and ProcessingatMCC

The MSFN is not configured for handling securedata.

250

MAJOR COST DRIVERS

• Non-Compatible Shuttle Telemetry System (Rate & Format)

• Tracking & Data Acquisition Systems Other Than Current & Planned

• Polar Orbit Missions During Flight Qualification Testing Prior to a TORS

• Use of a Command System & Technique Other Than That AvailablePostSkyjab

• Degree TORS Utilization (When Operational)

• Integration of DOD & NASA Data Acquisition Systems

• Transmission of Secure Data Through MSFN & Processing at MCC

257

In the analysis of the configurations for lowcost avionics, it was found that the three major disci-plines of telemetry, tracking, and command were re-quired to support each configuration. The input para-meter rate to the MSFN and MCC was 51.2 KBPS foroperational telemetry and 500 KBPS for engineering(DPI) data. These rates did not exceed the capabilitiesof the remote site. The RF interface was unified S-band for all cases. In the evaluation of the hardwareconfiguration, it was determined that the hardwarecapability of the MSFN and MCC on 1 January 1974could support the space shuttle. No new procure-ments could be identified. Some modifications wererequired to provide an acceptable support configura-tion.

252

RESULTS OF PRELIMINARY SUPPORT ANALYSIS

• Ground Data System Support Reqmts are Approximately the Same for Eachof the Avionics Configurations Considered in This Low Cost Avionic Study

• The Post Sky lab Ground Data System Will Have the Capability to Supportany of the Avionics Configurations Considered

• No Major Hardware Procurements Could be Identified as Required forGround Support of the Shuttle. Only Modifications to Existing SystemsWere Required.

253

The software associated with the MSFN iemotedsite, GSFC communications interface and the MCCwere baselined at a functional level. The effect on thesoftware was that of introducing a new vehicle, suchas the ATM on SKYLAB, into the system. The tele-metry processor at the remote site was capable ofhandling the 1050 parameters associated with opera-tional telemetry. This number is somewhat larger thanthe CSM, but does not exceed the AM/ATM of SKY-LAB.

The baseline telemetry processing was the samefunctionally with changes required for input formats,input sampling rates, scaling, changes, limit sensechanges, event drivers, etc. The functional programwas not altered.

Command processing was required for Shuttlecomputer loads associated with flight dynamics andreal time commands associated with data retrieval. Nonew concepts would be identified. While program

changes will be required, a major software impactcould not be defined. The SKYLAB command tech-nique was adequate for the requirement. An increasein command requirement will exist for an unmannedvehicle but is within the capacity of the ground datasystem.

The trajectory processing will be impacted byan increase in launch complexity (launch azimuthsfrom 0 to 90 degrees) and a conceivable dog-leg launchto polar orbit from ETR. A recoverable booster mustbe considered and a new sequence of abort modes withthe orbiter and booster landing capability. The entryphase will present a new entry profile with precisiontrajectory management required. The baseline trajec-tory program will need to undergo extensive changeto satisfy the requirements. The manned mission sup-port requirements were compared with Apollo 8 andthe unmanned requirements with AS503. The base-lined ground data system could support the known re-quirements at the functional level.

254

RESULTS OF PRELIMINARY SUPPORT ANALYSIS (CONT)

No New Major Software Developments Could Be Identified. Modifications &Rework of Existing Programs Can Meet Reqmts

The Level of Ground Data System Support Required for the Mk I ConfigurationWas Determined to be Approximately the Same Level as Earth Orbital ApolloFlight

The Effect of an Unmanned Orbiter is not Considered to be a Major CostImpact Except in the Area of Command. The Effect of Automatic LandingSystem Must be Examined . . .

The Major Cost Impacts Associated With the Ground Data System Will ResultFrom Implementation to Meet the Support Reqmts for Mk I

255

A phased approach was considered for each con-figuration. The growth profile for each avionics pack-age was designed to meet only those requirements ofthe mission. A First Horizontal Flight (FHF), FirstManned Orbital Flight (FMOF) or Mk I and a final con-figuration (Mk II) were evaluated. A ground data sys-tem transition from each configuration was developed.The degree of autonomy achieved by the configura-tions varied with the recommended configurationachieving an excellent compromise. The analysis ofthese transition profiles led to the conclusion that theMk II orbiter will not require less ground support hard-ware, but rather will result in using less of the Mark Iground data system hardware and software capabili-ties. The Mk II ground data system requires the sameground support configuration except that a TDRS withany time access capability has been combined with theintegrated MSFN/STADAN, and the MCC will havefully-implemented terminal system and data base.These added capabilities to the ground data systemadd to its flexibility and make it attractive for use inaccomplishing the non-system functions of the shuttle.

The Integrated Network and MCC will be multiple usersystems. The impact of Mk II on the system will besimilar to the transition from one Apollo vehicle to thenext. Normal M&O of hardware and software shouldbe adequate for the transition. A completely differentMk II would not exceed the cost impact of a Mk I.

The results of evaluating the various configura-tions indicated that the ground system was insensitiveto the degree of autonomy of the vehicle. All the con-figurations reviewed established requirements for tel-emetry processing, trajectory support and commandload and RTC support. A basic configuration of theground system in hardware and software is required toprovide support in these disciplines. The degree ofmission time data use will provide the major reductionin ground data system cost unless one or more of themajor disciplines is deleted. The cost differential be-tween all configurations considered was minor, andthe engineering and software of the ground system

.could not be used as a cost driver in selecting an avion-ics configuration.

256

RESULTS OF PRELIMINARY SUPPORT ANALYSIS (CONT)

• Transition to Mk II Will be a Minimum Cost Impact on the Ground Since itInvolves Primarily the Deletion of Ground Support Functions Provided forMkl

• The Ground Data System Cost Differences Between the Avionics Configurationis Not an Influencing Factor in the Choice of Low Cost Avionics System

. Approach

• The Ground Data System Cost is Relatively Independent of Autonomy inthe Phased System Approach

• The Shuttle; Avionics Design, Regardless of the Cost Approach/Should be anIntegrated Effort With Full Assessment & Consideration Given to theCapabilities of the Ground Data System & TORS

257

The ground data system was evaluated to a func-tional level to determine the degree of characteristicsof a vehicle and its onboard processing functions whichwould have the most significant impact on the grounddata system. The impact will be primarily in the userfacilities of the processing and the required time framefor processing. The vehicle characteristics included asa minimum:

• Does not rely on ground data processingwhich involves real time processing in thedecision making functions

• Does not rely on the ground to process dataassociated with immediate vehicle, missionand payload deployment problems

• There is a telemetry exchange between vehi-cle and ground. The vehicle format shouldbe selectable by the ground or crew. (On-board compression should be examined asone method for transmission of normal oper-ational transfer of telemetry)

• The uplink to the vehicle involves the trans-fer of command loads and data acess realtime commands to the Primary computer

• Flight control programs are dedicated to vehi-cle systems and are refined programs which re-mains fixed

• Data management programs have programflexibility and are used as the growth side ofthe system. As vehicle autonomy increases,the data management capability is increasedwith the growth profile established to accom-plish the total real time processing of thevehicle (excluding payload) to manage thevehicle environment as the autonomy goal

• The flight control and data management soft-ware address only the space shuttle and thecontrol of its systems and its environment.All other processing functions are accomplishedon the ground or by equipment charged topayload

• The general ground support concept for sucha vehicle provides a flexible data retrievalcapability for both the flight crew and groundsupport personnel

258

GENERAL CONCEPT FOR MK II SHUTTLEGROUND DATA SYSTEM

Data

On-BoardPrimaryComputer

^ nequesis ^

- Formats ^* or TLM f

\

\Loads

Comm (USAnd/Or KBand)

t

^ Computer Words

i i

B »

i \. '

Crew Controlof Access orUse

t Orbiter Contractor

• Payload Contractors• Booster Contractor

• NASA Centers

255

The addition of the TDRS to the network andimpact of payloads must also be considered in con-sidering the degree of autonomy.Degree of Use of TDRS

The TDRS introduces a positive and negativeelement into the program. The "any time" accesswould allow a greater reliance on ground support. Thegoal of autonomy dictates less reliance. The allocationof data system functions as discussed above providesa meaningful use of TDRS with the space shuttle. Pro-cessing functions associated with the vehicle systemsand its immediate mission environment should be al-located onboard. Other processing functions whichtend to cause mission to mission software changesshould be allocated to the ground with the TDRS usedto access the data in the time interval required.Allocate Payload Operations and Checkout to the Ground

Payload varies from mission to mission and sowill the payload operations and checkout software.Use of the shuttle capability to bring the payload backif it does not work must be considered in conductingdata system trades in this area. Crew training associ-ated with payload checkout and operations must alsobe addressed. A software package for each payloadwill complicate the onboard system which has the pri-mary function of delivering or returning payload to orfrom orbit. Software for vehicle function can be contin-ually refined and improved. The introduction of ex-

ternal systems software for payload checkout and oper-ations will only complicate the onboard software de-velopment. Processing associated with checkout andoperations of payloads should be allocated to theground data system because of

• Crew training• Software development of onboard systems

from mission to mission• Any time access of TDRS• Availability of experts for assistance

• Calibration standards• The ground must interface the payload for

data retrieval anyway• Use the "any time access" capability of

TDRS as a major item of trade when assess-

ing ground data processing vs onboard data

processing

• Allocate payload checkout and operations

functions to the ground data system (De-ployment and its associated functions to the

vehicle)

260

AREAS OF CONCENTRATION FOR MK II AVIONICSCONCEPT WHICH IMPACT GROUND DATA SYSTEM

• Allocate Certain Systems Mgmt Functions Onboard

• Allocate Certain Trajectory Mgmt Functions Onboard

• Transfer Only Those Mission Mgmt Functions Onboard Which areConsidered Mandatory

• Use the "Any Time Access" Capability of TORS as a Major Item of TradeWhen Accessing Ground Data Processing Versus Onboard Processing

• Allocate Payload Checkout & Operations Functions to the Ground DataSystem

261

Preliminary analysis concerning trade-off of ma-jor ground support functions both on this study andprevious studies conducted in mission operations in-dicate that certain functions could be allocated to theonboard data system which would contribute to theautonomy of the shuttle vehicle and increase its in-dependence from the MCC. While much additionalstudy is required to establish a positive position interms of cost, safety and reliability, the following pre-liminary results are submitted:Mission Management

• Allocate those functions associated with man-agement of the vehicle and vehicle systems tothe onboard data management system (crewactivities scheduling, contingency planning(problem immediate), Reentry scheduling)

• Allocate functions associated with overallmission objectives with the ground data sys-tem (mission planning, mission scheduling,reentry and landing coordination, weather,biomedical monitoring and diagnostics).

262

MISSION MANAGEMENT CONCEPT - MK II

Allocate Functions Associated With Mgmt of the Vehicle & Vehicle Systems tothe Onboard Data Mgmt System

• Crew Activities Scheduling

• Contingency Planning (Immediate Vehicle Problem)

• Reentry Scheduling (Emergency Entry)

Allocate Functions Associated With Overall Mission Objectives to the GroundData System

• Mission Planning

• Mission Scheduling

• Reentry & Landing Coordination

• Weather

• Biomedical Monitoring & Diagnostics

263

Systems Management

• Allocate the mission time systems manage-ment functions to the onboard data manage-ment system (system checkout (priorityitem), system monitoring (priority item),real time control (priority item), system con-figuration control, communications control,and consumables control).

• Allocate the long term system managementto the MCC (maintenance planning, trendanalysis, consumables management, communi-cations access, failure analysis, and payloadoperations).

264

SYSTEMS MANAGEMENT - MK II

Allocate the Mission Time Systems Mgmt to the Onboard Data Management System

• System Checkout

• System Monitoring

• Real-Time Control

• System Configuration Control

o Communications Control

• Consummables Control

Allocate the Long Term System Mgmt to the MCC

• Maintenance Planning

• Trend Analysis

• Consummables Management

• Communications Access

• Failure Analysis

• Payload Operations

265

Trajectory Management Concept

• Allocate those trajectory areas which dealprimarily with preprogrammed functions tothe onboard data management system (IMUalignment, maneuver planning, vehicle ephem-eris, rendezvous planning, and entry and land-ing).

• Leave those functions associated with missiontime trajectory to the ground support system(multiple ephemerides, ephemeris calculations,navigation updates, guidance updates, retro-fire maneuver updates, time updates, EMU up-dates, and abort trajectory analysis).

266

TRAJECTORY MANAGEMENT CONCEPT - MK II

Allocate Trajectory Areas Which Accomplish the Following Functions to the OnboardData Management System:

• IMU Alignment

• Maneuver Planning

• Rendezvous Planning

• Entry & Landing

Allocate Those Functions Associated With Mission Time Trajectory to the GroundSupport System:

• Ephemeris Calculations

• Navigation Updates

• Guidance Updates

• Retrofire Maneuver Updates

• Time Updates

• EMU Updates

• Abort Trajectory Analysis

• Vehicle, Target & Payload Ephemerides

267

318VH3AO03Hoiismva

The first of four pressure-fed boosters studied isthe Model 979-141, - an expendable two-stage booster.The first stage consists of three strap-on tank/enginemodules which are expended and dropped at a veloc-ity of 2315 fps. The second stage, is expended anddropped at a velocity of 5157 fps. Thrust vectorcontrol of up to six degrees per engine is effected byON-OFF injection of N204 into 16 nozzles (LITVC)located around the throat of each engine expansionchamber. This control capability precludes the needfor tail fins that might otherwise be required to mini-mize upsetting moments that occur when boostingthrough the high wind shears often found at about30,000 ft altitude.

Navigation, guidance, and control intelligence

is obtained from orbiter-borne equipment. Triplethread redundant control signals are hardwired fromthe orbiter avionics bay to the TVC voter where thedominant ON-OFF signal is selected for activation ofthe TVC valves.

A multiplexed instrumentation system isemployed for developmental, operational, and pre-flight checkout instrumentation. This instrumentationsystem is also used to feed data on booster status tothe orbiter. Abort decisions and sequencing are ef-fected by the orbiter guidance computer and crew.

Squib-activated, silver-zinc batteries are used inthe booster stages to power the instrumentation,telemetry transmitter, destruct system, and to powerthe LITVC valves.

270

MODEL 979-141 UDMH/N204

2-Stage Expendable, Pressure Fed Booster

GLOW

BLOW

OLOW

Wpb

VSTG.

BOOSTER WT.

INERT

ORBITER WT.

INERTLANDING

DESIGN CHARACTERISTICS

1ST STAGE 2ND STAGE

6,530.000 LB

3.834.000 LB. 1.398.000 LB.

1.350,000 LB.

3.289.000 LB. 1.097.000 LB.

0.847

2.315 FPS 5.170 FPS

545.000 LB.

211.300 LB.168.500 LO.

19S.OOO LB.

THRUST/ENGINE

2.72 x 106LB(SLI

NOTE: ORIGINAL ESTIMATE

UDMH TANK

66« CU. FT.

SECOND STAGEMODULE (t PLACE)

260" DIAMETER-» •»

271

The Model 979-142 pressure-fed booster isidentical to the two-stage 979-141 described on theprevious page with one major exception: the firststage only is soft-landed by parachutes and recoveredfrom the sea for reuse. Since the average life of abooster motor is about twenty uses, the older boostmodules, previously used on the first stage, are ex-pended as second stages, because the cost of recoveryof the older motors is not justified.

The requirement to recover the 979-142 addsthe following requirements to the booster avionics,as described for the 979-141:

• A parachute sequencer, using thrust chamberpressure decay as the initiating signal, isadded

• A UHF recovery beacon is added to each ofthe three boost modules, to aid the recoveryship in locating the units after splash-down

• Special salt water protection techniques areused on cable connectors and electronicpackages. The added cost of using 0-ringseals, corrosion resistant metals, and pottingof cable connectors is estimated to be$25,000 per booster

272

MODEL 979-142 UDMH/N2O4,2-Stage Recoverable Pressure Fed Booster

<Q

^-l;S

s ~^., —\_

>.>v

. ..: XJ

fJ

iL

hfJ-U


1ST STAGE 2ND STAGE

GLOW 6,853.000 LB.

BLOW 4,132,000 LB 1.370,000 L.B

VSTG 2'279 FPS 5'165 FPS

INERT 702,000 LB 233.000 LB.IMPACT- 682,000 LB

ORBITERWT.INERT 211,300 LB.LANDING 168,500 LB.

THRUST/ENG. •V" 2.88 x 106 LB (S.L.)


273

SECOND STAGEMODULE (1 PLACEI

260" DIAMETER •*• —

The Model 979-143 is a single-stage booster con-

sisting of seven identical engines fed by a single tank

assembly of UDMH and N204. The entire stage is re-

covered by deploying drogue and main parachutes

after a controlled re-entry at 70° deg angle-of-attack.

Recovery of the attitude control system, recovery

beacon, destruct receivers, TVC and RCS drive elec-

tronics, telemeter receiver and instrumentation is

aided by special salt water protection techniques that

minimize refurbishment costs.

274

UDMH/N204, SINGLE STAGE, MODEL 979 - 143

/1 ^- ~ "7

^^ ~^~

,'

^v

61

|

OIA. N2<H LINE

\ I

\ \

,<\

t \ ^TOR" nia .707

ELLIPTICALBULKHEAD (TYPI


:12O4 TANK

14.810 CU. FT.

UDMH TANK

31.975 CU. FT.

260" DIA. ORBITERDROP TANK

BOOSTER NOSE

STA 2145

GLOW

BLOW

OLOW

PROPELLANTWEIGHT

"STG.

BOOSTE R WT.INERTIMPACT

7.592.000 LB.

6.242.0OO LB.

1.350.000 LB.

5.280.000 LB.5.O29.000 LB. ASCENT

251.000 LB. LITVC

O.Mf

5.354 rrs

3,765"

/Tx~t

\j.7' '

<;SEPARATION

STA. 2270

If

LITVC(N2O4 INJECTIONI

• THRUST / ENGINE1.36 x 106LB(SL)


275

The Model 979-144 like the Model 979-143, is

a single-stage booster consisting of seven identical

engines fed by a single tank assembly. The major dif-

ference between the 979-144 and the 979-143 is that

LOX-RP propellants are used instead of the UDMH

and N204 propellants used in the 979-143. The LOX-

RP propellant, although lacking the storability feature

of UDMH - ^64, is free of the toxicity problem of

UDMH - ^04, and is a lower cost propellant to manu-

facture.

The avionics and recovery techniques for the

979-144 are essentially identical to that selected for

the Model 979-143.

276

LOX/RP - 1. SINGLE STAGE, MODEL 979 - 144DESIGN CHARACTERISTICS

58" DIA. LOX LINE

396" DIA. v.707ELLIPTICALBULKHEAD (TYPI

GLOW

BLOW

OLOW

PROPELLANTWEIGHT

VSTG

BOOSTER WT.INERTIMPACT

ORBITER WT.INERTLANDING

LITVC(LOX INJECTION)

• 6.945.000 LB

• 5.59S.OOO LB.

• 1.350.000 LB.

4.700,000 LB.

4.476.000 LB. ASCENT

224.000 LB. LITVC

0.840' :

5.372 FPS

895.000 LB.'866.0OO LB.

^THRUST/ENGINE •1.24 I 106 LB (S.L.I


277

BOOSTER TRAJECTORY MODEL

300-

200-

Altitude,K FT

100-

278

REENTRY TRAJECTORY

6-,

qr 1.000-1

800 H

600 H

I 400^CD

Q 200-

0J

4j

3'

2

1MainChutes

roguev >/ MChutes

Impact = 150fps

100 200

Time From Staging, Seconds

300 fImpact335 Sec

275

RECOVERY SEQUENCE

REENTRY/DECELERATIONORIENTATION

Boaster Oriented , Broadside • Two 4-Ft Diaby Reaction Control Reentry(a= 70°) Pilot Chutes

• Balanced By Mortaf Deployed .'DyhedralFins

PITCH DOWN

• Two 45-Ft Dia DrougeChutes Deployed at • Six 120-Ft Dia MainM = 1.2 and 50,000 Ft Chutes Deployed

Reefed At M = 0.6 • 0.8 and38,000 Ft De-Reefed 4Seconds Later

• Bridle AttachedFor -30° WaterImpact

RETRIEVAL

DECELERATION ANDLET - DOWN

at Impact

• DetachFins atImpact

Impact

V = 150fpsW = 895 K

281

A Monte Carlo analysis was conducted onstatistics of BRB wear-out and attrition. All casesanalyzed assumed 445 flights and assumed that theprobability of loss was independent of the flighthistory or design life of the booster. One hundredsimulations were run at each point analyzed to providea reasonable sample size.

Parametric results are shown on the facing page.These results provided the basis for determining thenumber of boosters required for the operational pro-gram. The total number of boosters required is basedon the following assumptions:

1. The booster has a useful life of 20 flights.2. The booster reliability is 0.99.3. The recovery system reliability is 0.98.4. The probability of favorable weather in the

recovery area is 0.995.5. The number of boosters can be based on 50%

probability of completing the 445 reusablelaunches without depleting the booster stock-pile.

The required number of boosters for each of thefour programs is shown in the table below.

NUMBER OF BOOSTERS REQUIRED FOR 460FLIGHTS

(Loss Probability = 0.035 per flight)

PROGRAM DESIGNATION

No. of Boosters -141 -142 -143 -144

460 127 45 45

282

DETERMINATION OF REQUIRED NUMBER OF BALLISTICREUSABLE BOOSTERS

P = 0.025 (Loss ProbabilityPer Flight)

0.50 ( Probability of Completing445 Flights Without Running)ut of Boosters)

30 n0.80

0.90

P= 0.05 (Loss ProbabilityPer Flight)

0.50

i 1020 30 40 50 20 30' 40 50

No. of Boosters No. of Boosters

283

Major avionics trades for the ballistic recover-able booster involve the difference in redundancyrequirements between the boost and recovery phases.The orbiter G&N equipment has the capability toeffect control of the mated vehicles and to do sowith the required level of redundancy.

When considering recovery of the pressure-fedbooster, one of the techniques involves an activeattitude control system employing reaction controljets, requiring some booster-located guidance andcontrol equipment, albeit crude compared to theboost phase G&N requirements. Equipment costsfavor the selection of orbiter-located G&N for theboost phase function, with a simple single threadattitude control system to effect a high drag re-entryprior to chute deployment.

284

AVIONICS TRADES

• G&N Redundancy

- Boost? - Reentry?

• Boost G&N

- Orbiter vs Booster

285

Considering the redundancy question by itself,independent of the "orbiter versus booster G&N forboost phase" issue, two basic techniques are available:(1) Triple masking redundancy employing simplemajority vote, and (2) dual standby redundancy usingcomputer interdiagnostic techniques. Although thedual standby redundancy technique is basically ca-pable of providing higher reliability with less hardwarethan the triple-voted method, greater experienceexists with the voting method, thus it was selected atthis time because of its lower development risk factorSince this reasoning applies for either the orbiter orbooster avionics, it follows that triple redundancy isrecommended whether orbiter-located or booster-located G&N equipment is used for the boost phase.

Redundancy of the booster avionics for the re-entry phase can be relaxed relative to the boost phasebecause the man-rating requirement is removed atorbiter-booster separation. With the re-entry attitudecontrol phase lasting approximately five minutes,the failure rate for single-thread redundancy is con-sidered adequate.

286

G&N REDUNDANCY• Boost

- Dual Monitored "Off-Line-Redundant" Higher Risk and Lower Cost is Not Obvious

. • . •: Re-Entry

- Single Thread Redundancy Contributes Approximately One Failure in 1000 Hrof Flight

- Vehicle Uses System 3 Min Each Flight Max No. of 20 Flights•t

- Therefore Probability of Vehicle Loss Due to Avionics Is 1 in 10 vs Assumed: Vehicle Loss Due to Recovery of 1 in 20

• Recommendation

, i . - Single Thread Redundancy Required for Re-Entry

- Triple Voted Required for Boost

287

Boost Phase G&N in Booster

Beginning with the requirement that an attitudereference unit (or platform) and a flight control com-puter (or G&N computer) are required in the boosterfor attitude control during re-entry, then two addi-tional platforms and two additional G&N computersare required to meet the triple redundancy require-ment for the boost phase. (Note: The re-entryattitude control system will require simpler equip-ment than a single-thread of the boost phase G&Nequipment; however, since the re-entry controllerhas not yet been fully defined, and as an aid togetting a first-cut on price comparison, a boost phaseG&N system was assumed for the re-entry controller.)

Boost Phase G&N in Orb'rter

The additional memory and software requiredin the orbiter prime computer for engine sequencing,abort logic, and thrust vector control of the boosterinduce additional costs to the orbiter that are tradedagainst the cost savings in the booster. An additional75 Ib of inert weight, added to the orbiter over a ten-year life of the program (assuming a traffic model of445 missions), moderates the advantage of using theorbiter G&N equipment for the boost phase controlof the booster.

The recommendation resulting from thistechnical trade is to utilize the orbiter's G&N equip-ment for boost phase guidance of the mated vehicles;and a dedicated special-purpose controller for there-entry phase of the booster.

288

IMPLEMENT G&N IN ORBITER OR BOOSTER?

• A In Booster

2 G&N Platforms @ 83K = 166K

2 G&N Computers @ 45K = 90K

Subtotal = 256K

46 Ship Sets @ 256K per Ship = 11,776K

100 Lb @ S5K per Lb in Booster = BOOK

Booster Total =12,276K

• In Orbiter

G&N Platforms and Computers in Orbiter = 0

*0rbiter Program Cost = 5,500K

*75 Lb @ S32.4K per Lb in Orbiter = 2,430K

Orbiter Total = 7.930K

Life Cycle Cost Would Appear to Reinforce the Trade.

*See Interim S-IC in Final Report

289

The navigation, guidance and control intel-ligence is obtained from orbiter-borne equipment,which is triple-threaded using the simple majorityvoting technique for redundancy management. Thecontrol signals for the LITVC function in the aft ofthe booster are voted at the input to the single-threadelectronics required to drive each of the ON-OFFLITVC valves.

The recovery technique selected for the Model979-144 requires a reaction controlled attitude con-trol system: the booster has two aerodynamicallystable modes during re-entry, one at 0 deg angle-of-attack, and another at 70 deg angle-of-attack. As ameans to minimize the parachute development pro-blem the 70 deg mode was selected because it has amuch lower ballistic coefficient (W/Cj-jA) than the0 deg re-entry attitude. However, in order to achievethe 70 deg attitude for re-entry and to dampen oscil-lations during re-entry, an attitude reference plat-form (or its equivalent) is required. A simple analog

or special-purpose digital computer is adequate tosignal the reaction control system (RCS). The base-line RCS is a bi-propellant, operating at a thrustchamber pressure of 98 psi; however, an alternateRCS which uses the ullage gas (100 psi) availablefrom the main fuel tank, is attractive. The RCSconsists of two, 500 Ib thrust engines in pitch, two,500 Ib thrust engines in yaw, and four, 250 Ib enginesin roll. A parachute sequencer, utilizing total andstatic pressure sensors, deploys the two drogue chutesat 50,000 ft (M 1.2) altitude and the six main chutesat 56 psf(M 0.6-0.8).

A multiplexed instrumentation system is em-

ployed for developmental, operational, and preflight

checkout instrumentation. This instrumentation

system is also used to feed data on booster status to

the orbiter. Abort decisions and sequencing are

effected by the orbiter avionics and crew.

290

BALLISTIC RECOVERED BOOSTERBOOST GN&C IN ORBITER

L\

Ring.Sifnv

ATitenwtry

A*~ Dm

Coupler *~RAU'S4

•^ tnstrumantltion

Rsquirad if Qfblter li Nat Utad For Control During Boon

291

wosiavdwoo3UVMQUVH

Using results derived from RCA's PRICE pro-gram (a computer modeling technique for projectingthe cost of electronics) it is possible to quantitativelyevaluate the alternates of selecting FAA, MIL, orSpace Standards for space shuttle avionics. Theillustration compares costs of the several approachesnormalized to the development cost of an FAAequipment. These results are typical of an all-electronic equipment. Production costs are gen-erated for a run of 34 units. The reliability associ-ated with each standard is shown, normalized tospace reliability. Units to Maturity - reflects thetypical number of units for each class of construc-

tion needed to get a mature product. Mainte-nance costs are developed assuming a 10,000 hr totalunit life with a 10% of unit cost attributed to eachfailure. The remainder of the chart shows in sum-mation several possible combinations of life cyclecosts for a given unit. The 20% development linerepresents a good approximation to the cost ofan "off-the-shelP' equipment which requires somemodifications for the shuttle application. Fromthese results, one can compare the cost of vari-ous strategies considering only the cost of equip-ment and its maintenance. This is not the onlycost. Another cost is considered on the next page.

294

FAA/MILITARY/SPACE COMPARISON

FAA1 MIL2 SPACE3

Development Costs 1.0 1.3 2.3

Production Costs (34) .8 1.2 1.9

Reliability (FR) 5.0 2.5 1.0

Units to Maturity 200. 50. 10.

Maintenance (10% per F) 1.6 1.2 .8

Prod + Maint 2.4 2.4 2.7

Dev + Prod + Maint 3.4 3.7 5.0

20% Dev + Prod + Maim 2.6 2.66 3.16

1. Standard commercial aircraft design standards (ARINC)

2. MlL-E-5400 (SST electronics probably fits here)

3. NASA Man Rated Equipment Standards

235

To assess the true impact of failure, we mustconsider vehicle aborts which result from equipmentfailure. For purposes of example, failure rates for atypical equipment have been selected. We assumethat the FAA equipment has a failure rate of 2000PPM and has an absolute cost as indicated on theprevious slide. Under the conditions outlined, wecan then establish a cost penalty per vehicle and acost for a four-vehicle fleet which applies foraborts resulting from equipment failure. Note thesignificant differences between the various standards.

296

FAILURE PENALTY

Example:

• Failure Rate (2000 PPM - FAA ^{1000 PPM-Mil [( 400 PPM - Space j

• 100 Missions for 100 Hours

• Triple Redundancy - Two Failures = Abort

• Abort Cost = $5 M

Then: Cost Per Vehicle, $K Four Vehicle Fleet, $K

FAA 450 1800

Mil 115 460

Space 25 100

237

This table shows the results of combining thefigures derived in the previous two charts. Column1 shows the life cycle equipment cost listed in in-creasing order. Column 2 applies the abort penaltyderived for a four-vehicle fleet. Column 3 sums thetwo figures. As can be seen, MIL standards is leastcostly for new design. For modified piece, MILagain is most effective but space is very close, andfinally, an existing space box is the least costly ofall. Thus, a policy of selecting MIL equipment forthe shuttle appears to make'economic good senseunless an existing space design is available.

298

FAA/MILITARY/SPACE COMPARISON (CONT)

Acq Maint, $M Abort, $M Total, $M

Existing FAA 2.4 1.8 3.8

Existing Mil 2.4 .46 3.0

Modified FAA 2.6 1.8 4.4

Existing Space 2.7 0.1 2.8

Modified Existing Mil 2.8 .46 3.2

Modified Existing Space 3.2 0.1 3.3

New FAA 3.4 1.8 5.2

New Mil 3.7 .46 4.2

New Space 5.0 .1 5.1

299

CONCLUSIONS - LOW COST RISK AVIONICS

• Development Costs more than Shuttle Production

• The Management & Systems Engineering for Redundancy Cost More thanthe Added Hardware

• FO/FS Makes Economic Good Sense

• Autonomy Principally Affects On-Board Software Costs

• Autonomy Must Be Defined on a Mission Basis

• Software Dominates DM Hardware Costs by at Least 4:1

- Do What it Takes in the Hardware to Minimize Software Cost

300

CONCLUSIONS - LOW COST RISK AVIONICS (CONT)

• Data Bus Should Be Used for Data Acquisition & Probably for G&C

• Digital Technology, in the Long Run, Will Be Cheaper, Lighter Than EquivalentAnalog Function

• Derived Low Cost Avionics Reduces Risk More Than Identified Cost

• No Hardware Technology Breakthroughs Required

• Ballistic Recoverable Booster Will Significantly Reduce Avionics Cost

• Avionics is an Expensive Place to Reduce Weight ($100 - 500K per Lb)

• Large Computer Complex not Required for First Horizontal Flight

307

COST/RELIABILITYANALYSIS

SPACE SHUTTLE STUDY COST/RELIABILITY ANALYSIS

• Redundancy Analysis

• Ground Support Impact

• Reliability Tradeoffs

• Life-Cycle Cost Evaluation

305

The degree to which redundancy is applied tothe onboard shuttle avionics is a direct determinantof hardware and software program costs. Thus, theuse of redundancy on each avionics function and eachLRU must be justified on a basis of program needsand economy. An effective way of accomplishingthis is to assign each avionics function (and eachLRU) one of the three critically levels listed. As afunction of criticality, the basic definition of re-dundancy requirements is as shown. This representsa minimum level of redundancy in each criticalitylevel. Any additional redundancy must be justifiedon a life cycle cost economical basis. General Elec-tric studies have shown that approximately 40% ofshuttle avionics LRU functions are crew safetycritical, 45% are mission critical, and 5% are for crewconvenience. In this manner redundancy (and cost)is significantly reduced when compared to the ori-ginal FO/FO/FS requirement for all functions.

306

LRU CRITICALITY ASSIGNMENT IMPACTON REDUNDANCY

Critical ity

1(Crew Safety)

2(Mission Critical)

3(Convenience)

Redundancy Impact

Continue Mission with Two or More Units Operative;if Only One Unit is Operative

Continue Mission if One Unit is Operative; Option toif No Units are Operative

Abort

Abort

Continue Mission if No Units are Operative

307

The degree of criticality for LRU's inpacts notonly the the redundancy as described, but also thedegree of testing required, i.e., the higher criticalityLRU requires more qualification testing. This showsthe testing impact for each criticality level taking intoconsideration that off-the-shelf equipment unmodifiedor modified, or new development equipment meetingeither FAA, airborne military, or space requirementsmay be used for the shuttle avionics. Thus, via LRUcriticality assignment the resultant testing impactreduces the overall avionics testing costs.

308

LRU CRITICALITY ASSIGNMENT IMPACT ON TESTING

Criticality Testing Impact

1(CrewSafety)

2(MissionCritical)

(Convenience)

Full Qua! for New Developments; For Off-the-ShelfHardware Qual Test Only Parameters Where SSS Environ-ment is More Severe

Full Qual for New Developments; Certification by Similarityfor the Off-the-Shelf Equipments

Use Only Certification By Similarity or Based on Development/Acceptance/Flight Test Experience

309

General Electric investigated the cost/perform-ance relationship of using existing ACE, modifyingACE or developing a new Ground Checkout System,Unified Test Equipment (UTE).

Conclusions reached are that UTE is the mostcost effective system, Ground Checkout costs are asignificant driver, approximately S120M for theDDT&E and delivery of approximately ten systems tothe field.

Of special interest is the fact that UTE costs areindependent of the four onboard avionic systemsconsidered.

UTE can be designed to minimize the numberof consoles and operators. Through modular buildingblock techniques and common designs, each systeminstallation can match the particular site require-ments.

310

GE AVIONICS GROUND SUPPORT SYSTEM

• Potential Avionics Cost Driver

• UTE is Cost Effective Versus ACE

• UTE Cost Not Sensitive to Onboard Avionics Configuration

e UTE Cost Advantages

- Low First Cost

- Comparatively Low Operating Costs

- Cost Effective Growth Capability

• UTE Functional Advantages

- Automation

- Modularity

- Commonality

- Flexibility

311

In 1962, 1 T. Duane, at the General ElectricMotor and Generator Department examined the per-formance of electromechanical and hydromechanicalproducts (such as motors, generators, turbines, water-wheels, etc.) which had undergone many thousandsof test hours. His efforts resulted in the formulationof a technique for predicting the reliability growth ofcomplex equipment as given by the log-log equationon the illustration. The main axioms determined asa result of this study are shown. In 1968 GeneralElectric's Aerospace Electronics Systems Depart-ment initiated a study to determine the applicability

of the Duane MTBF growth equation to aerospaceelectronics equipment programs. GE-developedavionics on the F-l 11 and P-3C programs and histori-cal data on various Air Force and Navy programs forspecific avionics equipments were studied and theresults confirmed the applicability of the Duane re-liability growth model. During 1969 and 1970 GEtested and verified this model by implementing itsprinciples on several current avionics programs. Theevaluation results from the Reliability Planning andManagement (RPM) technique which is briefly de-scribed next.

372

RELIABILITY GROWTH MODEL

• MTBF = at + b On Log-Log Scales

• Axioms

- Reliability Improvement of Complex Equipment Follows a MathematicallyPredictable Pattern

- Reliability Improvement is Approximately Inversely Proportional to theSquare Root of Cumulative Operating (Test) Time

- For a Constant Level of Corrective Action Effort & Implementation, ReliabilityGrowth Closely Approximates a Straight Line on Log-Log Scales

- These Relationships Permit use of a Simple Technique for Monitoring ProgressToward a Predetermined Reliability Goal

• Data Source

- Initial Patterns Developed in Early 1960'sfrom Data on Five Divergent Groupsof Products Based on Typically 50,000 Hours Operating DataTwo Hydromechanical Devices, Two Complex Aircraft Generators,One Aircraft Jet Engine

- Pattern Confirmed by AESD to be Applicable to Avionics from Data OnFour Programs

313

Reliability Planning and Management (RPM) is anew methodology developed by GE to relate reliabilitycriteria to program planning options and constraints.It incorporates predicted reliability growth rates anddemonstrated reliability growth rates, the latter basedon visible evidence of performance, enabling the di-mensioning of time, resources, assets, and facilities re-quired to bridge the gap between the sterile specifiedreliability requirements and the practical reality of pro-gram execution.

Based on GE evaluation and application experi-ence, certain axioms must be accepted to apply RPM:

• That no design is ready to release for prod-uct manufacturing until (using MIL-Hand-book 217A failure rates) a reliability pre-diction of 125% or more of the specifiedMTBF requirement is established

• Based on historical data, initial product per-formance will be approximately 10% of thepredicted value

• Reliability growth is predictable and alphavaries from approximately 0.1 when a con-tract has no specific reliability improvementrequirements to approximately 0.6 when anambitious reliability improvement program isimplemented

• Where the min/max alpha growth lines in-tersect, the required MTBF determines themax/min reliability demonstration test hoursrequired to meet the specification.

• The option (reliability program, number ofunits to be tested, facilities, etc.) which bestmeet program needs economically and withinthe program constraints is planned in detail,implemented and managed.

These axioms permit the portrayal of RPM on onesimple chart as shown here. This is the ReliabilityPlanning and Management Model as presented by GEto government and industry.

314

RELIABILITY PLANNING & MANAGEMENT• Initially Released Design - Approx 10% of Predicted Inherent Capability

• Growth-Plan Program Based on Duane Growth & RPM Tradeoffs

• Prediction-Simplify Design Until MIL HDBK-217 Prediction is 125% of Reqmt

• Screening/Processing-Adjust Levels to Meet MTBF Reqmt

u*E

• 100%

£ 10%

a= Growth Rate

Prediction

Reliability Growtha=.6Max Rate

-Hi Rel -;

AsReleased.. a=.1

Min RateNo Specific Rel

Evaluation Exposure, Hrs (Logarithmic)

MaxProg Planning Options• Equipments• Facilities• Level of Corr Action

'Min Option

Prog Constraints• Chg Limitations, i.e., Config Control• State of the Art• Dollars• Time

315

Shown here are the actual RPM results on APQ-

113 Attack Radar used for the F-l 11 program. RPM

was applied about midprogram and there was excel-

lent model correlation as shown. The initial equipment

configuration had 16,000 parts, a predicted MTBF of

90 hr compared to the 137 hr minimum requirement,

and an actual initial demonstrated 9 hr MTBF. RPM

analysis indicated that this initial configuration would

not meet the specified MTBF within the program time

and funding constraints. Thus, the equipment was re-

designed into a reduced parts count configuration now

having 10,000 parts, a 180 hr MTBF prediction, and a

plan for extended parts and product screening. As can

be seen, the initial demonstrated MTBF was approxi-

mately 18 hr (10% rule) and the actual reliability

growth rate was an alpha of 0.5 (high reliability pro-

gram effort). The specified MTBF was achieved after

approximately 9,000 hr of Reliability Demonstration

testing and consistently improved thereafter. Note

when configuration change constraints were applied

via implementation of configuration control on pro-

duction units, this lower flexibility also resulted in

an expected lower reliability growth rate as shown.

316

RPM MODEL - PROGRAM 1

200-

2100-1 80-i • •u.- 60-oa5 40-1

20-

10-

• Analog/Digital• 10,000 Components

• LRU Burn-In

Specified MTBF, 137 Hours

• Component Part Screening• Reliability Demo & Acceptance

PerMIL-R-26667 . P r o d Accept

ConfigChg Constraints"

446 Unitsccept I

'a =.50

-(10% Reqmt & Prediction)

I2 4 6 8 10 20 40 60 80100 200 400

Time, Hours x 100LRU Environmental & Reliability Demonstration Hours

377

The RPM model for the AN/APQ-113 Attack

Radar as shown on the previous page was applied by

GE into a major design improvement program. This

improvement represented a 20% design-modified ver-

sion of the AN/APQ-113 Radar, forming the new AN/

APQ-114 Radar. Using RPM planning analysis, a com-

posite model based on the predicted performance of a

mixture of changed and unchanged parts resulted in an

initial MTBF estimate of 33 hr. A conservative reli-

ability growth slope of alpha equals 0.375 was selected

yielding a required 3,750 hr test program. This plan

was negotiated as part of the contract with incentives

and was implemented. As can be seen, correlation

between performance and plan was excellent. The

actual alpha was 0.48. After completing the 3,750 hr

demonstration, the 21 production systems which were

subjected to Reliability Acceptance Testing measured

212 hr MTBF, substantially exceeding the specified

MTBF.

318

RPM MODEL PROGRAM 2

EVENT HISTORY

1

•»oc

Event

Dev Models3 Systems

Prod (20% Change84 Systems Hardware)

Test & Fix (3750 Hours)3 Systems

Prod Acceptance Test21 Sys

1966

l|2|3|4

•

1967

l|2|3|4

• B

^

'

1968

1|2|3|4

••

tm

'

1969

1|2|3|4

• ^

—

1970

1|2|3|4

•i

'

RELIABILITY GROWTH-PREDICTED vs EXPERIENCED250

- 50 S

(Hr) 100(Yr) 1/1/68

Time

319

40001/1/69

When applying general RPM analysis to the

Space Shuttle low cost avionics objectives, certain

guidelines become apparent as follows when also the

low production volume is considered:

• New equipment designs should be avoided as

much as practical in order to eliminate the

cost and time needed to grow the reliability

from the initial 10% of prediction (b) to full

specified MTBF

• Achieve the Shuttle program time constraints

by timely attainment of the required MTBF

via optimum tradeoff between the reliability

design/implementation, accelerated testing

(step stress, overkill, etc.) and selection of

number of units to be tested simultaneously

• Be certain that the predicted MTBF exceeds

the actual Shuttle required MTBF by at least

25%

• Include in the RPM implementation plan an

aggressive program of reliability problem

identification, corrective action, and test

validation

• Include in each Shuttle avionics equipment

specification the requirement to plan and im-

plement a reliability program using the RPM

technique

• Measure and manage the Shuttle avionics

reliability growth using RPM for the overall

avionics system, each subsystem, and each LRU

320

RPM APPLIED TO SPACE SHUTTLE

(WITBF = at + b

• Beware of New Equipment Designs

Where Reliability Will Be Approx 10% of Prediction

• Address Time Constraints

Through Accelerated Testing (Step Stress Overkill)

• Accelerate Reliability Growth

Through Aggressive Problem Identification, Corrective

Action &. Test Validation .

• Assure That Substantive Rel Predictions Exceed Reqmts

By Sufficient Margin to Enhance Achievability & Allow

for Uncertainties

• Optimize Level of Screening Tests

Commensurate With Reliability Reqmts

(b)

(t)

( a )

(MTBF)

(MTBF)

327

RPM can readily be used to tradeoff whether to

grow an existing equipment otherwise meeting require-

ments to also meet the specified MTBF or to select a

new development. A mature existing equipment would

have an alpha of about 0.15 and a new development

would have an alpha of about 0.5. As shown, in the

example, the required MTBF is 1,000 hr, the existing

equipment has an initial MTBF of 600 hr and the new

equipment has an initial MTBF of 150 hr. The new

equipment and existing equipment, respectively, re-

quire 5,000 and 2,000 testing hours to achieve the

required MTBF. If, for example, program timing is

such that the testing has to be completed in 3,000 hr

then two new development equipments must be tested

in parallel. The cost of the two testing programs and

two reliability programs along with other recurring and

. non-recurring costs may be now compared and evalu-

ated for selection of the best candidate.

322

RPM APPLICATION EXAMPLE FOR SPACE SHUTTLE10000-1

Required MTBF

1000 2000 5000 10000

Test, Hours

323

100000

GE has developed a Life Cycle Cost model for

Shuttle avionics cost comparison for any two can-

didates taking into consideration such factors as

non-recurring development costs, unit recurring pro-

duction cost, MTBF, redundancy, maintenance cost,

mission abort probability, vehicle loss probability,

cost of mission abort, cost of vehicle loss, number of

missions, number of vehicles, mission duration/

phases, weight penalty, power penalty, ground support

cost, etc. This illustrates the results using the model

to compare two candidate IMU's used in the Shuttle

without redundancy. Candidate 1 has an MTBF of

3,000 hr and a hardware/software cost of SAM.

Candidate 2 has an MTBF of 5,000 hr and a hard-

ware/software cost of $6M. After 445 missions the

3,000 hr MTBF equipment has a life cycle cost of

about $80M compared to a cost of about $50M

for the 5,000 hr MTBF unit, showing that the higher

MTBF unit is much more economical. In this example

further analysis must be made on testing candidates

with redundancy using the same model.

324

LIFE CYCLE COST-RELIABILITY EXAMPLE80-i

70-

60-

50

u

u

« 30H

20-

10-

1

IMU. MTBF = 3000 Hrs /<# '1 I <*> i

IMU2 MTBF = 5000 Hrs

10 100No. of Flights

325

1000

General Electric as a Grumman team member has

concluded in its studies that redundancy requirements

should be determined by functional criticality in com-

bination with LRU reliability assessment. In addition,

once LRU candidates are identified, it is recommended

that an early well-planned test program implementingthe Reliability Program Management technique can

significantly improve the reliability and hence the

operational availability of each LRU and result inlower risk and lower life cycle costs.

New ground checkout equipment is most cost

effective for the Shuttle program and the costs to

develop this test equipment is insensitive to the on-

board avionic systems considered.

326

AVIONICS STUDY LESSONS LEARNED

• LRU Criticality Assignment Reduces Redundancy and Testing Requirements

• UTE for GSS is Cost Effective

• UTE Insensitive to Variations in Configurations

• Reliability Program Management Techniques Can:

- Enhance Equipment Tradeoffs

- Reduce Risk

- Increase Schedule Confidence

327

SNOIJ.VQ

RECOMMENDED FOLLOW-ON EFFORT

• Confirm Major Architecture Decisions

- Dedicated Flight Control Computer

- Digital Flight Control Computer

- Fly-By-Wire

- G&N Function in Central Computer

- Dedicated Flight Instruments

— Further Study to Determine Technical Possibilities vs Over-All ProgramCost for Development of Common Use RAU

— Further Study to Determine Best RF Transmission Means/Bands forDFI Due to Quantity of Data to Be Transmitted

- Phased Growth Program (FHF, Mk I, Mk II)

- Crew Size

- SST Flight Control Actuators

- Review Candidate Equipments With NASA RQ&A

• Define Mission Reqmts to Ensure that the System Designed Will Satisfy theUltimate Reqmts

• Define the Avionics System to the Next Level of Detail (Prel EquipmentProcurement Specs, Interface Control Documents, etc)

330

RECOMMENDED FOLLOW-ON EFFORT (CONT)

• Conduct Tech Tradeoff Studies in the Following Areas:

- Auto-Landing Aids

- Software Sizing

- Redundancy Levels

- Extent of Cross Strapping

- Ground/Flight Interface,. Reqmts

- Mk I On-Board vs Ground Checkout

• Conduct In-Depth Reviews of the Siutability of the Low Cost EquipmentCandidates for Space Shuttle Application. Define and Cost Delta RQ&A

• Study the Reqmt for Unmanned Vertical Flight Test

• Define Safety & Mission Success Reqmts to Next Level of Depth & VerifyRedundancy Meets these Reqmts

331

GRUM.MAN /sMsi o i i isiM (SOI"TTjJll B^P " BETHPAGE. NEW YORK

1889