NASA / TP--2001-210992

Launch Vehicle Design Process:

Characterization, Technical Integration,

and Lessons Learned

J.C. Blair, R.S. Ryan, and L.A. Schutzenhofer

AI Signal Research, Inc.

W.R. Humphries,

Marshall Space Flight Center, Marshall Space Flight Center, Alabama

May 2001
The NASA STI Program Office...in Profile

Since its founding, NASA has been dedicated to

the advancement of aeronautics and space

science. The NASA Scientific and Technical

Information (STI) Program Office plays a key

part in helping NASA maintain this important

role.

The NASA STI Program Office is operated by

Langley Research Center, the lead center for

NASA's scientific and technical information. The

NASA STI Program Office provides access to the

NASA STI Database, the largest collection of

aeronautical and space science STI in the world. The

Program Office is also NASA's institutional

mechanism for disseminating the results of its

research and development activities. These results

are published by NASA in the NASA STI Report

Series, which includes the following report types:

TECHNICAL PUBLICATION. Reports of

completed research or a major significant phase

of research that present the results of NASA

programs and include extensive data or

theoretical analysis. Includes compilations of

significant scientific and technical data and

information deemed to be of continuing reference

value. NASA's counterpart of peer-reviewed

formal professional papers but has less stringent

limitations on manuscript length and extent of

graphic presentations.

TECHNICAL MEMORANDUM. Scientific and

technical findings that are preliminary or of

specialized interest, e.g., quick release reports,

working papers, and bibliographies that contain

minimal annotation. Does not contain extensive

analysis.

CONTRACTOR REPORT. Scientific and

technical findings by NASA-sponsored

contractors and grantees.

CONFERENCE PUBLICATION. Collected

papers from scientific and technical conferences,

symposia, seminars, or other meetings sponsored

or cosponsored by NASA.

SPECIAL PUBLICATION. Scientific, technical,

or historical information from NASA programs,

projects, and mission, often concerned with

subjects having substantial public interest.

TECHNICAL TRANSLATION.

English-language translations of foreign scientific

and technical material pertinent to NASA's

mission.

Specialized services that complement the STI

Program Office's diverse offerings include creating

custom thesauri, building customized databases,

organizing and publishing research results...even

providing videos.

For more information about the NASA STI Program

Office, see the following:

• Access the NASA STI Program Home Page at

http ://www.sti.nasa.gov

• E-mail your question via the Internet to

help@ sti.nasa.gov

• Fax your question to the NASA Access Help

Desk at (301) 621-0134

• Telephone the NASA Access Help Desk at (301)

621-0390

Write to:

NASA Access Help Desk

NASA Center for AeroSpace Information

7121 Standard Drive

Hanover, MD 21076-1320
NASA/TP--2001-210992

Launch Vehicle Design Process:

Characterization, Technical Integration,

and Lessons Learned

J.C. Blair, R.S. Ryan, and L.A. Schutzenhofer

AI Signal Research, Inc.

W.R. Humphries,

Marshall Space Flight Center, Marshall Space Flight Center, Alabama

National Aeronautics and

Space Administration

Marshall Space Flight Center • MSFC, Alabama 35812

May 2001
Acknowledgments

Section 4.3.9 describing the Avionics Design Function was authored by

James Atherton, Charles Morris, Gray Settle, and Marion Teal.

Sections 4.3. I0, 4.3.11, and 4.3.12 describing the Materials and Manufacturing

Design Functions were authored by Paul Schuerer.

Available from:

NASA Center for AeroSpace Information

7121 Standard Drive

Hanover, MD 21076-1320

(301) 621-0390

National Technical Information Service

5285 Port Royal Road

Springfield, VA 22161

(703) 487-4650
PREFACE

The combined experience of the authors extends over 150 years. During that time, they have

participated in the design activities associated with the following programs: Redstone, Saturn I, Saturn IB,

Saturn Apollo, Skylab, Space Shuttle, Spacelab, Hubble Space Telescope, HEAO, Chandra, Space Station,

X-33, and various payloads. At present, they are participating in training activities at Marshall Space

Flight Center. In that capacity, they are active in publications, course development and teaching, process

modeling, mentoring and advising, and interactive computer tools.

AUTHORS' E-MAIL ADDRESSES

J.C. Blair: james.blair@msfc.nasa.gov

R.S. Ryan: robert.ryan@msfc.nasa.gov

L.A. Schutzenhofer: luke.schutzenhofer@msfc.nasa.gov

W.R. Humphries: wrhum@aol.com

111
o

{D

"E

f-

{D

E

a.

! ....... • ! I

I I !

............. 1 | | I

I I I !

I ................ I I

o

Z

X

Z

=: !

Ill

°_

_-._ _

Figure 1. Design process overview.

iv
FOREWORD

This report deals with the design process for launch vehicles. It extracts information from the

experience of the authors, their associates, and related literature. The initial sections of the report address

essential groundwork and fundamentals, and the final sections address guidance for achieving a successful

design and advancing design process technology. However, the core of the report is the characterization or

description of the design process itself given in section 4.3. An overview of the process description is

represented in figure 1 which illustrates the main elements and connections of the process. Main elements

include compartmentalization/reintegration, subsystem tree, design function planes, discipline functions,

decision gates, IxI and NxN diagrams, and the process balancing act.

A reader concerned specifically with the process description can go directly to section 4.3 for the

detailed discussion. The description then serves as a basis for (1) understanding the design process and

how its various elements interact, (2) incorporating subtleties necessary for a successful design, and

(3) achieving advances in design process effectiveness and efficiency.
TABLE OF CONTENTS

° INTRODUCTION ......................................................................................................................

1.1 Motivation and Approach ...............................................................................................

1.2 Report Overview and Organization ................................................................................

2. DESIGN PROCESS OVERVIEW .............................................................................................

2.1

2.2

2.3

Top-Level Characterization ..................... ,......................................................................

Engineering the System ..................................................................................................

Thumbnail Sketch of Process .........................................................................................

7

8

18

19

3. ESSENTIALS .............................................................................................................................

3.1

3.2

3.3

3.4

3.5

3.6

3.7

3.8

3.9

3.10

3.11

Basis of Good Engineering .............................................................................................

Constraints ......................................................................................................................

Derived Requirements ....................................................................................................

Formal Design Criteria ...................................................................................................

Categories of ModelinJActivities ..................................................................................

Analyses, Test, and Simulation .......................................................................................

Parameter Matrix and Uncertainties ...............................................................................

Sensitivities .....................................................................................................................

Failure Modes .................................................................................................................

Judgments .......................................................................................................................

Probing Questions ..........................................................................................................

4. DESIGN PROCESS CHARACTERIZATION ..........................................................................

4.1

4.2

4.3

4.4

Project Technical Framework .........................................................................................

Technical Integration ......................................................................................................

Characterization Model ..................................................................................................

Design Sequence .............................................................................................................

5. PROCESS IMPROVEMENT ....................................................................................................

5.1

5.2

Vehicle Hardware/Software Technologies ......................................................................

Design Process Technologies .........................................................................................

24

24

24

24

24

25

26

27

27

27

28

28

31

32

40

43

150

168

168

168

vii
TABLE OF CONTENTS (continued)

6. ILLUSTRATIONS OF PROCESS .............................................................................................

6.1 Overview of Space Shuttle Design History From Phase A Through Phase C ................

6.2 Design Process for Flight Mechanics With Loads Modeling Example ..........................

7. EXPERIENCE-BASED KNOWLEDGE ...................................................................................

7.1 Survey of Experienced Practitioners in Aerospace .........................................................

7.2 Design Suggestions From Selected References ..............................................................

7.3 Lessons Learned .............................................................................................................

8. CONCLUDING SUMMARY ....................................................................................................

9. RECOMMENDATIONS ............................................................................................................

APPENDIX A--NxN DIAGRAM FROM REFERENCE 2 ...........................................................

APPENDIX B--SPACE SHUTTLE PARAMETER MATRIX ITEMS ..........................................

APPENDIX C--GLOSSARY ..........................................................................................................

C.1 Alphabetical Index ..............................................................................................................

C.2 Definitions ..........................................................................................................................

REFERENCES .................................................................................................................................

BIBLIOGRAPHY ............................................................................................................................

173

173

186

196

196

202

203

209

210

211

213

222

222

225

232

234

viii
LIST OF FIGURES

,

,

*

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

Design process overview ........................................................................................................

Product evolution cycle ..........................................................................................................

STS design--highest order challenge .....................................................................................

Design process/life-cycle flow ...............................................................................................

Influence of aerospace infrastructure and specialization in design ........................................

Top-level compartmentalization of design process ................................................................

Categories of compartmentalization of design process ..........................................................

Illustration of design function stack with structures plane example ......................................

Design process compartmentalization and reintegration ........................................................

Design/discipline interactions .................................................................................................

Structural design process flow ................................................................................................

Design process flow ...............................................................................................................

Successive refinement ............................................................................................................

Design process overview ........................................................................................................

Major project stages ................................................................................................................

Project phases .........................................................................................................................

Project main products .............................................................................................................

Project total technical effort rate distribution .........................................................................

Typical project management organization ..............................................................................

Typical organizations ..............................................................................................................

iv

4

7

8

9

10

12

14

15

16

17

17

23

3O

33

34

35

36

36

37

ix
LIST OF FIGURES (Continued)

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

41.

Integrated product teams ......................................................................................................

Technical integration--T-model ...........................................................................................

Technical integration--activities distribution ......................................................................

Launch vehicle hardware subsystems compartmentalization ...............................................

Fuel tank example: Subsystems, design functions, and discipline functions .......................

Technical integration of system, design, and discipline functions .......................................

Matrices of input/output data flow .......................................................................................

Design process balancing act ................................................................................................

Design process technical integration--system design function ...........................................

System design function plane ...............................................................................................

I×I matrix for launch vehicle ................................................................................................

N×N matrix for launch vehicle .............................................................................................

System design function gates ...............................................................................................

Design process technical integration--aerodynamic design function ..................................

Aerodynamic design function plane .....................................................................................

WBS 2.3--aerodynamics and induced environments ..........................................................

Aerodynamic design function gates .....................................................................................

Design process technical integration--trajectory]G&N design functions ...........................

Trajectory]G&N design function plane ................................................................................

WBS 2.2--performance and trajectories design process flow diagram ...............................

Trajectory design function gates ...........................................................................................

39

40

42

44

45

48

49

50

52

53

56

57

59

63

64

65

67

70

71

72

74

X
LIST OF FIGURES (Continued)

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

G&N design function gates ..................................................................................................

Design process technical integration---control design function ...........................................

Control design function plane ...............................................................................................

WBS 2.6--guidance and control design process flow diagram ...........................................

Control design function gates ...............................................................................................

Separation system and clearance gates .................................................................................

Design process technical integration--structure design function ........................................

Structure design function plane ............................................................................................

Structure design function gates .............................................................................................

WBS 2.4---structures analysis design process flow diagram ...............................................

WBS 2. l--vehicle configuration and structural design process flow diagram ....................

Design process technical integration--thermal design function ..........................................

Thermal design function plane .............................................................................................

WBS 2.5--thermal design process flow ...............................................................................

Thermal design function gates ..............................................................................................

Design process technical integration--propulsion design function .....................................

Propulsion design function plane .........................................................................................

WBS 2.8--propulsion system design process flow diagram ...............................................

Propulsion design function gates ..........................................................................................

Design process technical integration--avionics design function .........................................

Avionics design function plane .............................................................................................

78

81

82

83

85

86

91

92

94

94

95

105

106

107

108

112

113

114

115

122

123

xi
LIST OF FIGURES (Continued)

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

Avionics systems design process interactions ......................................................................

Avionics process flow diagram .............................................................................................

Avionics system design function gates .................................................................................

Design process technical integration--materials design function ........................................

Materials design function plane ............................................................................................

WBS 2.9--materials and processes design process flow diagram .......................................

Materials design function gates ............................................................................................

Design process technical integration--manufacturing design function ...............................

Manufacturing design function plane ...................................................................................

WBS 2.14--manufacturing design process flow diagram ...................................................

Manufacturing design function gates ...................................................................................

Representative percentage of system life-cycle cost determined

as a function of design stage .................................................................................................

Cost overruns in NASA programs ........................................................................................

Quality lever .........................................................................................................................

Conceptual design stage--sizing and functional flow sequence ..........................................

Conceptual design stage--process for more indepth assessment.

(Structures/thermal/flight mechanics perspective.) ..............................................................

Conceptual design stage--overall integration ......................................................................

Conceptual design stage--options and ideas ........................................................................

Design process activities interactions ...................................................................................

Space Shuttle history--example Phase A configurations .....................................................

124

125

127

132

133

134

136

140

141

142

143

150

151

152

153

155

158

159

167

175

xii
LIST OF FIGURES (Continued)

83.

84.

85.

86.

87.

88.

89.

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

Space Shuttle history--Phase A concept studies and groups ...............................................

Space Shuttle history--Phase B ...........................................................................................

Space Shuttle history--Phase B baseline configurations .....................................................

Space Shuttle history--example Phase B' configurations ....................................................

Space Shuttle history--example Phase B" configurations ...................................................

Space Shuttle history--Phase C configurations ...................................................................

Space Shuttle AFSIG---example parameter matrix event ....................................................

Space Shuttle AFSIG---example parameter variations .........................................................

Overall concept for flight mechanics ....................................................................................

Method to achieve performance goal ...................................................................................

Illustration of design process: structural loads .....................................................................

Structural loads illustration ...................................................................................................

Structural loads illustration--squatcheloid approach for loads ............................................

NxN matrix from reference 2 ...............................................................................................

Parameter matrix ...................................................................................................................

Basic parameters ...................................................................................................................

Liftoff load parameters .........................................................................................................

176

177

179

181

182

185

187

188

190

191

191

192

194

212

214

215

219

XII1
LIST OF TABLES

o

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

System design function tasks .............................................................................................

WBS 2.3--aerodynamics and induced environments task description .............................

Primary tasks for aerodynamic design function ................................................................

WBS 2.2--vehicle performance and trajectories task description ....................................

Primary tasks for trajectory design functions ....................................................................

Primary tasks for G&N function .......................................................................................

WBS 3.6.0---guidance and control task description ..........................................................

Primary tasks for control system design function .............................................................

Example expansion of vehicle design NxN diagram ........................................................

WBS 2.4---structural analysis task description .................................................................

WBS 2.1--vehicle configuration and structural design task description ..........................

Primary tasks for structures design function .....................................................................

WBS 2.5--thermal design task description .......................................................................

Primary tasks for thermal design function .........................................................................

WBS 2.8--propulsion task description .............................................................................

Primary tasks for propulsion design function ....................................................................

Data management subsystem task description ..................................................................

Primary tasks for avionics design function ........................................................................

WBS 2.9--materials design task description ....................................................................

Primary tasks for materials design function ......................................................................

60

66

68

73

75

79

84

87

93

96

97

98

109

110

117

118

126

128

135

137

xiv
LIST OF TABLES (Continued)

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

WBS 2.14---manufacturing process task description ........................................................

Primary tasks for manufacturing design function ..............................................................

Conceptual design stage products ......................................................................................

Space Shuttle history--political activities .........................................................................

Space Shuttle history--Phase A ........................................................................................

Space Shuttle history--Phase B ........................................................................................

Space Shuttle history--Phase B'. ......................................................................................

Space Shuttle history--Phase B" ......................................................................................

Space Shuttle history--Phase C ........................................................................................

Space Shuttle preliminary design ......................................................................................

Space Shuttle detail design ................................................................................................

Space Shuttle change examples .........................................................................................

Space Shuttle change examples--test and operations .......................................................

Structural loads illustration ................................................................................................

Structural loads illustration--X-33 ...................................................................................

Structural loads illustration--summary .............................................................................

142

145

160

174

176

178

180

181

184

186

187

189

190

193

194

195

XV
LIST OF ACRONYMS

AFSIG

AIAA

ASSC

ATP

CAD

CAM

CC

CDR

CFD

CG

CIL

DCR

DDT&E

DMS

DOD

DR

ECLSS

EGSE

ELV

EMI

EPA

EPS

ET

FA

FDL

FM

FMEA

FPR

FR

FRR

G&N

GD

GN&C

GSE

IZcs

ICD

IPCL

IPT

ISO

Ascent Flight Integration Working Group

American Institute of Aeronautics and Astronautics

alternate Space Shuttle concept

authority to proceed

computer aided design

computer aided manufacturer

controlled convergence

critical design review

computational fluid dynamics

concept generation

critical items list

design certification review

design, development, test, and evaluation

data management subsystem

Department of Defense

disposal review

environmental control and life support system

electrical ground support equipment

expendable launch vehicle

electromagnetic interference

Environmental Protection Agency

electrical power system

external tank

further addition

Flight Dynamics Laboratory

functional manager

failure modes and effects analysis

flight performance reserve

further reduction

flight readiness review

guidance and navigation

General Dynamics

guidance, navigation, and control

ground support equipment

interactive information and communication system

interface control documents

instrumentation program and component list

integrated product teams

International Standards Organization

xvi
LIST OF ACRONYMS (Continued)

Isp

JSC

L

LEO

LSEAT

MAC-DAC

MCR

MDR

MIU

MM

MPS

MSC

MSFC

MUA

NAR

NASA

NDE

NMI

NPSP

OMB

OPS

ORR

OSHA

PDS

PDR

PRR

PSIG

QFD

RBCC

RCS

RFP

RLV

RSS

S/W

SAR

SDR

SEA

SLWT

SN

SOA

SRB

SRM

specific impulse

Johnson Space Center

liaison representative

low Earth orbit

Launch System Evaluation Advisory Team

McDonnell Douglas

mission concept review

mission definition review

material identification and usage list

Martin Marietta

main propulsion system

Manned Space Center

Marshall Space Flight Center

material usage agreement

North American Rockwell

National Aeronautics and Space Administration

nondestructive evaluation

NASA Management Initiatives

net positive suction pressure

Office of Management and Budget

operations

operational readiness review

Occupational Safety and Health Administration

product design specification

preliminary design review

preliminary requirements review; also, program readiness review

Propulsion System Integration Working Group

quality function deployment

rocket based combined launch

reaction control system

request for proposal

reusable launch vehicle

root-sum-square

software

system acceptance review

system definition review

statistical energy analysis

Super Light Weight Tank

stress versus number of cycles to failure

state of the art

solid rocket booster

solid rocket motor

xvii
LIST OF ACRONYMS (Continued)

SRR

SSME

SSTG

SSTO

STG

STS

T/W

TCS

TPS

TRIZ

TRL

TSTO

TVC

WBS

v&v

system requirements review

Space Shuttle main engine

Space Shuttle Task Group

single-stage-to-orbit

Space Task Group

space transportation system

thrust to weight

thermal control systems

thermal protection system

Russian acronym meaning "theory of inventive problem solving"

technology readiness level

two-stage-to-orbit

thrust vector control

work breakdown structure

verify and validate

°,,

XVII1
TECHNICAL PUBLICATION

LAUNCH VEHICLE DESIGN PROCESS: CHARACTERIZATION,

TECHNICAL INTEGRATION, AND LESSONS LEARNED

1. INTRODUCTION

1.1 Motivation and Approach

There is a strong need within NASA and the aerospace industry to reduce the cost and improve the

effectiveness of launching payloads into orbit. Understanding and improving the design process for launch

vehicles are essential ingredients in obtaining a low cost, effective launch capability. This report addresses

characterizing, understanding, and improving the launch vehicle design process. It grew out of an initiative of the former Structures and Dynamics Laboratory at NASA Marshall Space Flight Center (MSFC).

The goal of this activity is to enable effective and efficient launch vehicle design by (1) providing

an understanding of the current design process as a basis for improving effectiveness and efficiency and

(2) providing a design process reference guide for less experienced engineers. This report characterizes

and clarifies the current design process. It examines common problems encountered and provides guidance

for effective implementation. It also includes an initial listing of improvements to the current design process

and initial observations on advanced technologies that might revolutionize the design process.

Engineering design is a challenging activity for any product. Since launch vehicles are highly

complex and interconnected and have extreme energy density, their successful design represents a

challenge of the highest order.

Most new launch vehicles require very high propulsion efficiency and mass efficiency, have

significant uncertainties in environmental and system parameters, and involve advanced technologies.

They have stringent requirements for performance, cost, reliability, safety, operability, and schedule. Meeting

the design challenge resulting from the combination of the above factors demands the best of engineering

skill, organization, communication, integration, and judgment.

The currently accepted design approach to space systems is to compartmentalize the hardware

subsystems, subsystem design functions, and discipline functions. The substructuring is driven by the need

to distribute the workload into manageable portions, the need to utilize multiple discipline specialties, and

the need to capitalize on industrial specialization. The functional characteristics of the subsystems enable

decoupling which allows for the distribution of the workload to the design functions and allows for the

utilization of the industrial specialization. Industrial specialization refers to the specific expertise that has

evolved in industry to provide unique subsystems (e.g., avionics, rocket engines, etc.) and parts
(e.g.,o-rings,transducers,etc.).Achievingthehighestquality andlowestcostfor alaunchvehicleentails

utilizing this specializedexpertiseof theindustrialbase.Industrialspecializationalsoprovideshardware

availabilityandschedulereduction.Thespecializationalsoenhancestechnologydevelopment.Compartmentalizationresultsintwo distinctfunctions:(1)Thedesignfunctionand(2)thedisciplinefunction.The

designfunctionsaresupportedandaccomplishedthroughthedisciplinefunctions.Theapproachrevolves

aroundallocatingrequirements,constraints,etc., to the subsystems,elements,and components.The

hardwareandsoftwarearedesignedandproducedthroughanalysis,testing,simulation,andmanufacturing

processes.The design and discipline functions accomplish thesetasks.As is true with industrial

specialization,this compartmentalizationfocusesspecializationand technology development.The

inherentproblemwith compartmentalizationis that it necessarilycreatesartificial boundariesin the

processandorganization.Theseboundariescreatethetendencytowardsandboxingor territorial syndromes.

This creates communication problems in properly exchanging interacting parameters and data. These

boundaries have made it difficult, if not impossible, to establish an ideal, seamless design process.

When the process works properly and interactions occur among subsystems, design functions, and

disciplines, design iterations must occur to converge the total system to achieve requirements. Key

decisions in the iterative design process are based on analysis, simulation, test results, and keen engineering

judgment. In this method, the system design is accomplished by assembling these separately designed

subsystems, etc., and iterating or balancing between conflicting outputs. As stated previously, the system

has evolved along the specialization (competencies) of industry and academia. This standardization and

specialization result in higher quality and lower cost parts, components, etc. The design process takes

advantage of these specialties. Design function and discipline function compartmentalization follow from

standard specialties of universities and design organizations. The approach is applicable in general;

however, it is usually based on the assumption of weak coupling between the subsystems, design

functions, and disciplines. If the coupling is not weak, there are more difficulties in allocating

requirements, communicating, and interacting within the total system.

It is a generally stated axiom that 80 to 90 percent of design problems are not caused by a lack of

discipline understanding but are due to a breakdown in communication. As a result, there are risks

associated with the process that must be assessed and understood.

First, the higher the performance requirements of a system, the higher the sensitivities and

interactions. This means extensive emphasis must be placed on allocations, interactions, integration, and

communications' reliability; otherwise major problems occur.

Second, compartmentalization naturally introduces boundaries, setting up the tendency for

industry and discipline nearsightedness.

Third, system design must be recognized as a balancing act between the conflicting requirements

and interactions.

In summary, ensuring that the current design approach works requires proper attention be given to

allocating and refining requirements, to understanding sensitivities and interactions, and to ensuring

technical integration through adequate communication.
The first part of the activity reportedhere is intendedto characterizeand baselinethe launch

vehicledesignprocess.In section4.3.1, theprocesshasbeencharacterizedby compartmentalizingthe

systeminto subsystems,with eachsubsystemhavingdesignfunctionplanesoverlaidwith asystemdesign

function plane.Within eachdesignfunction planearethe contributingdisciplineand designactivities

alongwith outputattributes.Thisdescriptionincludesboththetasksandhow designdecisionsaremade

fractionallyandincrementallyandhowdesigndecisionsareintegratedintothetotaldesign.Foreachplane

a flow diagramis developedfor illustrating the various decisiongatesand a descriptionof top-level

attributesto be comparedwith requirements.This approachwasdevelopedto characterizethe launch

vehicledetail designstageand canbe appliedto otherdesignstages;e.g.,conceptualandpreliminary

designstages.

Thetypicalprocessaspracticedcurrentlyisreferredto hereinasthebaseline.Thecharacterization

of thebaselineservesasareferencepointfor refiningandimprovingthepresentprocess(evolutionary).It

alsoservesasa referencepoint to developrevolutionarytechnologiesfor thedesignprocessthat could

produce orders of magnitude jumps in process efficiency and effectiveness. The effort

reportedhereis theinitial taskof determiningtheessenceof thelaunchvehicledesignprocess.If weareto

meetthelaunchcapabilitydemands,thenbreakthroughmustoccur.

UtterbackinMastering the Dynamics of Innovation _discusses how companies can seize opportunities in the face of technological change. Others have dealt with the subject also. Utterback characterizes the

development of a product in steps. First, the company concentrates on product innovation until it is an

established product. Second, they concentrate on process improvement. Third, the product is then in a

specific phase and is firmly established. During this time, the product performance (sales, use) continues to

rise with minor attention to product or process improvement. As invading technologies or the requirement

for them come in, the product will accomplish bursts of improvements. However, this is not sufficient to

save the product as it is, and the invading technologies take over. For example, digital watches replaced the

Swiss jeweled watch. The manual and electric typewriters were replaced by the word processor. The

household refrigerator replaced the ice factories. None of these invading technologies were implemented

by the parent companies. Utterback's concept, as discussed above, was applied to aerospace as indicated in

figure 2. So, NASA and the major aerospace industries should follow a three-pronged attack:

1. Delineate and baseline the launch vehicle design process

2. Refine and improve the baseline process---evolutionary

3. Implement new innovative technologies to advance the process--revolutionary.
eE

o

CL.

¢,J

o

_,tmBmw

Today _ Stage4--New

Stage2--Incremental ff_ Technologies Improvement

Stage3--Burst

-- ,E

.-..,._ _.... _7qt=ge _,_ 1-- _.... Improvement

i-

,,.,,__z Innovation

Time

Today

_. CurrentProduct __ Stage4--New Product

/

E

Stage I--Innovation; Stage 2--Incremental Improvement;Stage g--Burst Improvement

Time

Utterback'sCharacterizationof Product Development:_

First Stage: Concentration is on product innovation until it becomes an established product

Second Stage: Concentration is on process improvement

Third Stage: Burst improvements in product stimulated by new requirements and new technologies

Fourth Stage: New technologies take over; e.g., quartz watch, word processor, refrigerator

Recommendation:

(1) Work hard to accomplish major burst in the current suboptimum approach, fine tuning it for more efficiency

in performance, cost, reliability, safety, operability, and scheduling.

(2) Pursue new technologies that can revolutionizevehicles.

Figure 2. Product evolution cycle.

4
1.2 Report Overview and Organization

The results presented in this report characterize and baseline the launch vehicle design processes.

This was achieved by systematically defining, delineating, and explaining the key features of the design

process. This overview is intended to illustrate that method via the organization of the report. The

following is a brief explanation of the various sections of the report.

1.2.1 Introduction

This section presents the motivation and goals of this activity. In addition, the complexity of the

process is explained as well as the challenges. The scope of the effort is delineated, and the process is

briefly characterized and explained. Utterback's characterization of product development is introduced to

reflect the potential impact on the aerospace community.l

1.2.2 Process Overview

A top-level description of the design process is presented to show the connectivity between the

space transportation system (STS), launch vehicle system and subsystems, design functions/discipline

functions with compartmentalization and allocation, and the technical integration process. Additionally, a

thumbnail sketch is presented to delineate concept selection, preliminary design, and detailed design.

1.2.3 Essentials

While the design process itself is key to evolving a design, there are also 11 essential engineering

considerations that must be recognized and carefully implemented. These considerations are subtle and

implicit in the process, but they are of such importance that we have called them "essentials." These

essential engineering considerations are as follows: basis of good engineering; constraints; derived

requirements; formal design criteria; categories of modelinJactivities; analyses, tests, and simulations;

parameter matrix uncertainties; sensitivities; failure modes; judgment; and probing questions that should

be asked throughout the design process.

1.2.4 Design Process Description

The main results of this entire activity are developed in this section. First, important aspects of the

project technical framework are addressed. Then the T-model for technical integration is introduced. In

this model formal and informal integration are defined. Finally, a symbolic model is developed that

characterizes technical integration and the design process. This model consists of design function planes

associated with the vehicle subsystems. These design functions are systems, aerodynamics, trajectory/

guidance and navigation (G&N), controls, structures, thermal, propulsion, avionics, materials, manufacturing, and others. In addition to the design function planes, the characterization also includes their associated decision gates and engineering tasks. This model is also linked to an existing, detailed discipline

description via its work breakdown structure (WBS) and N×N matrix from reference 2. While the basic

characterization has been developed, there are some detailed aspects of the model that are still being

investigated.
1.2.5 Process Improvement

It is thought that process improvement can be achieved by fine-tuning the present design process

and implementing revolutionary technologies. While it is planned to investigate these activities in

follow-on efforts, some ideas associated with process improvements are delineated in this section. Some

categories associated with fine-tuning are as follows: requirements and criteria, designing for simplicity,

improved modeling tools, and inte_ation of discipline analyses. The categories associated with revolutionary

technologies are compartmentalization/reintegration, synthesis and design, and interactive information and

communications systems.

1.2.6 Illustrations of Process

The baseline design process that is characterized in this work was implemented in the Saturn/

Apollo and Space Shuttle programs. Examples of the application of this characterization are given in this

section. An overview of the conceptual design stage is given, and an example is presented of the Space

Shuttle conceptual design process.

1.2.7 Distilled Wisdom

This section pertains to lessons learned and the results of a survey of experienced practitioners.

During the evolution of the effort presented herein, key ideas were noted. Then upon completion of the

baseline characterization effort, the process was reviewed to extract important ideas. From these two

resources, lessons learned were distilled, and they are presented in this section. In addition, a survey of

experienced practitioners was taken to determine "What is the essence of engineering design based on your

many years of experienceT" Their collective wisdom is also presented in this section.

The remainder of the report contains conclusions, recommendations, three appendices including a

glossary, references, and a bibliography.
2. DESIGN PROCESS OVERVIEW

The launch vehicle design process presents a challenge of the highest order. This challenge is

illustrated in figure 3. It can be seen that after the mission statement is defined, the project must achieve

the system attributes related to performance, cost, reliability, safety, operability, and schedule via the

design process. The challenges that the system designer must address are high energy densities, propulsion efficiency, dry mass efficiency, and loss management, along with technology readiness and

requirements on cost and "-ilities." As can be seen, the loss management falls into the categories of

uncertainties and interactions. The design process must rely upon analyses, testing, simulations, and past

experience to provide insight for trading within and among the various challenges to achieve the best

design. In addition, this same knowledge base is applied to develop philosophies and methods to support

subsequent design judgments. The design and associated judgments are eventually assessed after

development testing and/or in the operations stage and may lead to operational constraints.

MissionStalement: Insert a specified payload into a specified orbit to the required tolerances,

within cost reliability, operability safety, and schedule requirements

EngineeringChallenges:

Designand Management Considerations Project Requirements

• High EnergyDensities

• Propulsion Efficiency r.-...

• Dry Weight Efficiency L DesignTo Achi

• Managing Losses

- Uncertainties

• Manufacturing Variables

• EnvironmentalVariables

- Interactions

• Multidisciplinary

• Interfaces

• Operations

• Failureto MeetTechnology

Readiness Level(TRL) Target

• Cost Reliability Operability

• Performance

• Cost

• Reliability

• Operability

• Safety

• Schedule

Figure 3. STS design--highest order challenge.

This section provides an overview of the main features of the launch vehicle design process, along

with associated challenges and connectivity. The details will be included in subsequent sections of the

report. A thumbnail sketch of the design process sequence is provided to show the ordering of main

activities of each design stage.
2.1 Top-Level Characterization

The engineering design process has five major areas of emphasis that flow in sequential order:

(1) Requirements definition, (2) design, (3) build (make or buy), (4) system integration and verification,

and (5) operations (fig. 4).

Requirements Definition i

"_ Design

Build I

(Make/Buy) L

I Syslem

Integration

and Verification

Operations

Figure 4. Design process/life-cycle flow.

Requirements definition specifies what the product is to do and how well it is to do it. It also

specifies constraints, philosophy, and criteria (e.g., margins, etc.). Therefore, the design process starts with

the mission statement and requirements. These are defined in terms of the requirements of the orbital

characteristics (orbit inclination, altitude, etc.) and the payload to be delivered. In addition to the mission

requirements, other requirements and constraints are also levied. These include cost (design, development,

testing, and evaluation (DDT&E); operations; life cycle), reliability, development time, etc. NASA has

program requirements such as design reviews and verification requirements that are contractually levied.

Many times additional requirements are provided as constraints which may include such things as geometry,

payload size, and environmental impacts. In conjunction with these mission and programmatic requirements,

most design and discipline functions have legal criteria that must be met by the design. Finally, requirements

evolve as the design progresses. These are called derived requirements and take many forms; for example,

load relief controls and engine turbopump temperatures cut off or shut down. An STS must be formally

verified to meet all these requirements and constraints before operation; figure 4 illustrates the top-level

flow down of the process ending with a verified system at the flight readiness review (FRR), thus providing

an operational system. The process works through system, design, and discipline functions, technical working

groups, technical interchange meetings, boards, etc., which enhance technical integration and

communications, thus enabling the design.
In order for the design process to work efficiently and take advantage of the state of the art (SOA)

knowledge base, the STS must be compartmentalized into workable units after the mission and programmatic

requirements are defined. The SOA information exists in three general areas: (1) Industrial specialization,

(2) Governmental specialization, and (3)Academic specialization. Figure 5 shows the influence of aerospace

infrastructure and specialization on design. The capabilities and knowledge bases of these three areas

constitute the SOA which is captured by standards, monographs, technologies, manufacturing processes,

etc., shown in the center block of the figure. These become the basis for the design process. The design

activities consist of (1) compartmentalization of the hardware and tasks into workable units, (2) synthesis

(concept identification), and (3) analysis and assessment of the synthesized concept. There is a major

iteration loop between the synthesis activity and the analysis and assessment activity. The results of the

design activities produce the design specifications. The heart of this approach of compartmentalization is

the SOA knowledge and specialized processes that have been developed. Design can thus start with SOA

capabilities that have already been developed. For example, the characteristics of various airfoil shapes

have been investigated and demonstrated. The designer can choose the one that best fits the product concept

under design. As another example, joints are a major design problem. Industry and academia have

standardized various joint concepts and analysis techniques. All these standards, data bases, and processes

are used for the initial synthesis process. The analysis and assessment function then fine-tunes and optimizes

Industry Divide

• Design • Compartmentalization

• Manufacturing

Capability

i

* Technology

ill /iiiiiii!ii!i !i!ii!51

• StateoftheArt

Inslilutesand -Standards

Government -Monographs

• KnowledgeBase -Technologies

• TestandLaunchFacilities -Manufacturing

• Methodology Capabilities

• Technology • Advanced

Technology

Academia

•D= p..es --

• Research B

S

• Technology _-

Synthesize

Analyze

and

Assess

Figure 5. Influence of aerospace infrastructure and specialization in design.

9
and,thus,resynthesizestheproduct.(Theiterationloopon the figure.) This approach of taking advantage

of the three specializations, if used properly, can result in a higher quality product at lower cost.

Compartmentalization by industrial specialization takes advantage of existing industrial expertise and

infrastructure, thus cutting cost and increasing quality. Government and academia compartmentalization is

along discipline lines as taught in universities and practiced in Government research labs. Most of the

complex theories and the corresponding computer codes have evolved along these discipline lines. Discipline

compartmentalization provides for indepth technical penetration and more efficient analysis efforts.

Discipline codes are available, including computer aided design (CAD)/computer aided manufactuerers

(CAM), structural codes, computational fluid dynamics (CFD), thermal codes, as well as many others.

Government also has many specialized facilities for testing and massive computing, etc., not available in

industry. Wind tunnels and rocket engine test stands are examples. The three areas of specialization produce

synergistic technologies critical to the design of future systems.

The compartmentalization process starts with the definition of the top-level systems that comprise

the STS overall system, as delineated in figure 6. These are based on specilized capabilities of Government

and industry. Typically, the first level of compartmentalization is composed of the following.

• Launch vehicle (design and build)

• Payload interfaces (accommodations)

• Operations systems (hardware and software required for assembly, mission operations, and

refurbishment).

Depending on the complexity of the STS and the industrial specialization, these systems can be

defined differently; however, the compartmentalization process is essentially the same. As will be

discussed later, each of these systems has its own design, manufacturing, and verification processes.

1.0

STS

2.0

Launch

Vehicle

I

3.0

Payload

Interfaces

4.0

Operations

Systems

Figure 6. Top-level compartmentalization of design process.

10
The next step in the process is the allocation and levying of requirements. At this level of compartmentalization, the requirements are apportioned to the three systems. For example, top-level management

decides what proportion of the STS budget is allocated to each of these.

Several techniques are available for enhancing requirement allocation to the STS systems and

subsystems. Quality function deployment (QFD) is the most accepted approach for accomplishing this

task. It starts with the customer's wants and translates them into designable attributes of the system. It

weights the importance of each, providing an indication of priority. The QFD process is described in detail

in many of the listings in the bibliography; therefore, no further discussion here is warranted. QFD is a

useful tool to aid the allocation process; however, allocation typically must draw on the judgment and

experience base of the leader and others involved.

After the allocations are completed, there are interactions/interfaces between the various systems

that must be determined and traded in order to achieve overall balance. The vehicle affects the launch pad;

the launch pad affects other facilities. The same is true of the payloads, etc. These couplings are generally

weak and can mainly be treated with allocations via interface control documents (ICD's), etc.; however,

they must be engineered and balanced to achieve some level of optimization.

The compartmentalization of the hardware/software systems continues down the tree, with the

launch vehicle being compartmentalized into subsystems, then into a hierarchy of sub-subsystems, and so

on into smaller entities, as indicated on the left side of figure 7. Each of the entities on the tree is a

hardware/software item that must be designed. For purposes of this discussion, we will generically call the

hardware/software item a subsystem.

The process of designing each subsystem entails a second type of compartmentalization, as

indicated on the middle portion of figure 7. This second type of compartmentalization divides the

subsystem design process into a set of design functions. These design functions are represented by a

"stack" of design function planes. The specific design functions needed will vary from subsystem to

subsystem, but typically include the design functions of structures, propulsion, thermal, avionics,

manufacturing, etc. The products of the design functions are the specifications for their portions of the

subsystem design. The top plane in the stack is the "system" plane that integrates the other design functions

into an integrated design (specification) for the subsystem that corresponds to the stack.

(Note that each subsystem on the tree has its own design function stack. As we move down the tree

into smaller subsystems, there will be an associated stack with each subsystem until we arrive at parts that

can be designed by a single designer, making use of handbooks, etc. At this point, further compartmentalization is not necessary.)

A third type of compartmentalization occurs on each design function plane, involving discipline

functions. Disciplines are technical areas of specialty and expertise. They perform analyses, tests, and

simulations in support of the design functions, and they can be thought of as residing on the design

function planes. This third compartmentalization is indicated on the right side of figure 7. On each design

function plane, there is an iterative synthesis/analysis activity that draws on all the pertinent disciplines to

arrive at a design (specification) whose attributes meet its allocated requirements.

11
Figure 7. Categories of compartmentalization of design process.

12
Thus,therearethreetypesof compartmentalization--subsystem, design function, and discipline

function. Each compartmentalization in turn requires reintegration to constitute the complete system

design. Figure 9 illustrates the three interconnected types of compartmentalization (proceeding downward

to the right) and their subsequent reintegration (proceeding upward to the left). Completion of the final

reintegration then results in the total system design.

These concepts will be further expanded and explained in section 4. The process of technically

integrating the compartmentalized parts into a successful design is a primary challenge and constitutes a

main subject of this report.

To further address the design and discipline function characterization, consider the design function

"stack" associated with the launch vehicle system, as shown on the left of figure 8. The design functions

shown are:

• System

• Aerodynamics

• Trajectory/G&N

• Control

• Structures

• Thermal

• Propulsion

• Avionics

• Materials

• Manufacturing

• Others

The structures design function plane is expanded on the right side of the figure as an example of the

plane content. Also, there is an additional expansion below to show the decision gates that reside on the

plane. Each plane is a flow diagram which shows top-level activities, beginning with requirements and

architecture allotted to that design function, then compartmentalizing and reintegrating the discipline

functions necessary to execute the iterative synthesis]analysis activity to converge on a design specification that meets the requirements. As the design matures through the iterative process, its attributes are

assessed and compared with the requirements. Attributes are the numerous measures of "goodness" of the

design in categories of performance, cost, reliability, safety, operability, etc., and are related one-for-one

with requirements. The comparisons of these numerous attributes with the requirements are represented on

the decision gate diagram where satisfying all gates means satisfying the summary decision gate on the

design function plane.

The top plane of the stack of design function planes is the system plane. It provides the compartmentalization, allocation, and reintegration for the other planes. Its product then is the design specification

for the subsystem entity on the tree for which the stack corresponds. A major feature of the process represented by the stack is the information flow that must occur among the planes. Critical formal feedback

between the design function planes and the system plane is shown, as well as informal feedback between

and within the planes. The rectangular vertical conduits with arrows pointing downward represent the

13
System

Aerodynamics .........

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials .".:i

Manufacturing

Other

Figure 8. Illustration of design function stack with structures plane example.

flowdown of requirement allocations, architecture, and approach. The vertical column with arrows pointing upward represents the upward flow of the design attributes from the design function plane to the

system plane. These conduits represent formal integration. The circular conduit with arrows pointing both

upward and downward represents informal integration among the design function planes. Informal integration also occurs on the design function plane within and among the various disciplines.

The large amount of information flow throughout the process will be further characterized in

section 4, using information flow matrices. Two types of matrices will be used: an interface information

matrix (designated IxI matrix) to address information flow among the subsystems on the tree, and an NxN

matrix to address information flow among design functions and disciplines. Material related to the

information flow in the launch vehicle design/analysis process has been developed by MSFC 2 that

14
System LaunchDef Vehicle nilion__"-"_ 1SubsystemSsystem Reintegratlon Intolj ofI

ii I Reintegralionof

Compartmentalization,., Into _ Subsystems_ JInto Design Sub"System" FunctionsI

Subsystems J I

Compartme!tahzatlon i i t

I Designln_Onci,on: _1_ FDnecS_igonn s

1

Compartmentalization] _ I

Into

Disciplines J I

_ Reintegrationof I

DisciplinesInto

DesignFunctons

I

"

Disciplines

ExampleDesignFunctions

(DevelopSpecifications for

Hardware and Software)

ExampleDisciplineFunctions

(Perform Analyses, Tests,and Simulations)

• System • System

• Aerodynamics Design • Structures (ExampleExpandedBelow*)

• Trajectory • Aerodynamics

• GN&C • Control

• Structures • G&lkl

• Thermal Protection System (TPS) • Trajectory and Flight Mechanics

and Thermal Control Systems (TCS) • Materials

• Propulsion • Manufacturing

• Avionics • Testing

• Materials • Simulation

• Manufacturing • Mission Analysis

• Facilitiesand GroundSupport • Propulsion

Equipment(GSE) • Thermal

• OperationsSoftware • Life Support

• OtherSystems;e.g.,

- Pyrotechnics * Categoriesof Discipline Tasks:

- RecoverySubsystem • Structures

- Life Support - Dynamics

- Etc. - Stress

- Durability

- Stability

- Vibroacoustics

The DisciplineFunctionsEnablethe Design Functions ........

Figure 9. Design process compartmentalization and reintegration.

addresses discipline inputs and outputs, tasks, and products of the design process. This includes the N×N

matrix mentioned above, discipline flow charts, and task definitions. These details are integrated into the

process description given in this document.

15
Figure 10 is another way of illustrating the complexity of design/discipline interactions, data

exchanges, and balancing. This figure illustrates some (but not all) aspects of design interactions. Expanding it to include all aspects would cloud the visualization process. Another example of visualization of

design interactions is shown in figure 11. This figure includes some details of the internal process flow for

the structural subsystem. Technical integration is a complex process, as this top-level discussion shows.

This document will probe further into its definition.

Technology

Fluids

ECLS

Atmosphere

Dynamics

Control

Structural

Integrity

Design

Thermal

i

' - Natural

Vibration *"4, - Operational

i

......

Verification

- Analysis

- Test

Structural - Simulation

Design - FlightEval.

orTPS

- Margins

- Performance

1

Operations

- Constraints

- LimitIndicator

- ModelUpdate

,_ Design Criteria/Procedures Standards/

Figure 10. Design/discipline interactions.

In summary, the process starts with requirements definition, moves to top-level system studies,

then to the compartmentalization of the overall system by comprising systems by subsystems, etc. Their

design is accomplished by the design functions, supported by the discipline functions. Design is followed

by manufacturing/assembly/checkout. The design as built must be verified to meet the requirements through

analysis, test, and simulation. Operational procedures are derived from the design and verification process.

A schematic of the interaction of the design functions and discipline functions is depicted in figure 12. The

process (integration) is very complex and requires focused communication, both formal and informal.

Detailed discussion of these aspects is given in section 4.

16
Project

Requirements

Design

l ec gy/

I Codes/Procedures _

Environments

- Aero

Flow

Heating

- Propulsion

- Acoustics

- Vibration

Natural

............................... ,_.'._Design |

....................... Interaction _ IStandards/Criteria_

Analysis

Thermal

Analysis __

- Heat _1- Passive

Transfer I- ACtive

- Definition _

Structural

Analysis

- Loads

- Vibroacoustics

- Stress

- Fatique

- Fracture Control

Logic/

Sensors/

Effectors/

Computers

Design

_- System

Subsystems

Elements

Pads

........................ QesignLoo_.....................

Verification

Operations I

- Support I

- Constraints I

Figure 11. Structural design process flow.

Requirements Mission

Conceptual

Design

$

Preliminary

Design

$

Detailed

Design

Manufacturing

System Integration

and Verification

Etc.

I

J

[ syst°m]

Subsystem

• Structures Propulsion j

* _ Design

!unctions

CompartmentalizationlReintegration

Disciplines

Figure 12. Design process flow.

17
2.2 Engineering the System

The design process must be focused on achieving the best total system design to meet the requirements. The leader is responsible for managing the design process, for engineering the system. His responsibilities are reflected on the top-level system design function plane, and entail wide-ranging judgment and

constant communication with members of the design team. Engineering the system involves the following

essential functions.

Essential Functions of Engineering the System

• Obtaining and Assessing Requirements

• Synthesizing Concepts and Designs

• Compartmentalization

• Technical Integration

• Risk Management, including Technology Development Risks

• Trading and Balancing

• Downselecting Concepts and Designs

• Manufacturing, Integrating, and Verifying the Design

• Developing the Flight Operations Rules and Constraints.

There are numerous tools used to accomplish these essential functions. In addition to generic

management tools, there are tools that are more specific to the design process. Categories of such tools

include the following.

Typical Tool Categories

• Requirements generation tools, such as QFD

• Synthesis-aiding tools, such as TRIZ

• Sizing programs

• Computer-aided design programs

• Design optimization tools

• Engineering analysis

• Manufacturing process simulation tools

• Engineering test

• Sensitivity analysis

• Cost analysis

• Decision tools for trade studies

• Risk management tools, including FMEA, fault trees, and risk/consequence analysis

• Classical systems engineering tools, including requirements flowdown, WBS, configuration

management, and verification plan

• Design reviews

• Integrated Information and Communication System.

18
2.3 Thumbnail Sketch of Process

This section provides an overview of the process sequence, divided by design stages.

2.3.1. Conceptual Design

2.3.1.1 Conceptual Design Definition. After the mission statement, requirements, and constraints

are defined and understood, feasible alternative top-level system concepts are defined and their attributes

determined via trade and sensitivity studies. Along with each concept there are supporting studies related to

risk, cost, reliability, schedule, safety, operability, refined requirements, facility/GSE concepts, TRL, project

plans and other documents, etc. Selection criteria are also developed to evaluate the alternative concepts.

At the completion of conceptual design, there is a review called the system definition review (SDR).

2.3.1.2 Activities. Conceptual design follows a process with the following steps:

a. Identify the basic mission requirements (mission definition, pounds of payload to orbit, cost,

schedule, etc.)

b. At the top level, define potential concepts to meet requirements (includes overall architecture,

staging, reusability, and broad definitions of propulsion system(s), structural systems,

avionics, and thermal systems).

c. Define evaluation metrics.

d. Perform top-level sizing and analysis of the concepts.

(1) Preliminary estimates of geometry, mass, environments, and propulsion characteristics

(2) Trajectory and performance definition

(3) Induced environment definition

(4) Top-level sensitivity study (example: dry weight versus dry weight margin)

(5) Margin determination necessary to envelope uncertainties

(6) Determination of performance, cost, and other attributes

(7) Risk assessment and technology development needs

(8) Trade and balance among alternatives to improve attributes and risks

e. Develop selection criteria and select top contenders.

19
f. Modify the contending concepts based on evaluation data.

g. Repeat the above process with more in-depth evaluation.

h. Downselect to remaining candidate concepts.

i. Modify the remaining candidate concepts based on evaluation; add new ones (if data indicate).

j. Modify requirements (if data indicate).

k. Continue to repeat the above process until clear, leading concepts emerge.

1. Define the leading concepts with general configuration definition, sensitivity data, and induced

environments.

2.3.1.3 Products of Conceptual Design. The products of conceptual design are a reduced set of

feasible alternative concepts that have attributes which satisfy the mission statement, requirements, and

constraints with acceptable margins and risk. In addition, there are additional supporting data as mentioned

above in the definition. In some situations there may be only one concept selected.

The concept selection quantification leading to selection therefore requires a small cadre of inventive, sound engineering specialists who carry out the tasks. The tasks in the early part of conceptual design

can be integrated together into one program for overall sizing; however, the operational requirements and

output of this program must be assessed by the respective disciplines for technical soundness. The tasks for

the subsequent program stages, however, have increasing levels of penetration, detail, and scope as the

program matures and is verified.

2.3.2. Preliminary and Detail Design

Preliminary and detail design follow the same general approach; i.e., the steps; however, the depth

of penetration and the results differ significantly.

2.3.2.1 Preliminary Design Definition. The purpose of preliminary design is to determine which

of the selected concepts from the conceptual design stage is the best and to provide greater assurance that

the concept is capable of meeting requirements. To achieve these results, the fidelity of the architecture is

increased and refined; in addition, the significant subsystems and their requirements are defined. The depth

of penetration of trade and sensitivity studies is increased through analyses, tests, and simulations. Then

the requirements, risk, cost, reliability, safety, operability, schedule, and TRL are refined and reassessed.

Interfaces, interactions, pertinent tests, top-level verification plans, and preliminary facility and GSE

requirements/concepts are defined and the fidelity of the project plans and documents is updated. Preliminary design can occur in iterations as concepts are downselected after each iteration until the best concept

remains. This concept then goes to detail design. In the situation where only one concept goes to preliminary design from conceptual design, the above procedure is still utilized but for a single concept. At the

completion of preliminary design, there is a review called the preliminary design review (PDR).

20
2.3.2.2 Detail Design Definition. The purpose of detail design is to provide drawings and specifications for all the hardware and software of the fully analyzed, tested, and simulated STS that can be

manufactured and operated within cost and flown with an acceptable risk. The performance, cost,

reliability, safety, operability, schedule, and technology readiness attributes of this system must satisfy the

mission statement, requirements, and constraints. At the completion of detail design, there is a review

called the critical design review (CDR).

2.3.2.3 Activities. Preliminary and detail design follow the same general approach (steps).

Preliminary design operates at less depth because the analysis and test data have not matured. Detail design

is in-depth and finalizes all the design trades and the configuration for production. The steps are in general

the following:

a. Using the database and the concept selected, apportion the design task by first-

(I) Delineating the major subsystems, elements, components, etc.

(2) Allocating requirements, constraints, etc., to these entities and their associated

design functions.

b. Start the design function and discipline process for each major subsystem.

(1) Define in more detail the data base required for the discipline task. Data bases include

mass properties, aerodynamics, thermal, materials properties, etc.

(Note: Steps b(2) through b(7) are examples pertaining to structure design.)

(2) Run the trajectory/performance analysis. Provide data to other disciplines.

(3) Using the baseline trajectory, conduct the control analysis determining the control logic,

control requirements, and responses.

(4) Conduct the loads analysis definition using the control results, determining the induced

structural environments.

(5) Determine the thermal environments, loads, etc.

(6)

(7)

(8)

(9)

(10)

Perform stress analysis and its subsets of strength, stability, deflections, and durability.

Durability also includes fracture and fatigue.

Determine sensitivities and margins.

Perform trade studies among alternatives.

Assess risks and technology development plan.

Reintegrate design functions and subsystems at each level.

21
(11) Perform risk assessments and trade studies, and balance design at each integrated level.

c. Modify the design based on the results.

d. Repeat the process in more depth.

The above sequence overviews trajectory/performance design, some controls design, and structural

design. There are concurrent parallel design activities for other subsystems and design functions, such as:

• Thermal protection and thermal control

• Manufacturing

• Avionics

• Propulsion

• Other systems such as pyrotechnics, recovery, etc.

These subsystems and design functions have their own design sequence and also interact with the

design process of other subsystems.

Two major activities that permeate the design process are (1) trading among design alternatives to

balance the competing aspects of the design, and (2) assessing and managing risks. Trades range in complexity f_om straightforward judgment decisions to detailed trade studies that drive out the differences in

design alternatives. Because of the strongly coupled nature of launch vehicles, trade studies are usually

numerous and constitute a significant part of the design process. A balance must be achieved among the

cost, performance, operability, etc., of the design. Achieving the best design also requires balancing among

the subsystems, design functions, and technical disciplines.

Technical, cost, and schedule risks must be actively managed throughout development. Active risk

assessment is an essential element of the design process. Failure mode analyses and risk/consequence

assessments are done for each design alternative. A technology assessment for each design alternative

identifies technology development required, along with the risk associated with maturing the technologies

to an acceptable level.

2.3.2.4 Products of Preliminary Design. The major product of preliminary design is a single

concept that has attributes that satisfy the mission statement, requirements, and constraints with acceptable

margins and risk. The margins and risks at the completion of preliminary design should be reduced from

those at the completion of conceptual design. The concept at the completion of preliminary design is the

baseline for detail design. In addition, all system support, manufacturing, test, and operations requirements

are also defined.

2.3.2.5 Products of Detail Design. The products of detail design are engineering descriptions of

the hardware and software pertaining to STS. These descriptions are drawings, specifications, plans, etc.

The attributes associated with the system must satisfy the mission statement, requirements, and constraints

with acceptable margins and risk. At this point the margins and risks should be at a minimum. Additional

products include plans for final development, manufacturing, verification, and operations.

22
2.3.3 Successive Refinement.

During the design process, there are various stages. The process has been divided into stages in

order to provide discipline and order while demonstrating evolving technical maturity with cost and

schedule adherence. The idea of successive refinement adds emphasis by focusing attention on

convergence to a concept (see fig. 13 and references 3 and 4). When the design process is first initiated,

there is considerable uncertainty (i.e., risk) associated with technical, schedule, and cost feasibility. In

addition, the knowledge base can be very limited. As the project proceeds, concepts are studied and assessed

in regard to satisfying all the requirements and constraints. These studies are iterative, and on each cycle

the penetration is deeper and deeper. The results provide information about the concept options and then

decisions are made that eliminate certain options. As the design continues, the knowledge base is refined

and increased iteratively while the uncertainty is decreased. Eventually, through this successive refinement

of knowledge, decisions can be made to downselect to the best concept. There have been projects where

the downselect was achieved in the conceptual design stage, and there are others where it was late in the

preliminary design stage. There are other government agencies where protoflight hardware is developed,

and the downselect is determined by comparison of the actual function, cost, and production schedule.

ApplyControlled

Convergence(CC)

Apply Concepl

Generation (CG)

CC

CG

CC

CG

CC

FronbendDesignWork

ProductDesign

Specifications(PDS)

ConceptGeneration

_.__I InitialNumber"_

of ConceptsBased/"

on PDS ¢

InitialNumber\

Reduced _

NewonesAdded/

"_ Further _

_ Reduction(FR)"_

X Further/

-'V

(SeeReference:3)

Physical realization of a system results from a

succession of decisions among alternativeconcepts.

Decisions at every step require that new information

be developed to mature the concepts.

As concepts are continuously refined and uncertainty

is reduced, choices among concepts can be madewith

confidence.

Concept selection consists of the defining and

understanding alternativeconcepts and implementing

decisionsthat lead to downselecting one concept.

[SeeReference4)

Iterate/penetrate Until the Degree of Uncertaintyand Concept b

Discrlminalors WarrantMovingto Next DesignPhase ................

Figure 13. Successive refinement.

23
3. ESSENTIALS

Before presenting the methodology in detail, it is necessary to understand some essentials that are

applicable to each design function and program stage. These considerations sometimes are subtle and

implicit in the process, but they are of such importance that we have called them "essentials."

3.1 Basis of Good Engineering

The process described is logical and depends on methodology, not dogma. Guidelines, procedures,

and criteria augment the process but can never replace the human mind, the human judgment. In the end it

is the individual or collective judgment that results in key design decisions. The methodology is based on

the scientific method geared to question the validity of the data and logic. Furthermore, the basis of good

engineering can be characterized as (1) sound physical principles and logic (design must be based on the

physics of the problem), (2) depth of engineering experience as a basis for judgment, and (3) communications, communications, communications.

3.2 Constraints

The constraints must be defined and evaluated, because they greatly alter a design. Therefore, it is

imperative that their effects be understood and quantified before acceptance. Most constraints are initially

based on historical data. For example, the maximum dynamic pressure for the Space Shuttle is constrained

to 650 psf nominal and 815 psf dispersed. Manned flight levies an acceleration constraint of 3.15 G's

maximum. As the studies/design progress, constraints evolve, and changes are made based on the effects of

sensitivities and trades. Cost and schedule constraints are much more difficult to implement, because they

have both programmatic and technical interactions that occur in a variety of ways.

3.3 Derived Requirements

During the design process additional requirements evolve. These derived requirements are necessary to balance the system and are determined through basic trade studies where top-level requirements

must be met. These are usually the basis of how the system is flown and/or how it is made to work.

Examples of derived requirements are load-relief control, monthly mean-wind biasing, day-of-launch

I-load updates, ground wind operational constraints, etc. Typically, derived requirements are evolved and

implemented; however, they in general introduce additional failure modes that must be identified and

assessed.

3.4 Formal Design Criteria

In the design process, the design must meet numerous requirements and constraints. Among these

are the formalized design criteria applicable to all NASA projects. These are in the form of formal documents, and they exist at both NASA Headquarters and at the various Centers. The Center-levied criteria

and requirements can be tailored for individual projects; however, the NASA Headquarters criteria must

not be violated in intent. The discipline specialists develop most of these Center-associated criteria even

24
though they may be listed in the systems requirements. One of the main activities of the system design

function is to determine what criteria will be imposed on the design. It is very important for the system

design function and the project to tailor the criteria for their specific needs. First, these requirements/

criteria delineate the various design stages and the levels of project maturity required for each. The main

discipline criteria apply at each stage but recognize the level of project maturity. Also at the system levels

are the verification requirements, including the requirements for the verification matrix, documentation,

etc. Each individual discipline provides input to verification requirements; however, the individual design

functions are responsible for their development and implementation.

Many specialized discipline criteria exist for use by the design functions. Structures have formal

criteria for strength, endurance, stability, etc. Safety factors are defined as well as detailed approaches for

verification (test and analysis), model correlation, model update, uncertainty factors as a function of program maturity, etc. These criteria become very formal gates in the structures design function and must be

met or waivers developed. For example, loads analysis initially uses a 1.5 factor on loads; as the project

matures, this factor may drop to 1.25. At the completion of the modal survey test and when the dynamic

model correlation is finalized, the factor becomes 1. The strength and fracture disciplines assessment

requires an indentured parts list to ensure that all parts have been analyzed. From this list a fracture critical

parts list is developed which requires fracture analysis and nondestructive evaluation (NDE). Proof pressure testing of various parts is specified along with the proof factor. Materials have a comparable set of

criteria, from material usage, to processing, to characterization. The control discipline has a less rigid set of

criteria. It depends more upon judgment using established guidelines such as phase and gain margins, as

well as response characteristics. The thermal discipline mainly depends on conservatism in the analysis

and design process without having specific margins defined. In the aerodynamic discipline, stability

margins exist for flutter, etc., and are spelled out in the NASA documents. There is an old but very good set

of NASA design monographs that can be applied as guidelines for design. Most industries have design

manuals spelling out procedures as well as criteria. There are many good books also on the subject. Pugh in

Total Design 3 says that development of these criteria for each project by the various disciplines is very

critical to development of successful products and can be considered the mantle which envelops the project.

This document is focused on the design process and not the detailed design criteria; however, they are very

important.

3.5 Categories of Modeling/Activities

Throughout the vehicle design and operations processes, the vehicle performance and physical

attributes are characterized by descriptions or models of varying fidelity. At today's state of the art, it is not

possible to have one single model that describes in full fidelity all of the vehicle constituents and interactions. Likewise, it is not possible to address total vehicle design as a single comprehensive synthesis/

analysis activity. In the category of vehicle performance and physical attributes, there are three parallel

sets of descriptions and activities:

. A generalized description of the vehicle that is evolved through synthesis/analysis activities

directed toward overall vehicle performance. This category encompasses trajectory/

performance, load cycles, and overall vehicle design for ascent and return.

25
. Discipline-specific descriptions that are developed from discipline analyses, tests, and simulations. This set of models feeds its information to the other two sets. The descriptions increase

in fidelity as the design matures and additional analyses and tests are performed.

o Specialized descriptions and synthesis/analysis activities that are applicable to specific

interactive aspects of the vehicle, such as flutter, pogo, rendezvous and docking, etc. These

issues are addressed separately from the generalized description with their design consequences

being fed into the generalized description. (The generalized description should initially allow

"headroom" for the accommodation of the specialized interactive aspects.)

The generalized description is the "backbone" of the design. It increases in fidelity throughout the

design process. Upon entering the operations stage, a less-detailed description is extracted from the

generalized description to serve as a basis for executing operational constraints.

In addition, there is a second category of models that must also be developed. These models are

other than those associated with vehicle performance and physical attributes. They are in a general

category related to constraints but could include some ancillary requirements. These models are associated

with risk (technical, cost, and schedule), cost, reliability, safety, operations, and other associated -ilities,

and they provide the means to assess and manage this category of associated design activities.

3.6 Analyses, Test, and Simulation

To design a successful launch vehicle, the design and discipline functions must produce correct and

effective technical results. While technical integration is emphasized herein, it can be no better than the

information flowing within it. Consequently, correct and effective discipline results are essential foundations of the design process. The discipline functions accomplish their tasks using analysis, test, and simulations. For example, the analysis starts by formulating describing equations or a mathematical description

of the plant. This model can never exactly describe the response of the system nor of the natural and

induced environments. Therefore, the model is an approximation of the plant and the environments. In

other words, the analysis uses a model based on a set of assumptions derived from experience and what is

known about the system. These assumptions must be constantly challenged and revised. Many errors occur

because assumptions are considered sacred and are not challenged. The evolving database is the anchor for

the modeling process. Engineering judgment in drawing from the database and applying assumptions to

the models is based on experience. These models should be validated by benchmarking methods and

verified in developmental testing.

The testing process has similar limitations. The actual flight environment cannot be duplicated. In

order to reduce cost, etc., only the essentials of the hardware are tested. For example, in dynamic testing

many of the parts are mass simulated. Programmatic and technical constraints dictate these approximations. As in analysis, engineering judgment based on experience and the evolving databases is the basis for

assumptions regarding what hardware is to be tested and what critical combined environments are to be

applied. Simulations are subject to the same considerations as analysis and test.

In summary, a successful design depends upon the discipline functions understanding physical

principles, applying proper assumptions, and producing accurate results.

26
3.7 Parameter Matrix and Uncertainties

Each design and discipline function must define and quantify all parameters and their uncertainties.

Initially, they are based on engineering judgment. As tests are run and analyses refined, the bands of uncertainty are reduced. In general these uncertainties are defined with some statistical measure, e.g. 3-sigma,

level relative to a nominal or mean. When possible, a distribution is defined. Also, procedures for proper

application of these uncertainties are developed. The discipline specialists are the only ones knowledgeable

enough to develop this data. Management's job is to question the assumptions and assure that unneeded

conservatism is avoided. In the early design stages of the Space Shuttle, the Ascent Flight Integration Working Group (AFSIG) spent approximately 4 months developing the parameter uncertainties matrix for each

flight phase along with the analysis/test philosophy and procedures. Although prior program history can

serve as guidelines, the process must be repeated for each new project. Future trends are toward more

probabilistic methods of design.

3.8 Sensitivities

The response of the system and its sensitivities must be determined. This can be accomplished

through analyses, simulations, or tests; however, it is usually accomplished through analyses. The higher

the sensitivity, the tougher the design problem.

3.9 Failure Modes

Failure modes must be identified. Classically, there are two ways to identify failure modes. In the

first, failure modes are defined and assessed by discipline and design functions relative to criteria, for

instance various design limits, etc. On the structures plane designers and stress analysts

routinely assess and eliminate or mitigate failure modes. For example, structural failure modes are

assessed using specified factors of safety for strength, stability, endurance, and others that are specific to

the structures design function. The assessment consists of comparing the structural capability with respect

to the design limit to determine the structural margin. In the second, potential failure modes are defined by

a team of discipline, design, and system specialists, but from the systems perspective. This activity is

orchestrated by the system plane.The failure modes are usually put into some formal tree or cascading

logic diagram. The uncertainty/sensitivity data are used to assess the failure modes and the trade study

results. This assessment is made using engineering judgment augmented with risk versus

consequence logic which relates to quantification and impact using uncertainties, sensitivities, risks, and

consequences. This process utilizes failure modes and effects analysis (FMEA), critical items list (CIL),

and hazards analysis.

In the final analysis this is a balancing act between wanted and unwanted characteristics. Gordon in

Structures or Why Things Don't Fail Down 5 says: "All structures will be broken or destroyed in the end.

Just as all people will die in the end. It is the purpose of medicine and engineering to postpone these

occurrences for a decent interval: the question is: What is to be regarded as a decent interval?" Pye in The

Nature of Design 6 discusses the source of problems and their compromises. He talks about the source of

problems dealing with the manifestation and transfer of energy. He says: "Any of these forms of energy is

capable of producing changes, changes in things; more exactly, redistribution of matter. Now whenever a

change is made by the passage of energy and a result is left, this event takes place in a group of things.

Things are always together. They do not exist separately and they cannot act separately. When you put

27
energyinto asystem,you canneverchoosewhatkind of changesshalltakeplaceandwhatresultsshall

remain.All youcando,andthatonly within limits, is to regulatetheamountsof thevariouschanges.This

you doby design."He talks aboutthe compromisesin the"designfor failures.""The requirementsfor

designconflictandcannotbereconciled.All designfor devicesareto somedegreefailures."Thedesigner

orhisclienthasto chooseto whatdegreeandwherethereshallbefailure.It is importantin thisprocessthat

engineershavea networkof specialiststhatcanbecalleduponfor understandingtheseproblems.

3.10 Judgments

Good engineering judgment is a critical essential to the design process. Judgment is based on

insights gained through experience. Whenever possible it should be backed up with either a quantitative or

qualitative assessment. Many times it is hard to quantify the decision; however, in these cases, relative

comparisons can be used to support the decision.

Judgment comes into play in many aspects of the design process. First, the compartmentalization

process of deciding which components can be lumped into a subsystem or sub-subsystem is a judgment

based upon the coupling and complexity of the components and industrial specialization. Second, the

balance between performance and programmatic issues (costs, schedule, risk, etc.) are generally made

using judgment in the presence of available data. Third, many desirable technical refinements must be

balanced against priorities, risks, etc. Although some parts of the decision can be quantified, most become

a judgment. Fourth, test options, test configurations, and test conditions are also judgment calls.

Finally, technical judgments are targeted to be within some acceptable risk that ensures eventual

flight success. In fact, detail design and operations eventually become a process of managing risk since

STS systems are so finely tuned.

3.11 Probing Questions

The question always arises, "How does management ensure the job is done correctly, and when do

they know that it is completed?" In general this is accomplished through asking a series of questions.

Typical questions are--

• Does the design meet requirements with adequate margins considering uncertainties and

sensitivities?

• Have all discipline analyses/tests/simulations been completed to the appropriate fidelity?

• Has adequate interdisciplinary technical integration been done?

• Have issues and concerns been adequately identified and dispositioned?

These questions lead to the general question, "How do I determine adequacy?" The answer is

usually a judgment for which the following questions offer assistance:

(Method)

• Define and explain ground rules and assumptions.

• What was your analysis method? How was it benchmarked?

• What comparative analyses, simulations, and tests have been done?

28
• Whataffectsyour system?What isit sensitiveto? Have the interactions been considered?

• What does your system affect? Have you worked these interfaces?

• What concerns do you have with the design (or analysis/test process)?

(Results)

• What trends/patterns are present?

• Are they consistent? Explainable?

• What are the margins and the basis for the margins?

• Can the observed characteristics be explained using a simple analogy? Using a free body diagram?

How does one explain the load paths?

• Does it pass "the physics of the problem" check?

(Specialist)

• What is the engineer's understanding and feeling of the uncertainties?

• What is the specialist's track record?

• What is your specialist comfort level?

J.R. Thompson told Bob Ryan the following story that gives insight into how decisions are made.

At the time, J.R. Thompson was MSFC's Chief Engineer following his tenure as the Space Shuttle Main

Engine (SSME) Project Manager. He said that when he and Bob Ryan were working together to solve some

SSME problems to get the first Shuttle flight off (had slipped at the time more than 1 year), Bob Ryan

would talk to him about dynamic issues that needed to be resolved through redesign. He said, "Those

dynamic problems scared the hell out of me." He went on to talk about the only way he could honor the

political viability was to delay the redesign, handling the safety issue by changing parts after each flight,

imposing stringent inspections and strict process control, thus launching the first six Shuttle flights

successfully. At the same time he supported efforts which downstream resolved the issues. He asked Bob

Ryan to write a paper on the dynamic issues and their resolution as lessons learned, because he said, "Their

resolution was one of the keys to Shuttle's success, and he felt it was a meritorious accomplishment." He

understood that the approach he took was more costly but politically necessary. The approach effectively

managed risks versus consequences. Engineering in general involves not only technical factors but also

managing risks driven by political factors.

Bob Ryan asked Bob Thompson, Level II Shuttle Program Manager at Johnson Space Center (JSC),

how he made decisions. Bob Thompson was a master at listening to technical presentations in detail and

asking penetrating questions. His answer, paraphrased as best Bob Ryan can remember, "I must effectively

listen to each and understand what is said; however, I try to gauge the different technical people in terms of

their integrity and their conservatism. If the decision I think is correct is agreed to by the specialists that I

have confidence in and who are conservative, the decision is easy. If they don't agree, I consider what I

believe to be their level of conservatism versus the level of unconservatism others have, balancing in my

mind the risks and consequences between the conservative and unconservative; then I make a decision.

The decision can be somewhere between the differences or can be the unconservative if the risks versus

consequences are acceptable. In the discussion of the various task examples in the following sections,

further elaboration of these general points will be presented.

29
0

,i

_n

i

e-

(/)

i i !

i !

i

i___ I ..... i

!

i

i i

i ....... _ i i............ i

i i i .............. I

o

s_

E)

............. I I

! ............... "m

0

,,=

2

_.. _ ._

• 1 t ._1

Figure 14. Design process overview.

30
4. DESIGN PROCESS CHARACTERIZATION

The purpose of this section is to describe figuratively the design process workflow, the tasks, and

the key decision gates currently used in the design process for launch vehicles. The design process description is a symbolic visualization that characterizes various design functions and their associated enabling

discipline functions. Included in this characterization is a representation of how significant interaction

activities are achieved via vertical and horizontal technical integration. The design functions, discipline

functions, and technical integration are a complex system of multidisciplinary activities. This has been

studied in order to develop a characterization of a baseline launch vehicle design process which is

presented in this section.

An overview of section 4 is now given, as seen in figure 14. This overview figure shows the

following: Various levels of compartmentalization and reintegration; aerospace specialization; T-model;

subsystem tree, stack of design function planes; the supporting decision gate diagrams; the I×I interface

diagram, N×N activities diagram, and the design process balancing act. For the various design stages,

compartmentalization and reintegration are generic processes that enable the structure of the design

process technical integration. The system is compartmentalized into a subsystem tree with an I×I diagram

representing interface data flow among the tree elements. The design functions are responsible for hardware and software products that are supported by analysis, simulation, and testing activities of the

discipline functions. The flow of technical information is managed through formal (represented by the

square conduits) and informal (represented by the circular conduits) technical integration. The NxN diagram illustrates information flow among the design functions and disciplines. The technical information

(i.e., all of the attributes) flows to the system plane where it is appropriately balanced to the achieve project

requirements.

To set the stage for the characterzation, a discussion of project technical framework and a

"T-model" of technical integration are provided first. Then the design process characterization is presented

which delineates the launch vehicle design functions with vertical and horizontal integration that is overarched

with the system design function. Subsequently, each of the design functions is specifically addressed in

order to show the flowdown of requirements; implementation of philosophies, procedures, and criteria;

development of parameter matrices with associated uncertainties; specific enabling disciplines and associated multidisciplinary horizontal integration; and, eventually, the desired product attributes. In parallel a

discussion of the decision gates and the tasks associated with each specific design function is presented to

complete the characterization of the baseline launch vehicle design process. The baseline process is merged

with the launch vehicle generic information flow description. 2

This process description is applicable to all the launch vehicle design stages. To demonstrate this

wide-ranging applicability, it has been applied to the design sequence at a top level. First, it is applied to the

conceptual design stage, and then it is applied to the preliminary and detailed design stages.

31
4.1 Project Technical Framework

Technical integration is required to be accomplished in an orderly fashion; therefore, a framework

is needed to provide an organized and disciplined structure to requirements definition, project workflow,

WBS, configuration control, systems analyses, trade studies, system verification, reporting, documentation, etc. This framework is developed, maintained, and coordinated via the functions of project planning,

control, and documentation. The activities associated with these functions are accomplished by the

systems engineering discipline. In reference 6, the systems engineering discipline is delineated in a global

sense; i.e., the definition is generic and considered by many to be the "classical systems engineering" view.

In the application of classical systems engineering discipline to the STS design process, it supports the

activities of the project leader on the system plane. From that view, the systems engineering discipline

contribution is through the system design function in the same way that stress analysis contributes to the

structures design function (see sections 4.3.2 and 4.3.6, respectively).

The primary activities of the systems engineering discipline, as delineated above, are in executing

the functions of planning, control, and documentation, see references 7, 8, and 9. It should be noted from

section 4.3.2, that the products of the system design function are validated STS design specifications and

attributes, balanced design attributes and requirements, and an operations plan. All these are achieved via

technical integration (see section 4.3), which is orchestrated by the project leader. The project leader needs

to accomplish the demanding multidisciplinary interaction tasks associated with technical integration in an

efficient and effective manner. The project framework enables him to orchestrate the design and to balance

its attributes in an orderly fashion by providing the necessary discipline and structure. While he uses the

tools and functions of the systems engineering discipline to achieve order in the process, he leads and

orchestrates the other design functions to achieve balanced design specifications. The tools of the other

engineering disciplines are implemented interactively among and between the various design planes to

accomplish the complex multidisciplinary engineering tasks and then their results are integrated and

balanced by the project leader via technical integration.

The purpose of this section is to delineate select key aspects associated with the STS design process

project framework. In this sense, it focuses on specific highlights that are considered typical. They are

project stages, project main products, technical effort distribution, typical organizations, and roles and

challenges. For more details related to the STS design process functions of planning, control, and

documentation (see references 7, 8, and 9).

4.1.1 Project Stages

Most projects are subdivided into stages (see fig. 15). It has been demonstrated through various

projects that this approach is successful. Historically the phases associated with most NASA projects are A,

B, C, D, and E. In phase A, the major goals are to determine the project objectives along with assessment of

feasibility. These activities correspond to the conceptual design stage. Additionally, the need for technology is

assessed, and various concepts are selected for trade studies. In phase B, the focus is on refining the selected

concepts through trade studies; system analysis and simulations; refined system and support requirements;

definition of preliminary manufacturing and test requirements; definition of advanced technology and

advanced developments requirements for focused funding; and assessment of technical, cost, and schedule

risks. These activities correspond to the preliminary design stage. In phase C, the focus is on completion of

32
detaildesignof the selected concept; performance of detail systems analysis; and development of final manufacturing, testing, operations, supporting systems and facilities plans. These activities correspond to the detail

design stage. In phase D, the focus is on development and test of prototype/protoflight hardware; verification,

validation, and qualification of hardware and software for flight; manufacturing and integration of flight

hardware; checkout of flight systems; launch operations; and initial flight operations. These activities correspond to the manufacturing and systems integration]verification stages. In phase E, the focus is on mission

operations and disposal. This corresponds to the operational stage.

Throughout the duration of the design process the aforementioned phases of the program are finalized with formal reviews. These reviews represent the project milestones; i.e., project gates, and are shown

in figure 16. The purpose of these reviews is to focus the progress of the project and verify that the project

is proceeding as planned. Throughout the design process there are about 12 major reviews; however, there

are numerous intermediate reviews. The project reviews that must receive major support from the design

laboratories are as follows:

• Systems requirements review (SRR)

• Preliminary Design Review (PDR)

• Critical Design Review (CDR)

• Design Certification Review (DCR).

For all formal reviews that occurred in the past, there was a specific process that was required to be

followed with clearly specified outputs. The guidelines for these reviews were contained in NASA

Management Instructions (NMI's).

Recently, NASA issued updated procedures and guidelines for the management of systems.l° It

defines the requirements that managers must meet in formulating, approving, implementing, and evaluating programs and projects. The program phases discussed above (i.e., A, B, C, D, and E) have been

replaced with four subprocesses. They are as follows: (1) Formulation, (2) approval, (3) implementation,

and (4) evaluation. The various design stages delineated in figure 15 must still be accomplished by the

Conceptual

Design Preliminary I _

Design

Detail

Design

IIII_ I System

Manufacturing Integration

Process and

Verification

m _ ,.,i

'_ DesignProcess

Figure 15. Major project stages.

Operations

33
leader whether they are called phases or subprocesses. However, the manner that they are accomplished

must be appropriately tailored for efficiency and effectiveness. The rationale behind the

management guideline is "faster, better, and cheaper." The themes are as follows: (1) Tailoring the process,

(2) end-to-end customer involvement, (3) comprehensive definition and requirements control, (4) risk

management, (5) missions enabled by technology, (6) technology commercialization, and (7) International

Standards Organization (ISO) 9000.

• Classical

I-Pre-OA-.),I_--OA_',_ @B _; _C _ _D _-',_ OE

I Mission I Mission I System I Preliminaryl Final I Fabrir4,ti°n I Prepfor I Dep_mentl Mission I

FeasibilitM_ DefinitionJDDefinition _r, Design_ Design _lnte_tion_Deployment_verifUicabtion_Operations_

R R Snn SDR PDR CDR DCR SAR FRR ORR DR

J\

I Fabrication, Integration I

• Typical I and Ground Verification I

In-house and Contractor

sys,Dff andI_BStudies I Contractor

I System I PreliminarYl Final I

Definition, Design I O_sign _¢

_C Contract PDR

Award

Disposal

CDR - Critical Design Review

OCR - Design Certification Review

DR - Disposal Review

FRR - Flight Readiness Review

MCR - Mission Concept Review

MDR - Mission Definition Review

ORR - Operational Readiness Review

POR- Preliminary Oesign Review

PRR - Preliminary Requirements Review

SAR - System Acceptance Review

SDR - System Definition Review

SRR - System Requirements Review

Figure 16. Project phases.

4.1.2 Main Project Products

For each design stage there are certain products that are required. A generic specification of these

products is given in various NASA documents. These specifications are meant to be guidelines in the sense

that each project can tailor the products consistent with the specific design stages. However, the projects

are subject to peer review, and certain products are required and others are expected. It is the responsibility

of the leader to determine what products are needed to demonstrate that their project is technically sound,

on schedule, and cost effective. Typical products associated with the various stages are shown in figure 17.

The products delineated here are meant to be illustrative and are not all inclusive; however, they provide

some indication of what is needed. In cases where the peer review results in excessive criticisms, referred

to as review item discrepancies, there is usually a delta review for that stage and additional products can be

added at that time. This can happen in very complex programs, and the value added is that the peer review

forces the project to become technically sound, on schedule, and cost effective. Reviews are successful

when the products are completely integrated through formal and informal communications. The systems

engineering discipline supports all these activities by organizing and coordinating the various reviews and

subsequently tracking/documenting results and action items.

34
CommunicationadInlegraUon

• Feasible Project

Concepts

• Trade/Sensitivity

Results

• Selection Criteria

• Refined Requirements

• Risk Assessment

• FacilitylGSE Concepts

• Pertinent Project

Documentation

• TRL Assessment

- Technology Needs

J Preliminary Design I I Design Detail

• Preliminary Design • Final Design and

Concept(s) Specifications

* Subsystem Definition - Parts,

and Requirements Components,

• Refined Top-Level Elements,

Requirements and System

. Trade/Sensitivity Results • Manufacturing and

• Interface DefinitionllCD Assembly Process Requirements

• Risk Assessment - Built-to-Specification

, TRL Assessment • Detailed Verification Plan

, Pertinent Tests • TRL's Must Be Satisfied

• Top-Level Verification • Quality and Acceptance

Plan Rec!uirements

• Preliminary Facility and * Facility and GSE

GSE Requirements/Concepts Requirements

• Pertinent Project • Preliminary Operational

Documentation Procedures and Constraints

• Pertinent Project

Documentation

I I Manufacturing "n'I I Operations

• Finalized OPS

Procedures

• System Design and OPS

Validafion and

Certification

• Product Improvement

• Hardware and Software • Flight Ready Hardware

Ready for Assembly and and Software

Test Verification , Demonstration That

• Facility and GSE Hard- Requirements Are

ware and Software Satisfied

• Operations (OPS)

Procedures and

Constraints Refined

and Verified

I Products Successfully Delivered Through Communicalion and Integration

Figure 17. Project main products.

4.1.3 Technical Effort Rate Distribution

A typical technical effort rate distribution is illustrated in figure 18 for the various project stages. It

should be clear that each specific project will have its own particular distribution. It can be seen that about

6 percent of the technical effort is allotted to the conceptual design stage and about 20 percent allotted to

the preliminary design stage. The remainder of the effort goes into detailed design, manufacturing, systems

integration, and verification. At this time there is some controversy regarding the amount of effort that

should be allotted to the conceptual design stage. There is a trend in the engineering community to put

more effort into the conceptual design stage, especially in situations where the design concept is revolutionary. At least 80 percent of the life-cycle costs are determined by decisions made during the conceptual

design stage (see section 4.4.1.1).

4.1.4 Typical Organizations

Engineering projects can be organized as shown in figure 19. In this figure is shown the leader and

supporting subsystem teams. While this structure can be considered typical of a project type organization,

it is noted that the design process as characterized herein does not depend upon any organizational structure. The elements of the design process must be executed regardless of the organizational structure. In the

past, several different types of structures have been implemented to achieve the project goals. Figure 20

from reference 11, but slightly modified, shows four basic types of organizations that have been

35
1.4 m

t.2

--= 1.0

O

1==

ULJ

-- 0.8

•I= 0.6

0.4

0.2

DetailDesign "_

Manufacturing

SystemIntegration

andVerification

PreliminaryDesign

ConceptualDesign

I I I I I

0.2 0.4 0.6 0.8 1.0

ScaledProjectDuralion

Figure 18. Project total technical effort rate distribution.

Leader

and

Deputy

Safetyand

Mission

Assurance

I

LeadSystem

Engineer

I

Lead

Subsystem

EngineerA

t Staff ]

Functions I

(Project Control)I

Lead

Subsystem

EngineerB

I

Lead

Subsystem

EngineerX

I

Lead

Subsystem

TestEngineer

Figure 19. Typical project management organization.

36
implemented in the past. Figure 21 is intended to show various types of organizations where integrated

product teams (IPT) have been used in the near recent past. These organizational structures are briefly

discussed below.

Engineering organizational types have been structured to achieve project goals in the most cost

effective manner. As mentioned above, four of the most commonly used organizational structures are

shown in figure 20. The functionally organized structure is frequently used when the product development

is not too complex and the functional managers can achieve the necessary system design function in addition to the functional operation of the organization. On the other hand, a certain product may require

special attention such that a project specific leader is required. Again, if the project is not too large, then a

light-weighted matrix organization can be suitable. In this case, representatives from some of the functional organizations usually support the project; in addition, the leader interacts with the functional managers. If the engineering task is complex, then a heavy-weighted matrix organization is favored. The leader

interacts formally and on a regular basis with the functional lead engineers and the functional managers.

All other engineers work informally with the functional lead engineer and report technically to functional

managers. This type of organizational structure has been very popular in the aerospace and automotive

industry. The final organizational structure is the project organization. In this structure the lead engineers

and the working level engineers are directly responsible to the leader. Their relationship to the functional

manager is to maintain functional discipline but the functional manager is not technically responsible for

their work. The leader interacts with the functional managers as needed. There has been a recent trend in

the automobile industry to use the project organization as opposed to the matrix organization. The four

organizational structures delineated here are basic, and many variations of these have been implemented.

Functional Manager (FM)

Grou

the_

of professionals who execute

tctivities in product creation

Functionally Organized Structure

-Leader

Heavy-Weighted Matrix Organization

PMra°_eaC_e r

Ass st_

Leader Liason " Area ofStrong Project

Representative(L) Manager influence

Light-Weighted Matrix Organization

,®

Dev.1 Dev.2 Dev.3

I

i

I

____i

Leader

Project Organization

i

i

i

Figure 20. Typical organizations.

37
Engineeringorganizationalstructureshavebeenfine-tunedrecentlywith theimplementationof

IPT's.TheIFF's areavariationof aprojectteam.Showninfigure21arethreevariationsof IPT's.Thefirst

teamstructureisof atypewheretheIPTistechnicallyconnectedtothefunctionalorganization.Theteams

canbecolocatedor the memberscanremainin thefunctionalorganization.The functionalmanagersare

responsibleforthetechnicalengineeringwork,andtheinformal integrationis within andbetweenteams.

Theleaderisresponsiblefor activitiesassociatedwith thesystemdesignfunction.This structurehasbeen

popularandverysuccessful.In thesecondtype,theIPTisconnectedto thefunctionalorganizationthrough

proceduresandstandards.Theteamsarelocatedwithin theproject,andtheinformal integrationiswithin

andamongteams.Again,theleaderisresponsiblefor activitiesassociatedwith thesystemdesignfunction.

Thefunctionalmanagermaintainstechnicaldisciplinebut is nottechnicallyresponsiblefor theengineering work. The third type of organizationalstructureis wheretheIFF is completelyindependentof the

functionalorganization.Theteamsarelocatedwith theprojectandtheinformal integrationis within and

amongteams.Theleaderis responsiblefor activitiesassociatedwith thesystemdesignfunction.Thereis

noconnectionbetweentheworkingengineersandthefunctionalmanagers.This particularstructurehas

provento beunsuccessfulin somecases.

It hasbeenlearnedthatwhenengineeringspecialistsareseparatedfrom thefunctionalorganization

for morethanabouttwoyears,thereis anerosionof theirtechnicalexpertise.Someorganizationsmovethe

technicalspecialistbackto thefunctionalorganizationafterabouttwo years.

4.1.5 Roles

The system design function uses systems engineering discipline tools like QFD to transform

the mission statement into a description of system requirements and a system configuration. These are then

allocated to the other design functions. All system requirements must be integrated to ensure balance and

compatibility of all interfaces. All other factors must be integrated into the total engineering effort to meet

the cost, schedule, and technical objectives.

The systems design function is responsible for the overall technical management and certification

of the system. There must be technical interchanges with all contributing parties as well as requirements

definition, management, analysis, and flowdown. In addition, there must be verification

planning and audit, interface management, risk analysis and management, configuration management, etc.

Again, the tools of the systems engineering discipline are applied to support these activities.

The challenge of systems design function is to provide the best system that meets all the requirements and provides a proper balance of performance, cost, reliability, safety, operability, schedule, and

TRL. The systems engineering discipline plays an important role in this process where the disciplinespecific tools are implemented to aid planning, to achieve design process control, and to provide the

documentation of all critical process elements. The system design function is the responsibility of the

leader, who is supported by the systems engineering discipline in planning, controlling, and documenting

the process.

38
Leader )L

XXXX

I_T-1

L vel-2

)FM

IPT TechnicallyConnectedIo FunctionalOrganization

DFr_ e f _1 -_IFM i Fr_

I Dev.2 Dev.3 Manufact

Procedures and Standards

IPT Connectedto FunctionalOrganizationThroughProceduresandStandards

f PT-1

Leader _, eveI-E

IPT CompletelyIndependentof FunctionalOrganization

Figure 21. Integrated product teams.

39
4.2 Technical Integration

Technical integration is the fundamental fiber that goes through every aspect of the STS design

process. It is accomplished with an increasing intensity as the design process progresses through the

various stages. Technical integration will be illustrated using a symbolic representation; i.e., a model. In

addition, there are various other factors that are known to enable it. These factors can be thought of as

describing attributes of technical integration. In this section a model is provided for technical integration,

along with a description of the enabling factors and a typical activities distribution.

4.2.1 Technical Integration Model

The T-model has been chosen to illustrate technical integration in this document. Helmut Horn

(Peenemtinde Team) discussed the T-model for technical integration during Saturn/Apollo era. Contemporary literature discusses the attributes and advantages of this model in today's environment. This model has

been called the T-model because it has vertical and horizontal components. The stem of the T represents

in-depth discipline (or component) activities and penetration while the crossbar represents interactions;

i.e., technical integration. The model, when applied to the space transportation design process, results in

two specific levels of technical integration shown as parts of the T's crossbar in figure 22. The upper level

(i.e., above the dashed crossbar) of technical integration is known by the interchangeable names of system

integration, formal integration, or top-level integration. The leader and his office are the primary facilitators and operatives of this level of integration. The emphasis of this level of technical integration is primarily upon the system aspects of the design process; i.e., the focus is on overall technical management and

certification of the system. The concerns are delivering the product with a proper balance of performance,

cost, reliability, safety, operability, schedule and TRL. Technical integration is achieved through communication and interaction with all contributing parties, customers, and similar interfaces associated with the

design process. The continual purpose is to converge to a balanced product via managing and resolving

conflict. All system related decisions and all system related technical conflicts are respectively made and

resolved at this level. In addition, all system planning, control, and documentation related to the design

T-model forTechnicalIntegration

• Systems

• Formal

• Top Level

---t

• Specific Discipline to

Specific Discipline

o,sc,0,,no 1 , , Ij:o'sc'0"no

:com0ooeo,-O,,, I____lt co oonoo'- 

IntegrationisEverybody'sResponsibility

Figure 22. Technical integration--T-model.

40
processis maintainedat this level.Thelevel of intensityof the activities increases as the design process

pro_esses through the various stages.

The lower level of integration (i.e., below the dashed crossbar) is given by the interchangeable

names of specific discipline to specific discipline, informal integration, or in-depth integration

(see fig. 22). The emphasis of technical integration in the horizontal portion below the crossbar represents

discipline-to-discipline or component-to-component interactions of the design process. The functional

organizations are the primary operatives of integration for discipline-to-discipline aspects of the design

process, while the engineering design functions (see section 4.3.1) are the primary facilitators of integration for the component-to-component specific aspects of the design process. The vertical legs of the

T-model can also denote activities of discipline engineers. It signifies that individual engineers must have

in-depth discipline capability with a systems perspective. These engineers must be knowledgeable, aware,

and responsive to their respective interacting disciplines, as well as the systems aspects of the process that

they impact throughout the various design stages.

The design considerations are the pedigree of input data, maturity of configuration, interactions,

compatibility, sensitivity, uncertainty, etc. The focus is on the technical adequacy of all the discipline

specific design attributes and how they horizontally integrate with other disciplines to achieve a balance of

the allotted attributes for the specific design functions. This is accomplished through an iterative process.

If proper balance cannot be achieved, then the design function must bring the conflict to the upper level for

reallocation of requirements or some other system resolution. It is the responsibility of the discipline

organizations to document and report their technical results.

4.2.2 Technical Integration Enabling Factors

The factors that enable effective technical integration include (1) an electronic communications

system; (2) the internal connectivity of sizing programs that inherently connect certain disciplines

(caveat--not a substitute for personal interactions among the specialists); (3) interactive team members

having strong leadership that in turn fosters interactivity; (4) proper overview by leader, functional

managers, advisors, etc., to ensure correct integration; and (5) interactive feedback of requirements,

strategy/philosophy, and architecture.

How does one know if proper technical integration is occurring? Throughout the process, management and participants must be very alert to the integration issues. Use a state-of-the-art communications

system tailored to provide pertinent information to the participants. Check inputs and outputs required to

ensure cognizance and understanding among design functions and disciplines. Determine the extent of

continuous interactions by being aware of informal integration and have participants display integration

activities and accomplishments. At each iteration, check to determine if the right problems are being worked,

verify data trends, determine if uncertainty is converging, and have independent experts evaluate critical

items. Throughout, check for consistency, compatibility, and convergence.

4.2.3 Technical Integration Activities Distribution

Throughout the various stages of the design process the distribution of the technical effort rate

changes. Figure 23 delineates the scaled technical effort rate variation with scaled project duration.

41
The major total technical effort rate can be categorized into two groups: (1) Technical activities and

(2) technical integration. Technical activities include all design function and discipline engineering and

other technical efforts required to complete the project. Technical integration is composed of formal and

informal integration. From figure 23, it can be seen that the technical activity peaks about midway through

the project where the major expenditure of design function and discipline engineering effort occurs. The

technical integration starts off at a low level, ramps up, and then levels out throughout the project. The

major formal and informal balancing acts are being achieved during this part of the project. The formal

integration tends to increase at the end of a project, since the project comes together as a validated hardware product. In summary, the rate distribution shown in figure 23 represents a typical distribution of a

representative project. In each specific engineering project, the distributions may be different; however, if

there is a significant difference, this difference should be studied to ensure that there is an appropriate focus

of all the activities.

1.4

1.2

1.0

t_

re"

o

08

c

u

_ 0.6

lu

0.4

0.2

m

iI

i I

Total Effort

//p J ._ •

jl ••

o o •

," TechnicalActivity

l

.,r a

..................................................... ............. .,- ._ ,_"""-TechnicalIntegration

....... " "Formal Technical Integration

- - "! I I I I

0.2 0.4 06 0.8 1.0

ScaledProjectDuration

Figure 23. Technical integration--activities distribution.

42
4.3 Characterization Model

A symbolic representation of the launch vehicle design process is developed in this section. It

consists of three categories of compartmentalization. They are hardware/software subsystems, design functions, and discipline functions. After compartmentalization, the T-model of technical integration is applied

to the subsystems and to the design and discipline functions. All this enables the symbolic representation

and enhances the capability to achieve technical integration. The features of hardware/software subsystems,

design functions, and discipline functions are delineated. In addition, the IxI and NxN matrices and the

balancing act are illustrated. This is followed by a description of the launch vehicle system. This description illustrates each design function, connections between design functions, how they are enabled by various discipline functions, and the launch vehicle system IxI and NxN matrices. In addition, this section

includes what tasks must be achieved, what product attributes are developed, and what decision gates must

be passed. All of the aforementioned is discussed in a parallel fashion for each design function. Also, the

NxN matrix, WBS's, and tasks in reference 2 are included to show the relationship to the process symbolic

representation.

4.3.1 Features of Description

The success of the design process depends upon achieving technical integration and achieving it in

an effective and efficient manner. Initially, the principal engineers from the systems design function and the

principal engineers from the functional organizations accomplish compartmentalization (see section 2.0).

The first category of compartmentalization consists of dividing the STS program into the launch

vehicle system, payload interfaces, and operations system. Then the launch vehicle system is further

divided into subsystems and so on, as illustrated in figure 24. Each division results in a "system," and there

are supporting design functions and discipline functions for each system. The design and discipline functions will be illustrated below. The information flow associated with these systems consists of allocations

from the parent system and suballocations to the lower-level subordinate systems (subsystems). Then there

is also information flow associated with interface requirements. It can flow from the parent system, from its

peer (i.e., mating interfaces, subsystems) and from its lower-level subordinate systems. In addition to those

types of information flow between these systems, there are also interactions. The interactions are physical,

functional, and informational. It is of paramount importance to track and account for all interface interactions. These can be determined through experience, analysis, test, or simulation. The information flow and

interactions in this category of compartmentalization are important aspects of technical integration.

The second and third categories of compartmentalization pertain to mechanics of how the design

specifications of the system are actually achieved. To further illustrate the design process, a distinction

must be made between the sometime misunderstood design functions (the second category) and discipline

functions (the third category). The distinction between design functions and discipline functions is illustrated in the following example. First, consider the design of the fuel tank subsystem (see the fuel tank

subsystem 2.2.3.2 in fig. 25). Recall, the fuel tank system design specifications are the responsibility of the

fuel tank system design function. It is shown in figure 25 at the top of the "stack" and is designated as

2.2.3.2.0.1 From the figure, it can be seen that the entire fuel tank system design activity is supported by

other design functions in the corresponding stack. The design functions design from their own perspective

but with cognizance of the other design functions in the stack. This aspect of technical integration that is

43
I

2.0

Launch

Vehicle

, , I

Propulsion Vehicle Thermal

Systems Structures Systems

I

I I I

Thrust Aeroshell Tankage

Structure

I

I

Oxygen

Tank

I I

2.23.2.1 2.2.3.2.2

Tank Tank

Structure Thermal

System

I

2.4

Avionics

Systems

I

I

2.2.3.2

Fuel

Tank

I

I STS 1.0 I

I

I 3.0 I

Payload

Interfaces

I

2.5

Other

Systems

I

2.2.4 I

Intertank

Structure

I

Payload Bay

Structure

!

I

2.2.3.2.3

Propellant

Utilization

System

I

Propellant

Conditioning

System

I

i 4.0

Operations

Systems

(Selected compartmentalization subsystems shown as an example)

Figure 24. Launch vehicle hardware subsystems compartmentalization.

associated with the stack will be discussed in a following section. Ideally, each design function in the stack

provides hardware/software design specifications (that satisfies the allocated requirements) to the system

design function. In turn the system design function is responsible for developing integrated fuel tank

system design specifications. The following is a typical list of the design functions that support the fuel

tank subsystem design:

• Fuel tank systems

• GN&C (for slosh baffle requirements)

• Structures

• Thermal

• Avionics

• Materials

• Manufacturing

• Other systems.

The hardware/software specifications delivered by design functions are designed by a person or

persons called designers. The designer has the ultimate responsibility for specifying the final hardware/

software configuration along with the associated attributes. Designers conceive (hypothesize, synthesize)

candidate subsystem configurations that are then analyzed to see if they will successfully perform as

desired. Designers' products are drawings and software specifications that define their subsystem. For the

fuel tank system example, the specifications (drawings, manufacturing instructions, etc.) would be those of

all tank structure, tank thermal systems, propellant utilization system, and propellant conditioning system.

In addition, it would also include the associated design attributes such as performance, cost, reliability, etc.

44
m+

LL-

,-=_

......... +i i++

,,il

:/

G,

l,/.,.

B

E

E

,i,

,,.,LI

F_

C

! I_'_ _

-'°'" i

1¢ 's =i I

, _IP.-,

_cm--

'... "+.. -,

.-. + "t ;,__m, ,_

, ,++_ ,''_" +, _ ::--+--, m

1 I ..... I_ i .... - I .,:1_ II i

..... , ,to , y_'_

_a_ 7.... '

, .-.,_ ._,

..... _,

_m. ,,N_._:

L#---

Figure 25. Fuel tank example: Subsystems, design functions, and discipline functions.

45
In summary, what the designer does is called the design function for his or her respective design

function. As can be seen, there are design function "stacks" corresponding one to one to each hardware/

software subsystem. The same principle applies as the subsystems are further compartmentalized into

sub-subsystems, components, etc.

On the other hand, discipline functions (third category of compartmentalization) are technical areas

of specialty and expertise. Discipline functions perform analyses, tests, and simulations of a given design

concept. The discipline functions support the design functions to achieve the desired attributes, and they

reside on the design function "plane." This particular aspect of technical integration will also be discussed

in a following section. A typical list of disciplines includes the following:

• Structural analysis

- Structural dynamics

- Stress

- Durability

- Vibroacoustics

• Control system analysis

• Etc.

It is possible for an engineer to have both a design function role and a discipline function role. This

is uncommon in structures, but in some other areas such as control, the same engineer may both conceive

(hypothesize, synthesize) a control system and perform analysis on that system. That engineer can be

found at different locations on the plane depending upon the activity engaged in at the time.

In summary, design functions can be represented as planes that produce the design specifications.

On each plane are the interacting discipline functions needed to support the development of those specifications. There is a "stack" of design function planes associated with each system, subsystem, etc. The top

"system" plane of the stack is responsible for integrating the other design functions in the stack and is

responsible for providing the hardware/software specifications for its respective system or subsystem. Discipline functions reside on the plane of the specific design function that they are analyzing or testing. If

they are involved in multiple subsystems, they reside on more than one plane. (For example, a stress analyst doing work on both the fuel tank structure and the main engine structure would find his respective

activities on the fuel tank structures plane and the main engine structures plane.)

In the previous discussion, the fuel tank system was addressed to illustrate the three categories of

compartmentalization. In the following discussion the focus will be on the launch vehicle system (see 2.0

on fig. 24). In this situation, the top-level system plane represents the system design function for the total

vehicle system. The designer in this case is the leader who has the ultimate responsibility for producing the

total vehicle drawings in addition to hardware/software specifications. Also resident on the system plane is

the discipline of system engineering that performs the discipline functions related to design process planning, control, and documentation.

After the first and second categories of compartmentalization are completed, activities on the system plane begin with a listing of hardware and software design products along with the required associated

tasks to produce these products. The design functions promote the necessary intega'ation and communication

46
to effectivelyandefficiently executethe tasksto producedesignspecificationsthat meetthe allocated

requirements.Toenablethedeterminationof designfunctions,considerationisgivenbothto arrangements

thattendto decouplethevariousdesignfunctionsandto arrangementswherethereisalogicalgroupingof

multidisciplinaryactivitiesfor eachdesignfunction.Figure 26representstypical arrangementof design

functionsfor the launchvehicle.The launchvehicledesignprocessconsistsof the following design

functions:system,aerodynamics,trajectories/G&N,controls, structures,thermal,propulsion,avionics,

materials,manufacturing,andothers.It canbeseenthatall of thedesignfunctionsareoverarchedby the

systemsdesignfunction.Eachof thedesignfunctionsisenabledbydisciplinefunctionsthathaveactivities

that supportthe developmentof the designspecifications.The discipline function activities include

analysis,simulation,groundandflight testverifications,etc.,to accomplishthedesigntasks.

The attributesand specificationsof eachof thesedesignfunctions are attainedthrough the

multidisciplinaryactivitiesof all thedisciplinefunctionssupportingthatdesignfunction.Theseattributes

andspecificationsmustsatisfythesystemrequirementsandnotconflictwith anyattributes,requirements,

orconstraintsof theotherdesignfunctions.Theproducts,obtainedviathedesignfunctions,arethelaunch

vehicledesigndrawingsandspecifications,otherassociatedcriteriaandrequirements,andconstraintsthat

relateto thelaunchvehiclehardwareandsoftware.

All designfunctionanddisciplinefunctionactivitiesmustbetechnicallyintegrated.Thisis accomplishedby bothformalandinformaltechnicalinte_ation,representedin figure26.Therectangularconduits

representtheverticalformaltechnicalintegration.Thecircularconduitrepresentstheverticalinformaltechnicalintegration.In addition,thereisalsoin-planeinformaltechnicalintegration.In-planeinformaltechnical

integrationis definedto meanmultidisciplinarytechnicalintegrationactivitiesonadesignplane.

The formal vertical integrationrepresentstheflow of informationdownwardsandupwards.The

downwardflow of informationis from the systemsdesignfunction to the other design functions. This

information mainly consists of subsystem specific requirements, architecture, philosophies, procedures,

and criteria and is represented by the downward pointing arrows. The upward flow of information is from

all the design functions to the systems design function. This information mainly consists of the attributes

(characteristics of the design to be compared to the allocated requirements, etc.) of the design from the

design functions and is represented by the upward pointing arrows. Formal in-plane integration occurs

within the systems design function. This integration pertains to achieving balance among the system

attributes and insuring compatibility to the requirements, managing and resolving conflict between design

functions, and overall system engineering management, certification, and documentation of the entire

system.

The informal integration is both vertical and in-plane. The vertical informal integration (i.e., the

circular conduit) represents a flow of information that is both upwards and downwards. The information

flow is between design functions and is represented by the arrow pointing upwards and downwards. Notice

that this information does not go to the systems design function. This type of information flow results

because of the iterative nature of the design process and the fact that the design functions are coupled;

i.e., the attributes of one design function may affect the attributes, requirements, or constraints of other

design functions. Thus, the final attributes from all the design functions must be balanced (i.e., mutually

compatible) and satisfy all the allocated requirements. Finally, there is also informal in-plane integration.

This flow of information results from the multidisciplinary activities that occur within each design

47
System

Aerodynamics

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

Figure 26. Technical integration of system, design, and discipline functions.

function. Again, these activities are iterative, and they are considered balanced when the attributes satisfy

the system level requirements and do not conflict with the attributes, requirements, or constraints of the

other design functions.

All information flow is accounted for and controlled through the utilization of the I×I and N×N

matrices (see fig. 27). The I×I matrices are associated with hardware/software interfaces and the N×N

matrices are associated with the design and discipline functions. As shown on the figure, the I×I matrices

pertains to input and output data flow associated with the physical, functional, and informational hardware

/software subsystems interfaces. This type of information is usually contained in interface control documents (ICD). Similarly, the N×N matrices pertain to input and output technical data flow associated with

interacting design and discipline function activities. This aspect of the design process characterization

provides a residence and a placeholder for information associated with the design process.

48
{0p

0

.m

0

CZ

IJ.

E

QP

_0p

-s

=i

X

Z

X

Z

T . .....

..... !_[_]

' i.... i '_°'

I ,_ _., _ .... , ,_= ,

I , _, ° _, ___,

..... '._,_=,_ ii __-_m.=,

I ,,_, ,_ "_

.... , , .®= ,-_-_ ,_._', 'N= ' '_._ ,

,_ ' ,_..... ,

' :" ' ,I '_- ,- .... "

I iCNJ II I .... _i I -_ I I_N,I I

i_l _

l , ..... ,_ , .... ,I : -¢E_,

I "-' oil

° , _-, ',"__ ', ' , ,_.,"_,,

I.'=.. I _r" C_ i I H I

_, ,_, ,:_., ,_-:_--, ,_ _=_ ,

- ,,,_ ..,'_' ,_ ', , ,_=-_ ,

! a .

I" '-1 ¢_dl_ I

, ,_ ' .,.. ,_ _ ,

I ¢.,_, i_--.,! I .....

I i_ i_11 I .... '1

, .-'-., _ _,

, . _,._ ,_._._'

-- .-

i ;E' .',

'1- ._opa

! Q= i

Figure 27. Matrices of input/output data flow.

,-r_=

w

-_=_

49
Technical integration is a balancing act. At the top level the design and the operational plan must

balance the program requirements (see fig. 28). During the design process there are numerous trade studies

where the attributes between various design function planes are balanced to achieve the best design.

(Individual engineering design functions will be interchangeably denoted as planes in some parts of this

narrative. For example, the aerodynamic design function may be denoted as the aerodynamic plane.)

In a specific plane there is also multidisciplinary balancing to achieve optimal attributes that satisfy the

requirements. Trade studies that drive out the differences in design alternatives constitute a significant part

of the design process as managed by the leader on the system plane. Because of the strongly coupled nature

of launch vehicles, trade studies are usually numerous and must be performed at a sufficiently detailed

level to reveal the differences in the alternatives. Trade studies usually involve multiple design functions.

How well the balancing is achieved determines the success of the product. Pye states, "Any of these forms

of energy is capable of producing changes, changes in things; more exactly, redistribution of

matter .... Now whenever a change is made by the passage of energy and a result is left, this event takes

place in a group of things. Things are always together. They do not exist separately .... All you can do, and

that only within limits, is to regulate the amounts of the various changes. This you do by design."

He states further, "The requirements for design conflict and cannot be reconciled. All design for devices

are in some degree failures... The designer or his client has to choose to what degree and where the failures

shall be...'6 Figure 28 also shows the function of system analysis and integration in performing the

balancing act. The various discipline functions provide sensitivity data that are used to perform trade

studies and technical integration. Through the use of assumptions, analyses, simulation and testing, and

using the core capability of the organization, these design tradeoffs can be made and aternative

design solutions achieved. These solutions in general will be suboptimum and can consist of several

compromises of the original requirements. Understanding and accounting for the balancing act are keys

to successful design.

Requirements Project I

I

I I

I oes,on I I oP P'an I

CoreCapability ]

DesignProcessIsa BalancingAct

Figure 28. Design process balancing act.

5O
Technical, cost, and schedule risks must be actively managed throughout development. Active risk

assessment is an essential element of the design process. Failure mode analyses and risk/consequence

assessments are done for each design alternative. A technology assessment for each design alternative

identifies technology development required, along with the risk associated with maturing the technologies

to an acceptable level.

In the compartmentalization process described above, the intent is to take advantage of weak

coupling between design functions and between discipline functions. This approach enables the design to

proceed at design function sublevels such as structures, propulsion, avionics, etc., and by the various technical disciplines. However, this assumption results in a suboptimum design from two standpoints: (1) The

total system is not optimized since the design is consummated at the element, subsystem and component

level. In other words, the assumption is that if all the parts are optimized, when they are put together the

system will be optimized. The degree that this is true depends upon the coupling between each of the

elements, subsystems, and components. (2) Elements, subsystems and components themselves are never

truly optimized due to the constraints levied, as well as the trades and balancing acts that must be

accomplished to make the system work.

The compartmentalization process also facilitates the allocation of requirements, etc., and the

definition of tasks. An orderly set of clearly defined discipline tasks must be developed. These tasks can be

discipline specific or multidisciplinary, and they must be timely (their association to the critical path should

be determined). At the system level, design and interface requirements are subsequently allocated to the

design functions, and these allocated requirements lead to metrics for the design function gates. It is most

efficient and effective when the system design function develops the requirements in conjunction with the

other design functions and is then reinforced by the discipline functions.

As illustrated in figure 9, a key aspect of the design process is the re-integration of design results

from the compartmentalized discipline functions, design functions, and subsystems. In the ideal situation

all of the discipline function results are integrated to support the design functions for each subsystem. The

design attributes would be integrated by the system design functions via trade studies with the balancing

act. Then all the subsystems are integrated (assembled) to achieve the launch vehicle assembly. During the

re-integration activities, the major aspects of technical integration are to ensure design attributes satisfy

requirements, constraints, etc.; interface requirements are met; interactions are appropriately accounted;

significant nonlinearities are included; sensitivities, uncertainties, and margins minimized; risks minimized,

mitigated and managed; verification is adequately achieved, all certification requirements defined; flight

and operational constraints minimized; and all issues and concerns resolved and documented.

4.3.2 System Design Function

Shown in figure 29 is the design process technical integration with a focus on the system design

function. The illustration delineates the relationship between the system design function and the other

design functions. In addition, it shows the work/information flow process that is supported by key system

decision gates required to develop and assess the system attributes. The details of all the above are

discussed in this section.

51
System

Aerodynamics

Trajectory/G&N

Control

Structures l

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

T..._. .................

Figure 29. Design process technical integration--system design function.

The launch vehicle process as practiced is sequential. Conceptually, one could "cut and try" to

achieve a design; i.e., build, test, and fix a product until it operates satisfactorily. For launch vehicles,

however, because of the system complexity, challenging performance requirements and environments, the

number and depth of technical disciplines, etc., the design process has evolved sequentially in order to

achieve design efficiency and technical fidelity. For example, as previously discussed, trajectory outputs

are inputs to control analyses, control analyses outputs are inputs to loads, etc.

Note: The systems design function is a process that involves formal technical integration of results

from all the other engineering design function planes supported by the systems engineering discipline. The

goal is to deliver a verified product that satisfies all the system requirements. This report does not describe

the system design process in detail, but provides a top-level overview to show key features as they relate to

the total vehicle design process.

4,3.2.1 System Design Function Plane. The systems design function is the overarching engineering activity that ties together all the other design function results and subsystem interface activities. The

key features of the systems design function along with the associated connectivity are shown in figure 30.

This figure will be referred to as the system plane. The systems design function must ensure that the design

52
conceptbecomesformally integratedasabalancedsystemproductthathasbeenvalidatedto satisfyall the

top-levelsystemandall otherengineeringdesignfunctionrequirementsandconstraints.Top-levelsystems

requirementsandconstraintsaredeveloped,analyzed,tested,balanced,formally integrated,andvalidated

by the systemdesignfunction.All otherdesignfunction requirementsand constraints,in contrast,are

developed,analyzed,tested,balanced,informally integrated,andvalidatedwithin andbetweentheother

designfunctionsandthenformallyintegratedintothesystemsdesignprocess.Mostof thetop-levelsystem

requirementsandconstraintsarederivedfrom thegivenmissionstatement,while othersaredetermined

from experience.The requirementsand constraintsderivedfrom the missionstatementaresomewhat

inflexible. The major top-level systemrequirementsareperformance,cost, schedule,TRL constraints,

reliability, safety,andoperability.

Top-Level

Requirements

andConstraints

System

Architecture

System

Philosophy

Procedures

Criteria

System

ParameterMatrix

andUncertainties

(

System ]

Attributes r

I

]lanceAllocations

(IterateonSystemand

BsignFunctionPlanes)

• Performance

• Cost

• Reliability

• Safety

• Operability

• Schedule

• TRL

System

Analysis

andDefinition

• Performance • Performance

• Cost • Cost

• Reliability • Reliability

• Safety • Safety

• Operability • Operability

• Schedule • Schedule

• TRL • TRL

Figure 30. System design function plane.

Throughout the duration of a project all the requirements and constraints are continuously assessed

and refined. In addition to the requirements and constraints, the project must also develop the system

architecture, certain philosophies, procedures, criteria, and ground rules. The latter are flexible and meant

as guides for the engineering development. Subsequent to the above, the associated system parameter

matrix with associated uncertainties is defined. The system architecture and its associated parameter

matrix with uncertainties are determined in conjunction with all the other engineenng design functions.

The system architecture is then evaluated and refined throughout the design process. The resulting

attribute of performance, associated with the system architecture(s), must meet the requirements,

constraints, philosophies, procedures, criteria, and ground rules. Other types of system analysis (e.g., cost,

53
reliability, etc.) are conducted for the architectural concept(s) to determine those remaining system

attributes. As concepts are being selected (in some situations there can be more than one concept),

requirements relating to the most promising concepts are allocated to all the other engineering design

functions. These allocations include the design specific requirements or metrics for each engineering

design function. Requirements are refined and updated throughout the design process; i.e., from

conceptual design through preliminary and detail design. As the design progresses, the requirements can

change as a result of a top-level change or because of the engineering balancing act.

Throughout the entire design process, the system design function and all other design function

knowledge bases are continually increasing while the uncertainty is decreasing. All the data relating to the

selected architecture(s) are assessed by systems and discipline engineers on the system plane to assure that

all the requirements, constraints, philosophies, procedures, criteria, and ground rules are satisfied. In fact,

the design process is iterated until all requirements are satisfied. In addition to determining and assessing

the system attributes, the systems design function is also responsible for other activities related to the

system. Some of these include risk determination, assessment, and management; requirement allocations,

management, integration, and redistribution; tracking system design performance metrics;

configuration management; etc.

Thus, the process illustrated on each desig-n function plane is iterative, consisting of the following steps:

• Determine requirements and guiding philosophy

• Synthesize a candidate design to meet requirements

• Analyze the candidate design to determine its attributes (performance, cost, reliability, etc.)

• Compare attributes to requirements

• Modify the candidate design if attributes do not meet requirements

• Compare new attributes to requirements

• Continue iterations until design satisfies requirements.

If a design meeting requirements cannot be found, a rebalance or modification of requirements is

necessary, as discussed earlier. Throughout the iterative process, all pertinent interactions with other

design functions are maintained.

In the past the cost of a launch vehicle project usually has not been a serious design consideration;

performance was always the primary design metric. However, in the next generation of launch vehicles,

cost will be one of the most serious design considerations. Bringing cost into the design equation is not

simple in that it must inculcate all the various contributing parameters, including infrastructure,

manufacturing, operations, engineering, etc. These relationships to the design are not all quantified and

must be dealt with using judgments, etc. Obviously, the best approach would be to have cost-estimating

relationships for all the various design parameters. This is not possible since credible cost-estimating

relationships are not available for most of the aforementioned; however, use must be made of those that are

available. For example, cost associated with the design itself can be broken out in terms of engineering

effort (analysis, testing, simulations, etc.), facilities (computational, staff, manufacturing, testing, etc.),

materials, manufacturing, verification, etc. It should be noted that cost is strongly driven by the requirements imposed, whether they be top-level project requirements (e.g., payload, performance, turnaround

time, reliability, etc.), formal discipline-specific criteria, or documentation and traceability requirements.

54
Theseshouldbetightly controlledsincetheycanhavemajorcostimpacts.If theaforementionedwerethe

only costs,thenthejob would befairly tractable;however,thevehicledesignhasa majorimpactoncost

throughoperations.The vehiclecombinedwith the missionrequirementsinteractsin a very complex

mannerwith operations.This canbe saidsinceit is clearthat operationshasto do with receivingthe

vehicle(usuallyby elements),processingandassembling,checkout, launching,communications(voice

and telemetry),maintainability (inspections,refurbishment,etc.), and availability (turnaround).The

vehicledesignandmarginsimpactthelaunchconstraints(allowablewinds,temperatures,etc.),andthe

proceduresfor eachsubsystem.As a result,operationsand sustainingengineeringmanpowercarry a

significantcostimpact,dependingonthevehicle'srobustnessandautonomy.

Designingfor cost, therefore,implies metricsand guidelinesthat effecttrade studiesbetween

operationaldesignandvehicledesign.Theseincludebutarenot limitedto--

• Requirements/criteria

• Robustness/reliability

• Infrastructure(facilities,etc.)

• Manufacturing

• Materials

• Maintenance

• Processing

• Assembly

• Checkoutandverification

• Launchprocedures/constraints

• Communication(voiceandtelemetry)

• Software.

Historical datahelp in formulatingthe cost models;however,cost specialistsmust assistthe

designerin understandingthecostdriversandachievingacost-effectivedesign.Onewarning:Do notdo

the costassessmentat theend.Makeit a partof theup-frontdesignprocess,andtrack it onthe system

plane.

All of theactivitiesassociatedwith theaforementionedareaccomplishedviaformal andinformal

technicalintegrationandorchestratedbythesystemdesignfunction.Thistechnicalintegrationisachieved

with theutilization of IxI andNxN informationflow matricesasdiscussedin section4.3.1andillustrated

in figure 27.Recallthe IxI matricesareassociatedwith informationflow relatedto hardware/software

interfacesandtheNxN matricesareassociatedwith informationflow relatedto thedesignanddiscipline

functions.Thespecificdetailsassociatedwith bothof thesetypesof matricesarediscussedbelow.

4.3.2.1.1IxI Matrices.Figure27illustratestwotypesof informationflow matricesthathelpinthe

characterizationof the designprocess.On the lower left is shownanIxI matrix correspondingto the

subsystemtree.IxI matricesrepresentinformationflow associatedwith thesubsystemtreeinterfaces.An

exampleexpansionof anIxI matrixis shownin figure31.It representsinterfaceinformationflow for the

launchvehicleandits nexttier of subsystems. Thelaunchvehicleis shownintheupperleft block,with its

nexttier subsystemson theremainderof thediagonal.Elementson thehorizontalrows containoutputs

from theentity onthediagonal,andelementsontheverticalcolumnscontaininputsto theentityon the

diagonal.

55
The first diagonal element contains the system (or subsystem) for which the I×I matrix is constructed. The remaining diagonal elements are the subsystems (or sub-subsystems) in the next lower tier of

the tree. Along the top row are the interface requirements imposed by the system on its subsystems. The far

left column then feeds back the description of the as-designed subsystem interface to the system; i.e., what

the subsystem design has accomplished in response to the interface requirements from above.

Ct.

Z

Inleractions Among Hardware Elements

OUTPUTS

iiiiiiii!i_iii_iiii!ili_iiii!iiiiiiiiiiiiiii

Structures

!_:_ Thermal

ii! ill

i ̧'ii !i i

_ .SyStems

i_!!_iiii!_i_!_iiii_i_:_i_ii_i_i_i_!_ii_ii_i!!_i_ii!_

i_iiii_ii!ii!i_i_i_iii!_ii_i!i_i_!_i_iiiii_i_'

Figure 31. I×I matrix for launch vehicle.

The remaining off-diagonal elements contain interface requirements and interface descriptions

among peer subsystems along the common tier. Note that the information flow between any two entities

takes a clockwise path on the matrix. In the case of peer subsystems, there are two concurrent interface

information flows occurring (represented by two shades on the inset blocks). One involves interface

requirements of subsystem A on subsystem B, along with B's interface description fed back to A. The

other flow involves requirements of B on A, along with A's interface description fed back to B.

56
Note that there are numerous I×I matrices. There is an IxI matrix associated with each system or

subsystem that is divided into lower tier entities on the tree. Thus there is an I×I matrix for each subsystem

as we proceed down the tree to its next-to-last tiers. The parts on the last tiers of the tree are sufficiently

simple that no further subdivision is required. These parts are simple enough to be designed by an

individual designer, using handbooks, standards, etc. These last-tier parts appear on the lower diagonal of

I×I matrices, but they do not have their own I×I matrices where they would appear in the upper left element

of the matrix.

4.3.2.1.2 NxN Matrices. On the lower right of figure 27 is shown an NxN matrix corresponding to

the stack of design function planes and the discipline function activities resident on the planes. NxN matrices

represent information flow among the design functions and the discipline functions. An example NxN

matrix is shown in figure 32. The example in this case is the launch vehicle system with its associated

design functions and disciplines. Note that the launch vehicle system plane is represented by the upper left

element of the matrix, and the remaining lower design function planes are represented on other diagonal

elements.

NxN Matrix for Launch Vehicle

................ Cost_eliabilityfOperability/Safety/OthePilities 1

OUTPUTS

t

_rli b _il .... __ AlloCate; Requirements. Architecture. Philosophy F'_ _--";_ :

i_e;'_' _:_ : .......... ............

Attributes 2:0.2 ............

to System Aero ............

220,3

.. Example Matrix Entry TrajeCtory/

G&N • Ascent Aero Heating Histories

, ,,,,,

Launch Vehicle Systems 2.0.4 ° Entry Aero Heating Histories

Design unclions Control _ • Compartment Flow Rates

• Plume Heating Environments

_ .0.1 Launch Vehicle System 2.0.2 Aerodynamics _ Structures

,,,, ,,, ,, ,,

2.-_--3.3rrajectory/G&N _ 2_0.6

J' 2.0.4 Control / Thermal

,,, .,i

2.0.5 Struclures _ 2_0.7

_" 2.0.6 Thermal _ Prop

2.0.7 Propulsion / 2:0.8 Avionics

t- 2.0.0A,i;nics / ...........

L/ 2.0.9 Materials ./,I' Materials 2;0,9

L/ 2.0.10 Manufacturing y

L," 2.( .11 Other ,,,,,7

2010

Ma,u!act,ring

r

Figure 32. NxN matrix for launch vehicle.

57
The input-outputpatternislike thatof theIxI matrix;i.e.,outputsof adiagonalelementareonits

horizontalrow,andinputsto theelementareonitsverticalcolumn.Thus,theentriesinthefirst rowarethe

outputsfrom thelaunchvehiclesystemplane(allocationsof requirements,architecture,andphilosophy)

thatareinputsto thelowerdesignfunctionplanes.Thisis theinformationthatflowsdowntherespective

conduitsof thestack.Theentriesinthefirst columnaretheoutputsfrom thelowerdesignfunctionplanes

(attributes)thatareinputsbackto thelaunchvehiclesystemplane.Thisistheinformationthatflowsupthe

attributeconduitof the stack.Theremainingoff-diagonalelementscontaininformationflow amongthe

lowerdesignfunctionplanes,asrepresentedbytheroundverticalconduitof thestack.An exampleentryis

shownfor theoutputfrom aerodynamicsthat is inputto thermal.

Thereis anNxN matrix associatedwith eachdesignfunction stack.Thus,therearemanyN×N

matricessincethereis a designfunction stackfor everyelementon the subsystemtreewhosedesign

involvesmultipledesignfunctionactivities.

An exampleof arelatedNxN matrixfrom reference2 is givenin Appendix A.

Inclusion of IxI matrices and NxN matrices with the subsystem tree and design function stacks

provides locations or placeholders for the technical information that must flow among the participants in

the design process. This characterization also suggests a framework for an electronic information and

communication system to enable efficient and concurrent interactions throughout the process

(see section 5.2.4).

4.3.2.2 System Gates. The decision gates for the system design function are shown in figure 33.

The inputs to the system design process are the mission requirements, constraints, and system philosophy.

The outputs are the system description, attributes, and operations plan. There must be a proper balance

among the requirements, constraints, vehicle design and associated attributes, and the operational plan.

The system gates are the locations in the project where the system attributes of performance, cost, reliability, safety, schedule, operability, failure modes, and TRL are compared to the requirements,

constraints, philosophies, procedures, criteria, and ground rules. If the comparisons are favorable

(i.e., yes), then the design process is completed. On the other hand, if the comparisons are unfavorable

(i.e., no), then there must be another design iteration. This process is repeated until the design is balanced

with the attributes satisfying the requirements, constraints, etc.

58
Yes

:No

S_stem Design

Modify Design

• System Description

and Attributes

• Balance BetweenAttributes

and Requirements

• OPS Plan "How to Fly"

No

• Mission

Requirements

and Constraints ".

• System ". No '

Philosophy Yes

Figure 33. System design function gates.

Yes

The systems design function must provide the project overview to achieve and enforce proper

balance. The balance can be accomplished by modifying the design, operations plan, requirements, constraints, philosophies, procedures, criteria, and ground rules. This is achieved through formal technical

integration between and among the system and other design function planes. To achieve balance, all the

results (i.e., attributes) are analyzed and assessed through informal technical integration on the system

plane. If balance is achieved, the design is completed. System design and integration are completed when

the attributes of performance, cost, reliability, safety, schedule, operability, and TRL satisfy the project

levied requirements, constraints, philosophies, procedures, criteria, and ground rules. If balance is not

achieved, the conflict must be resolved by modifying the vehicle design, requirements, constraints, operational plan, or other influencing factors. The process is iterated until balance is achieved. The final major

outputs of the system design and integration process are the following: (I) Description of system with

attributes, (2) balance between attributes and overall requirements, and (3) operational process of how to

fly the vehicle. The formal and informal integration are a continual process in the design project, and

results are documented at major reviews.

4.3.2.3 System Design Tasks. The definition of vehicle design tasks associated with the activities

of the system design function begins with the definition of the mission statement. After the

compartmentalization activity, the principals of the system design function, all the other design functions,

and discipline organizations delineate all the major vehicle design tasks. The tasks associated with the

system design function can be categorized into five major groups that are as follows: (1) Develop engineering design activity plan; (2) analyze, allocate, and manage subsystems and requirements;

(3) perform system analysis; (4) integrate for balanced design product; and (5) verify system design. The

specific tasks associated with the aforementioned major groups as shown in table 1 are discussed below.

59
Table 1. System design function tasks.

Activities Interactions Tasks

1.Engineering design

activity plan

2.Allocation and

management of

subsystems and

requirements

3. System analysis

4. Integration for balanced

design product

5.Verification

Program office

Designfunctions

Discipline functions

Design functions

Discipline functions

Designfunctions

Discipline functions

Designfunctions

Discipline functions

Designfunctions

Discipline functions

1. Developthe engineering organizational structure.

2. Establishformal and informal communications process.

3. Developschedule of engineering activities with associated

deliverable products.

4. Establish WBS.

5. Document and disseminate plan; include mission statement.

1. Consult with project office to establish top-level system

requirements, philosophies, and constraints.

2. Assess and compartmentalize systems into subsystems and

elements.

3. Determine and allocate performance, cost, reliability, operability,

schedule, and TRL requirements to design functions.

4. Acquire and formally allocate discipline criteria.

5. Document and disseminate all requirements.

1. During concept selection phase, define concepts; apply sizing

program to evaluateand refine concepts; determine sensitivities;

and identify new technologies required for each concept.

2. Developsystem parameter matrices and associated uncertainties.

3. Determinesystem derived requirements and impose discipline

derived requirements.

4. Determinesystem attributes from systems analyses.

5. Assess configuration and subsystems to verify conformance to

all requirements.

6. Establishfailure modes and perform a risk assessment.

7. Continueanalyses throughout the project duration.

8. Document and disseminate results.

1. Formally integrate and balancethe various design function

attributes to satisfy all systems requirements and discipline criteria

2. Manageconflict among discipline functions and between design

functions to resolve all issues.

3. Perform trade studies as required.

4. Manageinterfaces and changes.

i5. Document and disseminate results.

1. Develop verification plan (analysis and ground/flight tests).

2. Audit verification process.

3. Correct anomalies.

4. Document results.

5. Validatesystem during developmental flight tests.

6. Implement operational plan compatible with the verified system.

7. Document and disseminateverification plans, corrective actions,

and operational plans and procedures.

4.3.2.3.1 Task lmEngineering Design Activity Plan. Initially the type of organizational structure

must be determined. The various types are delineated in section 4.1. Subsequently, the details of the formal

and informal communication process are set up consistent with the organizational structure selected. This

includes the chain of command, electronic communication system and control, formal data reporting,

security, and others. Then based upon the compartmentalization, a WBS system must be developed with

6O
associated tasks to support the activities of all the engineering design functions. These WBS designations

are then implemented to develop an electronic schedule of engineering activities and the associated

deliverable products. An important feature of the schedule is the critical path along with associated uncertainty. When the above is completed, the plan should be documented and disseminated.

4.3.2.3.2 Task 2 Allocation and Management of Subsystems and Requirements. A major focus of the

system plane relates to understanding the mission statement and then developing the top-level

requirements, constraints, and architecture philosophies. This activity is important and continues throughout the

duration of the design process with the _eatest intensity initially. The significance of the top-level requirements

as they relate to the mission statement and to the vehicle design and operation must be determined by considering nominal conditions in addition to sensitivity and uncertainty analysis. These data will be applied to assess

potential impacts from trade-study results. Usually, the top-level requirements are invariant; however, they can

be changed if there is cause and there is not a significant compromise to the mission statement.

The system is then assessed in order to compartmentalize it into appropriate subsystems and design

functions. Then the system plane in conjunction with the other design planes determines the performance,

cost, reliability, safety, operability, and TRL constraints that are to be allocated by the system plane to the

other design planes. The system plane must also acquire discipline specific criteria for formal allocation.

All these data are then documented and disseminated. Throughout the process, the system plane manages

the configuration evolution so that the activities of the various design functions are coordinated. After

preliminary design, a baseline is established, and all data are under formal configuration control.

4.3.2.3.3 Task 3--System Analyses. The system analysis pertains to determining performance,

cost, reliability, safety, schedule, operability, and TRL design attribute values for the total system along

with formal technical integration to resolve conflict in order to achieve a balanced system design. Initially,

architectural concepts along with parameter matrices and their uncertainties are determined and then, by

applying the sizing program, the concepts are assessed. Trade studies and sensitivity analyses are performed

and the concepts are refined to achieve the performance requirements restricted to the constraints and

program guidelines. The refined concepts may require new technologies; thus, these must be determined

and evaluated. The number of new technologies required to achieve a concept then becomes a factor in the

concept selection. As the refined concepts begin to converge, the system parameter matrices and associated

uncertainties are matured. Then by applying those input data, systems analyses are conducted to determine

the remaining system attributes; i.e., cost, reliability, schedule, and operability along with their uncertainties.

Then all these results are applied to assess the architectural concept's attributes in regard to conformance

with all the requirements, constraints, guidelines, etc. The results are eventually applied in a decision

model to numerically rank the architectural concepts to aid in the concept selection.

After the number of concepts has been narrowed down, risk analyses are performed. The major

focus of these analyses is technical, cost, and schedule risk. The failure modes are established as part of the

technical risk analysis.

The total system analyses delineated above are continued, and the system attributes refined throughout

the design process. The other design functions provide attributes of their subsystems as input to the total

system analyses. The objective of the analyses is to improve the quality of the values of the attributes and

reduce the uncertainties. These data are applied as technical performance parameters that are used to track

61
theprogressof the design and to make numerous decisions throughout the design process. These results are

documented, controlled, and disseminated by the systems design function.

4.3.2.3.4 Task 4--Integration for Balanced Design Product. The system plane facilitates informal

and formal technical integration to achieve a balanced design product. The informal integration pertains to

the technical integration on the system plane to attain balance among the system attributes. The formal

technical integration is between all the design planes and the system plane. The focus of the integration is

to obtain a balance of the attributes among the design functions to satisfy all the requirements, constraints,

and discipline criteria. To achieve balance, sometimes it is required to manage conflict among design

functions and between disciplines to resolve issues that cannot be resolved through informal integration.

This may require a multiplicity of changes. The system plane must control and manage all changes as the

conflict is being resolved. In addition, it must also control and manage all system interfaces. These interfaces may or may not be part of the conflict resolution. All these data must be documented, controlled, and

disseminated by the system plane.

4.3.2.3.5 Task 5--Verification. The system verification activity is the responsibility of the system

design function, and it is supported by all of the other design functions and the discipline functions. Initially, verification plans are developed. The verification can be accomplished by analyses, simulation, or

test (ground/flight). It is then the responsibility of the system plane to audit the verification process. This

is usually accomplished with the other design functions and discipline functions. When anomalies are

discovered, corrective action is required. The corrective action can be accomplished by redesign or by

requirement changes. The corrective action must be subsequently verified. The results of these activities

must be documented and disseminated.

The final verification is obtained from developmental flight tests. If significant anomalies occur,

then a corrective redesign is required or an operational constraint is place on the system. These corrective

changes are required to be verified. All of these results are required to be documented and disseminated.

4.3.3 Aerodynamic Design Function

The connection between the design process technical integration and the aerodynamic design function is delineated in figure 34. This illustration depicts the relationship between the aerodynamic design

function and the other design functions. In addition, it shows the work/information flow process that

is supported by key aerodynamic decision gates that are required to develop and assess the

aerodynamic attributes. The details of all the above are delineated in this section.

62
AERODYNAMICS

System

Aerodynamics

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

Figure 34. Design process technical integration--aerodynamic design function.

4.3.3.1 Aerodynamic Design Function Plane. This discussion describes the features of the

aerodynamic design function delineated in figure 34 and its connection to the stack in figure 26. The

aerodynamic design function interacts through informal integration mainly with the trajectory/G&N, structures, thermal, and control design functions. However, the aerodynamic requirements and constraints are

allocated through formal integration with the system design function (see fig. 26 and 35). These requirements and constraints include the aerodynamic configuration, cost, schedule, etc. They are assessed with

established aerodynamic procedures, criteria, and methods. Subsequently, the aerodynamic design process

is initiated where analytic, empirical, numerical (CFD), and test methods are applied to determine the

significant aerodynamic parameters and associated uncertainties. Initially, the aerodynamic force and

moment coefficients are determined. They are used in the sizing/trajectory program and are continually

refined and updated throughout the design process to support system performance analysis. The steady

aerodynamic environments are the basis from which localized loads and compartment venting pressures

are determined. The unsteady aerodynamic environments consist of determining aeroelastic stability,

acoustics, overpressure, ground winds, and buffet design parameters. The aerodynamic heating environment consists mainly of the radiation heat flux from the engine plumes and the convective heat transfer

from the external flow over the launch vehicle during ascent and reentry. The plume electron profiles must

also be determined. All the aerodynamic parameters and their uncertainties are implemented into the

63
design process in an iterative manner until there is convergence with the requirements and constraints

allocated from the system plane. In some situations the allocated aerodynamic requirements and

constraints are modified to achieve overall balance. This can occur when all other disciplines are formally

integrated by the system plane or when the physics of the situation dictates. Eventually, the aerodynamic

design attributes must satisfy the requirements and constraints. This is delineated with the gate shown in

figure 35. Finally, the aerodynamic parameters and their uncertainties are verified in flight experiments.

U U Aerodynamic

Aerodynamics Aerodynamic Procedures

Requirements Configuration Criteria

and Constraints Approach

Yes ,_/'N_....._ No

(Stop) T (Iterate)

I Aero Attributes

I ° Stability

• Force/Moment Coefficients

• Environments

___ Aerodynamic

Design

• Analysis

• Test

Aerodynamic

ForceCoefficients

Moment Coefficients

Aerodynamic

Environment

• LocalizedLoads

• Venting

Unsteady Aero

• Aeroelasticity

• Acoustics

• Overpressure

• Buffet

Aerodynamic

Heating

Special Analyses

and Tests

H

Informal _ _

Integration 5

Aerodynamic

Parameter Matrix

and Uncertainties

Figure 35. Aerodynamic design function plane.

The aerodynamics parameters and induced environments design process flow diagram from

reference 2 is shown in figure 36. It can be seen that there is a direct correlation with figure 35. The focus

of aerodynamics design function shown in figure 35 is to illustrate formal and informal technical

integration, requirements and constraints, procedures and criteria, parameter matrix and associated uncertainties, major design functions that are accomplished by the aerodynamic discipline along with associated

connectivity, and the output design attributes. The focus of the aerodynamic design process shown in figure

36 is the aerodynamic discipline activities along with the corresponding requirements, inputs, outputs,

connectivity, and products. The NxN diagram of reference 2 (Appendix A) is representative of further

delineation of the inputs and outputs associated with the aerodynamic design process.

64
i .Requi,oment, k

Program/Project L

• Concepts _ "

• Constraints

Inputs (One-Way)

• Natural Environments

• Mass Properties

• Light Operations

Outputs (One-way)

• Communication and Data

Handling

• Electrical Power

• Guidance and Controls

Inputs/Outputs (Two-Way)

• Vehicle Configuration

and Structural Design

• Performance and Trajectories

Structural Analysis

• Thermal

• Propulsion

• Materials

• Safety

• Reliability

• Cost

Aerodynamics

Ascent Aerodynamics

External Pressure

Protuberance Airloads

Aero Coefficients

Stability Derivatives

Entry Aerodynamics

Prelaunch Wind Effects

Breakup/Disposal Analysis

Acoustics/Overpressure N

Launch Overpressure B

Ascent Acoustics E

Entry Acoustics 1

(GenericActivities)

r

Hazards

;ost/Makeor f

_uy IL

Aaterials/

>artsList

Aerothermodynamlcs

Ascent Aeroheating

Ascent Plume Heating

Entry Aeroheating

Aerothermal Test

Requirements

_ Trajectory Constraints

for Heating

Plume (Electron) Profiles

.Ventino -- b

• Vent Location and Sizing |

• Compartment Pressures _

• Compa_rt_nt How Rates _

IParachute Analysis l

System Requirements

_nefits Reliability Operability I Maintainability

;ourcesRequirement.,Test Software(S/W)_Server

ization RequirementsjAIgorithrnsI Needs

:hnical Sizing/ Conceptual

scriptions Confgurat on Sketches/Layouts

Products

Aerodynamics

Acoustics/Overpressure

Venting

Ascent Aeroheating

Base Heating

Entry Heating

Plume Effects

Launch Stand Effects

Parachute Design/

Requirements

Figure 36. WBS 2.3--aerodynamics and induced environments. 2

These inputs/outputs show the correlation with other design functions, and they represent the

product flow of figure 26. The corresponding tasks are shown in table 2. These tasks are related to accomp|ishing specific aerodynamic design objectives. The tasks associated with figure 35 are the allocation of

requirements, aerodynamic design, and verification. These tasks are further discussed in section 4.3.3.3.

65
Table 2. WBS 2.3--aerodynamics and induced environments task description. 2

Inputs Tasks Outpuls

• Projected ground rules and goals

• Launch pad geometry

,.Preliminary design out emold line

• Ground and ascent wind profiles

-Atmosphericmodels

• Launch stand ambient temperatures

•Protuberance geometry

•Engine placementgeometry

•Ascent trajectory sets (altitude,

velocity, c_,15histories)

and engine operatingconditions

•Entry trajectories

•..Airflow history to inlet

•Trajectory constraints

--Mach transitions

•Structural deflections

•Heatingconstraints

-Wall/surface temperatures

•Control weights, centers of gravity

•Engine dimensional and operational

characteristics

•Turbine exhaust definition

•On-pad effluent definition

•-,,Rocket basedcombined launch

(RBCC)exhaustconditions

--Forebody inlet performance

requirements

•..Transition roach number

•Vehicle integrated OPSconcept

and requirements

•Hazard analysis

•Failure mode effects analysisinputs

--CIL inputs

3.4.1 Aerodesign consultation

3,4.2 Generateascent aerodynamics

3.4.3 Generateexternal pressure distributions

3.4,4 Generateprotuberanceairloads

3.4.5 Generateaero coefficients

3.4.6 Generateaero stability derivatives

3.4.7 Generatevehicle/stage entry aerodynamics

3.4.8 Determinevent size and location requirements

3.4.9 Determinecompartment pressures

3.4.10 Calculatecompartment flow rates

3.4.11 Generateascent aeroheating histories

3.4.12 Generateascent plume heating histories

3.4.13 Generateentry heating histories

3.4.14 Determineaerothermal test requirements

3.4.15 Specify trajectory constraints for heating

3.4.16 Generatelaunch overpressure environments

3.4.17 Generateascent acoustics environments

3.4.18 Generateentry acoustics environments

3.4.19 Determineprelaunch wind effects

3.4.20 Determineparachute system requirements

3.4.21 Perform breakup/disposalanalysis

3.4.22 Generateplume electron profiles

Tools:

• Computer codes: CEC/-IRAN72,SPF/2,StRRM,RAMP2,

RAVFAC,BLIMPJ, MOC,SPP, LANMIN,MINIVER,Various

CFDcodes, etc.

• Wind tunnel data

• Historical ground and flight test data base

• Pressure ventsizes and locations

• Moldline update including airframe/

engine design

• Vehicleascent aerodynamics

•Heatingindicators

-Vehicle/stageentry aerodynamics

• Engine inlet flowfield definition

• Externalaerodynamicpressure

distributions

•Compartment pressures

•Protuberance airloads

•Acoustic/overpressuredefinition

•Fluiddynamic loads (buffering)

•Ascentaero heating histories

•Entry aero heating histories

•Compartmentflow rates

•Plume heating environments

•Guidanceand control

instrumentation locations

•Airloads on propulsion elements

--Engine installed thrust

--Forebody pressure recovery

and flow field history

•Aerothermaltest requirements

•Plume electron profiles

•Ascent and descentpressure

distributions

•Heatingand pressure

instrumentation requirements

•Sonic boom overpressure

•Test requirements to include

instrumentation

Key: • ELV,reusablelaunch vehicle(RLV),and RBCC

•. RLVand RBCC

-- RBCConly

4.3.3.2 Aerodynamic Gates. The decision gates associated with the aerodynamic design function

are shown in figure 37. It can be seen that the inputs are from the system plane and the aerodynamic

discipline, plus there are interactions from other design functions. The outputs are the aerodynamic design

attributes, and they must satisfy the system requirements on the aerodynamic design function plane. This is

shown with the gate in figure 35. The decision gates shown in figure 37 relate to specific aerodynamic

design needs and requirements; e.g., force and moment coefficients, acoustics, heating, etc. The data

related to each gate are determined by aerodynamic designers via discipline analyses and testing. During

this process, the aerodynamic designer must also be aware of the overall system requirements of cost,

reliability, TRL, etc. The aforementioned data are the aerodynamic parameters and induced environments.

Each of these quantities is determined in an iterative fashion. As the aerodynamic configuration begins to

converge, metrics for the various gates also converge. The metrics are determined through formal technical

integration of all the relevant design functions. These metrics then become the design targets or requirements for the aerodynamic designer. As the design proceeds, some of the metrics may change because of

unforeseen impacts. This can result in another design subiteration. When all the gates are satisfied, the

aerodynamic design is complete. The aerodynamic design is finally validated with data obtained from

flight experiments. Operational constraints or a delta redesign may be required if the flight data indicate a

serious operational impact.

66
__--{ Buffeting

t...N, o..............,,.

Venting _._

Localized and

I

_[.No Loads

Overpressure

|

L.No.................

Yes

'No

| .... •

i

m

AeroelasticityI

I Aerodynamic Analysis

Aerodynamic

Testing

AerodynamicDesign

- Configuration

- Stability

- ForceandMomentCoefficients

- Environments

Forceand I

Moment i --

I /\ Yes

Coefficients_

andPressureI ,Y

Distributions] No

AeroRequirements

andConstraints

Configuration

AeroPhilosophy

Yes

Heating Aero I

Figure 37. Aerodynamic design function gates.

4.3.3.3 Aerodynamic Design Tasks. The aerodynamic design function begins with the determination

of the aerodynamic forces and moments to be used in the trajectory analysis and with the determination of

the acoustic and blast overpressure environments to be used for environmental impact assessment. As the

design matures, more and different aerodynamic parameters are needed for other aspects of launch vehicle

design (see fig. 35). These parameters and their uncertainties are determined in an iterative fashion through

the design process and continually matured. A summary of the aerodynamic tasks is shown in table 3.

4.3.3.3.1 Task l--Requirements Determination and Allocation. This activity is accomplished by

the aerodynamics design function with the support of the system design function and other design functions

and disciplines as shown in table 3. In addition to performance, the overall vehicle aerodynamic configuration is determined from many factors, with cost and operational considerations being significant. The

aerodynamic design procedures and approaches are then established along with various design criteria.

Specific metrics are determined for the decision gates. These metrics can change as more knowledge is

acquired about the configuration and when additional constraints evolve from other design functions.

Eventually, the metrics converge, and they become the targets for the aerodynamic designer. At this point

the metrics are maintained at the system level and are under configuration control. Initially the technical

integration is formal, but as the vehicle design advances, it becomes predominately informal until the

aerodynamic attributes satisfy the requirements. These final attributes flow upwards to the system plane;

i.e., formal integration. There are some aerodynamic parameters that are not allocated. The configuration

and the associated physics (e.g., plume radiation heating, ignition overpressure, and others) determine these

parameters.

67
Table3.Primarytasksfor aerodynamicdesignfunction.

Activities Interactions Tasks

1. Requirements

determinationand

allocation

2. Aerodynamicdesign

3.Verification

System

Control

Trajectories

Propulsion

Structures

Thermal

Naturalenvironment

System

Control

Trajectories

Propulsion

Structures

Thermal

Naturalenvironment

System

Control

Trajectories

Propulsion

Structures

Thermal

Naturalenvironment

1. Acquireallocatedrequirementsand constraintsfrom system

andinteract,formally andinformally,through allocationprocess.

2. Obtaindefinitionof configuration.

3. Establishprocedures,criteria, andapproaches.

4. Setupdisciplinespecificcriteriaas the metrics for decisiongates.

5. Communicatethrough formal andinformal integrationprocess.

1. Developaerodynamicmodelsto determineforceand moment

coefficientsandsteadyaeroenvironments.

2. Developmodelsto determineunsteadyaerodynamicand heating

environments.

3. Establishall input dataanddetermineaerodynamicdesign.

- Provideaeroparametermatrixand uncertainties.

4. Communicatewith interactingdisciplinesto resolveunacceptable

conditions.Resolveinformally if possible.

5. Formallyintegrateaeroattributes.

6. Documentattributes.

1.Performaerodynamicteststo verify forceand moment

coefficientsand steadyaeroenvironments.

2. Performspecialitytests to verify unsteadyaerodynamic

andheatingenvironments.

3. Updateall input dataand refineaerodynamicdesigndata base

using test data.

- Refineaero parametermatrix and uncertainties.

4. Communicatewith interactingdisciplinesto resolve

unacceptableconditions.Resolveinformally if possible.

5. Formallyintegrateaeroattributes.

6. Updatedocumentedattributes.

7. Validateaerodynamicdesigndatabaseduring developmental

flight tests.

4.3.3.3.2 Task 2--Aerodynamic Design. The aerodynamic design is accomplished by the

aerodesigner with continuous formal and informal technical integration interactions with the appropriate

groups as shown in table 3. Initially, all of the steady, unsteady, and heating aerodynamic parameters and

their uncertainties are determined empirically from databases. Usually the estimates of all these quantities

are conservative. As the configuration converges, more accurate determinations of the parameters are

achieved via mathematical/numerical modeling and wind tunnel testing. The formal and informal

technical integration continues in order to ensure that the aerodynamic attributes do not cause conflict or

adversely affect the attributes of the other design functions. All unacceptable conditions are required to be

resolved. After resolution is achieved, the aerodynamic attributes are formally integrated with the system

design function. Finally, the significant aerodynamic features and the aerodynamic attributes are

documented.

68
4.3.3.3.3 Task 3--Verification. In order to ensure that all requirements and constraints are

addressed, the verification activity is achieved with full cognizance of the appropriate groups as shown in

table 3. Tests of the final (flight) configuration are accomplished to validate the already published

aerodynamic parameters and determine the uncertainty associated with those parameters. Tests are also

accomplished to determine parameters that are questionable and where the associated uncertainty is

unknown.

After all testing is completed, the aerodynamic attributes (i.e., parameter matrix and associated

uncertainties) are reassessed and refined. Then those results are informally integrated with the appropriate

design functions. Subsequently, the results are formally submitted to the systems design function for final

assessments and documentation. If there is conflict, it must be resolved at the system level. This could

lead to a redesign or to an operational constraint. When all of the aforementioned is completed, the

aerodynamic design database is augmented with all the newly acquired configuration dependent data.

The final validation is achieved during the developmental flight-test phase of the program. The

flight-test data are compared to the aerodynamic attributes that are documented by the systems design

function. If serious differences occur, there must be a redesign or an operational constraint must be enforced.

The tasks delineated in table 2 from reference 2 correspond to the discipline specific tasks

associated with the aerodynamic design function. A comparison to table 3 indicates that the tasks are

complementary. It can be seen from table 3 that the emphasis is associated with allocation of requirements,

aerodynamic design, and verification; and these are design function specific activities.

69
TRAJECTORY/G&N

System

Aerodynamics

4 Control

Structures

4 Thermal

Propulsion

4 Avionics

4 Materials

Manufacturing

Other

Figure 38. Design process technical integration--trajectory/G&N design functions.

4.3.4 Trajectory/G&N Design Functions

The connection between the design process technical integration and the trajectory/G&N design

functions are delineated in figure 38. The illustration depicts the relationship between the trajectory/G&N

design functions and the other subsystem design functions. In addition, it shows the work/information flow

processes that are supported by key trajectory/G&N decision gates that are required to develop and assess

the trajectory/G&N attributes. The details of all the above are delineated in this section.

4.3.4.1 Trajectory/G&N Design Function Plane. The trajectory/G&N disciplines closely

interact, and their design functions are shown together in figure 39. Trajectory design in this description

encompasses payload performance and includes the design activity that determines what basic vehicle

mass and propulsion characteristics are needed to achieve the desired pounds to orbit. The fundamental

performance requirements are payloads to specified orbital targets to which are added vehicle constraints

such as limits on acceleration, loads, thermal, dynamic pressure (flutter), etc. The additional complication

of abort targets, separation targets, or reentry/recovery targets must be included as intermediate points on

the trajectory if the system requires them. An initial definition is made of the trajectory and guidance

70
approach, and the philosophy and pertinent parameters, including their uncertainties, are identified.

Trajectory optimization programs are used to determine trajectories that optimize the appropriate objective

function and constraints. Initially, this is done deterministically with simplified models to establish basic

feasibility, then with increasing fidelity, incorporating appropriate parameter uncertainties. Moment

balance constraints are included for asymmetrical configurations. In early conceptual design, trajectory

determination uses simplified representations of propulsion, aerodynamics, mass, winds, and air density.

Requirements

and Constraints

I es.j .o

_ (Stop) . (Iterate)

Ves .o l

(Stop) y (lterate)l

Trajectory Attributes

• Payload

• LoadIndicators

• ThermalIndicators

• TrajectoryCharacteristics

Trajectory/

Guidance

Definition

Informal '_

ntegration ;:

i [TrajectorylGuidance[

I Trajectory Inputs [ [ Philosophy [ I

[[ Criteria [ [Trajectory/Guidance [ [ Special Constraints

[_'1 Procedures _ Parameter Matrix _ •Thermal

[ " [,Flutter

[] Approaches [ [ and Uncertainties I I" Loads

I I • Other (Separation)

Trajectory ._

Determination

• Constraintsand

Requirements

G&N System Attributes

• Sensor Requirements

• Computer Requirement

Accuracy (Errors)

• Cost Factors

• Reliability Factors

• Complexity

i Trajectory Design ]

• Payload

• Design Ref. Trajectory

: Flight Per. Reserve

• Separation Char.

Throttlin_ Profile

Algorithms ,_

Sensor Requirements

• Error Budgets

* t

G&N System Performance

Error Definition [

Figure 39. Trajectory/G&N design function plane.

Achieving desired payload to orbit with adequate performance reserves usually requires iteration

of vehicle parameters with the system. The trajectory definition, constraints, and system parameters are

iterated until the attributes are satisfactory. As the vehicle design process proceeds, trajectory design

follows the successive refinement approach experienced by the other design functions and subsystems.

It uses improved definitions of the vehicle and environment models to define trajectories (time histories of

flight mechanics variables), performance, and performance reserves to higher fidelity. Both nominal

trajectories and dispersed design trajectories are developed; the latter represent time-consistent trajectories

that produce maximum expected values of certain variables such as loads or aerodynamic heating.

Analysis using dispersions also produces performance sensitivities (partial derivatives), flight performance

reserves, and fuel bias definition.

71
TheperformanceandtrajectoriesprocessflowdiagramandWBS task chart from reference 2 are reproduced in figure 40 and table 4, respectively. The process flow is consistent with the flow diagram of figure 39,

with the former emphasizing inputs/outputs and connectivity, and the latter emphasizing the iterative comparison of requirements and attributes to achieve convergence. Outputs are indicated for payload performance and

trajectory time histories, both nominal and dispersed. The NxN diagram of reference 2 (Appendix A) is representative of further delineation of the inputs and outputs associated with the performance and trajectories design

function process. The tasks given on the WBS chart are expanded in more detail in section 4.3.4.3.

Requirements _[ I

• Program/Project _ I

• Mission Requirements _-Vl

• Constraints _._,_ I

Inputs (One-Way)

• Natural Environments

• Cost

Outp(as(One-Way/

• Ground Operations

Inpuls/Outputs (TwoWay)

• Vehicle Configuration

and Structural Design

• Aerodynamics and Induced

Environments

• Structural Analysis

• Thermal

• Guidance and Control

• Mass Properties

• Propulsion

• Communications and Data

Handling

• Flight Operations

• Safety

• Reliability

Internal Flow

I • Reference • Flight Performance

• Trajectories (Payload Capability)

• Flight profiles

• Vehicle Partial

• Derivatives

Inlet Trade

Versus Thrust/

Performance

• Design

Traiectories

FuelBias

Time Histories

- Acceleration

- Aeroheating

Indicators

- Attitude/Velocity

Attitude

Dynamic Pressure

_tVersus Inlet Size

(Effective)

Hazards

3ost/Makeol

Buy

Materials/

PartsList

Benefits Reliability I (_perabilityI Maintainabifity

Resource.,RequirementsTest S/W Server

UtilizationFeedback Requrements Algorithms Needs

Technical [ Sizing/ Conceptual

DescriptionsI Configuration Sketches/Layouts

ReferenceTrajectories

Design Trajectories

Vehicle Partials

Dispersions

Performance

Time Histories

Contingency Analysis*

Operational Trajectory

Flight Evaluation Best

Traiectory

• Range Safety

• Guidance or Onboard

Computer (OBC)

Presetting

* FailureAnalysis

Engine Axis

Gyroscope/Accelerator

Failure

>3(_

Flight performance

Reserve(FPR)

CZcritical RBCC Shutdowr

Document: Amount of air

captured Ispeffective Iso

engine drag loss (lipspill

age) and parasitic drag

and smooth body drag

losses for RAM/SCRAM

Figure 40. WBS 2.2--performance and trajectories design process flow diagram. 2

The G&N system design follows a pattern more similar to other design functions in that a tentative

G&N configuration is hypothesized and then analyzed to determine its performance. In specifying sensor

and algorithm requirements, close coordination is maintained with avionics specialists to obtain adequate

performance at acceptable cost and complexity. Uncertainties (errors) determined from the analysis are fed

back to the trajectory analysis as inputs to margin and reserve determination. The tentative G&N system is

iterated until its attributes satisfactorily meet requirements, or else requirements relief is sought from the

system plane. G&N system analysis and design activities shown in figure 39 are combined with the control

system activities in reference 2. The G&N process flow and WBS from reference 2, therefore, are included

in the figures in section 4.3.5.1.

72
Table4.WBS 2.2--vehicleperformanceandtrajectoriestaskdescription.2

Inputs Tasks Outputs

•Mission definitions 3.2.1

•Initial performance

•Vehicle coordination system

•Launch pad geometry

•Project ground rules and goals

• Redundancy requests

• Preliminary design concept

and database

• Rangesafety constraints

•Atmospheric model

•Ascent wind models

• Launch pad environments

• Engine alignment tolerances

,..,Vehicle geometry drawing

• Vehicle ascent aerodynamics

• Heating indicators

.-,Vehicle/stage entry aerodynamics

•Engine inlet flow field definition

•Engine installed thrust throughout

trajectory

•Qcc,QI3constraints and structural

load indicators

••Wall/su rface temperatures

•Heating rate or temperature

indicators

•Autopilot definition

•Guidance system inputs

•...Modified autopilot to reflect

a control law for airflow to inlet

•Control surface mixing logic

•Control weights and current weights

Perform trade studies on trajectory/

configuration options

3.2.2 Develop nominal trajectories

3.2.3 Develop design trajectories

3.2,4 Assess vehicle sizing, mass properties

3.2.5 Evaluatevehicle performance

3.2.6 Developabort scenarios and trajectories

Tools:

• Software--Dynamic simulations, program to optimize

simulated trajectories (POST)

• Staging requirements

• Propellant requirements

• Number of engines

•Performance updates

•Entry propellant weight

•Ascent trajectory sets (altitude,

velocity, X, I_ histories) and engine

operating conditions

•,,Entry trajectories

,.,,.Airflow history to inlet

•Trajectory constraints

,-..Mach transitions

•Loads trajectory data

•.,,Ascent, cruise, loading requirements

•Reference trajectories and time

histories

• Max Q

•...e_,airflow

•-,.Ascent, cruise, landing requirements

• Propellant load versus time

• Burn times

-Residuals at main engine cutoff, etc.

•Vehicle mass versus time

• Isp(flow rates)

• Usable propellant requirements

•Flow rates

•System dispersions

....(_ inlet

,--,Derived air volume

•Antenna range data

•Launch mission rules

•Vehicle breakup and disposal analysis

•Launch commit criteria

•Launch corridor

,-..Landing corridor

•Abort alternate mission analyses

• Eventtimelines

Key: • ELV,RLV,and RBCC

•.. RLVand RBCC

,,-- RBCConly

4.3.4.2 Trajectory Gates. Trajectory design is driven by top-level payload performance and

targeting requirements, along with constraints which limit the acceptable trajectories to those satisfying

assumed system limitations such as staging conditions, maximum dynamic pressure, maximum load or

thermal indicators, abort targets, etc. Working with appropriate other disciplines, the trajectory designer

identifies pertinent parameters and their uncertainties and produces optimal constrained trajectories, both

nominal and dispersed, to identify the distributions of trajectory performance variables. The trajectory

designers work closely with specialists from structures/mass properties, aerodynamics, and propulsion,

especially in the early design stages to iterate the basic variables of the vehicle in order to attain performance requirements with acceptable margins, considering parameter variations. Trajectory decision gates

are shown in figure 41. Indicated gates consider three possibilities: (1) Surplus performance margin

(unlikely), where the system plane is provided the excess margin for other tradeoffs; (2) neither surplus nor

shortfall, where performance, sensitivities, and timelines are provided to the system plane without further

iteration;and (3) performance shortfall. In the third case, collaboration with the above design functions

73
attemptsto find anachievablefix for theproblemwithin therespectiverequirementsandconstraints.If

successful,anoutputlike thesecondcaseismade,but,if unsuccessful,theissuegoesto thesystemplane

for relief or rebalanceof requirementsandconstraints.

__ Mass Propertie_

Parameter Matrix

and

Uncertainties

(__.c_ Parameter Matrix I Trajectory "_

k,_Design _' "1 and I Design

I Uncertainties ] t

I Propulsion I

Parameter Matrix I

and I

Uncertainties I

Go to System with

_ _ _-,v,_ _ YES ,. Parametric Information

-_ .... _'_" " to TradeTrajectory

Margins

NO

.,_0 I Go to System with Trajectory

/ A, _ IA.ributes

//Requirements_ YES J°Performance

%,_nd Constraints//" "1 Sensitivity of Performance

"_atisfie_" I • and Constraints

I Mission Timeline

/%ggested'_ YEsl Interactwith I _¥ES_

(_ Changes /_lDesign Functionsl")_A_hi_.-ahl_/"_-'_

_1 _ [toAssessRxes I x4Q_ 7

NO _0

I for GoResolution to System I

I

Go to System I

for Resolution I

Go to System

with Trajectory

:Attributes and

All Changes

Performance

Sensitivity of

Performance

and Constraints

Mission

Timeline

Figure 41. Trajectory design function gates.

4.3.4.3 Trajectory Tasks. The trajectory/performance design function is a part of the earliest

conceptual feasibility activities. It iteratively matures its output through the design process and continues

to perform mission-specific trajectory/performance determination in the operational phase. The primary

responsibility is to determine the trajectory time histories that maximize payload performance subject to all

pertinent constraints and to identify payload performance and margins, flight performance reserves, and

fuel bias. The multiplicity of constraints on a typical launch vehicle that evolve concurrently with and as a

part of design make trajectory design a highly interactive and iterative process. Task summaries are shown

in table 5.

4.3.4.3.1 Task 1---Requirements Determination and Preliminary Perfonrmnce Estimates. In the

early part of conceptual design, the trajectory design function (referred to as "trajectory") is a central

element of concept feasibility screening. Working as part of a small group, trajectory obtains the vehicle

fundamental concept, operating philosophy (e.g., abort accommodation), top-level payload requirements,

and constraints from the system plane. Initial estimates of weight, drag, thrust, Isp, and any special environmental conditions are obtained from their respective design functions and disciplines. Using historical

information, or by discussion with other disciplines, preliminary constraints are generated. Then, using

74
Table 5. Primary tasks for trajectory design functions.

Activities

1. Requirements determination

and preliminary performance

estimates

2. Detailedpayload

performance determination

3. Design reference

trajectories

4.Verification

Interactions

System

Mass properties

Propulsion

Aerodynamics

Natural environment

System

Mass properties

Propulsion

Aerodynamics

Thermal

Natural environment

Aerodynamics

Thermal

IStructures (loads)

Natural environment

System

Aerodynamics

Natural environment

Propulsion

Structures

Tasks

1. Obtainfundamental concept, operating philosophy (e.g., abort

accommodation), and top-level payload requirement

and constraints from system.

2. Obtain initial weight estimate, drag estimate, thrust and Isp

estimates, and any specialenvironmental input from the

respective design functions.

3. Run simplified trajectory program with initial inputs to obtain

performance (including appropriate margins).

4. If desired performance not obtained,work with small group

of representatives of other design functions to trade basic system

descriptors (listed in item 2) to convergeto a solution acceptable

to all parties.

5. If trades are major, or if convergence cannot be attained,

taketrade information to system for decision or requirement/

constraint change.

1.As concept matures, perform detailed trajectory simulation

and payloaddetermination, maintaining close coordination with

pertinent other design functions.

2. Although information is more detailedand interaction somewhat

more formal than activity 1, interact with other design functions

on sensitivity and trade data to convergeto acceptable solutions.

3. Interface with system to provide sensitivity, trade, and margin

information for possible adjustments to requirements, constraints

and allocations.

i 1. Obtain from thermal and loads disciplines indicator functions

of trajectory variables, and calculate indicator values with each

trajectory run within the trajectory/system/environment

parameter space.

2. Work with each respective discipline to select its design reterence

trajectory from the total set, representing a time-consistent

trajectory which maximizes the appropriate indicator. Provide

these to the disciplines as analysis simplification tools.

3. Continueto consult with the disciplines as the design matures

to makeany necessaryadjustments to the design reference

trajectories.

1. Develophigh-fidelity simulation to accommodate test-verified

models.

2. Obtaintest-verified models of major contributors to trajectory/

performance, such as propulsion system characteristics,

structural mass, etc.

3. Using this simulation, verify trajectory design over range

of expected parametersand conditions.

4. Obtain final verification from flight test.

these initial inputs with a quick turnaround program, estimated payload performance and margins are

determined. If desired performance is not obtained, the trajectory design function works with other design

functions and disciplines to trade basic system descriptors (the inputs listed above) to converge to a solution acceptable to all parties. If the trades are major or if convergence cannot be attained, trade information

is provided to the system plane for screening decisions or revision to requirements/constraints.

75
4.3.4.3.2 Task 2--Detailed Payload Performance Determination. Similarly to other design

functions, trajectory accommodates increasingly detailed descriptions of vehicle and environmental

parameters as the design progresses. The vehicle and environmental models include nominal and dispersed

(uncertainty) parameters obtained from the propulsion, structures, and aerodynamics planes, and from the

natural environment group.

Likewise, performance requirements and system constraints are refined. The constraints which are

imposed on trajectory shaping and engine throttling derive from numerous other disciplines and include--

• State vector orbital targets

• Intermediate staging states dictated by clearance, recovery, and disposal of stages

• Structural loads (represented by load indicators)

• Maximum dynamic pressure

• Maximum acceleration

• Aerosurface hinge moment limits

• Aeroheating (represented by thermal indicators)

• Abort targets and limits, if pertinent

• Communication and range safety constraints

• Etc.

Trajectory identifies and updates these constraints through interaction with the other respective

design functions and disciplines.

Detailed trajectory optimization programs are used to determine trajectory and throttling time

histories, payload performance, and flight performance reserves/fuel bias to accommodate variations in

vehicle and environmental parameters. Sensitivity data are derived to guide trade studies and point the

direction of design improvement. Informal trades are made among the design functions and disciplines to

converge to acceptable solutions. The trajectory plane interfaces with the system plane to provide

sensitivity, trade, and margin information for possible adjustments to requirements, constraints, and

allocations.

A cycle is complete when trajectories, dispersions, and margins meeting requirements have been

determined for a comprehensive set of constraints and vehicle/environmental parameter values with

variations. Validity and appropriateness of the input data, constraint def'mition, and program fidelity should

be queried and brought to satisfaction.

4.3.4.3.3 Task 3--Design Reference Trajectories. Design reference trajectories are generated as a

means of simplifying the loads and thermal analysis/design process. Since it is impractical to include all

statistically-varying parameters independently in loads and thermal analysis, it is useful to develop reference trajectories that represent the trajectory parameter set which maximizes (to a statistical measure)

loads or aeroheating. These design reference trajectories then serve as nonlinear time-consistent bases for

detailed loads or thermal analyses (usually linearized) that include the remaining larger set of additional

parameter variations.

76
Trajectory obtains from the loads and aerothermal disciplines indicator functions of trajectory

variables and calculates indicator values with each trajectory run within the trajectory/system/environment

parameter space. Trajectory then works with each respective discipline to select its design reference trajectory

from the total set to a suitable statistical measure. This provides the loads and aerothermal disciplines a

time-consistent basis upon which to develop their maximum design cases, considering the large set of

remaining variables. Although this approximate approach is used as an expedient for analysis, full-dimensional

Monte Carlo check cases run in past programs have confirmed that the approximate approach achieved the

desired statistical measure for the systems checked. As the design matures, trajectory continues to consult

with the disciplines to make any updates or adjustments necessary to the design reference trajectories.

4.3.4.3.4 Task 4--Verification. Verification of the trajectory and performance design is accomplished with high-fidelity analytical simulations that make use of test-verified models of key components.

For example, propulsion system characteristics derived from hot-fire testing and actual structural weights

are used in the verification simulation where possible. The vehicle and its environment are modeled in as

complete detail as practical. The combined simulation then is used to verify satisfactory trajectory design

over the range of expected conditions and parameter variations. Flight test provides the final verification

and performance capability.

4.3.4.4 G&N System Gates. In this document, the G&N design function is taken to be the G&N

system design synthesis function, as distinct from the hardware/software design function which is assumed

to be part of the avionics design function. G&N decision gates are illustrated in figure 42. Primary G&N

system interfaces in the design process are with the trajectories, control, and avionics planes. (The avionics

interface is for negotiating and specifying sensor and software requirements). G&N also works initially

with the system plane to identify the requirements and philosophy which will be allocated from the system

plane. Top-level requirements and philosophy as flowed down from the system plane are expanded with

greater detail by the G&N specialists to provide the basis and starting point for G&N design. The design

process involves the typical synthesize/analyze cycle. Outputs are the G&N system specifications,

including algorithms and software requirements, sensor requirements, and operational information requirements; i.e., what mission-specific information will have to be loaded. Before providing the converged

outputs, the design must meet the gates of acceptable performance (accuracy, payload delivered), accommodation of required failure and abort modes, and reasonableness of the requirements for sensors,

software, and operational information. Close interaction with avionics specialists helps converge and

assure the latter requirements are met.

77
Reasonable

Software

Requirements

t ............ _ .....

• G&N Philosophy

and Approach

• Targets

• Staging and

Trajectory Constraints

• Failureand Abort

Philosophy

Yes

Yes

Reasonable n

Sensor I

Requirements I

w.... .

u

G&N

ties

G&N

System

Analysis

Failure

and Abort Modes

Accommodated

G&N System

Specifications

Software Requirements

Sensor Requirements

Operational Information

Requirements

Acceptable

Performance

• TargetAccuracy

•PayloadDelivery o

No:

Reasonable

Operational and Update _

" uirements

',, No !

Figure 42. G&N design function gates.

4,3.4.5 G&N Tasks. Tasks for G&N are summarized in table 6. G&N synthesis requires interaction

with the systems, trajectory, avionics, and control planes.

4.3.4.5.1 Task 1--Requirements Accommodation. G&N works closely with trajectory in determining target accuracy and payload performance margin requirements and capability. The potential target

errors of the G&N system are provided to trajectory as part of the dispersion set that determines performance reserve margins. Stringent accuracy assumptions in this margin drive the G&N system cost and

complexity. G&N synthesis balances these conditions to converge on the best design.

Constraints on the vehicle have a major effect on G&N design. For vehicles that require abort

capability, abort modes are strong drivers. G&N works with the system and trajectory design functions to

accommodate failure and abort modes. A constraint on maximum dynamic pressure may require throttling

control that adapts to the specific state conditions. Constraints on the permitted range of engine throttling

must be observed.

Another balance that must be achieved is G&N system performance versus the complexity of

operational data loads and updates needed to attain the performance for the range of expected missions.

78
Table 6. Primary tasks for G&N function.

Activities Interactions Tasks

1. Requirements Trajectory system

accommodation

2. Detailed G&Nsystem

synthesis

3. Component and software

requirements

4.Verification

System

Trajectory

Control

Avionics

Avionics

Trajectory

System

Avionics

Control

Trajectory

Propulsion

System

1. Work with trajectory in converging to accuracyand payload

margin requirements and capability

2. Work with system andtrajectory in accommodating constraints

such as failure and abort modes, maximum dynamic pressure, etc.

3. With system, determine appropriate balance betweenperformance

and complexity of operational data loads and updates.

1. Perform iterative synthesis/analysis to best balanceperformance

requirements with cost and operational considerations.

2. Maintain close coordination with system and trajectory as

requirements mature, with control to define initiation state

requirements and to coordinate flight control computer

interactions, and avionics for software/hardware requirements

(see below).

3. Iterate to satisfaction of requirements and constraints with an

adequatebalanceof performanceand cost/complexity.

1. Maintain close working relationship with avionics to keepabreast

of hardware/software state of the art.

2. During G&N system synthesis, work with avionics in

specifying component and software requirements to

provide acceptable performance, cost, complexity, reliability,

operability, and maintainability.

3. If performance cannot be achievedwith hardwareand software

that meet avionics attribute allocations, explore performance

requirement relief with trajectory and systems.

4. If resolution not obtained,take to system for top-level trades.

1. Develophigh-fidelity analytical simulations, modeling system

and environment.

2. Using simulation, verity G&N performance over full range

of parameter and environment variations.

3. Work with avionics to perform software verify and validate (v&v)

and to verify G&N performance in hardware/software test beds.

4. Obtain final verification from flight test,

4.3.4.5.2 Task 2--Detailed G&N System Synthesis. The core activity of the G&N design function

is to synthesize a G&N system architecture that best meets the vehicle requirements while satisfying interfacing constraints. It is not the intent of this report to describe in detail the process used by G&N specialists

to accomplish this, but to note primary considerations and interactions.

The process is the usual iterative synthesis/analysis cycle, directed toward best balancing the

performance requirements with cost and operational considerations. Throughout the process, close coordination is required with the system and trajectory planes as described above, with the control plane to define

guidance initiation state requirements and coordinate flight computer cycle requirements, and with the

avionics plane for software/hardware requirements as noted below.

79
Wheredataandprogramshavebeensubjectedto critical assessment,satisfactionof requirements

andconstraintsandanadequatebalanceof performanceandcost/complexitydetermineadequacyof the

detaileddesign.

4.3.4.5.3Task3--ComponentandSoftwareRequirements.Oneof themainoutputsof theG&N

designfunction is a convergedset of requirementsfor G&N sensorsand algorithmsoftwarewhich is

providedto the avionicsplane.Beforeandduringthedesignprocess,G&N specialistsmaintainaclose

relationshipwith hardwareandsoftwarespecialistsin avionicsin orderto keepabreastof thestateof the

artandcapability.Duringsystemsynthesis,G&N worksverycloselywith avionicsto specifycomponent

andsoftwarerequirementswhich bothmeetsystemperformancerequirementsandrepresentacceptable

cost,complexity,reliability, operability,andmaintainability.Thelattersetof requirementsis capturedin

thesystemallocationof requirementsto theavionicsplane.

If performancecannot be achievedwith componenthardwareand software that meetsthe

avionicsplaneallocations,G&N exploresperformancerequirementrelief with the trajectorydesign

function. If resolution is not obtained,the issueis taken to the systemplanefor top-level tradesor

requirementsrevision.

Theprocessis completewhenthesensorcomponentandalgorithmsoftwarerequirementssatisfy

boththeG&N systemperformancerequirements(imposedonG&N) andthecost,reliability, operability,

andmaintainabilityrequirementsallocatedto theavionicsplane.

4.3.4.5.4 Task4--Verification. Verificationof the G&N systemis accomplishedprimarily with

analyticalsimulations,asaugmentedwiththeuseof testbedsinvolvingflight-type hardwareandsoftware.

High-fidelity analyticalsimulationsaregeneratedto modeltheG&N systemalongwith thevehicleandits

environmentin ascompletedetail aspractical.The combinedsimulationis run usingthe full rangeof

expectedparametervariationstoensurethatsatisfactoryperformanceis attainedatall operatingconditions

andsystemvariations.Avionics test beds use flight-type hardware and software with simulated vehicle

aspects to confirm the correct functioning of the G&N system as implemented physically (as discussed in

the avionics section). Finally, flight test provides the final verification.

80
.J

/

CONTROL

System

Trajectory/G&N

Control

Structures

Thermal

T_

Propulsion !._"

Avionics =,

Materials

Manufacturing ,,........................

Other

Figure 43. Design process technical integration--control design function.

4.3.5 Control Design Function

As shown in figure 43, the connection between the design process technical integration and the

control design function is shown. The illustration depicts the relationship between the control design function and the other subsystem design functions. In addition, it shows the work/information flow process that

is supported by key control decision gates that are required to develop and assess the control attributes. The

details of the above are delineated in this section.

4.3.5.1 Control Design Function Plane. The control design function as represented on the control

plane is illustrated in figure 44. The control design function involves the synthesis of the vehicle control

system, specification of the control component requirements, and necessary interactions with other design

functions and disciplines. Also involved is determination of vehicular dynamic response and the associated

design parameters, including studies of lift-off and separation clearances, pogo, sloshing, etc. First, the

requirements and constraints are interpreted into a form applicable to the control system. From experience,

81
atentativecontrolsystemconfigurationisdefined,alongwith thephilosophy,procedures,andcriteriathat

will be employed.The control specialiststhenidentify the matrix of parametersaffectingthe control

systemandtogetherwith specialistsfrom otherdisciplinesidentify by dataor judgmentthe variations

(uncertaintydistributions)of theparameters.Nominal anddispersedstability andresponseanalysesare

runto assesstheperformanceof thetentativedesign.In somecases,suchasstructuralloads, the acceptability of the performance is determined initially by load indicators, but final acceptability of the refined

design is determined on the structures plane.

ControlSystem

Definition

Control System

Requirements

and Constraints

__..__I ControlSystem

I Philosophy,

Procedures,Criteria

Informal_

_ilntegration

ControlSystem

ParameterMatrix

andUncertainties

Yes _ _ No

(Stop) (Iterate)

ControlSystem

Attributes

• Response _-

• Stability

• Margins

Control

Component

Requirements

J¢ Response

Analysis

Structural

Dynamics

Stability

Analysis

SpecialAnalysesandTests

SeparationandLiftoff Clearances,Pogo,

Sloshing,Etc.

Figure 44. Control design function plane.

Structural dynamics are shown on the diagram as a particularly significant input to the control

analyses, but also other design functions and disciplines such as aerodynamics, trajectories, and propulsion

are important interactors with control. A close relationship is necessary with the avionics and propulsion

design functions that have the responsibility for the control system component hardware and software. The

eventual specification of control system component requirements evolves from this close interaction and

influences the cost, reliability, and operability attributes of the avionics and propulsion planes. Thus while

response, stability, and margins are shown as the control system plane attributes, the attributes of control

component cost, reliability, etc., on the avionics and propulsion planes are determined by the control

component requirements as converged between the control system specialists and the avionics/propulsion

specialists. The tentative control system design is iterated until its attributes meet the requirements and

constraints, or relief from requirements is sought from the system plane.

82
In reference 2, the guidance and control functions are shown combined. The process flow diagram

and WBS task chart from reference 2 are reproduced in figure 45 and table 7, respectively. The process

flow is consistent with the flow diagram of the control plane, with the former emphasizing inputs/outputs

and connectivity, and the latter emphasizing the iterative comparison of requirements and attributes to

achieve convergence. The N×N diagram of reference 2 (app. A) is representative of further

delineation of the inputs and outputs associated with the control design function. The tasks given on the

WBS chart are expanded in more detail in section 4.3.5.4.

As will be addressed later, additional activities of the control design function are to specify design

aspects necessary to ensure adequate lift-off and separation clearances, pogo stability, and propellant slosh

stability.

Internal Flow

Requirements [_

• Constraints F

• Program/Project

• Concepts Design W

,Constra ots Guidance t 1" Contro I"Performance

.......::': _ System r---_l system ..._1 Predictions E U

l,npuls (One-Way) _ Definition J F--_'J° Design J and _

Natural Environments _ I _ I I and Analysis I Requirements_

"----- I , Oefiniti°n • Aerodynamics and Induced _ I : -_{

Environment It_

• Mass Properties Ill Slosh "1 Stability _ 1_

Outputs(One-Way) _ II I

• Electrical Power U [ Analysis

Inputs/Outputs(Two-Way) _ I

• Vehicle Configuration Wl i I" Pogo I" Baffle _ k

• and Structural Design IJ I I I Stability _ :-I Requirements_

•

•

Structural

Performance

Communication

Analysis

and

and

Trajectories

Data

IW

_

_

I

I

"

I

I

_ I Definition

'....

II N

Handling _ I

• Propulsion U I lazards Benefits Reliability Operability ..... l Maintainability

• Safety IJJ I ;t/Makeor ResourcesRequirementsTest SA_/ Server

• Reliability _1 ' UtilizationFeedback I RequirementsI AlgorithmsI Needs

• Cost _ terials/ Technical Sizing/ Conceptual

.................................. I ts L st Descrpt ons Confguraton Sketches/Layouts

I Products

• Autopilot Definition

• Guidance Algorithms

• Load Indicators

• Performance

• and Stability Margins

Subsystem

and Component

Requirements

Figure 45. WBS 2.6--guidance and control design process flow diagram. 2

83
Table 7. WBS 3.6.0---guidance and control task description. 2

Inputs Tasks Outputs

•Projected ground rules 3.7.1

• Design-to-cost goals

• Launch probability requirements

• Preliminary design concept

and data base

•Atmospheric model

•Wind models (ground/ascent)

•Gust models

• Launch pad environments

•Overall vehicle dimension

•Engine alignment tolerance

•Feedline drawings

•Vehicle aerodynamics

•Guidance and control instrumentation

locations

•Vehicle flex-body modes

•Propellant slosh modes

•Propellant feedline flex modes

• Qc_, 013and structural load constraints

• Mass properties control plan

• Documented control weights

•Weights, centers el gravity, moments

of inertia

• Mass versus time

•Thrust vector control (TVC) gimbal

capability (degree and rates)

•Kinematic analysis

•PU system definition

-.Inlet airflow constraints for ascent,

cruise, and landing

,',.,Air capture transition

•Sensor characteristics

• Computational characteristics

•Antenna types and locations

• Hazard analysis

• Fault tolerance requirements

• Failure mode effects analysis inputs

'.'CIL inputs

• Hardware design, development, testing,

evaluation, and production costs

• Cost trades

Develop flight guidance and control system

strategies

3.7.2 Derive subsystem/component requirements

3.7.3 Determine system performance/margins

3.7.4 Determine induced environments

Tools:

• General purpose simulations and control system

analysis packages such as Matlab and Marshall

Systems for Aerospace Simulation (MARSYAS)

Key: • ELV,RLV, and RBCC

•. RLV and RBCC

-. RBCC only

• Maximum engine deflection

• Control sensor locations

• Control surface deflection requirements

•Autopilot definition

•Guidance system inputs

-,Modified autopilot to reflect a

control law for airflow to inlet

• Control surface mixing logic

•Slosh damping requirements

•Oc_versus O_ envelopes

•Flex-body mode frequency constraints

•Vehicle transient response to wind

disturbances

•Pogo suppressor requirements

•I-VC requirements

• Reaction control system (RCS)

requirements

•Software requirements

• Computer requirements

•Sensor requirements

•Power requirements for control

system

• Diagnostics/control logic

•Technical descriptions

•Test requirements to include

instrumentation

•Product quantities

• Make or buy plan

4.3.5.2 Control System Gates. Decision gates for the control system design process are shown in

figure 46. The control system synthesis process is accomplished by control systems specialists in concert

with specialists from aerodynamics, structures, trajectory/G&N, avionics, and propulsion. Inputs to the

process include the control philosophy and approach, allocated architecture (concepts and characteristics),

and the expected environments. Stability analyses and response analyses are used to determine the performance of synthesized designs. Output of the process is the control system description, component and

software requirements for the avionics group, control responses for the loads group and others, and attitude

errors for the G&N group. Before a converged set of outputs are made, the control design must pass the

gates of acceptable stability margins, sufficient control authority for maximum disturbances, acceptable

load indicator ranges, acceptable attitude errors, operability and complexity appropriate to the system, and

reasonable component and software requirements. Threshold levels for these gates are determined in

collaboration with other disciplines as appropriate. The control design is iterated until the gates can be

passed successfully, which is represented in summary on the control plane by the control attributes meeting

the control requirements and constraints.

84
__ Acceptability

Stability

Margins

No

Control Philosophy/

Approach

Prescribed Concepts

and Characteristics,

Environments

!

No

Reasonable

Component

and Software

Requirements

_erodynarnics

Stability

Analysis

Response Analysis

• Load Indicators

• Response Envelope

•Component and Software

Requirements

•Control Responses

• Attitude Errors

Sufficient Control

Authority for

Maximum

Disturbances

Acceptable

Load Indicator

Range

No I

Figure 46. Control design function gates.

Pogo stability is assured by performing stability analyses of the engine/feedline/tank/structural

system and specifying requirements for Pogo suppressors if needed to achieve adequate stability margins.

Therefore, the Pogo gate (not specifically shown on the figure) is adequate Pogo stability margins.

4.3.5.3 Separation System and Lift-off Clearance Gates. Separation and lift-off clearance analysis

and design is an adjunct to control system design and extends to the design of the separation system or, for

lift-off clearance, potentially to specification or modification of the launch pad interface (see fig. 47).

Dynamic clearance analyses are conducted for tentative separation system designs with pertinent vehicle

and environmental inputs. Appropriately, extreme disturbances and parameter variations must be incorporated into the analyses. Separation system decision gates include adequate separation clearance margins

and reasonable separation system component requirements at acceptable reliability and cost. When the

design converges to meet these gates, the separation system specifications/drawings can be finalized.

Lift-off clearance assurance is obtained through determining adequate lift-off clearance margins by

dynamic clearance analysis. This analysis must include appropriately extreme disturbances and

parameter uncertainties. Inadequate clearance margins require iterating on the independent variables,

predominantly the launch pad interfaces.

85
R 7 ec0s, Separat,0nSystem

e,,ao_jae _ Component Iv_. -I Drawings/Specifications

' '! No RequirementsI !No

•Vehicle Configuration l • w I..............................

I.MassProperties '._ v | v ,,..tj ', I Adeauate No

• PropulsionCharacteristics Separation .......... _ - _ •

I-ControlSystem _ System _ ............. I Separat'°n _ -

•Environments _ Design Dynamic _.[ Clearance !_ _ D::_amnl e I _ =Margins

AboveInputs _ Liftoff _ Analysis _ Adequate /_v_

PlusPad r_ _ Clearance I I _ Lir[on _

Configuration/Interfaces_ Assurance_ Clearance

Margins No

ModifyLaunchPad/Interfaces-_-..... !..) .....................................................

/

jJ

ModifyControlSystem _"

Figure 47. Separation system and clearance gates.

4.3.5.4 Control Tasks. In this report, the control design function is taken to be the control system

synthesis function, as distinct from the control hardware/software function which is assumed to be part of

the avionics and propulsion design functions. It is assumed that the avionics design function has responsibility for sensors, computers, and software, and that the propulsion design function has responsibility for

control effectors; i.e., actuators, reaction control systems (RCS) thrusters, and valving for differential throttling or secondary injection. As will be noted, a very close working relationship must be maintained

between the control design function and these two hardware/software design functions in order to achieve

a successful design. The main control activities in design are summarized in table 8 and are given below.

4.3.5.4.1 Task 1--Requirements Determination and Allocation. Requirements allocation is a joint

responsibility between the system plane, the control plane, and the avionics and propulsion planes. Control

and avionics/propulsion planes consult with the system plane in identifying and flowing down the initial

requirements to which the control system must be designed. Avionics and propulsion are the design functions for the control system hardware/software and, therefore, are the keepers of the requirements for cost,

reliability, maintainability, power usage, etc. Control is the control system design function and, therefore, is

the keeper of the requirements for control system configuration and performance. Most of the top-level

requirements that are allocated by the system plane fall in the former category (imposed on the avionics and

propulsion planes), whereas the requirement imposed on the control plane is to deliver acceptable control

performance for the vehicle. Acceptable control performance means acceptable stability, attitude errors,

load responses, lift-off and separation clearances, etc. These are requirements that must be given definition

by the control design function and are quantified by working interactively with the other design functions.

As the design progresses, if the control system attributes do not meet the requirements and informal

iteration among the design functions and disciplines cannot resolve the problem, the attributes and sensitivities

are fed back to the systems plane for trades and possible revision of the requirements allocation.

86
Table8.Primarytasksfor controlsystemdesignfunction.

Activities Interactions Tasks

1. Requirements System 1. Consult with system to aid in initial requirements allocation.

determination and Avionics 2. Feed back attributes to system. Provide trade data

allocation and consultation for revised allocation if required.

2. Control authority

3. Detail control system

syntheses

4. Component and software

requirements

5.Verification

Trajectory

Guidance

Aerodynamics

Propulsion

Natural environment

Structural

configuration

Avionics

System

System

Trajectory

Guidance

Structures

Propulsion

Aerodynamics

Avionics

Avionics

Structures

Trajectory/Guidance

System

Avionics

G&N

Propulsion

System

t. Determine wind, trajectory, and thrust disturbances with natural

environments and propulsion.

2. Consult with trajectory/guidance to determine acceptable

response excursions.

3. Consult with avionics/propulsion/structures to determine

reasonable control effector authority limits or trades.

4. For specified control concept and configuration, simulate with

appropriate disturbance inputs to determine response

excursions as functions of control authority.

5. If response excursions and/or control authority are not

acceptable, perform trades in concert with aerodynamics

and configuration to improve conditions. Alternatively, revisit

items 2 and 3 above.

6. If issues resolved among participants, send attribute

and configuration information to system.

7. If issues not resolved, take to system for top-level tradeoffs.

1. Collect and derive requirements from system and interfacing

design functions, along with internal design criteria.

2. Perform iterative synthesis/analysis with increasing fidelity,

directed toward meeting requirements, constraints, and criteria

while balancing performance with cost and complexity

3. Work informally with other design functions to resolve conflicting

requirements. If resolution is not obtained, take to system

for top-level trades.

4. In addition to synthesized control system design, provide load

indicator responses, providing load relief design if required.

5. Interactively determine slosh baffle requirements.

6. Using clearance analysis, determine separation system

requirements and launch facility geometrical constraints.

11Maintain close working relationship with avionics to keep abreast

of hardware/software state of the art.

2. During control system syntheses, work with avionics in

specifying component and software requirements, to provide

acceptable performance, cost, complexity, reliability, operability,

and maintainability.

3. If performance cannot be achieved with hardware and software

that meet avionics attribute allocations, explore performance

requirement relief with structures (load indicators) and trajectory/

guidance (attitude errors).

1. Develop high-fidelity analytical simulations.

2. Using simulation, verify system performance over full range

of parameter and environment variations.

3. Work with avionics to perform software v&v and verify

control performance in hardware/software test beds.

4. Verify separation and clearance margins using high-fidelity

response analysis, incorporating any available test-verified

component models.

5. Verify Pogo stability margins analytically, using test-anchored

dynamic models of propulsion system and structure.

6. Damping performance of the Pogo suppression system

may be confirmed by pulsing during hot firing tests,

with and without the suppressor.

87
4.3.5.4.2 Task 2--Control Authority. An important early activity is sizing the control effectors for

sufficient control authority. Effectors are the devices that cause force or torque to be applied to control the

vehicle. Effectors may be engine gimbal actuators, aerodynamic control surfaces, engine differential throttling, etc. The range (or existence) of control capability in these effectors needs to be determined early in

the cycle since it can have significant effects on the total design. Also, the rate capability of the effector is

an important variable.

Working with natural environments and the propulsion plane, control determines maximum wind,

trajectory, and thrust disturbances and their appropriate statistical combination to provide a design disturbance set. Vehicle mass and aerodynamics data are obtained from their respective disciplines, along with

uncertainties in these parameters. (Note: Historically, problems have occurred in this area. Adequate

definition of parameter uncertainties is critical.) Control consults with trajectory and guidance design functions to determine maximum response excursions acceptable to those functions. Control also works with

hardware-responsible personnel from the propulsion design function and, in the case of aerodynamic

surfaces, aerodynamics/structures design functions to obtain reasonable effector authority range and rate

limits and the relationship of authority/rate values to hardware cost and complexity. (In very early design

stages, control personnel may make preliminary control authority assessments based on their historical

knowledge of the above variables.)

A control system architecture is hypothesized and simulated with the above disturbances and

parameter variations to determine response excursions as a function of control effector authority and rate.

If response excursions and/or control effector authority/rate are not acceptable, trades are performed in

concert with the aerodynamics, structures, and propulsion planes to improve the conditions. Alternatively,

the response excursions and effector authority/rate definitions described above may be revisited. If issues

are resolved informally among the participants, the control attribute and configuration information is sent

to the system plane. If the issues are not resolved, they are taken to the system plane for top-level tradeoffs,

reconfiguration, or requirements revision.

When is the control authority determination adequately addressed? At each design cycle, there

must be satisfactory definition of inputs, parameters, and their uncertainties. For example, aerodynamic

data should have realistically sufficient uncertainties identified based on the data source (analytical,

database, wind tunnel tests, etc.) The simulation model should be of appropriate fidelity, including allowances for response lags and unmodeled effects in the system. Margins or headroom should be provided,

their magnitude being a function of the fidelity of the configuration definition and simulation. The margins

will decrease as the design converges to better definition. For a given design cycle, control authority

determination has been adequately addressed when effector authority/rate capabilities which are

reasonable in terms of cost and complexity produce acceptable response excursions, while considering,

and this is key, uncertainties and margins appropriate to the fidelity of the models.

4.3.5.4.3 Task 3--Detailed Control System Synthesis. The core activity of the control plane is to

synthesize a control system architecture that best meets the vehicle requirements while satisfying interfacing

constraints. It is not the intent of this document to describe in detail the process used by control

specialists to accomplish this, but to note primary considerations and interactions.

88
In additionto thoserequirementsimposedby thesystemplaneandthosederivedfrom interfacing

designfunctions and disciplines,control usesinformal designcriteria (for example,phaseand gain

margins)whichhavetheintentof assuringsatisfactorystabilityandresponse.Input to theprocessincludes

the informationnotedin Task2 from otherdesignfunctionsand disciplines,plus detailedsensorand

actuatorcharacteristics,structuraldynamicmodes,sloshdynamics,andenginedynamics.The process

usesiterativesynthesis/analysiswith simulationsof increasingfidelity asthedesigncyclesprogress.

Typically, analysesand simulationsaredoneon multiusedynamicsand control software(e.g.,

MARSYAS,Matlab,etc.)thataccommodatesavarietyof systemmodels.As thedesignprogressesthrough

finer definition, the modelof the vehicledynamicsis expandedto include higherfrequencystructural

modesandsloshmodes.The modelof thecontrol systemcomponentdynamicsis expandedto include

higherordereffectsandnonlinearities.Thesemodelsareusedin stabilityandresponseanalysesto assess

theperformanceof thesynthesizedcontrolsystemdesign.

Wind disturbancesmayberepresentedin veryearly designstagesby syntheticwind profilesthat

have been constructed to represent a high wind or design disturbance. Subsequently, sets of measured

winds are used in Monte Carlo analyses to determine the system response in a probabilistic sense.

Along with satisfying internal and external requirements and criteria, the control system design

produces load indicator responses to disturbances and dispersions, configuring the system to provide load

relief if necessary. Also, it interactively determines slosh baffle requirements and through clearance

analyses determines separation system requirements and launch facility geometrical constraints.

Again, adequacy of the detailed design is determined by satisfaction of requirements and adequate

margins, where the input and simulation data and its uncertainties have been subjected to critical assessment.

4.3.5.4.4 Task 4--Component and Software Requirements. One of the main outputs of the control

plane is a converged set of requirements for control components and software that is provided to the

avionics and propulsion planes. Before and during the design process, control specialists maintain a close

relationship with hardware and software specialists in avionics and propulsion to keep abreast of the state of the

art and capability. During control system synthesis, control works very closely with the avionics and propulsion

planes to specify component and software requirements that both meet system performance requirements and

represent acceptable cost, complexity, reliability, operability, and maintainability. The latter set of requirements

is captured in the system plane allocation of requirements to the avionics and propulsion planes.

If performance cannot be achieved with component hardware and software that meets the avionics

and propulsion plane allocations, control explores performance requirement relief with the structures plane

(load indicators) and the trajectory/guidance plane (attitude errors). If resolution is not obtained, the issue

is taken to the system plane for top-level trades or requirements revision.

The process is complete when the component and software requirements satisfy both the control

system performance requirements (imposed on the control plane) and the cost, reliability, operability, and

maintainability requirements allocated to the avionics and propulsion planes. Again, appropriate

allowances for uncertainties and margins must be included.

89
4.3.5.4.5 Task5--Verification.Verificationof thecontrolsystemis accomplishedprimarily with

simulationsof twotypes:(1)Analytical simulationsand(2)testbeds.High-fidelity analyticalsimulations

aregeneratedto modelthecontrol systemandthevehicle/environmentin ascompletedetailaspractical.

The combinedsimulation is run using the full rangeof expectedparametervariations to ensurethat

satisfactoryperformanceis attainedat all operatingconditionsandsystemvariations.Avionicstestbeds

useflight-typehardwareandsoftwarewith simulatedvehicleaspectsto confirmthecorrectfunctioningof

thecontrolsystemasimplementedphysically,asdiscussedintheavionicssection.

Verificationof lift-off andseparationclearanceis done in analytical simulations. Since this can

only be done analytically, it is important that sufficient margins are maintained. Pogo stability verification

also is done by analysis, using test-anchored dynamic models of the engine and structure. Pogo pulsing

during engine hot-fire tests can be used to obtain engine dynamic response information and to show the

damping effect of adding Pogo suppression systems. Sloshing and flexible-body stabilization are verified

by the best-available analytical models but are not fully validated until flight.

9O
System

STRUCTURES

Aerodynamics

Trajectory/G&N ,,,

Control

Structures

Thermal

Propulsion

Avionics

Materials "°i

Manufacturing

Other

Figure 48. Design process technical integration--structure design function.

4.3.6 Structures Design Function

The connection between the design process technical integration and the structures design function

is delineated in figure 48. The illustration depicts the relationship between the structures design function

and the other design functions. In addition, it shows the work/information flow process that is supported by

key structural decision gates that are required to develop and assess the structures attributes. The details of

all the above are delineated in this section.

The structures design function is defined as any design activity involving structural subsystems;

e.g., tanks, interstages, thrust frames, lines, ducts, components, etc., and finally the total structural

system (vehicle).

91
4.3.6.1 Structures Design Function Plane. The structures plane in figure 49 shows the information

flow among discipline functions required to accomplish the structures system design. The output of this

plane is the structures' design and its various attributes. The flow diagram starts with the requirements and

the initial configuration, moves through the definition of philosophies, criteria, procedures, and approaches,

then establishes the parameters and their uncertainties. The next blocks are the discipline functions which

interact with the structural analysis to provide the structural design data. Included are the trajectory, controls,

and thermal disciplines. Inputs to the discipline tasks are compatible data inputs from natural environments

and materials. The structural analysis discipline functions are loads and response, stress, stability, buckling,

etc. All these discipline functions culminate in the structural design discipline which produces the structural

design. The discipline functions in conjunction with the design function are fundamental in defining the

structural attributes. The integration of the tasks is performed using inputs and outputs from one discipline

to the other, as discussed in the following sections. The tasks performed on the structures plane produce

results which must be passed through a prescribed set of gates that determines when the design is completed.

In cases where gates cannot be met, the structures plane communicates with the system plane to balance

out the design.

Structural I I

Requirements ]-_

and Constraints I I

Yes_ No

(Stop)- y (Iterate)

Structural Attributes

• Assurance

- Strength

- Endurance

- Stability

- Reliability

• Weight

• Cost Factors

• Complexity Factors

• Failure Modes

• TRL Assessment

Configuration

Definition

H Structural I [ Structural H Trajectory

Philosophies [._ Parameter Matrix Shaping,

Criteria Proceduresl I and Performance,

Approa_:hes I I Un#ertainti_$ ond Guidance

....

Structural Stress Thermal

Design

i,

I'|

i,

Loads "_

and Controls

Response

Special Stability, AnalysesBuckling and Tests:

Informal_

_!ntegrationl_

i

i

i

,,

Figure 49. Structure design function plane.

As discussed previously, an NxN diagram has been developed consisting of a matrix of inputs and

outputs (see ref. 2 and app. A). Table 9 depicts an exploded scale portion of this diagram, showing the

inputs and outputs for structural analysis. Shown are the inputs from thermal and control. Structural analysis outputs are shown horizontally, and structural analysis inputs are shown vertically. For example, structural analysis outputs are flex-body modes, propellant slosh modes, propellant feedline flex modes, and

q-alpha and q-beta constraints as input to control, while control provides to structural analysis the inputs of

slosh damping requirements, q-alpha and q-beta envelopes, flex-body mode frequency

constraints, and autopilot definition.

92
Table 9. Example expansion of vehicle design NxN diagram. 2

• Structural

3.5

Structural analysis

Temperatures/gradients

• Slosh damping requirements

• Qxalpha versus qxBeta

envelopes

• Flex-body mode

frequency constraints

• Autopilot definition

• Vehicletransient response

to wind disturbances

• Temperaturegradient

design limits

3.6

Thermal

• Vehicle flex-body modes

• Propellant slosh modes

• Propellant feedlineflex

modes

• Q'Alpha, Q'Beta and

structural constraints

3.7

Guidanceand control

4.3.6.2 Structures Gates. Structural decision gates are shown in figure 50. This figure shows the

integration of structural assessment and structural design. The inputs are the prescribed concepts and

characteristics. The basic outputs are drawings and specifications. Also shown are the corresponding gates

that affect the structural design. For example, structural assurance must meet the criteria for stability,

strength, endurance (fatigue and fracture), and reliability. The other gates are clear and left to the reader to

interpret. Gate metrics that cannot be met result in either design change which meets the metrics or an

involvement of the system plane to rebalance requirements, etc.

The NxN diagram and related write-up separate structural analysis and structural design into

separate activities while the structures plane is an integration of both. As a result, the NxN augments with

more detail the activities of the structures plane. Figure 51 depicts the structural analysis process. The left

side gives the requirements including the discipline criteria. One-way inputs and outputs are defined as

well as the two-way inputs and outputs. The middle section of the chart shows the structural analysis tasks

and the flow. The loads analysis is central to combining outputs from vibroacoustics and dynamic analysis.

The loads output is input to the stress analysis which is then the input for the life or durability analysis. The

products of structural analysis are shown on the right side of the chart. Other internal flows are shown

including vehicle configuration, options, cost, etc.

93
Yes

TPS _.

Accommodations / -_

Propulsion _ "

Accommodations J '_"

Operability I "'"_//

• Accessibility I /

Inspectibility I i

• Processing

and Checkout I

• Maintainabilityl..._

|

Launch Facility

yNoI coom o°at'on J

_ctural Desig n

Structural

Assessment

Drawings and I Specifications

Structural _Yes

Assurance

• Stability

• Strength

• Endurance

• Reliability I NO_

Manufacturing

No :

Y

Prescribed

Concepts ""V

and

Characteristics

Yes

Assembly I

Performance

• Weight

• • Deflection

",,,..................

Figure 50. Structure design function gates.

r- Internal Flow

I

.... I Consultation Options Trades Analysis IcostI

Mequlremeras _ ' ' ' ' _ _ '

• Program Ground Rules _ I IVibroacoustic Analysis

I" Factors of Safety Criteria _ I I" Random Vibration and Shoc4

I" Fracture Control Requirements W I I Criteria

• Constraints I" Component Accelerations I

t I (High Frequency. >50Hi)

Inputs (One-Way) _ _ I ........... _................................

• Mass Properties I .......... " I_

_e rrtoenSents r Lo_du_._,y.,_ .

- _ I uestgn LOaO B

•Onlnpu ne'Wav)p mutS(On [ . Y) , i.VehicleLineLoads I[i

• Communication and Data I . or FEM Loads . .. I

_ceiWnaYlndData L uomponen, _cce,era,,ons |

• u I , Load Spectra • El_'Ctr;c_lPower [ ........ l IStress Analysis

m I * ueslgn uonolllons IB _1 . .

Inputs/Outp s (y) U .................. El Structural Sizing ut Two Wa I -Ground Handling • Stress Anatysis

•_iO!ii_iiioVehtcle . Cont=guratmn , . _ -- SUI Id_ Ilall_pUI t{IHUII ,

and Structural Destgn II p .............................. ............. v t _, _1" _1. Margms Stresses ofandSafety Stratus

• a_dUlH_;>b FIHH_ L_UHI_tl .

ries .... in _[• Deflecbons

• Aerodynamics and Induced _ I -_Cee_ _Laa_di_,, _l • Strength Verification

Environments _ I - R over' _ Ii I Test Requirements

• Thermal _ - ec ry ............ _

• Mat?rials .... _ _ ..... Life Anai_;sis"

•Gutdance and Controls Fah ue • G.uidance and Controls _ Structural Dynamic Analysis bl Fracture and g

• Propulsion W , Transient Analysis ll Analysis

• Ground Operations _ o Structural Models and Modalll Cycles and Time to Failure

• Safety _ Analyses B Proof Factors

• Reliability _ • Propellant Slosh Dynamics i Critical Initial Flaw Sizes

• Flutter Assessment _ Nondestructive Test

• Pre-Test and Post-Test B Inspection Requirements

Analyses for Modal Survey If

Products

Random Vibration

and Shock Criteria

Design Loads

Structural Dynamic

Analysis

Modal Survey Tests

Analysis

Strength Verification

Test Requirements

Stress Analysis

Fracture and Fatigue

Figure 51. WBS 2.4--structures analysis design process flow diagram. 2

94
The structuraldesignflow chart,figure52,showsthestructuraldesignactivity andhasthesame

format asthestructuralanalysisflow chart.Structuraldesigndealswith componentgeometry,interfaces,

subsystemlayout,etc.Themajorproductsarethedesignspecificationsandthedrawings.

Requirements _ I

Program/Project

• Concepts L I

• Design r I

• Verification _ I

I

ruts (0ne-Way)

• Natural Environments

Ioputs/Outp,,ts (Two-Way)

• Performance and Trajectories

• Materials

• Manufacturing

• Guidance and Controls

• Mass Properties

• Thermal

• Structural Analysis

• Propulsion

• Aerodynamics and Induced

Environments

• Communication and Data

Handling

• Electrical Power

• Ground Operations

• Flight Operations

• Safety

• Reliability

• Cost

Internal Flow

Vehicle Configuration

• Subsystems

Interfaces

Moldline

Structural Element Function

. I

StructuralDesign

• Component Geometry

Construction Type

- Dimensions and Tolerances

Mass and CG

CrossSection Properties

• Interfaces

Mechanical

Datums

• Subsystem Layout

-Subsystem Placement

Line Routing

Access Panels

Vent Ductwork

• Holddown/Release Mechanism

- Staging

Active Systems

Passive Systems

Hazards Benefits Reliability OperabilityI Maintainability

Cost/Makeor ResourcesRequiremenisTest S/W Server

Buy Utilization ]RequirementsAlgorithms Needs

Materials/ Technical Sizing/ Conceptual

PartsList DescriptionsConfiguration Sketches/Layouts

Products

• Vehicle Configuration

• System Layout

• Construction Type

• Detailed Drawings

• Structural Mass

• Subsystem Layout

• Structural System

Description

• Functional Requirements

• Vehicle/Pad Interface

• Transportation

Requirements

• Verification Requirements

Figure 52. WBS 2.1--vehicle configuration and structural design process flow diagram. 2

The N×N diagram is a complement to the structures plane, providing more details of tasks shown

on the structures plane. The structures plane diagram shows the linkage between structural design,

structural analysis, and the system plane. The tasks provided in reference 2 can be correlated to the task

details given in section 4.3.6.3 which follows.

95
Reference2 delineatestheWBStaskswith inputsandoutputsasshownin tables10andl 1.

Table10.WBS 2.4--structuralanalysistaskdescription.2

Inputs Tasks Outputs

• Projected groundrules and goals

•Factors of safety criteria and fracture

control requirements

•Launch platform finite element model

•Ground and ascent wind models

•Vehicle geometry

•Vehicle/pad interface geometry

•Holddown/release mechanism definition

•Structural details

•Component installations

•Shock sources

•External aerodynamic pressure

distributions

•Compartment pressures

•Protuberance airloads

•Acoustic/overpressu re definition

•Fluid dynamic loads (buffeting)

•Structural temperature and gradients

•Slosh damping requirements

•Q-alpha, q-beta envelopes

• Flex-body mode frequency constraints

•Autopilot definition

•Vehicle transient response to wind

disturbances

•Weights, centers of gravity, moments

of inertia

• Ignition and shutdown thrust transients,

timing

•Steady state thrust oscillation

•Ullage pressure and tank fill heights

versus flight time

•..,RBCC exhaust/thrust

•.,-Forebody inlet

•Material properties

•Material allowables

•-,,Materialselection consultation

,-.,TPS design definitions

•Material thermal (required/expected)

•Drawings for flight GSE

• Launch sequence timelines

•Vehicle integrated OPS concept and

requirements

• FMRand LMR

• Hazardanalysis

• Faulttolerance requirements

• System and component reliability

allocation and estimation

• Failure mode effects analysis inputs

•,.,CIL inputs

3.5.1 Vibroacoustic analysis

3.5.2 Load analysis

3.5.3 Structural dynamic analysis

3,5.4 Stress analysis

3.5.5 Life analysis

Tools:

• Commercial soffware---NASTRAN, ABAQUS,ANSYS,

PATRAN

• In-house software--dynamic loads analysis programs,

NASGRO,bolt strength analysis software

• In-house vibration data base

•Structural sizing, margins of safety

•Loads and deflections

•Propellant slosh baffle sizing

•Q-alpha, q-beta constraints and structural load

indicators

•Temperaturegradient design limits

•Vehicle flex-body modes

•Propellant slosh modes

•Propellant feedline flex modes

•Q-alpha, q-beta and structural load constraints

•Structural analysis of lines and brackets

•Establish dynamic envelop of feedline

•,.,-Aft/forebody structures

,., Life limit

oVibroacoustical design criteria

• Review of battery cell design (pressure vessel)

•Structural failure modes

• Failurepropagation logic development

•Test requirements to include instrumentation

Key: • ELV,RLV,and RBCC

,,,,RLV and RBCC

,.,- RBCConly

96
Table 11. WBS 2.1--vehicle configuration and structural desig-n task description. 2

lnpuls Tasks Outputs

• Projected groundrules and goals

• Production and ground OPS

• Critical interfaces

• Subsystems definitions

• EPAand OSHAconstraints

• Environmental 0PS constraints

•Preliminary design concept and

data bases

•Staging requirements

•Propellant requirements

•- Entry propellant weight

• Pressure vent sizes and locations

•Structural sizing and margins of safety

•Loads and deflections

• Propellant slosh baffle sizing

•Cryogenic insulation sizing

•Active thermal control system sizing

•Temperature and propellant sensor

locations

• Maximum engine deflection

• Control sensor locations

• Control surface deflection requirements

• Mass properties data--weight;

e.g., inertias

• Propellant inventory

•Propulsion system layout

•Tankinternal pressures

•,.,Forebody moldline (iterate required

air volume)

•,--Staging requirements

•-,,Propellantrequirements

•Material allowables

•,-,Material selection consultation

•,-TPS design, thermal materials

required

• Packagingvolumes required

• Electrical power system (EPS)

component details

•Access requirements

•,,-Turnaround, launch, and landing

facilities

•Vehicle integrated OPS concept and

requirements

• On-orbit flight OPS

•- Landing gear drawings

•Fabrication parameters

•Range safety requirements

• Hazardanalysis

• Fault tolerance requirements

•Reliability estimates

•Failure mode effects analysis inputs

•-, CIL inputs

•System-to-subsystem reliability, allocations

Hardware design, development, testing,

evaluation, and production costs

•Cost trades

3.1.1

3.1.2

3.1.3

3.1.4

3.1.5

3.1.6

3.1.7

3.1.8

3.1.9

3.1.10

3.1.11

3.1.12

3.1.13

3.1.14

3.1.15

Configure vehicle

Layout 3D structural model

Determine suitable construction type (e.g.,

truss, isogrfd, etc.)

Select appropriate material

Calculate structural member sizes

Analyze crosssection moments of inertia

Determine structural component mass and CG

location

Assess provisions for clearanceand access

Locate subsystems

Route subsystem lines

Produce detail drawing for manufacturing shop

Design structural components

Identify shock sources

Specify critical dimensions

Establish suitable manufacturing tolerances

Tools:

• Commercial software--CAD platform and translators,

EMS

• In-house software--optimization design codes

• Engine alignment tolerances

• Vehicle geometry and structural details

• Feedline drawings

• Component weight estimates

• Parts list

•Cross-sectional properties

• Line routing zones

• Pressurant bottle locations

,,,-Preliminary air column

,,,,-Profile

• Power return thru structure

•Component installation

•Verification requirements

•Transportation requirements

•System definition and design

description document

•Holddown release mechanism

,,Hazardanalysis inputs

,Schematics

• Failure mode effects analysis inputs

,,--ClL inputs

•Technical descriptions

• Test requirements to include

instrumentation

• Production quantities

• Make or buy plan inputs

Key: • ELV,RLV,and RBCC

,- RLVand RBCC

•,, RBCConly

97
Table 12. Primary tasks for structures design function.

Activities Interactions Tasks

1. Requirements

determination and

allocation

2. Loads analysis

3. Structural

capability

determination

4. Structural design

5. Verification

Mass properties

System

Control

Trajectories

Materials

Propulsion

Aerodynamics

1. Consult with system to obtain operations philosophy,

constraints, cost, mass fraction, etc.

2. Obtain initial configuration definition.

3. Provide to systems the discipline peculiar criteria for formal/legal

application.

4. Develop discipline specific verification requirements.

5. Setup allocated requirements, discipline specific criteria, etc., into

the metrics for decision gates.

6. Flow up derived requirements to system.

Trajectory 1.

Control

Aerodynamics

Materials 2.

Thermal

Propulsion 3.

Avionics

Propulsion 4.

5.

6.

7.

Loads 1.

Thermal

Materials 2.

Aerodynamics

3.

4.

Loads 1.

Thermal

Materials

Stress

!Testing

Loads

Thermal

Stress

Setup describing equations (models) of the system (separate sets

are required for the various mission events such as transportation,

liftoff, max "g," max "q," separation, etc.).

Develop all input data, configurations, environment, etc., and

execute loads analysis.

Work with trajectory, control, etc., to resolve excessive load

conditions. Resolve informally, if possible.

Consult system to resolve remaining loads issues, constructing

derived requirements such as load relief controls.

Input loads to stress and design.

Work with propulsion, aerodynamics, and avionics to

accommodate packaging and special requirements in the

design. Continue to work trades and balancing activities.

Insure that cost, reliability, and operations are a part of the

design trades and metrics.

Determine strength margins, fatigue margins, fracture control

requirements, and structural stability margins.

Coordinate with design and loads to informally resolve

undesirable margins.

Consult systems for trades and requirements changes to resolve

remaining margin issues.

Continue to work with design to resolve issues and concerns

through design changes.

.

Using system requirements, loads, thermal, and stress perform

detail design, outputting configurations (geometry), materials,

specifications, drawings, etc., to serve as baseline of next iteration

Continue to work with stress, thermal, and systems to upgrade

design to accommodate requirements change, reduced margins,

and issues. Provide trade date and recommendations to

program on issues.

1, Work with stress, loads, and thermal to determine test facility

requirements, test condition, instrumentation, and data system

requirements.

2. Work between disciplines to evaluate results.

3. Flowup anomalies to system for design changes or changes in

operational constraints and procedures.

4. Final structural validation achieved in development flight tests.

98
Structural analysis and structural design are shown separately, whereas these activities are

integrated herein.

4.3.6.3 Tasks. The top-level tasks of the structures plane are shown in table 12. They are divided

into five categories: (1) Requirements determination and allocation, (2) loads analysis, (3) structural capability

determination, (4) structural design, and (5) verification. For each category the interactions are shown

along with the corresponding tasks.

4.3.6.3.1 Task l--Requirements Determination and Allocation. Task 1 is a joint task between the

system plane and the structures plane. The system goal is to take the total system level requirements,

compartmentalize them, and allocate them to the planes. In this case, typical requirements allocated to the

structures plane are:

• Weight

• Geometry constraints

• Cost

• Operations constraints

• Schedule.

The structures design function works with the system design function to properly accomplish this

allocation task.

The discipline groups develop a second set of requirements that are technical criteria. These are

approved and levied by the project and controlled or managed by the disciplines. Typically in structures

there is a detailed set of these criteria, documented officially by NASA for general use as legal requirements. Generally, the criteria are too comprehensive and must be tailored by the disciplines, the system,

and the project. Typical examples are strength criteria, endurance criteria such as fatigue and fracture,

criteria for loads analysis, vibroacoustics, and attachment methods.

Included in these criteria are not only safety factors but also verification requirements such as static

and dynamic test, qualification and acceptance criteria, parameter variation ranges, and traceability. Gates

include not only meeting requirements given in the criteria documents but validation of models, data

accuracy, etc. If the model is wrong, the accuracy of the input data is immaterial. Therefore, all models

must be verified.

Finally, during the design and development process, derived requirements will evolve and can

become part of the legal requirements. Examples of derived requirements are requirements for load relief

control, slosh baffles, day-of-launch wind biasing, launch constraints, etc. in each case the design must

accommodate the new requirements. The total set of structures requirements (allocated requirements,

derived requirements, and formal discipline criteria) becomes the gate acceptance criteria (metrics) that

determine if the structural design is acceptable and complete. The specifications and design attributes from

the structures design plane are provided to the system and other design function planes. Obviously, some of

these specifications and attributes result in constraints for the other planes that place limitations on their

application and interaction with the structures design.

99
4.3.6.3.2 Task2--LoadsAnalysis.Utilizing inputsfrom (1) configuration,(2) naturalenvironment, (3) aerodynamics,(4) materials,(5) thermal,(6) trajectory,(7) control, and (8) propulsion;the

externalload environmentsaredetermined.For efficiency andease,the loadsanalysesareperformed

separatelyfor thevariousmissioneventsinvolving(1) transportationandhandling,(2)lift-off, (3)maxq,

(4)maxg,(5) separationandstaging,(6) docking,(7)reentry,and(8)landingandrecovery.Theseinputs

arealsoaddressedin theNxN diagram,processflow, andWBS charts.Tables10and 11definetheWBS

taskswith inputs andoutputs (products)which include the load analysis.Table 12definesthe total

structuralanalysistasks,includinginputsandoutputs,with theloadanalysisbeingoneelement.Thetasks

in thesethreetablesarecompatible.The other designactivities arecoveredin the subsequentasks.

Structuralmodels,bothrigid body anddynamic,mustbedevelopedfor eachevent,describingtheplant

characteristics. Thesemodelsarethencombinedinto appropriatesystemmodelswith all theenvironmental

inputs,constraints,etc.,anda responseanalysisis run to determinethecombinedloads.Thesemustbe

definedin somestatisticalor quantifiablemanneraccountingfor variationsandunknowns.Theseresults

alongwith otherdatabecometheinputto thenexttask.

Duringthis process,if excessiveloadsexist,thentheloadspecialistworks informallywith other

disciplinesin anattemptto resolvethe issue.Can aerodynamicsbealtered?Are the variationsof key

parameterstoo conservative?Are the criteria too conservative?Can the wind model be changed?Are

dynamictuningscreatingaproblem,requiringdetuning?

Occasionally,theissuescannotberesolvedinformally.In thiscasetheissueiscarriedtothesystem

planewheretradesand balancesare accomplishedacrossthe subsystems,designfunctions,etc. For

example,theconfigurationshapemaybealteredto changetheaerodynamics.In orderto reduceloads,yet

maintainanacceptablesystem,criteriacanbechangedaswell asdesignlevelsof parameteruncertainties

andtheir combinations.

Achievingthe acceptableloadssetrequiresthat the loadsspecialistsnot only communicateand

understandin depththeir specialty,but that they haveanunderstandingof the interactingdisciplines.

Togethertheymustclearlydefinerequirementsfor theneededinputdata.For example,theymustspecify

the neededresolutionof theaerodynamiccoefficientmatrix, pressuredistributionspatialresolution,and

critical locationsrequiring higherfidelity resolution.The interactionswith otherdisciplinesarevery

importantandcomplex.Theyincludebut arenot limited to thefollowing:

• Trajectories---definitionsof theflight pathandangles

• Control--the controllogic, controlgains,andthedynamicresponses

• Interfaces----definitionf mechanismenvelopes,constraintsrequiredfor separation,docking,etc.

• Material--materialspropertiesdefinition asafunctionof operationalenvironments

• Aerodynamics---definition of the aerodynamic and acoustic environments.

The detail of the load process, technically and computationally, is not a part of this report. Other

documentation (see bibliography) adequately covers those details. What is key here is an understanding of

the metrics for deciding when the job is finished and how the models, data, etc., are validated. Uncertainty

factors are normally used on loads until the model/data verification/validation are accomplished. This

validation pertains also to both the stiffness and mass distribution of the models.

100
4.3.6.3.3 Task3--Structural CapabilityDetermination.This taskis concernedwith determining

the structuralcapability usingthe loadsand otherinducedenvironmentalinputs suchasthermal.The

capabilityassessmentsincludeatleastthefollowing:

• Strength

• Ductility

• Fracture

• Fatigue

• Stability

• Deflection/interference

• Attachmentcapability(welds,fasteners,bonds,etc.)

• Vibroacousticcapability.

Very specific formal criteria arelevied for eachof theseareasand must be met or a waiver

approved.Thesecriteria in generalarethe meansof defining marginsfor the variouspredictedfailure

modes.If they arenot met,thenthe sameprocess,informal and formal, as discussedunderloadsis

employed.Therearefour maininteractions/interfacesfor the stressfunctions:loads,thermal,materials,

andfacilities.Theloadsandthermaldisciplinesdefinetheenvironmentsincludingaccelerations,deltaP's,

etc.Thematerialsdisciplinedefinesthe materialspropertiesasa function of operationalenvironments.

Assemblyandlaunchfacilitiesdefineinterfaces,constraints,etc.

The activities onthe structuresplanerequireunderstandingloadpathsand stressvariationsand

concentrations.As a resultnotonly mustthespecialistunderstandthemanyvariouscomputerizedtools

suchasfinite elementcodes,thermalcodes,grid codes,graphiccodes,etc.,butmustbeableto analyzeby

handspecialcasesof structuralresponseandevaluatethemwith respectto criteriaandspecifications.

Thestructuralanalysisfunctionandthestructuraldesignfunctionarehighlyinteractive.Thereare,in

general,two avenuesopenif thecriteriaarenotmet:(1)Changethedesigntoaccommodatetheenvironments

or (2)reducetheenvironments(loads)asdiscussedunderloads.As aresult,communicationsbetweenloads,

design,and stressaretightly knitted.Manyproblemscanbe solvedinformallyamongthe threegroups;

however,somecritical tradesmustbemadethroughthe systemsplanedueto the highcomplexityof the

interactionswhichrequiretestsandcompromises.

4.3.6.3.4Task4--Structural Design.Structuraldesignisoneof themostcomplextasksin developinga launchvehicle.It requiresstronginteractionswith all otherdisciplines,subsystems,etc.,andthe

designermustbethe structuraldesignintegrator.This dictatesthat thedesignerhasnotonly anindepth

understandingof design(loadpaths,functions,materials,attachments,etc.)butalsoanunderstandingof

thesupportingdisciplines,subsystems,elements,etc.Partsstandardizationknowledge,aswell asaccepted

designapproaches,is alsoimportant.Materialsselectionis a key choicein design.All the marginsare

drivenbymaterialsselection,asismassfraction,weight,etc.Thestructuraldesigntasksaresuboptimized

tasksinthatthedesignis drivenby constraintsandinterfacerequirementsaswell asloadsandthermaland

manyothertasks.As eachdesigncycleis approached,thepreviousdesigncycleconfigurationis refined.

In eachnew cycle, all problemsraisedin the previouscycle areaccommodatedor challengedon the

systemsplaneagainstotherrequirements,criteria,anddisciplines.In generalthefinal decisionmustbe

approvedat thesystemlevel.

101
Not only must the design tasks accommodate loads and thermal, but, also, they must accommodate

design considerations of the following other factors:

• Cost

• Performance--mainly weight; structural efficiency

• Operations--processing, check out, accommodation, accessibility

• Propulsion--thrust frames and element location, lines, ducts, engines, etc.

• Avionics--accommodation of electrical components, sensors, and actuator

• Pyrotechnics--location and security

• Manufacturing and assembly---design to accommodate and optimize

• Launch facilities--interfaces, accessibility, etc.

• TPS--structural design provides the support for the TPS

• Packaging--structural design provides location and support for components, etc.

• Materials--material characteristics required.

The design process is further complicated by the wide choice of materials from composites to

metallics; shapes, particularly shapes of tanks and fairings; stabilization techniques such as orthogrid, ring

stringer, etc.; and manufacturing approaches such as welding, casting, powder metallurgy, etc. The wide

choice of attachment approaches such as welding, rivets, adhesives, bolts, etc., is also a major

consideration. Additionally, cost considerations greatly complicate the design process. All have impacts on

structural margins and weights.

The design is complete when all the decision gates are satisfied. Those gates include the top-level

requirements, structural assurance, subsystems accommodations, and other significant design

considerations as shown in figure 50. The top-level requirements are met with appropriate cost, weight,

mass fraction, etc. The structural assurance is achieved when all the stability criteria and structural margins

are satisfied. All subsystems and interfaces such as TPS, propulsion, avionics, and launch facility must be

accommodated efficiently. Finally, the design must meet the gates of acceptable manufacturing, assembly,

and operations. When all these gates are met, the drawings and specifications can be finalized.

4.3.6.3.5 Task 5--Verification. Verification of structural systems is one of the key tasks of assuring

a launch vehicle is ready to fly. The verification process ensures first that the structures meet or exceed the

requirements/specifications and, second, that the operational constraints/procedure are adequate to ensure

structural integrity. The verification is a combination of analysis, similarity, and testing. Structural testing

is the preferred approach; however, due to the cost of structural testing and the maturing fidelity of

structural analysis, analysis is used in special cases in lieu of testing. Protoflight testing of structures is

another viable option which incurs a small risk to flight hardware but validates the structure to loads

slightly greater than limit. The missing link is quantification and understanding of critical failure mode

margins. The philosophy of protoflight testing is "Test the hardware to a specific margin above the largest

expected flight load (usually 5 percent), correlate the analytical model to that load, update the model, then

use the updated model to predict margins." Structural verification is, therefore, a combination of similarity;

testing, and analysis.

102
a. Similarity.

Verification by similarity is valid where a similar structurehasbeenverified by testand the

similaritiescanbequantified.In general,thistechniqueisusedwhentwoor moreof thesamearticlesare

built. In the caseof componentswhich must passenvironmentaltesting at both the qualification]

verificationlevelandacceptancelevel,only onearticleof afamily (i.e.,commonvalves)is qualification

tested,thusqualifying the othersby similarity. Acceptancetests,however,mustbe performedon all

articles.Theseenvironmentaltestsinclude acoustic,vibration, and thermal.Sinceit is expensiveand

schedulecritical, vibrationenvironments(criteriathat areacousticallydriven)cannotalwaysbeverified

by acoustictests.Two techniquesareusedto verify thesecriteria: (1) Data bank scalingof similar

structuresthathavebeentestedand(2) statisticalenergyanalysis(SEA).

b. Testing.

As statedpreviously,testingis thepreferredmethodof verifying the structure; however, cost and

schedule many times prevents testing. Structural testing occurs at the part, component, subsystem, and

system levels. Structural testing has several major categories:

• Component qualification and acceptance (vibration, acoustics, thermal/vacuum)

• Dynamics

• Strength

• Stability

• Aeroelasticity (flutter, divergence, etc.)

• Fatigue

• Proof (fracture)

• External loads

• Pressure.

Testing is accomplished to meet specifications, and traceability must be shown between the

requirements and the test results.

Coupon tests are conducted by the materials discipline establishing the materials characteristics in

the following areas:

• Ultimate strength

• Yield strength

• Fatigue life

• Fracture

• Environmental compatibility.

Where required, these tests must include temperature and environmental effects.

Component qualification and acceptance testing was discussed under similarity.

103
Dynamictests are required to validate the dynamic model for control system design, Pogo suppression, aeroelasticity, and loads. Models are corrected and updated based on the tests, then used by the above

mentioned disciplines to perform their design and verification analysis. The test hardware must simulate or

duplicate the dynamic characteristics of the system. Mass simulators can be used for components whose

frequencies are outside the frequency range of the basic modes. Also, too many dynamically tuned or

closely spaced component frequencies can contaminate the basic modal data, making it hard to get

accurate data. Judgment must be used as to which are important. Sensitivity analysis helps quantity this

judgment. Dynamic tests must consider boundary conditions, excitation methods and locations,

instrumentation, modal goodness criteria, data collection, and evaluation systems. Testing boundary

conditions in general are either fixed, fixed hinged, or free-free. Excitation methods are single-point

random, multi-point random, sine sweep, sine dwell, and impulse. Model assurance criteria are used for

mode selections from the test for modal correlation. These range from frequency accuracy to modal cross

correlation, etc. Dynamic testing verifies the dynamic stiffness and mass distribution assumed by the

analytical modeler.

Strength verification applies the external loads environment, verifying the analytical model's static

stiffness assumptions and the critical load paths. If the structure is tested to failure, margins are verified

along with critical failure modes. As discussed previously, if protoflight test is used, the structure is tested

to limit load plus some margin below yield. The correlated/updated model is then used to predict margins.

Aeroelastic testing establishes flutter margins. This is accomplished as an integrated structures/

aerodynamic wind tunnel test. The structures discipline must design the scaled wind tunnel model to have

the appropriate scaled modal frequencies required to predict flutter.

Proof testing takes advantage of fracture data, establishing that no flaws are present which will lead

to failure in a prescribed mission lifetime. Proof pressure testing is used extensively for pressure vessels

and rotating machinery.

c. Analysis.

Verification by analysis is becoming an acceptable approach in today's environment. There are two

basic approaches used for verification by analysis: (1) Models are benchmarked or correlated using tests

(in particular protoflight test) and then used to predict structural failure modes and margins and (2) larger

design safety factors are used to cover model uncertainties. Models/analysis also play a key role in test

verification, predicting the test response, instrumentation utilization, loads application, etc.

Structural verification uses the above three approaches (similarity, testing, and analysis),

either independently or interdependently. Structural verification is complete when the requirements have

been met. If requirements are not met, three options exist: (1) Redesign, (2) waive requirement, or

(3) implement operational constraints and procedures.

104
J

.r!t

it ̧

.!l

I/

i ,

i#

i1

iJ

_6

THERMAL

System

AerodynamJcs

41

Trajectory/G&N

i

Control

!

|

_ Structures

t

Thermal

t

Propulsion

t _ Avionics

I

Materials

1

t _ Manufacturing

j _ Other

',,................... _. ,.._

Figure 53. Design process technical integration--thermal design function.

4.3.7 Thermal Design Function

The connection between the design process technical integration and the thermal design function is

delineated in figure 53. The illustration depicts the relationship between the thermal design function and

the other design functions. In addition, it shows the work/information flow process that is

supported by key thermal decision gates required to develop and assess the thermal attributes. The details

of all the above are delineated in this section.

The thermal design activity is fundamental to the vehicle design and its operational success. It

consists of determining the thermal environments (with input from aerothermal), predicting the heat

transfer, achieving the thermal designs, and providing verification. The thermal design activities provide

design of insulation, TPS, and component and compartment TCS's. These systems provide the desired

thermal states for structures, propellants, components, payloads, and crew. An important function is

providing structural temperatures for stress fields for fracture, fatigue, and deflection.

105
4.3.7.1 Thermal Design Function Plane. The thermal design plane is shown in figure 54. It

depicts the thermal design flow and various interacting discipline functions. The design process flow starts

with requirements and the thermal system definition. Following these are the thermal system philosophies,

procedures, and criteria. As in the other planes, the parameter matrix and uncertainties are developed by

the discipline functions in conjunction with the system plane. The major discipline functions shown are

heat transfer, thermal response, and thermal environments for such things as compartments and tanks.

Outputs from these activities, as well as inputs from other disciplines, become the inputs for the TPS and

TCS design. More details of the tasks are in later sections. The attributes of the thermal design are compared

to requirements. If they meet the requirements, the design is complete; otherwise design iterations occur. If

the design iterations cannot solve the problem, then the system plane becomes involved with trades and

balances to achieve overall convergence.

0 :2

{ntegration_

Thermal

Requirements

and Constraints

1

Yes _ _ No

(Stop) _, (Iterate)

Thermal Attributes

• Deflections

• Material Limits

• Compartment

Environments

• Cost

• Reliability

• Operability

_,_ Thermal System

Thermal System Philosophy

Definition Procedures

Criteria

Tps and

Thermal

Design

Figure 54. Thermal design function plane.

Thermal

Parameter Matrix

and

Uncertainties

._ Heat

Transfer

._ Thermal Response

IThermal Environment I

I Compartments L_

"_-] Tanks I--

_ Special Analyses

and Tests:

Combined

Environments

The thermal process flow from reference 2 is shown in figure 55. External inputs are shown as

requirements, one-way inputs and outputs, and two-way inputs/outputs. These are the details of what is

illustrated on the thermal design plane. The process flow represents the details of the discipline flow of the

thermal design plane (shown as heat transfer, etc.). Depicted are the analysis tasks, thermal design data,

and thermal design areas. The NxN diagram of reference 2 (Appendix A) is representative of further

delineation of the inputs and outputs associated with the thermal design function. More detailed discussion

is provided in the following para_aphs.

106
Requirements

• Programs/Project L

• Concepts [ "-

• Constraints |

• Designs ..... ............r- l_

Inputs (One-Way)

• Natural Environments

• Safety

Outputs(One-Way)

• Ground Operations

Inputs/Outputs (Two-Way)

• Performance and Trajectories

• Aerodynamics and Induced

Environments

• Structural Analysis

• Vehicle Configuration

and Structural Design

• Materials

• Propulsion

• Communications and Data

Handling

• Electrical Power

• Mass Properties

• Flight Operations

• Cost

• Reliability

Internal Flow

I Consultation I Options I T'a, les I Analysis I Cosl I

Thermal Models/Analysis

• Environments/Properties

Data Base

• Develop Models/Analyze

- TPS

- Cryogenic Tanks/Insulation

- Main PropulsionSystem

(MPS) Components/Insulation

- Structures

- Compartment Conditioning

- TCS(Active/Passive)

- Integrated vehicle

Thermal Design Data

• Material Selections

• Establish TPS Split Lines

• Establish TPS Thickness/Sizing

• Establish Insulation Location/

Thickness/Sizing

• Determine Minimum/Maximum

Temperatures

Determine Structural Gradients

Fluid Selection

Heat Rejection Modes

Special Components

OverallThermal Integration

Thermal Interfacing Definition

Establish Compartment

Environments

Thermal Design

• TPS

-Aerothermal

-Base Heating

-Control Surfaces/

Leading Edges

Insulation

-Tanks

-MPS Components

Structures

Compartment Conditioninc

TCS(Active/Passive)

Products

TPS Sizing

Cryogenic Insulation

Sizing

Structure Temperatures/

Gradients

TCSSizing

Compartment

Environments

Thermal Design

Figure 55. WBS 2.5--thermal design process flow. 2

4.3.7.2 Thermal Gates. The decision gates for the thermal design process are shown in figure 56.

All these gates must be satisfied to produce the design of TPS, insulation, and TCS and to output structural

temperatures and compartmental environments.

The thermal design must pass not only the performance gates (margins and sensitivity) but also the

discipline gates such as structural integrity. Thermal design is complicated in that it must protect from

plume and aero heating, condition propellants (tank insulation), and provide thermal environments for

components and crew. Interactions with other disciplines are a fundamental part of meeting the thermal

gates. If the gates cannot be met through informal design interactions, the system plane is used to make

trades and balance requirements. Foremost in the thermal gates is that the thermal model must be shown to

have the accuracy required to predict thermal characteristics. Other gates include acceptable cost,

reliability, and operability.

107
Operability

'No I

Yes

_. No

_ Reliability

t_No

, Thermal Requirements

and Constraints

• Thermal Configuration

• Philosophy, Procedures

and Criteria

Yes

,_ Compartments

Environments

Criteria

!

, No

I

I

Systen

kerodynanTic_

Thermal

Analysis

Tests

NO °i

I

I

I insulatio Criterian

TPS Design

Insulation Design

TCS Design

Structural Temperature

Compartment Environments

Yes

Figure 56. Thermal design function gates.

4.3.7.3 Tasks. The thermal WBS tasks from reference 2 are shown in table 13. These tasks delineate

the discipline tasks depicted on the thermal design plane, figure 54.

Shown in table 14 are the top-level thermal design function tasks including the activities, the interactions, and the tasks. This task matrix is provided to illustrate primary technical interacting activities

discussed in the following paragraphs.

4.3.7.3.1 Task 1--Requirements Determination and Allocation. Task 1 is a joint activity with

systems and other design functions to jointly define and allocate the systems and thermal requirements and

criteria for thermal design application. As a part of this activity, a preliminary definition is made of the

thermal system. Associated with this are the design philosophy, parameter definition, and uncertainties.

108
Table13.WBS 2.5--thermaldesigntaskdescription.2

Inputs Tasks Outputs

•Projected groundrules

*Design-to-costgoals

•Preliminary design concept and data base

•Launch pad environments

•Configuration details, materials,

dimensions

,.,*Ascent, cruise, loading requirements

•Ascent aeroheating histories

• Entry aeroheating histories

•Compartment flow rates

• Plume heating environments

•Temperaturegradient design limits

• Mass properties control plan

• Documented control weights

•Weights, centers of gravity, moments

of inertia

• Ground hold conditions

• Heat load requirements for propellant

conditioning

*Chill down requirements

.Engine configuration

• Engine operating characteristics

.Engine thermal requirements

.Material thermal properties

•Material allowables

m Material selection consultation

,.,-TPS vehicle interface definition

,,,. Material thermal required

.Thermal design limits

.Sensor characteristics

.EPS operational environment

requirements

•Vehicle integrated OPSconcept

and requirements

.Hazard analysis

-Fault tolerance requirements

-Failure mode effects analysis inputs

,--CIL inputs

• Hardwaredesign, development, testing,

evaluation, and production costs

• Cost trades

3.6.1 Review PhaseA results

3.6.2 Establish properties data base

3.6.3 Analyze thermal design concepts

- TPS

- Cryogenic insulation

- Compartment thermal assessment

- TCS(active/passive)

- MPS

3.6.4 TPS sizing

3.6.5 Cryogenic insulation sizing

3.6.6 TCSsizing (active/passive)

3.6.7 Compartment thermal environments

3.6.1] MPS thermal sizing

Tools:

• Commercial software--SINDA and PATRAN

• In-house software

•Ternperaturesensor

locations

,-, Wall/surface temperatures

•Heating rate or temperature

indicators

•Heating constraints

•* Wall/surface temperatures

•Structural temperatures

and gradients

•TPS sizing (aerothermal/base

heating)

•Cryogenic insulation sizing

•Active TCSsizing

•Component weight estimates

•Parts list

• Propellant condition

•Temperature time history

.Pressure

•Chilldown of engine

•Temperature and heating loads

• Structural temperature

requirements

•Thermal environment

•Thermal environment for EPS

•Power requirements for

thermal control system

•Structural temperature

requirements

•Subsystem definition and design

description document

•Environments and loads definition

•Materials type

•Technical descriptions

•Test requirements to include

instrumentation

•Production quantities

• Make or buy plan

Key: • ELV,RLV,and RBCC

•,, RLVand RBCC

,,_ RBCConly

4.3.7.3.2 Task 2--Thermal Analysis. Task 2 utilizes Task 1 requirements and preliminary definition

in conjunction with the design reference trajectory and the predicted external thermal environments to calculate

the heat transfer, thus the temperature of the structure. The task evolves into three distinct analysis areas:

• Thermal environments considering radiation, convection, and conduction for the compartments

and tanks, as well as human environments, payload conditioning, etc.

• Heat transfer characteristics

• Thermal response of the system to the thermal environment.

109
Table 14. Primary tasks for thermal design function.

1. Requirements

determination and

allocation

2. Thermal analysis

Activities Interactions Tasks

1.

3. Thermal system design

4. Verification

Mass properties

System

Aerodynamics

Propulsion

Trajectories

Structures

Consult with system to obtain operations philosophy, constraints,

cost, etc.

2. Obtain definition of configuration.

3. Provide to systems plane discipline peculiar criteria for formal/

legal application.

4. Develop thermal verification requirements.

5. Develop thermal requirements into gate matrices.

6. Flow up derived requirements to system.

Aerodynamics 1.

Propulsion

Structures 2.

Trajectories 3.

4.

5.

1.

2.

Test 1.

Trajectories

Stress

2.

3.

4.

5.

Set up describing equations for each of the separate subsystems

and mission events.

Develop all input data and executevarious thermal analysis.

Work with interacting disciplines to resolve anomalies, etc.

Consult with system to resolve remaining issues.

Insure that cost, reliability, etc., are included in trades, etc.

Using system requirements, thermal analysis results, etc., design

the TPS outputting design specifications to serve as the baseline

for the next design iterations or for verification.

Using system requirements, thermal analysis results, etc., design

the TCSoutputting design specifications to serve on the

baseline for the next iteration or for verification.

Work with interacting disciplines to determine test facility

requirements, test conditions, instrumentation, and data

system requirements.

Work between disciplines to accomplish verification test.

Work between disciplines to evaluate results.

Flow up anomalies for resolution and operational procedures

definition.

Final thermal verification achieved in development flights.

These data become the inputs for thermal design of TPS, life support systems, payload

conditioning, and compartments, and for structural design to account for thermal effects. Thermal effects

on structure include stresses, deflections, and materials property changes. Execution of this task requires

close communications with the trajectory, materials, structures, propulsion, avionics, and aerodynamic

design functions. This interaction includes both input data and output data. For example, the propulsion

system may use a regenerative-cooled nozzle or an ablative nozzle where each requires special analysis.

The regenerative-nozzle analysis includes flow circuits, boundary layers, film coefficients, heat transfer,

etc. The ablative nozzle analysis combines heat transfer, gas dynamics, pyrolosis, materials, erosion, etc.,

to determine thermal/materials characteristics.

110
4.3.7.3.3 Task 3--Thermal System Design. This task is responsible for the design of the various

thermal systems. These designs include at least the following:

• TPS and insulation for propellant conditioning

• TPS for aerodynamic and plume heating

• Life support thermal environment system

• Payload conditioning

• Ablative nozzles

• Regenerative and passively cooled nozzles

• Solid rocket motor insulation and heat protection

• Compartment and component thermal conditioning (includes avionics components).

Thermal design interfaces with the other design functions and with systems. These exchanges are

both formal and informal. As the design evolves, the gates for completion are a combination of the performance and the specialist's criteria. For example, structural margins for strength, fracture, and fatigue

(influenced by temperature) must be met. The performance gates usually have to do with the resulting

thermal environments and/or materials limits. Cost and operability are additional gates. Special gates exist

for the special systems such as life support and ablative nozzles. The system, the design function, and the

disciplines determine these special gates.

Usually, thermal gates are worked informally with the various disciplines. If the informal approach

cannot achieve an adequate design, then the system design function must provide the appropriate balance

to achieve the best design. Engineering judgment plays a central role in the balancing act.

4.3.7.3.4 Task 4--Verification. Thermal verification generally is achieved using tests. These tests

are for both components and subsystems. The tests are designed to duplicate the environments. As a result

many thermal verification tasks must be accomplished in thermal vacuum chambers. Other tests include

wind tunnel and hot-gas facility testing for aeroheating and propulsion plume impingement and solid rocket

motor hot-fire test beds for solid rocket motor (SRM) components.

Designing and conducting high-fidelity ground component and subsystem tests are essential to the

verification process. Proper boundary conditions and environments must be ensured. All tests as with all

models are approximations; therefore, the test limitations must be well understood and challenged.

Verification, therefore, requires the following:

• Environments definition

• Component definition

• Test constraints and fixtures

• Instrumentation and data systems requirements

• Test conduction

• Test data evaluation

• Correlation of analysis to test data.

The verification of the thermal design is achieved when the analysis and hardware test data meet

the requirements. Final verification can only be accomplished during developmental flight testing. It is

very important that the development flights have proper instrumentation and data systems.

111
&

II

PROPULSION

System

Aerodynamics

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

Figure 57. Design process technical integration--propulsion design function.

4.3.8 Propulsion Design Function

The connection between the design process technical integration and the propulsion design

function is delineated in figure 57. The illustration depicts the relationship between the propulsion design

function and the other design functions. In addition, it shows the work/information flow process which is

supported by key propulsion decision gates that are required to develop and assess the propulsion

attributes. The details of all the above are delineated in this section.

112
(Note: Design of the propulsion subsystem is a complex process in itself, involving numerous

subsystems and specialties. This report does not describe the propulsion design process in detail but

provides a top-level overview to show its relationship and interaction with the total vehicle design using a

liquid engine system as an example.)

The design of the propulsion system is strongly coupled with the structural design as well as the

flight mechanics (trajectory, control response, etc.). The interrelationship between these design areas is

very complex. Vehicle design can be characterized as putting a given payload into a specific orbit by

achieving minimum dry weight with a highly efficient propulsion system. The propulsion system converts

chemical, etc., energy into thrust, pushing the vehicle and payload into the desired orbit. Choice of the

energy conversion system (liquid engine, solids, etc.) and energy source clearly has a strong influence on

the structural system. Coupled together, they determine the flight mechanics system. Vehicle design from

the performance standpoint is, therefore, concerned with three focus areas: (1) Structural (dry mass)

efficiency, (2) propulsion system efficiency, and (3) management of losses (nonideal effects).

4.3.8.1 Propulsion Design Function Plane. The top-level propulsion system (for a liquid engine

example) design function is illustrated in figure 58. This figure shows as separate activities the design of

the engine subsystems and/or elements. These are turbomachinery, combustion devices, lines, ducts, valves,

ignition system, and the engine system. Each of these propulsion subsystems requires its own design

including all of the interactions of the supporting discipline functions. The propulsion design process would

be comparable to the design process presented in this report. This top-level chart is provided because of the

strong interaction between the propulsion system and the rest of the launch vehicle.

Requirements Configuration

and Constraints Definition

(Stop) I (Iterate) 4

-d

-4

Propulsion System

Attributes

• Thrust to Weight

(T/W)

• Isp

• Size

• Strength

• Endurance

• Cost Factors

• Reliability Factors

• Complexity Factors

• Failure Modes

i[

Informal _

_lntegration ;;

Procedures ro0 ,s,on t--I Parameter ro u,s,on Matrix ]--l er'° mand

Criteria and Layout

Approaches Uncertainty

TankageSystem Design

Turbomachinery Design

Combustion Devices Design

F

I--

I--

I--

F

Lines, Ducts, and Valves Design

Ignition System Design

Propulsion

System

Design

Figure 58. Propulsion design function plane.

113
This strong interaction results in many trades and balancing of the attributes of the propulsion

system and the other design functions of the vehicle such as trajectory, structures, and control. These

design functions are heavily involved also in the system trades which balance requirements and performance attributes. For example, there may be a trade between the amount of payload to orbit and the size of

the propulsion and structural systems, with the associated cost.

The process starts, as it has for each of the other planes, with requirements definition and

allocation, then proceeds to the parameter matrix definition, then to design the system, subsystems, etc.

Section 4.3.1 discusses this generic process.

Figure 59 from reference 2 shows the inputs, outputs, requirements, and products, as well as a

limited process flow. The process flow only shows the activities supporting structural design and trajectory

design. The detail designs of the propulsion system and its subsystems are not shown; however, they are

required to generate the data for the activities shown. It is assumed that these complex activities are

accomplished in designing the propulsion system. The propulsion system entry on the NxN diagram from

reference 2 (app. A) follows the same pattern shown previously.

Requirements k

Program/Project L

Constraints r

Concepts ,,.... ..............

[

Inputs/Outputs (Two-Way)

• Vehicle Configuration

and Structural Design

• Performance and Trajectories

• Aerodynamics and Induced

Environments

• Structural Analysis

• Thermal

• Guidance and Controls

• Materials

• Communications and Data

Handling

• Electrical Power

• Ground Operations

• Flight Operations

• Manufacturing

• Safety

• Reliability

• Cost

Internal Flow

Feed System Geometry

• Tank/Feed System Analysis

,* Tank/Feed Fluids

_. Pressure Analysis

• Schematic Drawings

-Lines

-Ducts

-Valves

-Components

• Propellant Inventory

Hazards

Cost/Makeor

Buy

Materials/

PartsList

Benefits Reliability Operability ] Maintainability

Resources UtilizationI Requirements Feedback Test Requirements/ S/W I Servel I Algorithms Needs

Technica' DescriptionsISizing/ Confi_ur I Conceptual ,a,tion Sketches/Layouts

Products

• Designand Layouts

• Weights, Parts List

• MPS/Engine System

• Propellant Inventory

• Ullage Requirements

• Lox/Fuel FeedGeometry

• Net Positive Suction

Pressure (NPSP),

Pressure Drop

• Propellant Conditions

• Fluid,Thermal, Pressure

Models

FPR,Start/

Shutdown Transient

Figure 59. WBS 2.8--propulsion system design process flow diagram. 2

114
4.3.8.2 Propulsion Gates. Figure 60 illustrates the propulsion system decision gates. The gates

the propulsion system must meet include Isp, thrust, thrust to weight, and volumetric constraints, as well as

the normal discipline gates associated with the discipline functions. Examples are control system stability,

turbomachinery stability and vibration, thermal, structural strength, and durability, as well as other pertinent

gates associated with propulsion system design.

_ Operability

i..N° ..............

_ Reliability

i

t.No

_ines,Valve

andDucts

TurboMachinery

Ignition

Combustion

Devices

Propulsion

(Engine)

Tankage

• Drawingsand

Specifications

• Thrust

• Isp

• Size

• Weight

AcceptableJ

Software __

aequirementsl NoY

PropulsionRequirements

• Philosophy/Approach

• Geometry

• Mass

• Isp

• ThrustandTAN

Yes

No ,

i ......

Acceptable I

Strength,EnduranceI

Stability I

Performance Acceptable

• i

.,,................... No.. 

Figure 60. Propulsion design function gates.

The propulsion decision gates include first and foremost the engine performance, which is its

ability to efficiently convert chemical energy into propulsive energy (thrust) at the level required to meet

the vehicle performance. Implied in this statement are the additional factors of weight, thrust to weight,

volume, etc. The engine system must also meet cost, reliability, and operational requirements. In addition

to these performance and program requirements, the propulsion system, its subsystems, elements, and

components must meet all the discipline requirements such as strength, fracture, fatigue, thermal, etc.

Additional thoughts on these gates are in section 4.3.6.2. The major point to remember is that there are

many crucial trades between the propulsion system and the rest of the vehicle that result from attempting to

meet their respective gates. It should be remembered that the propulsion system provides the energy to

achieve orbit. In achieving this requirement, it dictates much of the structures design. For example, the

liquid propellant tanks and lines transfer the chemical potential energy to the engines that produce thrust

that transmits through thrust frames back to the tanks, etc., to achieve vehicle kinetic energy. Thus, the

propulsion system greatly influences the dry weight (mass fraction) of the system. The vehicle cannot

115
weigh too much or it is too costly. Its geometry cannot be too expansive or, again, operations and cost

are too high. Reusable systems also require well-defined, efficient, and effective maintenance and

refurbishment characteristics. All these become part of the propulsion system gates and tasks.

4.3.8.3. Propulsion Tasks.

4.3.8.3.1 Task l--Requirements Determination and Allocation. The propulsion system WBS from

reference 2, table 15, is limited to a set of tasks that interact with the other vehicle design functions. There

are many tasks required to design the propulsion system and produce the inputs for the tasks defined in

table 15. They include design of the engine system, turbomachinery, combustion devices, and engine

components. The discussion in the following paragraphs will briefly discuss these tasks. At top level,

technical integration tasks are shown in table 16. As with the other design planes, the charts show the

general activities, the interactions, and the tasks.

Propulsion system design, as all other design functions, starts with an interaction with the systems

plane to determine and allocate requirements to the propulsion plane. Because the propulsion system is composed of many subsystems and elements, these top-level requirements must then be distributed and allocated

to the propulsion subsystem levels; for example to turbomachinery and combustion devices. The subsystem

requirements are modified by the engine concept selected; e.g., staged combustion versus a gas generator

system. In addition, there is a strong interaction from the materials, manufacturing, and structure planes.

In the discussion that is to follow, it is assumed that the propulsion system has been chosen and that

the trades and sensitivity data generated to make the selection are available along with the preliminary

configuration definition (i.e., staged combustion cycle, liquid hydrogen and oxygen propellants, etc.). This

information, along with the above allocated requirements, starts the design process.

Propulsion system design to some extent follows the same compartmentalization approach

discussed previously. Subsystems include engine systems, line and ducts, valves, turbomachinery,

combustion devices, nozzles, control, etc., each requiring its own design specialties. Key disciplines are

rotordynamics, fluid dynamics, thermal, stress, dynamics, fatigue, fracture, combustion, etc. Not only

must the propulsion system meet all its engine specific gates but must satisfy the vehicle-imposed

requirements. Since the propulsion system ends up influencing a large percentage of the total structural

system, this interface is very important. Propellant tanks, for example, compose a large volume and weight

of the structure, carrying loads as well as propellant and conditioning the propellant in terms of at least

temperature and pressure. Propellant utilization is an important part of the design (how, when, etc., the

propellants are flowed and managed). This includes the provision for dumping propellant for aborts or

removing propellants during extended holds. A major factor in vehicle design is accommodation (location

and arrangement) of engines and the transfer of the energy (thrust) efficiently to provide vehicle

acceleration. The first task of propulsion system design is, therefore, the requirement determination and

allocation, first from the systems plane to propulsion plane, then from the propulsion plane to its various

subsystems, etc.

116
Table 15. WBS 2.8--propulsion task description, z

Inputs

• Projectedgroundrules,design-to-cost

goals

•Technologyrequirements(TRLlevel)

•EngineI/F

• Redundancyrequirements

•Programmaticconstraints

• Launchpad environments

•Vehicleconfigurationandtank geometry

• Line routingzones

•Pressurantbottle locations

--Preliminary air column

.,-Profile

•Vehiclemassversustime

• Thrust,accelerationand pressureversustime

•lsp(flow rates)

• Usablepropellantrequirements

• Axialacceleration

• Dynamicpressures

• Flowrates

•System dispersiOnS

•Wind dispersions

Air inlet constraints

'...Derived air volume

•Air loads on propulsionelements

- Engineinstalledthrust

_Forebody pressurerecoveryand flow

field definition history

•Structural analysisof lines and brackets

•Establishdynamicenvelopof feedline

• Determinelinethickness

_Aft/forebody structures

•Propellant condition

•Temperaturetime history

,Pressure

• Chilldown of engine

•Temperaturesand heatingloads

•Pogo suppressorrequirements

•TVArequirements

• RCSrequirements

• Masspropertiescontrol plan

•Weights,centersof gravity,moments

of inertia

• Materialcompatibility

• Contaminationanalysis

• Materialproperties

•Thermal and cryogenicproperties

•Temperaturelimits

•Telemetrycapability

•Sensorcharacteristics

•Availabilityof power(current, voltage,phase)

•Operationaltimelines

• Maintainability

•GSEcapability

•VehicleintegratedOPSconcept

and requirements

•Flight timellne

oFabficafionparameters

•Flight safety reviewof schematicand OPS

•East and westtest rangeinterface

•Hazardanalysis

•Faulttolerancerequirements

• Reliability allocationand estimation

•Failuremode effectsanalysisinputs

--ClL inputs

• HardwareDDT&Eand production costs

•Costtrades

Tasks

3.9.1 Establish baseline teed system geometry

3.9.2 Analyze tank/feed system fluid, thermal issues

- Temperature profiles

- Cryo fluid management

- Pressure drop, NPSP availability, water

hammer

- Residuals ullage

- Propellant inventory

3.9.3 Pressurization system sizing and design

3.9.4 Valves, ducts, mechanisms design, and layout

drawings

3.9.5 TVC componentsand design

1396 Propulsion system schematics andlayout

drawings

3.9.7 Testing engine/propulsion component

Tools:

• In-house software

• Fluid flow models--cryo fluid management thermal

models

• Testing

• Commercial software--CAD layout/drawing packages

Outputs

•Propellant inventory

•Propulsionsystem layout

•Tankpressures

•Propellant levelsensorlocations

--Forebody moldline (iteratereq air volume)

--Staging requirements

--Propellant requirements

--Numi_er of engines

--Performance updates

- Entry propellantweight

•Propellantload

•Engineperformance(Isp,thrust)

--Expected engine roachtransitions

--Inlet captive volume

,.,,Recoverypressures

--o_,for inlet airflow asa function

of roach number

--Mach transitions

• Enginedimensional and operational

characteristics

•Turbineexhaust definition

• On-padeffluent definition

--RBCC exhaust conditions

--Forebody inlet performancerequirements

• Ignitionand shutdown thrust transients

and timing sequences

•Steadystate thrust oscillation

• Ullage pressureand tankfill heightsversus

flighttime

•..RBCCexhaust/thrust

•Ground hold conditions

• Heatload requirementsfor propellanl

conditioning

• Chill down requirements

•Engineconfiguration

•Engineoperating characteristics

•Enginethermalrequirements

•TVCgimbal capability (degreeand rates)

•Feedlinelayout

•Kinematicanalysis

•PUsystem definition

--Air capture transition

•Propulsionsystem drawings and models

• Componentweight estimates

•Parts list

• Life limits

.Instrumentation

• Uplinlddownlink requirements

• Driveelectronics

• Electricalpower requirements

• MPScheckout and fill

• Refurbishment/inspectionrequirements

•Verification requirements

•Transportationrequirements

• Subsystemdefinition and design

description document

•Vehiclecontrols

• Powerusage

--Flight rules

• Drawingsand schematics

• Hazardanalysisinputs

• Functionalfailure model

•Failurepropagationlogic development

• Diagnosticstcontrotlogic

•Failuremode effectsanalysisinputs

--CIL inputs

•Technicaldescriptions

•Vendorquotes

•Testrequirements tOinclude

instrumentation

•Production quantities

• Makeor buy plan

Key: • ELY,RLV,and RBCC

•- RLV and RBCC

-.. RBCC only

117
Table 16. Primary tasks for propulsion design function.

Activities Interactions Tasks

Systems

Turbomachinery

Combustion

Valves, ducts

Structures

1. Requirements

determinationand

allocation

2. Enginesystem design

3. Enginesubsystemdesign

4. Verification

Thermal

Flow

Control

Trajectory

Flow

Thermal

Combustion

Turbomachinery

Controt

Structures

Testing

Propulsion systems

Materials

Flow

Thermal

Manufacturing

Testing

Propulsion system

Dynamics

Stress

Thermal

Manufacturing

Systems

1. Work with systems to flowdown requirements to propulsion

including thrust, Isp,T/W,geometry, tankage, etc.

2. Work with propulsion subsystems to allocate requirements for

design and verification.

3. Provideto systems, discipline peculiar criteria for formal/legal

applications.

4. Develop verification requirements for systems as well as

propulsion subsystems.

5. Developmetric flowdown for use by design function gates.

6. Flowup derived requirements to system.

1. Determine engine performancecharacteristics flowdown/allocate

requirements to subsystems in conjunction with subsystem inputs.

2. Develop propellants, usage requirements,and coordinate with

structural airframe design.

3. Estabtishproputsion systems devetopment and verification

ground-test and flight-test program in conjunction with systems

plane, propulsion subsystems, and disciplines.

1. Designcombustion devicesto meet vehicle systems and engine

systems requirements and discipline criteria.

2. Designturbomachinery to meet vehicle systems and engine

systems requirements and discipline criteria.

3. Designlines, ducts, and valves to meet vehiclesystems and

enginesystems requirements and discipline criteria.

4. Devetopground test programfrequirements for each subsystem.

1. Developfacility (test stands) requirements and implement in

conjunction with enginesystem, subsystems, and disciplines.

2. Coordinate hotfire test requirements with engine systems and

subsystems and disciplines including instrumentation, data

systems, and test profiles.

3. Run ground test program (hotfire) in conjunction with engine

system, subsystem, and disciplines, obtaining and coordinating

data for development,verification, and acceptance.

4. Develop plans for qualification and acceptancegates with engine

systems, subsystems, and disciplines for static and dynamic ground

test that includes, at least,flow, modal, fatigue, strength,vibration,

and thermal.

5. Run ground test programs (static and dynamic) in conjunction

with engine systems, subsystems, and disciplines obtaining and

coordinating data for development,verification, and acceptance.

6. Establish the constraints, maintenance,and operations procedures

from results of test program.

7. Final propulsion system validation is achieved in developmental

flight tests.

118
4.3.8.3.2 Task 2--Engine System Design. Task 2 takes these requirements/criteria and designs the

propulsion system. This design process is very complex. Analytical models are difficult to obtain. As a

result, during design and development of liquid propulsion systems it is mandatory that component and

systems tests be used to evolve the design. They can range from air- and water-flow simulations to hot-fire

component tests as the design evolves. Then, finally, propulsion systems are developed, verified, and

accepted in single engine and propulsion system test stands. A major design activity becomes one of

determining test profiles, evaluation metrics, acceptance metrics, etc.

The engine system design must combine all of the subsystems/components into a working system.

System design is very complex and challenging. How do you start the engine? How do you control flow

and mixture ratio? How do you throttle and shut down the engine? A part of this sequence is engine

conditioning before start due to the use of cryo propellants and engine conditioning and purging after

shutdown. Obviously, part of this design is tying the valves, actuators, igniters, etc., together through a

control system. The timing and balance between the propulsion subsystems, components, etc., is very

critical to engine operations. Packaging is also a key issue since, in general, volume is a prime design

constraint. As a result, the engine system must put all the parts together and ensure that they work.

Managing losses such as flow losses is very critical. Matching the propulsion system to the vehicle system

is mandatory. Therefore, interaction between the vehicle system and the propulsion system determines the

propellant capacity required, flow rate, and pressures to the vehicle system (then structures), as well as the

thrust, etc., and derived requirements such as pogo suppression. Thrust and Isp are provided as propulsion

attributes to the system and trajectory planes. Aerodynamics and thermal require the nozzle geometry,

thrust, etc., to generate aerodynamics (mainly drag) and plume heating environments. Also, in general, the

propulsion system provides thrust vectoring for vehicle controllability.

It should be pointed out again that the propulsion system and the vehicle are strongly coupled.

Eighty to ninety percent of the vehicle mass is propellant which drives the structural size. The propulsion

system provides the power for boosting payloads to orbit. Producing the power causes effects on

aerodynamics and vehicle drag. Usually engines are thrust vectored to provide control thrust as well as

axial thrust, in addition to the large coupling with launch vehicle system performance. As a result, detailed

communication is required between the propulsion system, the vehicle system, and the other design

functions and subsystems.

4.3.8.3.3 Task 3 Engine Subsystem Design. The subsystemcomponent design usually proceeds

in parallel. Turbomachinery must move the propellants at a certain flow rate and pressure. As a result the

pumps are a high-energy system requiring a large power source to provide the energy to move the

propellants. The first set of gates for turbomachinery design is, therefore, its performance in terms of flow

rate and pressure. Designing this type of high performance machine introduces the potential for cavitation

and other propellant instabilities that can destroy a pump or degrade its performance. These stability

margins become a another set of gates. Rotordynamic stability is another design issue requiring not only

damping devices but also minimizing the destabilizing forces. Excessive vibration prevention due to

unbalance, etc., is another design task. Gates for rotordynamic stability margins and vibration levels are

required. The turbine can have the same kind of issues including disk mode instability, flutter of turbine

blades, etc., which must be prevented and require gates as weI1. Beating wear is also a design issue. The

gate on bearings can be a trade between lifetime and maintenance (bearing replacement). In addition to

these very complex, dynamic, and thermal issues, the pump is also a pressure vessel (high pressure) and

119
must meet strength requirements. It also must meet durability requirements that include low- and

high-cycle fatigue, fracture, flutter/vortex shedding, acoustics, and creep. The turbomachinery is,

therefore, a very complex design problem with a very stringent set of gates from performance, to stability,

to strength and durability. There are other gates which must be met, such as weight and cost; however,

some trades to balance can be made between subsystems and at the engine systems plane, as well as at the

vehicle systems plane.

Combustion devices follow a similar breakout of design tasks and gates. The first task is the energy

conversion task (combustion). Due to the shape of the chamber and other factors, combustion instability

can occur, reducing efficiency or even destroying the engine. Gates exist for performance as well as

stability. Thrust and Isp are the performance gates. Combustion instability is difficult to predict

analytically, thus resorting to test. Combustion chambers and devices are subject to flow instabilities,

strength, fatigue, and fracture. Large thermal gradients impact the low-cycle fatigue. Gates, usually the

typical structure types, are necessary for these areas. All combustion processes create noise which also

impacts the fatigue gates. The combustion device design is also complicated by ignition.

Nozzles can be considered a part of combustion devices or a separate entity. They are very strongly

coupled with the combustion devices and the overall performance of the system. Basically, the nozzle

shape greatly influences the thrust of the engine. At sea level a low nozzle exit-area-to-throat-area ratio is

needed to maintain throat stability as a function of power. At vacuum conditions, a large area ratio is

required. Most engine nozzle design is a compromise between atmospheric and vacuum conditions, thus a

restriction on the throttle (thrust) level is required in the atmosphere. During start up and shutdown, large

shock transients are produced. These transients can produce fatigue damage to the nozzle. Nozzle cooling

can be passive or regenerative. In the regenerative cooled case, care must be taken to control leakage,

particularly if the engine burns hydrogen. Clearly the nozzle design must deal with strength, fracture, and

fatigue. These issues are complicated by the large thermal gradients present. The nozzle design must meet

weight, dynamic, and performance gates, as well as the typical strength, fracture, and fatigue gates.

Valves, actuators, lines, ducts etc., all follow the same approach. Their design must meet the

performance gates, as well as the standard structures and materials gates. Because of materials

compatibility issues, especially with hydrogen and other exotic propellants, gates for materials

compatibility exist for the design of all engine parts. Stress corrosion can be a problem for some parts.

4.3.8.3.4 Task 4--Verification. Verification of the propulsion system is very complex and costly,

due first to the complexity of the fluid flow and chemical conversion systems (combustion devices).

Second, the high performance requirements drive structural design, flow design, thermal design, etc.,

which usually require special verification. Verification is always a combination of analysis, simulation,

and test. The tests consist of component and element tests and system hot-fire tests. Not including all the

developmental tests, SSME required for certification at the engine system levels 20,000 seconds on each

of two engines of hot-fire ground test. Each new engine or refurbished engine must pass a hot-fire ground

acceptance test. The engines and hot-fn'e tests have special instrumentation for adequate evaluation.

120
In additionto these engine system tests, the following tests are performed on elements and components:

• Cold flow (water and air)

• Dynamic (model testing, spin-pit testing)

• Proof pressure

• Strength

• Fatigue (low and high cycle)

• Qualification and acceptance

• Vibration

• Thermal

• Material characterization

- Extreme hot and cold (near melting to cryo)

- Environments (hydrogen embrittlement)

- High mean loads.

Key also is the use of simulations where the engine components and elements such as avionics/

control, valves, etc., are coupled with a computer simulation of the other functions such as the combustion

process. This allows efficient verification of sequencing, coupling, and software.

Analysis with test verified models is used in general to establish propulsion system structural

margins such as strength. Many other analysis tasks include extrapolation to flight environments,

off-nominal conditions, etc. There are many verifications which are combined test and analysis. These

include propellant conditioning that leads to temperature and pressure requirements on tanks and lines,

engine conditioning, start sequences, shutdown sequences, and purges.

Verification of the propulsion system is, therefore, very complex as touched on here briefly. The

complexity is greatly increased for high performance manned usage. In this case, reliability and safety is

crucial, leading to the requirement for safe engine shutdowns and vehicle aborts. The final verification is

achieved through developmental flight testing.

121
AVIONICS

System

Aerodynamics

TrajectorylG&N

Control

Structures

Thermal

Propulsion _, _

Avionics ,_

Materials

Manufacturing

Other

Figure 61. Design process technical integration--avionics design function.

4.3.9 Avionics Design Function

The connection between the design process technical integration and the avionics design function

is delineated in figure 61. The illustration depicts the relationship between the avionics design function

and the other subsystem design functions. In addition, it shows the work/information flow process that is

supported by key avionics decision gates that are required to develop and assess the avionics attributes.

The details of all the above are delineated in this section. (Note: Design of the avionics subsystem is a

complex process in itself, involving numerous subsystems and specialties. This document does not

describe the avionics design process in detail but provides a top-level overview to show its relationship

and interaction with the total vehicle design process.)

In this report, the avionics subsystem includes all vehicle electrical and electronic systems, such as

GN&C, RF/communications, data management subsystem (DMS) including computers and engine

controllers, instrumentation, software, electrical ground support equipment (EGSE), and the electrical

power system.

122
4.3.9.1 Avionics Design Function Plane. The avionics design function includes responsibility for

designing the electrical and electronic hardware and software that comprise the avionics system for the

vehicle. The avionics system is often considered to be the flight system only. However, both the flight

systems and the ground support and checkout systems are included here as part of the avionics design

function. Subsystems of the avionics system include GN&C, DMS, RF/communications, instrumentation,

software, EGSE, computers, and electrical power. Typical flight hardware components include the vehicle

computer, the engine controller(s), the telemetry processor, multiplexers, data storage, antennas, transmitters,

receivers, video cameras and processors, instrumentation, sensors, signal conditioners, batteries, cabling,

power conditioners, power distributors, rate gyros, and actuator controls. The avionics design function

plane is illustrated in figure 62. The avionics design function involves the synthesis of the avionics system

to meet requirements in two general categories: (1) Performance of the electrical /electronic systems and

(2) resource and interface requirements, including cost, reliability, weight, power use, volume, and thermal

conditions. The design of the avionics system involves interactions with disciplines in other design functions

including the systems plane. Interaction with the systems plane is vital in determining the requirements for

the avionics system. The system plane establishes the aforementioned general categories of requirements.

Internal to the avionics design function is the avionics system engineering and integration discipline.

This discipline is responsible for understanding the requirements for avionics from the systems plane and

deriving the more detailed avionics system requirements. Requirements are allocated and analyses and

trade studies are performed. Reliability requirements are considered together with weight, power, volume,

and cost to determine the appropriate level of redundancy and redundancy management which is a major

driver in avionics complexity. From these requirements, the avionics system architecture is defined. All

disciplines within the avionics design function are involved in the architecture definition, but the avionics

systems discipline is responsible for assuring that the architecture will meet the overall requirements and

constraints. Component requirements and constraints are derived and an electrical, electronic, and

electromagnetic (EEE) parts plan is developed.

Avionics

Requirements and

Constraints

Yes No

(Stop) (Iterate)

Avionics Design

Attributes

• Performance

° Power

• Cost Factors

• Reliability Factors

• Weight

• Volume

• Operability

Avionics

D Architecture

Definition

Avionics

Performance and

Uncertainties

Resources and

Interface

Accommodation

Avionics

Philosophy

Criteria and

Approaches

Avionics

Analysis and Trade

Studies

Avionics

Component

Requirements

and Constraints

Informal __.

i Integration_

Figure 62. Avionics design function plane.

123
An important factor at the time of the architecture definition is the determination of the means and

extent of verification of the avionics system. In some cases, verification may begin in an avionics systems

testbed or hardware simulation laboratory. Within the testbed, vehicle and engine computer simulations

are integrated with the various hardware elements allowing early system testing of the avionics system.

This testbed is also used for the important function of verification and validation of the vehicle flight

avionics system software. Flexibility is built into the testbed so that all avionics hardware elements do not

have to be present at all times. Those hardware elements not present are simulated with computers and

software or, in some cases, simple electrical simulations.

The defined architecture provides the basis for preliminary layouts of the various avionics

elements. The preliminary layouts are determined from the judgment of the designers as to what hardware

will best meet the requirements and the proper division of hardware and software functions. Analysis and,

where appropriate, breadboard testing determine the performance and uncertainties of the components.

Packaging to accommodate the environments is designed, and estimates are made of the power, weight,

volume, and thermal characteristics. The collected attributes of the preliminary design are then compared

with the avionics requirements and constraints, and the design is iterated until satisfactory convergence or

relief from requirements is sought from the system plane. Make or buy decisions are made on the

individual elements of the preliminary design. These elements are built and tested before integrating into

the avionics subsystem. Testing as a system may be done in a hardware simulation laboratory. An overall

representation of the avionics systems design process and the interactions is depicted in figure 63.

Project Vehicle Integration, Checkout, and Flight Avionics

Management System Into

Perform Vehicle

Avionics

System

Testing

System

Design

Function

Project

Requirements

;rmine

Avionics

System

;fine

Avionics

System

Architecture

Avionics

System

Elements

or Buy

Elements and

Test/Qualify

Elements

Subsystem

Avionics System Elements

Design and Development

Internal Avionics

System Engineering

and Integration

Internal Avionics

System Engineering

and Integrtion

Thermal,

Manufacturing,

and Test Discipline. _

Figure 63. Avionics systems design process interactions.

124
A listing of inputs and outputs for the avionics design function process along with discipline activities and products is shown in figure 64. This process flow diagram addresses design considerations for the

elements that comprise the total avionics system and is consistent with the flow diagram of the avionics

plane. Table 17 is a WBS for the design process for a typical avionics subsystem, the DMS. The WBS

chart lists specific tasks that are embedded in the task categories of section 4.3.9.3 and the inputs and

outputs of the subsystem design process. The WBS for the other subsystems, including software, would be

of a similar nature. Figure 64 and table 17 are an adaptation of the process flow diagrams and task WBS

charts of reference 2.

I Requirements k I Internal Flow

Program/Project Oon ra,n _1I -' I Con u,,a,,on I O ,,on IZra e I I I

• Concepts I_ I I

__ --..... GN&C, Communications, Data Management Subsystem,

I I Electrical Power System, Software, EGSE Inputs

• Aerodynamics and

Induced

Environments

• Structural Analysis

• Materials

• Manufacturing

• Vehicle

Configuration and

Structural Design

• Performance and

Trajectories

• Mass Properties

• Thermal

• Guidance and

Controls

• Propulsion

• Ground Operations

• Flight Operations

• Safety

• Reliability

• Cost

I

--i,.- I

• Component Specification

• Make/Buy Evaluation

• Design

• Project Design Reviews

• Parts List

• Schematics

• Test Requirements

• Test Procedures

• Test Reports

• Interface Control Drawings

• Hazard Analysis Inputs

• FMEA Inputs

• Software Requirements

• Software Development and Test Plan

• Software Design Specification

• Software Test Procedures

• Systems Simulation Testing

• Integration and Verification Test Support

_ I Hazards Benefits I Reliability I Operability I Maintainability

I I Cost/Make Resources I Requirements I Test Req'ts/I S_V

IiI or Buy .Utilization I Feedback I Procedures I Algorithms

Products

Specifications and

Drawings For:

• Flight Components

• Flight Software

• GSE

• Ground Support

Software

• Instrumentation

Program and

Component List

(IPCL)

• Verification Reports

Figure 64. Avionics process flow diagram.

125
Table 17. Data management subsystem task description.

Inputs Tasks Outpuls

• Avionics system requirements

• Avionics architecture

• IP&CL

• Natural and induced environments

- Thermal

- Vibration

- Radiation

- EMI

• Materials

• Weight

• Power

• Volume

• COSt

• Verification requirements

3.10.3.1 Requirements

3.10.3,1,1 Components

3.10.3.1.2 Avionics system inputs

3.10.3.2 Design

3.10.3.2.1 Trades and analysis

3,10.3.2.2 Subsystem design

3.10.3.2.3 Components

3.10,3.3 Documentation

3.10.3.3.1 Parts list

3.10.3,3.2 Schematics

3,10.3.3.3 Released drawings

• Subsystem design specifications

• Flight components specifications

- Computer

- Command receivers

- Data processors

- Remote data acquisition units

- Storage devices

• GSE specifications

- Subsystem design

- Components

• Released drawings

- Test specifications and

procedures

• Manufacturing

• Vehicle configuration

• Flight operations

• Ground operations

• Safety

• Reliability

3,10.3.4 Test

3.10.3.4.1 Test requirements

3.10.3.4.2 Test procedures

3,10.3.4.3 Component tests

3.10.3.4.4 Subsystem tests

3.10.3.4.5 Test reports

3.10.3.5 Subsystem/component GSE

3.10,3.5,1 GSEtrades and analysis

3.10.3.5.2 GSEdesign

3,t0.3.5.3 GSEtest

3.10,3.5.4 GSEdocumentation

3.10.3.6 Project/program reviews

The design and development of the avionics software and the EGSE should be an integral part of

the avionics design function from the onset. The development of the software requirements requires the

interactions of the other design functions through the systems plane. This is evident from consideration of

examples of typical functions relegated to the software, such as execution of vehicle and engine control

algorithms, receipt, interpretation, and execution initiation of uplinked commands, acquisition of data

from on-board instrumentation, and compilation and formatting of instrumentation and operations data for

telemetry downlink. Typically, the development of the detailed software requirements may lag the

development of the hardware requirements. For example, it may be prudent for the completion and review

of the software requirements to coincide with the review of the preliminary design of the avionics system.

The EGSE requirements depend on the overall GSE requirements for the vehicle which is a responsibility

of the system plane. Typically, there may be requirements for ground power systems and a ground computer

system to control and monitor the vehicle ground checkout process. The design of these EGSE systems

may be complex and require a process similar to the flight system design process. The ground computer

system must have numerous hardware interfaces for meeting requirements for issuing command discrete

and analog voltages and acquiring instrumentation data and the vehicle telemetry stream. A user interface

system for the EGSE computer must be developed. In some cases, it may be cost effective and technically

desirable to achieve some software design commonality in the EGSE computer system and the

aforementioned hardware simulation laboratory, particularly in the user interface, the command handling,

and the telemetry processing functions.

126
4.3.9.2 Avionics Gates. Decision gates for the avionics design process are shown in figure 65.

Inputs to the process are the avionics philosophy and approach, the environments for the hardware, and

performance requirements from the vehicle subsystems that require avionics, such as GN&C, propulsion,

thermal, and structures. Interactions with these subsystem design functions are required throughout the

design process. Gates for the avionics system fall into three general categories: (1) Performance gates

which measure the functional performance of the various avionics subsystems against their requirements;

(2) survivability gates which measure the ability of the avionics hardware to withstand its environments;

and (3) resource/operational gates which measure attributes such as weight, power consumption, volume,

thermal conditioning requirements, reliability, operability, and cost. Functional performance is determined

by analysis, simulation, and breadboard, prototype, and qualification testing. Layout and packaging to

withstand thermal and vibroacoustic environments lead to units which are environmentally tested, with the

packaging design being modified until survivability is demonstrated. Avionics designers are guided by

program requirements and resources. The top-level attributes such as cost, weight, power, volume, reliability,

and operability are measured against allocated requirements. Once the design has converged to satisfy all

gates, the avionics system drawings and specifications can be released, software produced, hardware

manufactured, and avionics components and subsystems tested.

)_ Reliability I_

', No

Performance

Yes of System,

_, Subsystems, and

Components Meet

Requirements

I

I

I

, No

Avionics Requirements

and Constraints

Avionics Philosophy/

Approach

Environments

Avionics Design,

Analysis, and Test

• Breadboard

• Prototype

• Qualification

• EMI/Radiation

• Packaging

• Thermal

Vibro-acoustics

Operability

Yes

, No

I

I

I

Avionics System

Drawings and

Specifications

• Flight Hardware

• Flight Software

• EGSE

Components Ye,,_

Withstand

Environment

"_--. No :

Figure 65. Avionics system design function gates.

127
4.3.9.3 Avionics Tasks. The top-level avionics design activities are summarized in table 18 and are

described below. The design activities include both flight and ground support equipment.

Table 18. Primary tasks for avionics design function.

Activities interactions

1. Requirements

determination and

allocation

2. Avionics architecture

'3. Avfonics subsystem

design

4.Verification

System

Internal system groups

Control

G&N

Propulsion

Thermal

Natural environments

System 1.

Internal system groups

Control 2.

G&N

Propulsion 3.

4.

5.

6.

tntemalsystem groups l.

Control

G&N 2.

Propulsion

Thermal

Structures

Environments 3.

4.

5.

Internal system groups 1.

Tasks

1. Consult with system to aid in initial requirements allocation of

cost, reliability operability, maintainability, etc.

2. Consult with control, G&N, propulsion, and any internal system

group to obtain avionics hardware/software/EGSEperformance

requirements.

3. Obtain environmental requirements, both natural and induced.

4. Feedbackattributes to system and to system groups. Provide

trade data and consultation for revised allocation, if required.

Obtain requirements from system and other system groups that

specify hardware/software requirements.

Identify candidate architectures and component options for flight

and ground.

Determineredundancy concept.

Identify initial make/buy approach.

Perform initial top-level assessment of attributes and compare

with requirements.

Modify architecture as required and iterate requirements if needed

to achieveconvergence of attributes and requirements.

During detai{eddesign, maintain close coordination with system

groups that specify hardware/software requirements.

Forsubsystems, including EGSE,and components that are to be

madeversus bought, perform necessary design steps through

concept identification, analysis, breadboarding, component

testing, and integrated testing.

Developnecessary software from requirements through coding,

checkout,and verification and validation testing.

Iterate performance and requirements to obtain convergence.

Trackcost, reliability, operability, and maintainability attributes,

iterating with system if not compliant with requirements.

Establisha verification plan at early stage of design or

Control

G&N

Propulsion

Thermal

Structures

Environments

procurement.

2. Perform functional verification incrementally as components are

developed.

3. Perform qualification testing on flight components.

4. Perform integrated testing of hardware components on integrated

test beds.

5. Perform verification in applied environments--vibrations,

thermal, vacuum, EMI, radiation, etc.

4.3.9.3.1 Task 1--Requirements Determination and Allocation. This activity is a joint responsibility

between the system design function and the avionics design function, working also with the design functions/

subsystems where avionics has responsibility for hardware/software design and implementation. These

include all of the avionics subsystems and other appropriate interacting disciplines. As the hardware/software

128
design organization, the avionics design function is the keeper of the requirements for cost, reliability,

maintainability, power usage, etc., as allocated from the system plane. Performance requirements for the

avionics components are derived through interaction with the design functions that have the system design

responsibility in their respective areas. For example, for control system sensors (i.e., rate gyros,

accelerometers, etc.), the sensor range, sensitivity, resolution, bandwidth, and noise requirements are obtained

from the control design function after close interaction between avionics and GN&C to converge to the

most appropriate set of requirements. Similarly, performance requirements for propulsion instrumentation

and avionics components are obtained from propulsion after intensive interaction between the avionics and

propulsion design functions. Environmental requirements are obtained from the natural and induced

environments _oups: radiation, shock, vibroacoustics, and temperature. Avionics interacts with materials

in determining the appropriate materials selection.

Avionics consults with the system plane in the allocation of top-level requirements for cost,

reliability, and maintainability. Most component performance requirements are derived requirements which

flow from the respective organizations which have system design responsibility for that particular subsystem.

Meeting the top-level requirement allocation with satisfactory performance usually entails iteration and

feedback by avionics with the interfacing groups to converge to a design acceptable to all parties.

4.3.9.3.2 Task 2 Avionics Architecture. Based on initial requirements allocation and interaction

with the system groups for the avionics subsystems, avionics identifies candidate architectures and component

options directed toward meeting the requirements. Vehicle reliability and failure philosophy requirements,

in conjunction with component reliability estimates, drive the requirement for redundancy which is a major

factor in the architecture. Initial consideration is given to make/buy options, and a top-level assessment is

made, comparing estimated system attributes of performance, cost, reliability, operability, etc., with their

requirements. Significant difficulty in meeting requirements may necessitate iterations on requirements

with the system and other design functions and disciplines at this stage. When reasonable compliance is

achieved with satisfactory margins, detail design begins on the avionics subsystems.

4.3.9.3.3 Task 3 Avionics Subsystem Design. As with other parts of the vehicle, avionics subsystem

design is of an iterative nature, entailing steps of greater fidelity and detail. Close coordination is maintained

with the systems groups as the hardware/software definition refines. Since the systems groups are also

iterating their designs to greater fidelity, requirements may change. Management of margins, primarily

from experience base, plays an important role in minimizing requirement iterations.

When the decision is to buy a component, the design function is replaced by detailed specification

development, procurement, test, and verification. When the decision is to make a component, design

proceeds through concept, simulation, analysis, preliminary design, breadboarding, detailed design, component testing, and integrated testing. The software design goes through a similar process as the hardware.

As previously stated, because some of the software detailed requirements are derived during the avionics

hardware design process, the software design may not reach maturity as soon as the hardware design. This

must be recognized as a factor in the planning and scheduling of the vehicle development.

4.3.9.3.4 Task 4----Verification. The avionics components and the inte_ated avionics subsystem

must be verified for functionality, performance, and compatibility with the environment it will experience.

Verification is an iterative process as the flight components and EGSE are developed or procured, making

129
useof testbedsappropriateto thecomponentor subsystembeingtested.Functionand performanceare

checkedfor the hardwareelementsover the rangeof variability that is expectedto be encountered.

Verificationof thecapabilityof thehardwareto withstandits expectedenvironmentsis accomplishedby

determiningcorrectfunctioningbefore,during,and aftertestingin thepertinentenvironments EMI,

radiation,vibration,acoustics,thermal,andvacuum.Softwareis subjectedto development,verification,

andvalidationtesting,exercisingthesoftwarewithasmanycombinationsof inputsandoperatingconditions

aspossible.Dependingonfactorssuchasreliability requirementsandcost,it maybedesirableto subject

the softwareto independentverificationandvalidation testing;i.e.,performedby thoseotherthanthe

developingorganizationsandpersonnel.Integratedtestingof theavionicssubsystemis accomplishedon

testbedsthatcombineflight-typeavionicscomponentswithsimulatedorrealinterfacinghardwareelements.

Thesetestbedsmaybealsousedfor softwaretestingwith boththesimulatedandrealhardwareelements.

Finalvalidationfor bothhardwareandsoftwareis accomplishedin flight testing.

4.3.9.4 Avionics Implementation Function. The avionics design function provides the

specifications and drawings required for fabricating the avionics hardware and generating the software.

The avionics implementation function produces the hardware and software. The hardware specifications

and drawings are developed in the design function based on the overall architecture decisions, as well as

the philosophy and approach. Depending on these decisions, there may be long-lead procurement items

which may need to be initiated soon after the end of the design function or, in some cases, prior to the end.

The most common examples of the long-lead items are the highest reliability class of EEE parts. In

implementation of the electronic subsystems, a breadboard system may be built and tested in the laboratory.

For each subsystem, such as the flight computer subsystem, a unit tester is designed and built. The unit

tester provides a stand-alone simulation of all interfaces with the ability to test the basic functionality of

the subsystem. The decision may be made to build an engineering model for some subsystems which

emulates the flight subsystem in "form, fit, and function." The unit tester for the flight computer subsystem,

as well as for some other subsystems, is useful for early software testing. Engineering models of the

avionics subsystems may be used for subsystem testing of the design but are also the primary avionics

components of the simulation laboratory that are used for avionics system and software testing. Qualification

models may be built which contain identical parts and packaging as the flight system. The qualification

models are used in the environmental and vibroacoustic testing phase. For one-time flights, the qualification

model may become the flight unit which is commonly called protoflight hardware. For a flight vehicle

avionics system design to be flown multiple times, the qualification model becomes the basis for the

fabrication of the flight systems.

In the design function phase of the software, design specifications are produced. The design

specifications contain information such as the overall architecture and design of the software, a breakdown

of the architecture into individual software modules, the detailed software-to-software and

software-to-hardware interface definitions, the structure of the telemetry and command interfaces, and the

definition of the methodology for implementation of the real-time requirements of the software. In the

implementation phase, the individual software modules are coded and subjected to development testing.

Appropriate groups of modules are integrated and tested. Timing analyses are conducted to ensure that the

implementation of the design will meet the performance requirements. Ensuring that the real-time

requirements are met in the software implementation is of critical importance. Once development testing

is complete, the software modules are integrated and the verification and validation testing phase can

begin.

130
4.3.10 Materials and Manufacturing Design Functions Overview

The design properties of a material system are contingent on the manufacturing processes employed,

both in the primary production and secondary shaping and assembly phase. Accordingly, the design functions

of materials and manufacturing have been historically linked. Their interdependence in the modem era has

been magnified by the rapid expansion in the development of both new materials and new processes.

Composite materials, including metallic, nonmetallic, and combinations thereof, are examples

of advanced structural material systems that challenge traditional design methodology. Many such systems

require the development of design properties specific to individual component shapes. This differs from

most metal alloy systems where the design properties for basic product forms (i.e., sheet, plate, extrusions

etc.) are readily available and apply, independent of final component shape. When working with advanced

structural material systems, it is often necessary to develop the manufacturing processes concurrent

with the component desig-n. The result is a "best fit" compromise between part configuration, weight,

cost, and schedule. Assembly processes, such as welding and bonding which alter the properties of a

material, also require special attention and clearly delineate the synergistic relationship between materials

and manufacturing.

Note: Executing the materials and manufacturing design functions is a complex process in itself,

involving numerous disciplines and specialties. This document does not describe the process in detail but

provides a top-level overview to show its relationship and interaction with the total vehicle design process.

131
Materials

System

Aerodynamics

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

Figure 66. Design process technical integration--materials design function.

4.3.11 Materials Design Function

Materials is considered a unique function. However, the distinctions between design functions and

discipline functions are less rigid in the materials plane than in the more traditional design planes such as

structures, propulsion, and avionics. Materials specialists interact directly with hardware designers and

analysts throughout the design, development, test, and verification phases. This interaction is enhanced

through the evolving integrated engineering environment which facilitates the immediate exchange of

information across design planes and between discipline specialists. The relationship between the materials

design function and other design functions is shown in figure 66.

132
4.3.11.1 Materials Design Function Plane. The materials design function plane is depicted in

figure 67. The output of this plane is the materials design with all its inherent characteristics for a component,

element, subsystem, or system.

and

Requirements atera ConstraintsH CandidatesMaterial H

: Informal --

_!ntegratio_

Material, _ Material Parameter Matrix Philosophy, Criteria,

and Approaches and Uncertainties

I Material and Analysis Testing

Yes No

(Sto___(._rate)

l

Material Attributes

• Mechanical Properties

• Physical Properties

• Processing Complexity

• Failure Modes

• Cost & Schedule

• Environmental Effects

•TRL

t V

Material Control I__ _ Fabricators Certified [_____ Suppliers Certified

Material

Selection

!

!

Failure

Analysis

iJ

Figure 67. Materials design function plane.

The materials design function can be viewed simplistically as having overall responsibility for

material selection, material control, and material performance. This responsibility extends to the full

compliment of environments to which the materials are exposed, starting with their receipt and ending

with their retirement from service.

Unlike the more conventional visualization of a design function, the materials design function does

not directly define a component configuration. Rather it provides design data and specifications regarding

materials and commercial piece parts that becomes a part of the release documentation.

The materials desi_ function is associated with all other design functions in which a physical product

(hardware) is being developed. Data bases, incorporating the mechanical and physical properties of virtually

all conventional aerospace materials along with acceptance criteria for their use, are maintained and can be

computer accessed by the design and analytical specialists. Additionally, it is the responsibility of the materials

design function to review the evolving structural, thermal, propulsion, and avionics designs, develop further

data where required, and approve the material selections and specifications contained in the release drawings.

133
Material specialists interact directly with process and manufacturing engineers to collectively assess

the producibility of the design. They also identify long lead procurements and enabling technologies, along

with their projected costs and development schedules. This becomes input to the other design planes where

design features can be reconciled with resource and schedule allocations at the systems level.

Material specialists also participate in acceptance and verification testing of component hardware

and systems, assessing material performance, and providing structural failure analysis when required.

The WBS elements 2.9, and tasks of reference 2 provide listings of inputs and outputs for the

materials design function. The NxN diagram of reference 2 (app. A) is representative of further delineation

of the associated inputs and outputs. The materials WBS elements are reproduced herein as figure 68

and table 19.

I Requirements I

• Program/Project I

• Concepts

• Design "_1

• Constraints I

-- I

I Inputs (One Way) I_ I

• Natural Environments_._pJ

• Flight Operation S]l I

I

Outputs (One Way) k I

• Communications | I

and Data Handling

• Electrical Power I '

• Ground Operations _ II,I!

Inputs/Outputs

(Two Way)

• Aerodynamics

and Induced

Environments

• Structural

Analysis

• Vehicle

Configuration

and Structural

Design

• Thermal

• Propulsion

• Mass Properties

• Manufacturing

• Safety

• Cost

• Reliability

Internal Row

Consultation Options Trades Analysis I Cost i

Materials and Process Design

• Compare Materials to MIL-HDBK-5

• Evaluate Materials for

- Toughness, Compatibility, Life Age, Corrosion,

Toxicity, Flammability, Reactivity, Etc.

• Fabrication/Jointing Effect

• NDE Techniques

• Static and Fatigue Test/Requirements

• Contamination Analysis

• Cleanliness Evaluation

• Critical Processes Evaluation

• Storage and Shelf Life Evaluation

• Select Materials and Processes

• Quality of Weld/Braze Process

• Development Contamination/Cleanliness Control Plans

I

I

Benefits

Resources

Utilization

Technical

Descriptions

Reliability

Requirements]

Feedback

Operability

Test

Requirements

Hazards

Cost/Make

or buy

Materials/

Parts List

Maintainability

S/W Server

Algorithms Needs

Sizing/ Conceptual

Configurations Sketches/Layouts

Products

Fracture

Mechanics

Evaluation

Material

Selection

Options

• Establish/

Select Fab

Techniques

• Structural

Analysis Data

• Material Usage

Agreements

(MUA's)

• Material

Identification

and Usage List

(MIU)

• Process

Specifications

• Repair

Techniques

• NDE Plan/Data

for Drawing Input

• Contamination/

Cleanliness

Plans

Figure 68. WBS 2.9_materials and processes design process flow diagram. 2

134
Table 19. WBS 2.9--Materials design task description. 2

Inputs

• Drawings

• Componentfunction

• Load/liferequirements

• Environment

- Temperature

- Humidity

- Pressure

• Accessibility

• Designengineering

andstrength

requirements

• Specialmaterial

requirements

•MIUL

• Assemblyoperations

• Environmentrestrictions

Tasks Outputs

3.8.6

3.8.7

3.8.8

3.8.9

3.8.10

3.8.11

3.8.1 Comparecandidatematerialsto

MIL-HDBK-5 data

3.8.2 Evaluatematerialsper MSFCSTD-506and NHB8060

requirements:

Includingbut not limitedto:

- Toughness

- Compatibilitywith intendeduse

environments

- Life andaging

- Corrosion,stresscorrosion

- Toxicity

- Flammability

- Reactivity

- Flawenvironmentalandcyclic

growth rates

3.8.3 Evaluatefabricationandjoining effects

3.8.4 DevelopNDEtechniques

3.8.5 Conductstatic andfatigueteststo

obtainmissing andneededdata

Contaminationanalysis

Cleanlinessevaluation

Criticalprocessesevaluation

Storageandshelflife evaluation

Selectmaterialsandprocesses

Qualificationof weld andbraze

specimens

DevelopNDEtechniques

Developcontaminationandcleanliness

control plans

Tools:

• NASAandMIL databases

• Fracturemechanics

evaluation

• Materialselectionoptions

• Establishmentand selection

of fabricationtechniques

• Datafor structural

analysis

• MUA

• Materialsselectionand

control plan

• MIUL- final

• Processspecifications

• NDEinspectionand

implementation

• Procedures

• Repairtechniques

• Hazardousoperations

evaluation

• Processschedules

• Personnelcertification

requirements

• NDEplananddatafor

drawinginput

• Contaminationand

cleanlinessplans

Key: • ELY,RLV,and RBCC

RLVandRBCC

RBCConly

135
4.3.11.2 Materials Design Function Gates. Decision gates for the materials design function are

shown in figure 69. They are (I) performance, (2) environmental compliance, (3) producibility/availability,

and (4) cost/schedule.

'_i PerformanceI :

: NO X .-._N I SelectionandControlPlan

.................. . __ J.._._ DesignData

"'___ _ ,___" " IAnalysi._ Failure s --

/ \

- y I Availability I 7 / [ As_;_! snt I _

i / I / I_ / _J Environmental_

',No I I / \ I I I Compliance

................... "\ \. .. ./ / '

__ _kX Xl_rop;rties _'_ , , Compat_ity _._'"y /'_F-. " ....... NO,....

DesLignd_equirements N__ _ /

• Environments Y;_ "s;.n _ ..

• ServiceLife _ ",No

................ ProgramRequirements-- _ "'"

• Cost

• Schedule ICost and Schedule

Figure 69. Materials design function gates.

Functional performance is determined by test, considering applied loads, service environments,

and service/cycle life. Environmental compliance requires a thorough researching of applicable Occupational

Safety and Health Administration (OSHA)/Environmental Protection Agency (EPA) regulations regarding

the control of hazardous materials. This extends to the production and use of a material or component and

the operation of a device that produces hazardous waste products. Producibility involves interaction with

potential suppliers to determine that all materials or elements of component design are available or can be

provided. Special purpose materials not readily available on the commercial market may require vendor

certification. This assures that the production processes are adequately controlled to provide a product with

consistent properties. Certification is also required for critical secondary processes, welding and bonding

for example, that can effect the properties of the assembled structure. Cost and schedule are self-explanatory.

However, in most aerospace applications, the basic material costs are relatively minor contributors to the

overall cost of the system and, generally, do not influence the design.

136
4.3.11.3 Material Tasks. The top-level tasks of the materials plane are shown in table 20. They

consist of (1) requirements determination and allocation, (2) material selection and control, (3) material

development, (4) materials testing and analysis, and (5) failure analysis.

Table 20. Primary tasks for materials design function.

Activities

1. Requirements

determination

andallocation

2. Materialselection

andcontrol

3. Materials

development

4. Materialstesting

and analysis

5. Failureanalysis

Interactions

System

Structures

Thermal

Propulsion

Manufacturing

Tasks

1. Meetwith system anddesignfunctions to identify

initial requirementsfor materialselectionor development.

2. Consultwith system anddesignfunctions to establish

safetyfactors andacceptablelevelsof risk to bereflected

in the materialsphilosophyand criteria.

3. Consultwith manufacturingto confirm the adequacyof

existing methods of fabricationor to determinethe need

for additionalprocessdevelopment.

4. Work with systemand designfunctions to establish cost

and scheduleresourceallocations.

5. Work with systemand designfunctions to reconcile

nonconformingmaterialissues,conduct tradestudies,

and, where necessary,reviserequirementand/or

resourceallocations.

Structures 1. Consultwith designersregardingacceptablematerial

Thermal usage.

Propulsion 2. Reviewand approvematerialspecificationscontained

Manufacturing in design documentation.

Procurement 3. Developand maintainmaterialdata bases.

Quality 4. Consultwith manufacturingto resolve primary and

secondarymaterial processingissues.

5. Coordinatematerialsupply issueswith procurement

and quality.

6. Maintainmaterialcontrol recordsfor critical hardware.

System 1. Consultwith design to obtain requirementsfor new

Structures materials.

Thermal 2. Consultwith manufacturingregardingapplicable

Propulsion processes.

Manufacturing 3. Work with qualityto certify new materialsand processes.

Qualify

Structures

Thermal

Propulsion

Manufacturing

Structures

Thermal

Propulsion

Manufacturing

Qualify

1. Consultwith designers regardingadequacyof available

materialsdata.

2.Perform testing to developsupplementalor "design

specific" data.

3. Coordinatespecimenfabricationwith manufacturing.

1. Consultwith design andqualityto developfailure

analysisplan.

2. Coordinatespecimenrequirementsfor simulating service

failures with design and manufacturing.

3. Work across disciplinesto implementfailure analysis

plan, developfault trees,andcoordinatesupporting tests

and documentationreviews.

137
4.3.11.3.1 Task 1--Requirements Determination and Allocation. The allocation of materials

requirements is determined jointly by the materials design function, the system design function, and other

design functions that are users of the materials. Materials consults with the system design function and the

user design functions to identify and flowdown the initial requirements for material selection or development.

Typical requirements include mechanical and physical properties, compatibility with other materials and

service environments, failure-mode constraints, environmental-compliance constraints, and cost and schedule

constraints. While formal requirements allocations are made by the system design function, the materials

design function has a central role in defining requirements and identifying an appropriate allocation.

Likewise, the materials design function defines the materials selection and control philosophy and criteria

that are then imposed formally from the system level. Metrics for the requirements are determined and

included in the decision gates. If the material attributes do not meet the requirements and informal iteration

among the design functions and disciplines cannot resolve the problem, the attributes and sensitivities are

fed back to the systems function for trades and possible revision of the requirements allocation. As the

design progresses, it is common for the requirements to be updated iteratively until convergence is achieved.

4.3.11.3.2 Task 2--Materials Selection and Control. Materials are selected based on their ability to

function in the overall range of loads and environments to which they will be exposed. Selection further

involves an assessment of the manufacturing processes to be employed, commercial availability, life cycle

of the component, and, in some instances, cost. Initial material selections are generally made by the other

appropriate design functions using information contained in a variety of databases. Material specialists

assist in the selection when available data is insufficient, or where indepth assessment of viable material

options is warranted. Material specialists also review the final material selections for all critical flight and

test hardware and concur in the released documentation.

The materials design function is the principal repository for materials data. It maintains a current data

base on virtually all-conventional aerospace materials. This data base is continually updated as new information

becomes available and can be readily accessed from any appropriately computer-equipped location.

Material control, an element of configuration control, is also a primary responsibility of the materials

design function with support from quality assurance. Material control is imposed on all critical flight

hardware and associated test facilities. It requires that the location of all materials used in these applications

be traceable and their pedi_ee verifiable. Issues such as cycle-life limits, out of specification service

environments, quality escapes, and fraudulent parts drive the requirement for material control.

4.3.11.3.3 Task 3--Materials Development. Materials development is undertaken by the materials

design function in concert with the manufacturing and hardware design functions. Materials development

is normally associated with research activities to extend the present state of the art for aerospace hardware.

However, it can also be the result of unique aerospace requirements for which a broader commercial

market is not apparent. Traditional suppliers often cannot justify investing their resources to produce these

materials without government subsidy and/or indemnification. Interestingly, in many cases, broader markets

evolve once these materials are developed and their properties characterized.

4.3.11.3.4 Task 4--Materials Testing and Analysis. Materials testing and materials analysis are

performed to upgrade and supplement the design data base. Testing and analysis are also done to support

unique design applications or assist in analyzing service or other hardware failures. Testing and analysis

ranges over the full complement of standard assessment techniques for determining the physical and

138
mechanicalpropertiesof materials.It alsoincludessimulatedservicetestingin theenvironmentsuniqueto

spaceflight,suchasvariousformsof oxygenandhydrogencombinedwithhighpressuresandtemperatures,

testingcorrosivemedia,andspaceradiationtesting.

Certainmaterialsarebatchsensitive;i.e.,vagariesintheproductionprocessresultinmaterialsthat

differ in serviceperformancefrom batchto batch.Somenonmetallicmaterialsused in oxygen-rich

environments,for example,mustbetestedfor impactsensitivityandindividual batchesacceptedfor use

basedonthetestresult.

Datafrom all testsareultimatelyreviewedby materialspecialistsfor significanceandaccuracy.

If it passesthesescreens,it is thensubmittedfor inclusionin thematerialsdatabase.

4.3.11.3.5Task5--FailureAnalysis.Assessmentof materialfailuresisperformedbythematerials

designfunction.It is oftenconductedinconcertwith otherdesign,analytical,andquality disciplinesthat

interactto definetherootcauseof acomponent,system,ortest-facilityfailure.Theactualanalysisof the

failed hardwareis precededby aplanthat assuresevidenceis not lost in the handlingof thepartor the

sequenceof dissection.Failureanalysisemploysa widerangeof sophisticateddiagnostictechniques. In

many instances it requires simulating the failure in specifically designed test specimens under precisely

controlled conditions. A fault tree is also a common tool used in exploring significant failure events. The

fault tree starts with the resultant and explores all possible contributors, weighing and rejecting those that

are less probable to arrive at the most probable cause. Fault trees are characteristically supported by analysis,

testing, and detailed documentation reviews.

139
4

#.

!

4

4t

_4

il

Manufacturing

System

Aerodynamics

Trajectory/G&N

Control

Structures

Thermal

Propulsion

Avionics

Materials

Manufacturing

Other

Figure 70. Design process technical integration--manufacturing design function.

p

4.3.12 Manufacturing Design Function

The manufacturing design function includes all activities associated with the definition and

implementation of the manufacturing process. The relationship between the manufacturing design function

and other design functions is shown in figure 70.

4.3.12.1 Manufacturing Design Function Plane. The manufacturing design function plane is

depicted in figure 71. The main output of this plane is planning and documentation to specify fabrication,

inspection, certification, and test. Residing on the manufacturing plane are the subelements involved in the

manufacturing activity. The significant subelements are described in limited detail in section 4.3.12.3.

They are requirements determination and allocation; planning, scheduling, and cost; process development

and certification; tool design and development; subcontractor/vendor selection and control; and parts

fabrication and assembly.

140
Manufacturing

Requirements

and

Constraints

Yes l No

(Sto_rate)

T

Manufacturing Attributes

• System Performance

-Dimensions and Tolerances

-Effects of Manufacturing on

Materials Properties

• Process Robustness

and Efficiency

• Cost

• Schedule

• Environmental Effects

• TRL

Manufacturing

Options

Manufacturing,

Philosophy,

Criteria,and

Approaches

Parts

Fabrication

and Assembly

Subcontractor

and Supplier

Selection F

Control

_ Informal _:

_-Integration

Manufacturing

Parameter Matrix

and

Uncertainties

Planning

and

Scheduling

,L

Process

Development

and Certification

ToolDesign

and

Certification

Figure 71. Manufacturing design function plane.

Manufacturing has overall responsibility for producing hardware in compliance with program demands

and the requirements of the released design documentation. Manufacturing engineers and planners interact

with process engineers, hardware designers, analysts, quality and safety personnel, contracting personnel,

material specialists, project engineers, vendors, and contractors throughout the manufacturing cycle. These

interactions are necessary to coordinate changes, adjust schedules, determine the disposition of discrepant

hardware, and react to program redirection or unforeseen problems that may impact cost or schedule.

The WBS elements 2.14 and tasks of reference 2 provide listings of inputs and outputs for the

manufacturing design function. The NxN diagram of reference 2 (app. A) is representative of further

delineation of the associated inputs and outputs. The manufacturing WBS elements are reproduced herein

as figure 72 and table 21.

141
I Requirements h [

• Program/Project ! I.

• Concepts

• Design | I

• Constraints I I

I¢

........... r I

Inputs (One Way) _ II

• Ground Operations

I

Outputs (One-Way) b I

• Communications ! I

and Data Handling

Inputs/Outputs

(Two-Way)

• Vehicle

Configuration

and Structural

Design

• Materials

• Propulsion

• Reliability

• Cost

I

I

I

I

Internal Flow

Consu,to,,on I O0,ioos I ro0esI Ano',sis I Oos' I

Manufacturing and Assembly Analysis

• Fabrication/Joining Techniques

• Fabrication Practices:

-Forging

-Casting

-Weldment

-Composite

-Adhesive

-Joining

• Material Form and Selection

Hazards

Cost/Make

or Buy

Materials /

Parts List

Benefits

Resources

Utilization

Technical

Descriptions

Reliability

Requirements

Feedback

Operability

Test

Requirements

Maintainability

SNV Server

Algorithms Needs

Sizing/ Conceptual

Configurations Sketches/Layouts

Products I

• Input for I!

Drawings, I!

Specifications, I!

Etc. I!

• Hardware II

Control II

• Manufacturing II

and Control II

Plan II

• Assembly and II

Verification Plan II

• Make or Buy li

Figure 72. WBS 2.14--manufacturing design process flow diagram. 2

Table 21. WBS 2.14--manufacturing process task description. 2

Inputs Tasks Outputs

• Drawings

• Componentfunction

• Assemblyoperations

• Schedules

• Inspectionand assurance

requirements

• Costrestrictions

• NDEplan

• Cleanlinessplan

• Contaminationplan

• Qualityplan

3.14.1 Developfabrication andjoining techniques

3.14.2 Evaluatefabrication practice:

- Forging

- Casting

- Weldment

- Composite

- Adhesive

- Joining

- Etc.

3.14.3 Evaluatematerialform andselectionfor

bestmanufacturingpractice

Tools:

• NASAand MIL databases

• Input for drawings, notes,

specifications,etc.

• Hardwarecontrol

• Manufacturingcontrol plan

• Assemblyand verification plan

• Makeor buy plan input

Key: • ELV,RLV,and RBCC

RLVand RBCC

RBCConly

142
4.3.12.2 Manufacturing Design Function Gates. Decision gates for the manufacturing design

function are shown in figure 73. They are (1) producibility, (2) robustness, (3) system performance,

(4) logistics, (5) environmental compliance, and (6) cost and schedule.

_4--_ i HardwareDocumentation ProcessRobustness • Fabrication

andEfficiency • Inspection

_...No............... _ • Certification

"-,, __'°°_. • Test

Environmental_

__>"_"-I Cost Schedule and Compliance No :

..No. ................ ....T

System Requirements Performance

• Program Facilities

• Engineering Oesign "

',, No _,

,.No..., ...........................

Yes Logistics

Figure 73. Manufacturing design function gates.

Producibility is addressed early in the design of a component or assembly and continues throughout

the design process. Manufacturing engineers participate directly with designers, analysts, and material

specialists to assure that the component or assembly can be produced and that appropriate manufacturing

requirements are incorporated within the design. Often these take the form of modifications to reduce cost

or simplify the manufacturing process. Producibility reviews also address the availability and adequacy of

proposed facilities, material suppliers, and parts vendors to support the project. Items that require long lead

times for procurement or new processes for their production are identified in the producibility reviews,

along with projected costs and development schedules. The output of the producibility reviews becomes

input to the other design planes where design features can then be conformed to resource and schedule

allocations at the systems level.

Robustness is generally inherent in well established manufacturing processes but is often lacking in

newly developed processes. These frequently rely heavily on operator skill to produce a satisfactory product.

Before a new process is placed into production, formal operating procedures are developed and rigid tooling

and/or modem control systems added. These promote consistency in the process and add to its robustness.

They also reduce the need for highly skilled operators by limiting and controlling the degree of operator

interaction allowed in the process.

143
System performance reflects the ability of the full complement of manufacturing activities to achieve

the requirements established by the design functions. Typical requirements include dimensions and

tolerances, material properties, inspection criteria, and maintenance criteria. System performance is a key

attribute of the manufacturing function.

The logistics gate involves interaction with designers, analysts, and transportation specialists to

assure safe packaging and transportation of large and/or delicate assemblies. Environmental compliance

requires thorough research of applicable OSHA/EPA regulations regarding the control of hazardous materials.

This research extends to the use and disposal of toxic materials employed in the manufacturing process and

the protection of workers involved in these processes. The cost and schedule gate is self explanatory.

It is important to note that the manufacturing phase of launch vehicle development places heavy

demands on program assets. It is advisable to allocate adequate time and resources to optimize the design

prior to its release. Changes made to the design after its release typically have a much greater negative

impact on both cost and schedule than changes made earlier in the project.

4.3.12.3 Manufacturing Tasks. The primary tasks of the manufacturing plane are shown in

table 22. They consist of (1) requirements determination and allocation; (2) planning, scheduling, and cost;

(3) process development and certification; (4) tool design and development; (5) subcontractor/supplier

selection and control; and (6) parts fabrication and assembly.

4.3.12.3.1 Task l--Requirements Determination and Allocation. The determination of manufacturing

requirements and constraints is achieved by the manufacturing design function in conjunction with the

system design function and other design functions that interact with manufacturing. These requirements

and constraints are then allocated to manufacturing via the system plane and this flowdown initiates the

manufacturing activities. The system design plane controls formal allocation of requirements and constraints.

The manufacturing design function, however, has a central role in defining them and identifying appropriate

allocations. Typical requirements and constraints include critical process identification, process verification,

operator training, environmental compliance constraints, facility and process constraints, and cost and

schedule constraints. The manufacturing design function also identifies the manufacturing philosophy and

criteria which are then formally imposed by the design function. Metrics for the requirements are determined

for the decision gates. When the manufacturing attributes cannot support the imposed requirements, informal

discussions between the design functions are initiated. If the problem cannot be resolved in this manner,

the attributes and sensitivities are fed back to the system design function for trades and possible revision of

the requirements allocation.

4.3.12.3.2 Task 2--Planning, Scheduling, and Cost. Planning and scheduling begin in the early

stages of the producibility reviews and mature into the detailed production control documents that govern

the manufacturing effort. Written process instructions which also contain the inspection requirements of

the quality control organization are generally adequate to manage small projects. However, large, complex

projects often require that the manufacturing philosophy be defined in a comprehensive manufacturing

plan. Development of this plan parallels development of the design and is normally a data requirement of

any procurement effort having a major manufacturing component. The manufacturing plan outlines the

tooling concepts and manufacturing processes to be employed and identifies any new processes that must

be developed and certified. It describes vendor and supplier requirements, inspection requirements, and

144
Table 22. Primary tasks for manufacturing design function.

Activities Interactions Tasks

1. Requirements

determination and

allocation

2. Planning, scheduling

and cost

3. Process

development and

certification

4. Tool design and

development

5. Subcontractor/

supplier selection

and control

6. Parts fabrication

and assembly

System

Structures

Thermal

Propulsion

Manufacturing

Project

System

Structures

Thermal

Propulsion

Materials

Procurement

Quality

Structures

Thermal

Propulsion

Materials

Procurement

Quality

Project

System

Structures

Thermal

Propulsion

Procurement

Materials

Quality

Project

System

Design

Materials

Procurement

Quality

Project

System

Structures

Thermal

Propulsion

Materials

Quality

Procurement

1. Meet with system and design functions to identify initial

requirements and constraints.

2. Consult with materials regarding unique material

processing requirements.

3. Work with system and design functions to conduct trade

studies and establish cost and schedule resource allocations.

1. Work with design, materials, quality, and procurement

to define the manufacturing approach or developthe

manufacturing plan.

2. Work with project, system and design to identify new

facility requirements.

3. Consult with project, system and design to reconcile priority,

cost, and schedule issues.

1. Meet with design and materialsto establish requirements

for new manufacturing processes.

2. Work with process and material engineers to developnew

manufacturing methods.

3. Work with procurement and/or quality to certify new

manufacturing methods.

1. Coordinatetooling requirements and approach with

design and materials.

2. Reconcilecost and scheduleissues with project and system.

3. Work with procurement and/or design to acquire tool

documentation and hardware.

4. Coordinatetool certification with design, materials, and quality.

1. Meet with project, system, design, and materials to

reconcile unique or sole source supplier issues.

2. Work with procurement and quality to identify and certify

viablesuppliers and contractors.

1. Createdetailed process specifications and work planning

documents in concert with design, materials, and quality.

2. Work with quality to train and certify technicians to perform

critical process operations.

3. Fabricateand assemble parts and coordinate changes

with design.

4. Meet with interacting disciplines to disposition discrepant

hardware, resolve problems, or react to program redirection.

145
any new facilities needed. The major tools and processes unique to the project are displayed in illustrations.

The flow of parts through the subassembly and inspection stations to final assembly is diagrammed in

factory floor layouts. The manufacturing plan and its implementation cost are major discriminators in

selecting a prime contractor for launch vehicle production.

Scheduling a new manufacturing effort cannot be done independent of other manufacturing facility

commitments. Priorities must be established, milestone accomplishments determined, and a start and

completion date negotiated. Critical path scheduling within and across projects optimizes the application

of resources and aids in meeting major project milestones. However, changing priorities, late delivery of

vendor supplied items, manufacturing mistakes, and design changes all contribute to schedule delays.

Controlling these factors requires a systems approach that cuts across functions and disciplines. Successful

results are achieved by appropriately scheduling reviews and establishing clear lines of communication.

4.3.12.3.3 Task 3--Process Development and Certification. Traditional processes will be employed

when manufacturing the majority of components for a launch vehicle. These processes have thoroughly

established standards and controls. However, achieving higher performance in a new launch vehicle may

not be possible using only traditional processes. Invariably, the introduction of new materials or shapes

occurs in select areas of the design. These often require that established processes be modified or that

entirely new processes be developed and certified. Projecting the time and resources required to perfect a

new material or process is an inexact science and is best accomplished by a team of discipline specialists.

Occasionally program demands force the development of secondary manufacturing processes to

proceed concurrent with development of the new material itself, with changes in one area affecting the

other. An excellent example of this is in the space shuttle external tank. A new aluminum lithium alloy was

introduced to improve performance. Attempts to weld this new alloy identified an extreme sensitivity to

constituent levels and other parameters employed in its production. Major modifications to both the alloy

and the welding processes were necessary. These changes extended over many months and successful

resolution required a coordinated effort between discipline specialists from the material supplier, the external

tank contractor, MSFC, and contributing consultants.

Many manufacturing processes contain within them a number of parameters considered critical to

achieving a consistent result. Modem process development employs statistical methods to limit the number

of tests that are required on combinations of these critical parameters for process optimization. Once the

process is optimized, it must be certified. This certification is supported by process sensitivity studies.

These studies establish the limits to be placed on each critical process parameter to assure material design

properties are not compromised.

4.3.12.3.4 Task 4--Tool Design and Development. Tooling is generally understood to include such

items as jigs, work platforms, handling slings, transportation dollies, assembly fixtures, and other similar

devices to hold, manipulate, or move parts throughout the various stages of manufacturing. While some

tooling may support several projects, the major tools for a new program are configuration unique. These

tools must be considered during the early stages of the program since long lead times are required for their

design and construction.

Tooling represents a major program cost element and can be a significant factor affecting both

production schedules and product quality. A careful balance must be struck between the use of "hard" and

146
"soft" toolingin themoredemandingphasesof production.Hardtoolingstrivesto maximizerigidity and

maintainthedesiredspatialrelationshipbetweenpartandprocessequipmentthroughouteachoperation.

Hard tooling is moreexpensiveto employand takeslongerto designandfabricate.However,its more

precisefeaturesreducethe risk of failureandwork aroundsduringstartup.Also, theuseof hardtooling

generallyresultsin fewerprocessdefectsandfasterturnaroundtimes.Softtoolingstrivesto achievethe

sameresultashardtoolingbutis generallylessrigid, with fewerautomatedfeaturesorassemblyaids.

Advancementsin multipurposeprocesssystemsemployingrobots,sensors,andpartpositioners

linked by a computerarereducingtheperformancegapbetweenhardandsoft tooling.However,most

largemanufacturingeffortsstill employamix of hardandsofttooling,with theselectionfor eachprocess

drivenbycontrolrequirements,schedules,andotherbudgetedresources.Designengineers,analysts,process

engineers,andmanufacturingspecialistsmustwork collectivelyto definetheappropriatetoolingapproach

bestsuitedto theprogramconstraintsof costandschedule.

4.3.12.3.5 Task 5--Subcontractor/SupplierSelectionand Control. Small projects often are

accomplishedat onelocationwithout subcontractsupportandwith supplierparticipationlimited to the

provisioningof rawmaterialsorcommercialpieceparts.Asprojectsgrowin scopeandcomplexity,reliance

on subcontractorsand outsidesuppliersincreases.Four commonfactorsinfluencethe decisionto use

outsidecontractors.Theseare(1)thecapacityof theprincipalfabricatorto absorbthework involvedin the

newproject,(2) therelativecostof doingthework in-houseversusby contract,(3) thecapabilityof the

principalfabricatorto performarequiredfunction,and(4)governmentregulationsrequiringthatportions

of thework becontractedout.

Subcontractorandsupplierselectionsarecritical toprogramsuccess.Theirperformanceaffectsthe

cost,schedule,andquality of thedelivereditems.Specialistsin manufacturing,materials,qualitycontrol,

andprocurementmustwork togetherto certify thateachnewsubcontractoror materialsupplierhasthe

capabilityandcontrolsto producean acceptableproduct.The processof certificationhasbeengreatly

enhancedin recentyearsby thewide spreadacceptanceof criteriaemanatingfrom theISO.Contractors

with ISOcertificationhavedemonstratedthattheyhavein-placea documentedsetof proceduresthatare

adequateto control all facetsof the work theyperform,aswell assatisfactorytrainingof thepersonnel

employingtheseprocedures.Maintaining certification requiresregularaudit and approvalby trained

representativesof ISO.

Specialattentionmustbegivento solesourcesuppliers.Everyeffort shouldbemadein thedesign

andmaterialselectionphaseof theprojectto circumventtheiruse.Solesourcesuppliersproduceaproduct

thatisuniqueorof suchlimitedmarketabilitythatcompetitiveinterestinthefield issuppressed. Occasionally,

thecommercialoutletfor asolesourcesupplier'sproductis reducedto thepointthatcontinuedproduction

isnolongereconomicallyviable.Whenthisoccurs,programsthatrely onsuchmaterialsmayberequired

to subsidizethesupplierto maintainproduction,fundtheacquisitionof alternatesources,ordevelopand

qualify areplacementmaterial.Any of theseoptionscanhaveseriouscostandscheduleimpacts.

4.3.12.3.6Task6--PartsFabricationandAssembly.Thedesignof acomponentorassemblyassures

its final form in themanufacturingprocess.Manufacturingengineersandproductioncontrol specialists

definetheprocessesto beusedandthesequencein whichtheyareto beperformed.Skilledtradesmenare

thenrequiredto implementeachactivity.Critical processesrequirethatoperatorsaretrainedandcertified

147
in their use. Certifications are time limited and operators must be recertified at prescribed intervals. All

critical processes and many noncritical processes are supported by detailed process instructions resident at

each workstation or contained in the "shop travelers." These are the planning documents that direct the

flow of parts through each step of manufacturing. These documents also contain the specified inspection

points and requisite approval stamps certifying that the right parts and materials were used and that the

operations were performed correctly. Although described as documents, the planning paper is frequently

computer generated and displayed on interactive monitors at each process station.

4.3.12.4 Manufacturing Implementation Function. While the manufacturing design function

results in planning and documenting the manufacturing process, the manufacturing implementation function

produces the hardware. Manufacturing resides midway in the life-cycle flow for a new vehicle. Requirements

definition and hardware design precede it. Implementation of the manufacturing function begins with the

flowdown of requirements from the system plane. Hardware production, however, is generally not initiated

until the final design documentation is released. Verification follows manufacturing. Should the verification

activities fail to confirm all hardware design requirements, further iteration of the design with manufacturing

is conducted. The process is repeated until convergence is achieved between design requirements and

hardware performance. Operations is considered the last step in the life-cycle flow for a new vehicle.

However, it is customary in programs having very long periods of operation for the life-cycle flow process

to be repeated, albeit in abbreviated form. Program exigencies and/or evolving technologies which offer

opportunities to improve vehicle performance or reduce operational cost are the catalysts for reinitiating

the life-cycle flow process.

4.3.13 Other Design Functions

The design functions delineated in the previous sections are primary to the design and development

of the launch vehicle. Through the activity of subsystem compartmentalization, all hardware and software

products are defined. Subsequently, the major subsystem design functions are determined.

There are hardware and software items that do not belong to any of the major vehicle subsystems.

They are denoted as auxiliary subsystems. However, the function of these auxiliary subsystems is critical

to the successful flight of the vehicle. Their design activities may require fewer design functions and

disciplines then that of the major subsystems. In addition, the number of interactions may be less, there

may be fewer design iterations, there could be less technical integration, or they are specialty/unique items.

As a consequence, the design functions of those subsystems are not allocated a specific plane but are

grouped as "Other Design Functions" in figure 26. Typical examples of these auxiliary subsystems include

recovery systems, landing gear, environmental control and life support system (ECLSS), crew interface,

payload conditioning, pyrotechnics, GSE, etc. Whenever a subsystem design is influenced by one of these

auxiliary subsystems, the design function of the auxiliary subsystem is represented by the "Other Design

Functions" plane.

4.3.14 Reintegration Into the Complete System

Figure 9 in section 2.1 illustrated three types of compartmentalization: the system into subsytems,

the subsystems into design functions, and the design functions into disciplines. Each of these compartmentalizations requires reintegration to reconstitute the total system. Figure 27 provides another view of this

process. On the upper left is an example subsystem tree which illustrates compartmentalization of the

148
vehiclehardwareandsoftwareinto smallerandsmallerentities.Eachof these hardware/software entities

has an associated design function stack, as shown on the upper right of the figure. Each design function

plane contains discipline activities. So, the tree represents subsystem compartmentalization, and the stacks

represent design function and discipline compartmentalization.

On the lower left, there is an IxI diagram, which represents information flow associated with the

subsystem tree interfaces. On the lower right is shown the NxN diagram which represents information

flow among the design functions and disciplines, as discussed previously. An important feature that aids in

the reintegration process is modeling provided by the disciplines on the design function planes. The modeling provides a means for accounting for interactions, nonlinearities, incompatibility, and uncertainties

that are inherent throughout the reintegration process. The models enable the analysts to perform trade

studies and sensitivity analyses that can be applied to desensitize any of the aforementioned undesirable

effects and to assess their effects in order to provide adequate margins. Models applied in this manner

provide the necessary understanding of the reintegrated hardware/software systems along with a high

level of confidence regarding flight safety.

As stated, each of the three compartmentalizations requires reintegration. Reintegration begins

with integrating the disciplines into the design functions, then integrating the design functions into

subsystem designs, then integrating the subsystems into the complete system.

This finally completes the process of reintegrating the subsystems into a total system design.

149
4.4 Design Sequence

The elements and connections of the design process have been described in the previous section,

along with specific tasks that are accomplished on and between the various design function planes. This

section will address the time sequence of activities that comprise the stages of the design process. There are

two parts: Section 4.4.1 describes the conceptual design stage and section 4.4.2 describes the preliminary

design and detail design stages.

4.4.1 Conceptual Design Stage

The conceptual design stage is the early part of the vehicle design process which begins with

hypothesizing candidate concepts to fulfill the given mission statement and typically extends to the

beginning of the preliminary design stage. Concept selection is the downselection to one concept. Concept

selection ordinarily occurs before starting preliminary design; however, in some cases, multiple concepts

are carried through preliminary design, and in the case of a "fly-off," multiple concepts are carried through

detail design, manufacturing, and verification.

4.4.1.1 Importance of Conceptual Design Stage. The conceptual design stage is crucial to the

success of the total design process and the resulting vehicle system. It has been estimated that at least

80 percent of a vehicle's life-cycle cost is locked in by the concept that is chosen (see fig. 74). Another way

of saying this is that choices made during preliminary design, detail design, manufacturing, and operations

(although essential) can have no more than a minority effect on determining life-cycle cost. While poor

detail design engineering can mess up a good concept, the best detailed design engineering will not correct

a flawed concept design and selection. The right concept selection is critical.

1.0 --

0.95

Percentof

Life-Cycle

CostDetermined

, I

;D(1)I pD(2)I DD(3) M & SI/V(4)

1. ConceptualDesign

2.PreliminaryDesign

3. DetailedDesign

4. ManufacturingandSystemIntegration/Verification

Figure 74. Representative percentage of system life-cycle cost determined as a function of design stage.

150
A significantelementof thelife cyclecost occurs during vehicle development. Inadequate phase A

& B activity is known to result in program developmental cost overruns. Empirical evidence of the influence

of conceptual and preliminary design efforts on final program costs is shown in figure 75 from reference 4.

Illustrated in this figure is the final cost as excess over the initial phase C commitment as a function of cost

in phases A and B as percent of development cost for a number of NASA programs. It can be seen that

when programs are initially underfunded (i.e., not enough up-front design effort), cost overruns can be

expected. Thus, insufficient efforts in the early design process will impact program life cycle costs resulting

in developmental cost overruns. Another aspect of the life cycle cost is flight and ground operations. There

is anecdotal evidence that inadequate up-front design efforts will also result in increased operations costs.

200.

E

E

E

_----100

o

x

ul

-- 0

c

o--

u.. -20

0

_7 "i Source: Presentationby Werner Gruhl,

. _ Office of the Comptroller, NASAHO, 1985

PO _

I

O

• Q

! m -- I u i i

15 30

CostsinPhasesA andB asPercentofDevelopmentCost

Figure 75. Cost overruns in NASA programs.

The aforementioned implies that we must put sufficient effort into front-end engineering during

conceptual design. Here the familiar quality lever is at work (see fig. 76). The quality lever idea is that

conceptual design decisions have a 100:1 leverage on end-product quality and cost; preliminary design has

a 10:1 leverage; detail design drops to 1" 1; and, during the operations stage, the leverage may reverse to

1:10. Make use of the leverage, and put the necessary effort at the front end.

151
Conceptual

Design

Preliminary

Design

Detailed

Design Product

100:1 Attributes

10:1

1:1

Figure 76. Quality lever.

4.4.1.2 Convergence of Process. Conceptual design and selection are a converging process, initiated

by a mission statement, and concluding with a selected concept to proceed into preliminary design. It

follows a series of iterations that include generating hypothesized concepts, evaluating the concepts, and

discarding unfavorable concepts. This was illustrated in a previous section in figure 13. Each successive

iteration entails describing and evaluating the remaining concepts in greater detail than for the previous

iteration. Thus, an iterative downselection is accomplished to fewer concepts, with increased penetration

on each iteration. New concepts may be introduced and requirements may be refined at each iteration. A

change in requirements necessitates a look at new and previously discarded concepts in light of the revision.

The process is completed upon selection of a single concept to carry forward into preliminary design, or in

some cases, multiple concepts to carry forward. A program might choose to carry multiple concepts forward

if no clear-cut winner is apparent without going to the level of detail entailed in preliminary design or if a

fly-off philosophy is used (for which the program must have sufficient development resources).

4.4.1.3 Conceptual Design Activity Sequence. An overview of the conceptual design process is

illustrated in figure 77. The activity sequence begins with the program providing a mission statement and

initial requirements that specify objectives and constraints for performance, cost, reliability, safety,

operability, and schedule, and indicate any TRL constraints, etc. In addition, program-level strategy and

philosophy are identified. Typically, the initial program requirements are expanded and refined as the

concept iterations proceed. This is even more true of the program strategy and philosophy which initially

are rudimentary and high level and are modified and expanded as the concepts mature.

Given these requirements and strategies, creative designers and idea generators conceive of

candidate vehicle system options that may meet the requirements. Functional decomposition is used to

guide the idea generation process. Sketches of architectural options put form to these ideas, and concept

evaluation criteria are selected. Concept evaluation criteria will include the attributes of performance, cost,

reliability, etc., corresponding to top-level program requirements. Other measures such as dry weight

margin sensitivity as a function of dry weight may be included as appropriate.

At this point, an informal screening may eliminate concepts that are clearly not competitive (but if

in any doubt, leave the concept in!). The remaining concepts are then subjected to quantitative evaluation.

152
Inputs

Mission

Requirements Concept Initial Aerodynamics

I

and Design -._ Initial

Philosophy Subsystem

Concept -._ i._............ _ _ Assessment

Propulsion _ / " - Structures

Ideas Characteristics i ip_

- Propulsion

- Thermal

Weight l/ -GN&C - Avionics

Estimates I" - Operations

- Other

m

j, ,%

/ Iterations

I

I Performance/

Trajectory

Assessment c°nc ' I

Configuration

Layout

Propellan

Volume

Sizing

Outputs

Sized

Configuration

Concept Layout

and Attributes

Margins

Technology

Maturation

Requirements

Risk

Assessment

Potential Iterated

Requirements and

CbncePfidea_s....

.......... | ......

I

!

Figure 77. Conceptual design stage--sizing and functional flow sequence.

Each competing concept is characterized at the idea-sketch level and is set up in a sizing program.

In this report, the term "sizing program" applies to the set of interconnected programs that manipulate toplevel system variables and "rubberized" subsystem descriptors to converge to a consistent set of vehicle/

subsystem weights and performance. Variables in the sizing program may be free to change, or may be

fixed at the concept designer's discretion. The iterative sizing process is started with initial estimates of

basic aerodynamics (drag, lift), propulsion characteristics (thrust, Isp), and weights. These initial estimates

are used in an initial performance/trajectory assessment, which then feeds a propellant volume sizing

adjustment. The adjusted volume is represented in a concept configuration layout that includes subsystems

reflecting the adjusted volume. An assessment of the adjusted subsystems leads to updates in the aerodynamics, propulsion characteristics, and weight estimates. This iterative process continues until the sizing

and performance have converged.

Since current sizing programs are approximate tools with significant simplifying assumptions, an

assessment of each concept is required by design and discipline specialists. Initially, this assessment typically consists of an overview of sizing program assumptions, inputs, and outputs by a small group of

experienced specialists. These specialists provide the subsystem assessment shown in figure 77, carried

beyond the level of detail included in the sizing program. The fidelity then may be augmented with more

detailed analyses and assessments by additional discipline specialists. By the time the design reaches the

preliminary design stage, the need for fidelity has exceeded the capability of current sizing programs, and

153
the design functions are performed by design specialists in each area. The transition from the design functions being performed by the sizing program to being performed by specialists ordinarily occurs in the

latter part of the conceptual design stage.

The outputs of the conceptual design process include (1) the sized configuration, (2) an updated

concept layout, (3) estimates of the concept attributes (these include cost and -ility attributes in addition to

the performance attributes represented in the flow cycle of figure 78), (4) identification of margins appropriate to the uncertainties and sensitivities of the concept, (5) identification of technologies needed and

their maturation requirements, and (6) a risk assessment. The process frequently results in a need to iterate

the requirements or in generation of new concept ideas.

Technologies required for each concept are identified, technology readiness levels are determined,

and the effort to bring the technologies to maturity is scoped. The primary attributes of cost, operability,

etc., are estimated. Top-level system failure modes are identified, and a risk assessment for each concept is

performed. This includes assessing performance risk, cost risk, and schedule risk, and a potential risk

mitigation plan.

All competing concepts are assessed in a matrix of attributes that reflect evaluation criteria

including refined top-level requirements. The concept evaluation criteria are used to evaluate and downselect

among the concepts. Downselection reduces the number of competing concepts and allows for the

introduction of additional concepts at this point, if additional ideas have been generated by the process.

Concepts may be modified in a direction indicated by the analysis and evaluation process. In addition, it

is typical for concept evaluation to reveal the need to modify or refine the system requirements or

philosophy.

Those concepts that remain after downselection are defined in greater detail, and more detailed

analysis is performed, repeating the cycle until a final concept is selected. In some programs, competing

concepts are carried through manufacturing and testing before final selection is made. Throughout the

concept design and selection process, it is crucial to consider uncertainty and sensitivity and to carry

margins appropriate to the fidelity of the system definition. There is not a single set of margins which are

correct for all projects, because the appropriate margins depend on the characteristics of the project. Highly

interconnected vehicles and those using more advanced technology should use higher margins than their

simpler or more conventional counterparts. A well characterized vehicle should have at least 20 percent

performance margin at the end of the conceptual design stage. More complex vehicles or those requiring

significant technology development should have greater margin--up to 30 or even 50 percent, depending

on the specific situation.

4.4.1.4 Process for More Indepth Assessment. The process indicated in figure 77 represents the

internal interactions of the sizing program as augmented by a small number of discipline and design function specialists. For concepts that are relatively close to the experience base and have relatively low sensitivity and uncertainty, the process represented on the figure is adequate for conceptual design. If there are

very high sensitivities and uncertainties, or if the concept is highly unconventional, a more indepth

assessment is required to achieve the correct conceptual design. In this case, a larger group of design and

discipline function specialists are needed to provide the increased penetration.

154
Figure78illustratesthemoreindepthassessmentfrom astructures/thermal/flightmechanicsperspective.Therewouldbesimilarprocessesfor moreindepthassessmentsof thepropulsionandavionics

systems.The processstartswith the conceptdefinition and outputsfrom figure 77, and proceedsas

indicatedto putmorerealisminto theconceptdesign.That is, iterationsaremadethroughtheindicated

disciplinesto bring theconceptto a morerefineddefinition that is consistentwith thephysicalrealities

representedby thedisciplines.

Start Process for

Configuration "n"

Initial Concept

Design

(From Figure 77)

A I Envir°nmentsI [

\ '_ I-Natural [

I Ivlal_"m ] -_ I Concept

_.....___ced i I Design

_----1, iterati0ns ] _- ]

Figure 78. Conceptual design stage--process for more indepth assessment.

(Structures/thermal/flight mechanics perspective.)

The process shown in figure 78 is detailed and complex, involving many concurrent activities and

interactions. The individual design functions and disciplines execute their respective tasks as best determined by the persons comprising those design functions and disciplines. Detailing these design and discipline-specific activities is beyond the scope of this report; however, there is an overall pattern and

sequence that will be addressed below.

Major steps in the process for each competing concept include the following:

a. Put form to the concept.

• Make initial sketches

• Estimate initial configuration parameters (elements, size, mass, etc.)

b. Estimate primary propulsion system characteristics.

C° Estimate primary aerodynamics.

• Total forces and moments for trajectories

• Distribute forces and moments for loads and control

155
d. Performbasictrajectory/performanceanalysis,iteratingamongstructures(weight),propulsion,

andaerodynamicsto sizethevehiclefor therequiredpayload.

e. Generatebaselinetrajectory and designreferencetrajectories.Include trajectory shaping

constraintsbasedonabortor recoveryrequirements.

f. Determinethecontrol systemphilosophy,logic, andarchitecture,basedonexperience.

g. Determinecontrol authority,and analyzerigid body control responseto variations in key

parameters.

• Variationsin aerodynamics,propulsion,massproperties,etc.

• Useloadindicators

h. Assesskey stabilityissuesif theyappearto besignificantdesigndrivers.

• Aeroelasticity,propellantsloshing,Pogo

i. Determine bounding vehicle loads for each flight event.

• Lift-off

• Ascent

• Reentry

• Landing and recovery

j. Conduct an overall stress analysis to assess top-level design.

• Use fundamental versus finite element analysis

k. Iterate with structural designers to converge structures configuration.

, Select TPS and thermal control system concepts (concurrent).

• Determine thermal environments from thermal reference trajectory and natural environments

• Obtain surface weight/density allowance

• Develop options

• Select TPS and thermal control system concepts

m. Develop conceptual propulsion system definition (concurrent).

• Propellants

• Components

• Weight and performance

n. Develop conceptual avionics system definition (concurrent).

• Components

• Redundancy

• Power, weight, cost

156
O. Develop conceptual definition of auxiliary systems, sufficient for estimating weights, size, cost,

and effects on major subsystems.

• Separation systems

• Landing, recovery systems

• Pyrotechnics, etc.

p. Identity initial production and operations plan.

q. Refine design content of concept.

• Material, mass distribution, type and size of element, etc.

• Induced environments

• Sensitivities

• Margins

r. Iterate at each level to arrive at a converged configuration.

s. Assess attributes, technologies, and risks in view of system requirements.

4.4.1.5 Overall Integration. During the conceptual design stage, the project leader and the systems

discipline are heavily involved in all major activities and associated decisions. These activities consist of

developing concepts and project requirements, constraints, philosophies, procedures, criteria, and guidelines

that are required to be mutually compatible. During this process, inputs are received from all technical

areas including operations. Consideration is focused on the concept(s) attributes of performance, cost,

reliability, safety, schedule, operability, failure modes, and the TRL constraints. The necessary mutual

compatibility is achieved with the aid of formal and informal integration. Formal integration is accomplished

by the leader on the system plane, supported by system engineers, discipline engineers, functional managers,

and working groups. Their focus, as stated above, is developing concepts with balanced attributes that

satisfy the requirements, constraints, philosophies, procedures, criteria, and guidelines.

As shown in figure 79, the formal integration is horizontal and, in the conceptual design stage,

predominates informal integration. The functional flow sequence associated with formal integration is

shown in figure 77. This activity is orchestrated by the leader and represents the initial system design

function. The informal integration is accomplished by design and discipline engineers. Their initial activities consist of subsystem assessments for structures, propulsion, thermal, GN&C, avionics, operations, and

others that could have a significant impact. It is noted that these subsystems or a variation eventually

become the vehicle-level design functions as the design progresses. After the subsystem assessments are

completed they are formally integrated into the conceptual design process. Then the entire conceptual

design is reevaluated as an integrated system. If there is conflict and balance cannot be achieved, then the

system plane is required to resolve the conflict. This can result in changing the requirements, constraints,

philosophies, procedures, criteria, and guidelines in an overall sense or rebalancing them among the subsystems. At this stage of the design process, the informal activities are at a lower level than the formal

activities, as shown in the figure. However, the informal input from the design and discipline engineers is

very important since they represent the core technical assessment. These inputs at this stage of the design

process can significantly impact the downstream preliminary and detailed design processes. Every effort

should be made to achieve balance and convergence at this stage and avoid delaying the balance to a later

157
design phase. In some programs the balance has been delayed when new technologies were required to be

developed to achieve program success. In other cases, balance was delayed because mass fraction could

not be achieved early in the conceptual design stage. These shortcomings during the conceptual design

process resulted in subsequent program delays and rework and in operational complexity which increased

operational cost.

NotActive

/-----7

Manufacturing Conceptual ! Preliminary ! ! Detail ! n ] Integration ] Operations

Design I Design I I Design I

landVerificationJ l L .... l

t Tt Tt it

FormalTechnicalIntegration

"_ _--" -- w inf--'ormationTechnicalintegration "_" -- _ -'_

• Formal

- ChiefEngineer

- SystemEngineeringManager

- SystemEngineers

- FunctionalManagers

- WorkingGroups

• Inlotmal

- DesignFunctionandDisciplineEngineers

- FunctionalManagers

- Panels

Figure 79. Conceptual design stage---overall integration.

4.4.1.6 Ideas and Options. During the idea-generation stage of conceptual design, the full range

of possible options to satisfy the mission statement should be explored. An option that is not brought forth

as a concept to be evaluated misses the cut by default. Figure 80 indicates example subsystem options to be

considered in developing candidate concepts. The options on this list are not nearly exhaustive but are

included as reminders of major options that may be chosen.

4.4.1.7 Conceptual Design Stage Products. The primary product of the conceptual design stage

is the concept or concepts that have been downselected to proceed to the next stage, preliminary design.

The downselected concept will have been screened for feasibility at a relatively low level of detail and

should have appropriate performance margins. The preliminary design stage will entail indepth trade studies

and assessments with higher-fidelity system/subsystem definition.

In addition to the primary product (the concept), activities of the conceptual design stage produce

other outputs that are carried forward with the concept or are retained as a record of the downselection

process. A listing of these products is given in table 23.

158
Top-LevelSubsyslemCategoriesfor TradeOptions

• Propulsion System • Aerodynamics System • Structural System

• Control System • Avionics System • Thermal System

• Materials System • Flight Mechanics/Trajectory Constraints

PropulsionSystem

• Liquid

RP-L02

LH2-L02

RP-Air Breathing

• Solid

• Hybrid

• Pressure Augmented

• EngineCycle

AerodynamicSystem

• Lifting Body

• Control Augmentation

StructuralSystem

• Main Frame

Composite

Metallics

Hybrid

• Tankage

Integral/Conformal

Nonintegral

Lines

• Internal

• External

• Casting

• Welding

• Fastener

• Shape Size L/D

• Bulkhead Configuration

AvionicsSystem

• Distributed/Centralized

• RedundancyLevel

• Degreeof Autonomy/Self Check

Thermal System

• Active • Passive

Metallic • Integral with Airframes

Ablative • NonloadPath

Reflective J

HeatSink

Insulation

• Manufacturing Options

Material Systems _ - Casting

• Metallic _ - Extrusions

- Steels - Welding

ALs _ - Fasteners

Tis _ - Milled

• Composites • Chemical

• Machined

Flight Mechanics/TrajectoryConstrainls

• Flight Mechanics

- Staging

• Single

• Multistaged

• Parallel Burn

• Air Assist

• Air Launch

• Guidance loop Closure

- Early

- Deferred

-Open

• Disturbance Accommodation Approach

- Wind Biasing

• Generic

• Short Term

Propulsion Performance

Anomaly Accommodation

• Trajectory Constraints

G Maximum Acceleration

Q Maximum Dynamic Pressure

o_13Pitch and Yaw Angle of Attack

SeparationAttitude and Orientation

Thermal

Atmospheric Winds

Azimuths

Orbit

Mixture Ratio

Launching Sites

Special

• Dynamic Pressure/Mach number

• Thermal

Figure 80. Conceptual design stage---options and ideas.

159
Table 23. Conceptual design stage products.

EstablishProgramSlralegy/Philosophy

• Listof constraints(mandatoryrequirements)

• Listof preferences, criteria,andweightings

• Uncertaintylevels;e.g.,3c, for systemandcombination

approachfor survivablefailuremodes

• Failuretolerancerequirements;e.g.,FS/FS/FO;engine(s)out

• Verificationphilosophy;e.g.,prototype/protoflight

GeneraleSystemsConcepts(Ideas)

• Systemsketches;includesvehicleconfiguration,

manufacturingprocess,andoperations

• Top-leveldiscriminators

- Performancecriteria/constraintsandmargins

- Derivedcriteriaandmargins

-Weighting factors

EvaluationofAlternativeConcepts

• Foreachconcept

- Pointdesign

- Sensitivities

- Uncertainties

- Margins

• Conceptvalidationprovidedby functionaldisciplines

• Performanceparametersfor eachconcept

• Listof nonmaturedtechnologies

- DefineTRL's,cost,andtimeto maturity

• Riskdefinitionandmitigation

-Estimate of risklevelsandtheir consequences,

includesfailuremodesdefinition

• Attributematrixfor eachconcept

4.4.1.8 Managing To Ensure Proper Concept Selection. Proper concept selection depends on

having the right skills, the right tools, excellent communication, and process leadership which enables the

desired synthesis while avoiding pitfalls that can delay the process. Experience has led to the following

guidance which is reiterated in the lessons learned section:

• The right concept selection is critical. The large majority of life-cycle cost is locked in by the

concept that is selected.

• The best detailed design will not correct a flawed concept selection.

• Put sufficient effort into front-end engineering (quality lever).

• Ensure that options are fully explored, converging with successive refinement (greater detail) of

concepts and requirements.

• Pick a concept only after appropriate convergence, considering all the concepts; i.e., do not

eureka the concept.

• In early phases, discipline specialists must assess validity of sizing program results. Do not

depend on sizing program alone.

• Avoid concepts having too many technologies at low TRL's.

160
4.4.2 Preliminary and Detail Design Stages

Preliminary design takes the concept(s) that was downselected by the conceptual design stage and

defines it in significantly more detail. Major trade studies are conducted to balance and specify the

subsystems. System attributes of performance, weight, and cost are determined with good fidelity. The

detail design stage continues the refinement process, detailing the system, subsystem, and component

design, and producing the drawings and specifications necessary to go into manufacturing.

Preliminary design and detail design follow much the same process in refining the design

definition as better data are obtained from tests and analyses. Both stages proceed toward convergence in a

series of design cycles having a typical basic pattern discussed in the following paragraphs.

4.4.2.1 Design Cycles. A design cycle is a sequence of activities among the design functions and

disciplines that produces a consistent set of subsystem definitions; i.e., where the designs of the structures,

propulsion, trajectory, etc. work together and are not contradictory. The Space Shuttle had five design

cycles (sometimes called loads cycles) and three or four abbreviated cycles to study special problems. The

special cycles (sometimes called minicycles) arise when a phenomenon is not initially revealed by analysis

or test and must be dealt with by design changes. Changes in operations are another means of dealing with

design shortfalls; however, these usually entail increased operational complexity or constraints on launch

availability.

An example of a special minicycle is the Space Shuttle lift-off dynamics coupled with lift-off

ignition overpressure. Not only did the complex multipoint dynamic constraint problem have to be dealt

with (roads too high if not considered), but also the high overpressure energ3' at SRM ignition had to be

accommodated by design changes to the vehicle hardware and the launch facilities (water suppression

system). Many external tank protuberances, etc., had to be redesigned and qualified.

Many design cycles must deal with a critical issue in a short period of time. The question arises:

How do we know when a cycle or cycles are complete? Generally, there are two types of criteria:

° The first criterion is task completion. Complete all the tasks in the process, and make appropriate

design changes. It will take a given amount of time to accomplish each task sequentially,

making use of parallel efforts where possible. The cycle is not over until all the tasks are

accomplished.

2. The cycle is not complete until all gates and criteria are met; in other words, the problem has

been solved. Where it is clear that further refinement of the design remains to be done, or if

other problems requiring a design cycle have surfaced, a new baseline is developed for the next

design cycle, including sensitivity data and special discipline study results.

It is not possible to quantify how many design cycles will be required. The complexity of the

system and the evolving top-level requirements have an effect on the cycles required. The minimum

number is around three: one each for PDR, CDR, and DCR. At DCR, the design cycle must include all the

verified models, a gate for this cycle only. The Space Shuttle had five design cycles during Phase C which

were called Integrated Baseline Vehicle Configuration (IBVC) I, II, III, etc. In addition, minicycles were

performed for--

161
• Overpressure (STS-1)

• Aerodynamic problems (STS-1)

• ET protuberances

• Minicycles in engine design

- Two-duct manifold

- Wide throat combustion chamber

- Advanced turbomachinery development

• Space Station had three major cycles and several minicycles, such as:

- Node gusset

- Common berthing mechanism

- Meteoroid/debris shields.

Some think that with modem techniques the design can be accomplished in one cycle. Certainly

that is desirable, but even with the most efficient approach, two cycles appear a minimum. Experience has

shown that if you cut too much from the mainstream design effort on high performance systems, problems

will occur, creating minicycles which end up extending the schedule and raising cost. The design cannot

violate nature. Ensuring a realizable and consistent design with the current compartmentalization/

allocation approach requires iteration.

4.4.2.2 Activity Sequence. The previous sections have dealt with various aspects and tasks of the

design process, indicating activities sequencing. This section summarizes key elements of this sequence.

In this document, the design sequence will be addressed primarily from the perspective of the aerodynamics,

trajectory, G&N, control, structures, thermal design functions, and system design function. It will include

propulsion and avionics at a summary level only. Also, interfaces with materials and manufacturing are

shown without developing the specifics of those design functions. Propulsion, avionics, materials, and

manufacturing can be expanded in detail similar to the above design functions, but this is beyond the scope

of this document.

A design cycle in either preliminary design or detail design follows the same basic sequence but

with differing levels of detail and fidelity of input data. The activity sequence of the interacting design

functions and disciplines is similar to that of the conceptual design stage which was illustrated in figure 77.

The starting point, however, is the baseline design of the previous cycle, along with its sensitivities and

supporting data. The first cycle of the preliminary design stage has as its starting point the output of the

conceptual design stage.

A number of activities can proceed in parallel and should do so where possible. However, some

activities require as input the results from other activities and so must be accomplished sequentially.

The following are the major steps in the activity sequence for a design cycle. The steps are

illustrated on figure 81, which will be discussed at the end of this section.

a, From the previous cycle, collect and review the requirements and constraints; the philosophy,

procedures, and criteria; the baseline design, including sensitivities and supporting data; and

any identified problems or design shortfalls. Determine the direction of modification for the

upcoming design cycle. The systems plane, in consultation with the other design functions,

allocates requirements and constraints to the design functions, reflecting the desired modifications.

162
b. Propulsionprovidespropulsionsystemcharacteristics,basedon its designcycle and on the

aboveallocations.

c. Structuresdesignmodifies the vehicle configuration, directed toward resolving problems of the

previous cycle's baseline or expanding the level of detail of its definition.

d. Aerodynamics provides updated aerodynamic forces, moments, and pressure distributions based

on updated configuration, wind tunnel tests, and analyses. Aeroelastic stability is assessed to

specify stiffness requirements or trajectory constraints on dynamic pressure.

e. Ascent trajectory/performance analysis is conducted to determine the payload performance of the

vehicle, including margins, reserves, and fuel bias, and to determine the flight path of the vehicle

under constraints developed at both the systems level and the discipline level. Typical constraints

levied in order to have a tractable and reasonable design include at least the following:

• Targeting points for staging and insertion

• Abort/failure targets for engine out

• Dynamic pressure for aeroelasticity and loads

• Axial acceleration for human passenger and payload limits

• Angles of attack for loads

• Thermal constraints.

The trajectories can be modified for operations, within limits.

f. Reentry and recovery trajectories are determined, considering dispersions in initial conditions

and variations in environmental and vehicle parameters.

g. Design reference trajectories are generated for control, loads, and thermal analyses. These

trajectories are chosen to represent potential operational missions, attempting to envelop the

design parameters to maximize a variable such as a load indicator, while maintaining a physically

realizable trajectory. The parameter combination for a reasonable maximization of the desired

variable is determined by a judgment choice, guided by numerous dispersed trajectory runs.

h. Basic control response analysis is performed for the design reference trajectories plus parameter

variations to determine the vehicle's response to winds and other forces during high-q ascent

flight and the transition response during reentry. This basic simulation is also used to determine

the control logic for stabilizing and controlling the vehicle. The control logic is adjusted to meet

additional constraints of load indicators like q-alpha and q-beta, control authority limits, etc.

i. Loads indicator models combine the control responses with other information about the vehicle,

trajectories, and flight events to produce estimates of structural loads at pertinent vehicle

locations.

j. Thermal indicator models use trajectory, control response, and configuration information to

produce estimates of heating at critical locations on the vehicle.

163
k. Approximationsof designcapabilitycorrespondingto the loads andthermal indicatorsare

determinedfrom theexistingdesigndescription.

Theloadsand thermalindicatorsareusedto provideestimatesof thestructuralandthermal

systemdemandthat arecomparedwith the approximatedesigncapabilities to determine

adequacyor impact.This informationguidesdecisionsonpotentialfurtherdesignchanges.

m. In addition to these activities that are focused on system performance, the cost, reliability,

operability, safety, and other attributes of the design are assessed and compared with requirements

and allocations.

Also fed by the design reference trajectory outputs are detailed analysis and design activities

that constitute the indepth determination of the design, and are the basis of the approximations used in

items i, j, and k above. These include the following:

n. G&N systems for each flight phase are synthesized and analyzed, balancing the magnitude of

off-nominal dispersions and performance loss with the accuracy (cost, complexity) of the

sensors and software requirements. Abort and contingency targeting are a major consideration.

o. The structural dynamics discipline generates dynamic models of the elastic structure for use in

control and loads analysis.

p. Control systems are synthesized and analyzed in detail, including all pertinent nonlinearities

and effects. Sensor and actuator requirements are identified and updated in coordination with

avionics.

q. Making use of the dispersed response data and the chosen method of combining uncertainties,

consistent vehicle loads are determined for each major loading event:

• Transportation

• Lift-off

• Ascent max q

• Ascent max g

• Docking

• Reentry

• Landing and recovery.

Iterations with other disciplines may be necessary to bring the loads to within an acceptable range,

through changing the aerodynamics, trajectory, control, parameter variation approach, criteria, etc.

E Acoustics/overpressure environments are determined and applied as loads to the structural

elements where this high-frequency loading is significant. The vibroacoustic environment is

determined for components and is converted to component design and test criteria.

s. Aerothermodynamic and plume heating environments are determined consistent with the

updated design reference trajectories and configuration.

164
t. Thermal analysis and design can be done in parallel with loads analysis. Induced environments

are determined from aerothermodynamics, plume heating, propulsion system inputs, avionics,

and other on-board system inputs. Based on these induced environments and the natural

environments, designs are accomplished for TPS's, cryogenic and propellant insulation, and

TCS for components and compartments. These design activities interact strongly with other

design functions and disciplines. Material selection for TPS and insulation systems is crucial

and, in conjunction with temperature requirements of the vehicle systems, provides the basis for

sizing the TPS and insulation. Designing active and passive TCS likewise requires selection and

sizing of materials and components.

U. Based on the thermal systems designed above, structural temperatures and gradients are

calculated, and thermal environments of components and compartments are determined. As in

other systems, the analysis is part of the iterative design process. Outputs to other design

functions and disciplines are made after convergence of the thermal design.

W. Stress and life analyses are performed for the baseline configuration, using the loads and

thermal data provided. Stress fields and deflections are determined and compared with

specified criteria. Deflection and buckling stability are analyzed. Fracture and fatigue analysis

are performed to obtain cycles and time to failure and to develop fracture control plans for

fracture critical parts. The level of modeling detail is set to be appropriate for the maturity of the

design cycle being analyzed. If criteria are not met, either the environments must be reduced or

the structural design must be changed.

W. Structural design works closely with the stress and durability disciplines to identify design

modifications to correct structural strength or life shortfalls. Meanwhile, structural design

receives inputs from and interacts with the other design functions, including thermal, propulsion, avionics, and auxiliary subsystems. The structural design is modified as required to

accommodate these other subsystems as their designs evolve. In this role, structural design has

a primary packaging and integrating function. The structural design as modified becomes the

baseline for the next cycle. If modifications are complete or are essentially complete (as

indicated by successfully meeting criteria and interfaces), drawings and specifications are

finalized.

In parallel with the summary-level and detailed discipline analyses and design activities

described above, there are special analyses of specific phenomena that must be assessed and designed for,

but which are handled separately from the primary design loop. These typically are stability or transient

phenomena such as flexible mode control stability, pogo stability, aeroeleastic stability, separation

transients, docking transients, etc. Provision or "headroom" is made for these effects in the primary design

loop, including appropriate margins. Examples are shown in the next four items.

x. Control stability analyses are conducted using elastic body dynamics and slosh dynamics

models. These produce slosh baffle requirements and algorithm requirements for stabilizing

elastic and slosh modes. Confirming analyses are run with the baffle models and stabilizing

algorithms simulated to confirrn satisfactory margins.

165
y. Aeroelasticstability is assessedby structures,aerodynamics,and(if pertinent)control.The

designismovedawayfrom anyaeroelasticstabilitylimits, allowingadequatemargins.

z. Pogostabilityanalysesarerunto determinetherequirementfor a pogosuppressionsystem.

aa. Special transient events are assessed, including liftoff and separation clearance, docking

response, landing or recovery response, etc. Results of these assessments produce requirements on the vehicle design and its interfacing ground systems.

Completing the design cycle involves the following activities:

bb. Concurrent with the above activities are related design and analysis activities that are influenced by the primary design cycle but are less coupled to it. These include landing and

recovery systems, pyrotechnic systems, compartment venting design, life support systems (if

applicable), and breakup/disposal analysis.

CC. Also concurrent with the above are the major propulsion, avionics, materials, and manufacturing design activities which can be described in similar detail to the items above (beyond the

scope of this document). They interact with the other parts of the system design to ensure

compatibility.

dd. All subsystems develop verification plans, production plans, and operations plans. Verification

of analysis models and development testing of the designs constitute an important part of the

design maturation.

ee. The end of the cycle produces the baseline design and sensitivities to begin the next cycle or, if

complete, produces the drawings and specifications for entering the production stage.

ft. The hardware and software are produced and verified, involving many components and

process steps.

gg. Operational procedures and constraints are developed from the above activities, drawing heavily

on the analysis and verification program to ensure that the vehicle maximizes its operational

capability while not violating safety constraints.

The activity sequence discussed above has a multiplicity of facets. A clear visualization of the

design sequence can be illustrated with the application of the various categories of activities and/or models

delineated in section 3.5. Recall, these models consist of a generalized model, specialized models, and

discipline specific models. Shown in figure 81 are the design process activities (i.e., activities a through gg)

and their association with the three models. This illustration indicates where the various activities fit relative

to the models, as well as how the models are applied after the initiation of a design or a design change.

166
SpecializedModels

General]Model /] \

IVehicleDesign DesignApprovedI

I Initiationor /

,c ano Discipline SpecificModels I i I

II __ r_] _---_"J 'ndicat°rM°d_l I I I

L.J / 'l =I k.Capability _ }

7 _[_'_ _ _ L_ _ ee.Drawingand_,_ Drawings/Spec

L 4 I SpecificationsI I Released J J

._ Paralleldesignof propulsionsystem, avionics,materials,manufacturing,andothersystems

ff. Production

andVerification

|

i

Iterateif Required_-i

H gg.Procedures OperationalI

Figure 81. Design process activities interactions.

Subsequent to initiation, the characteristics of the trajectory are determined using the generalized

model. It can be seen that properties of the trajectory (i.e., g) drive the specialized models and the discipline specific models. The major outputs from the discipline activities are drawings/specifications, the

design capability, and indicator models. The indicator models are included in the generalized model to

assess the loads and thermal demand versus the capability of the design. In a parallel fashion, results (e.g.,

stability determination) from the specialized models are also compared to the capability. When the total

demand is within the capability and has acceptable margins, the design is approved and the hardware goes

into the production, verification, and operational stages.

For every iteration of the design, all primary subsystems are assessed (see bb and cc). Since many

subsystems are coupled to the vehicle system (e.g., propulsion, avionics, etc.), the impact of their interactions is required to be evaluated. This evaluation is accomplished through an activity sequence similar to

that of the vehicle activity sequence. For those subsystems, a figure parallel or similar to figure 81 could be

developed to illustrate their specific design cycle activity sequence. It would include a generalized model

that describes the subsystem attributes, and the associated specialized models and discipline models.

While figure 81 has been developed to illustrate launch vehicle design, a similar illustration could be

developed for operations. For instance, after a payload is selected, similar vehicle generalized model is

applied to assess the impact of the payload on the vehicle and vice versa. Assuming that the demand meets the

capability, the generalized model is applied to assess the operational constraints for flight; e.g., day-of-launch

wind limits.

167
5. PROCESS IMPROVEMENT

The major focus of this document is to characterize the launch vehicle design process. This

characterization can then serve as a baseline to identify and evaluate improvements on the current process.

As discussed in section 1.1, there is a clear need for low cost, high performance, reliable launch systems.

NASA and the aerospace community must attain significant advances in launch system technologies in

order to meet this need.

There are two categories of technologies applicable toward this objective: (1) hardware/software

technologies, and (2) design process technologies. The first category includes the obvious technologies of

new materials, new propulsion concepts, etc., that address the physical aspects of launch systems. It is

essential that these technologies be advanced, and major efforts are underway toward this objective. The

second category recognizes that the conduct of the design process is itself a technology that must be

advanced in order to achieve more capable and cheaper systems.

5.1 Vehicle Hardware/Software Technologies

This category deals with the different ways of optimizing the effects of the physics of the problem as

was so well expressed by Rick Fleeter 12 when he said that the energy available in splitting the molecules

(propellant) was just sufficient to overcome gravity to get to orbit. Technologies in this category range from

advanced energy transfer and propulsion concepts to new structural materials and alternative avionics

systems. These areas must be pursued to achieve the needed major advances in cost, reliability, and performance.

Several such technologies are being explored and matured; new technologies need to be identified.

5.2 Design Process Technologies

In addition to essential advances in vehicle hardware/software technologies, the design process

itself must be improved. The efficiency and effectiveness of the process can be improved by application of

the experience-based principles and lessons learned identified in section 7. In addition, the technology of

the design process itself must be improved. This is the subject of the remainder of the section.

It should be noted that the ideas and suggestions presented here are by no means all inclusive. They

are just ideas and suggestions that are intended to stimulate thought and action toward improving the

design process.

5.2.1 Design Process Shortcomings and Potential Approaches for Improvement

An examination of the current design process and its history indicates areas of shortcomings,

including at least the following:

• The process is fragmented and not well organized, producing inferior designs.

168
• Therearedeficienciesin the ability to predict(model)designperformance,especiallycost,

reliability, andoperability.

• Synthesisisanidea-drivenprocessthatmaymisspromisingconceptsif thedesignerstayswithin

hisexperience"box."

• Thereis low confidencein theconceptualdesignstagewherea highpercentageof thecostis

lockedin.

• Thedesignprocesshasdifficulty in handlingthevastquantityof requireddataandinformation

andin providingnecessaryvisibility to all involved.

Newdesignprocesstechnologiesshouldbesoughtto addresstheabovedeficiencies.Approaches

for highleverageimprovementinclude--

Reductionof processfragmentation;moreseamlessdesignin

- Subsystem,designfunction,anddisciplinefunctioncompartmentalization

- Designfor all missioneventsanddesignstages

• Improvedmodelingandknowledgebase,especiallyfor cost,reliability, andoperability

More direct synthesis approaches

- Conversion of requirements to concepts and designs

- Ideation and visualization of design space

Improved conceptual design process

- Better synthesis and higher fidelity models

- Scaleable representations that mature into subsequent design stages

• Means for efficiently conveying and displaying necessary design information to all participants.

5.2.2 Evolutionary Improvements

There are many options for fine tuning the present design process. Several are discussed in the

following paragraphs.

5.2.2.1 Requirements and Criteria. The tendency in aerospace has been to place all our lessons

into the form of requirements and criteria. This takes many forms. Analysis of failure modes is replaced by

various detailed criteria instead of understanding and preventing failures. The requirements/criteria are so

stated that many times they dictate the design and leave very little room for innovation and creativity.

Required documentation, procedures, etc., are often very excessive. Currently in the Space Station program,

NASA is insisting on excessive documentation and traceability of not only hardware but also all analysis,

test, etc. No use or very limited use is being made of electronic databases, etc., to meet the documentation

requirements. A key task for fine tuning the system is to strongly work the requirements and criteria,

making the system efficient and allowing for the interjection of creativity and innovation.

169
5.2.2.2 Design for Simplicity. The "Experienced Practitioner" survey (section 7.1 ) has many references

to designing for simplicity. There are many measures of simplicity that can be used as guidelines:

• Simple load paths

• Number of functions

• Number of parts

• Complexity of functions

• Number of turnings

• Number of steps/offsets

• Etc.

This is only a partial list. Pugh in Total Design 3 and other publications emphasize designing

structures by load lines/paths. Others illustrate the approach in different ways. Present launch systems are

very complex. Future systems require simplicity. The key task is to study simplicity and implement ways

of incorporating it into design.

5.2.2.3 Improved Modeling Tools. Initiatives are in progress to improve modeling and simulations

related to essential aspects of the design process. These include:

• High fidelity simulations for virtual flight

• More granular operability and maintainability modeling

• Embedding more probabilistic methods into the design process

• Bottoms-up cost modeling for smoother interface with current top-down cost models

• Multidisciplinary modeling using CAD geometry as basis

• Rapid modeling techniques to enable a greater number of sensitivity analyses.

5.2.2.4 Integrating Various Discipline Analyses Into Single or System Tasks. The process today for

structural design is for the dynamic specialists to first run a load analysis and then pass the loads to stress analysts

for strength and durability analyses. These results are then passed to the designer for design changes, etc. Instead

of sequential analysis, a better method would be multidisciplinary analysis. At various stages of the design, the

multidisciplinary analyses take different form. This process is more efficient, and confidence in the results

increases, without putting any discipline out of business. Activities directed toward this end are--

• Load transformation matrices

• Stress transformation matrices (allow time consistent stresses)

• Integrated trajectory, control, and loads

• Thermal transformation matrices

• Improved sizing programs

• Combining multidisciplinary equations into a single set and developing codes for the integrated

system

• Applying design of experiments for analysis and test.

170
5.2.3 Revolutionary Advances

As noted in the previous section, evolutionary improvements in the design process should be pursued

as an immediate means of increasing process efficiency and effectiveness. However, as discussed in section

1.1, revolutionary changes are required to achieve major advances in launch vehicle cost and

capability.

The following discussion is intended to stimulate thinking and ideas toward needed revolutionary

advances. Revolutionary changes in design process technology can address the two general problems with

current design process: (1) The current process does not arrive at the best design because of its many

compartmentalization/reintegrations, its ad hoc experienced-based synthesis, and its fragmented analysis

of limited fidelity; and (2) the process is too long and costly.

The ideal design process would be an automated process that converts requirements into an optimal design in a single step. Achieving such an approach lies in the distant future but should be the guiding

star target for our efforts in the interim. Until the ideal one-step approach is achieved, we will need to seek

revolutionary advances in the multistep process that is characterized by compartmentalization, synthesis,

analysis, and reintegration. We can consider advances in each of these areas.

5.2.3.1. Compartmentalization/Reintegration Technology. Generically compartmentalization/

reintegration technology currently is applied, not only to vehicle system/subsystem compartmentalization,

but also to design functions, disciplines, requirements accommodation (i.e., performance, cost, etc.),

operational events (lift-off, atmospheric flight, reentry, etc.), and stages of the program. Technology

advances are needed to unify as many of these compartmentalized areas as possible into a seamless whole.

5.2.3.2 Synthesis and Design Update Technology. Currently, any design synthesis or design

update depends on the designer's ideas and experience base on an ad hoc basis. Possible approaches to

technology leaps in this area include idea stimulus approaches; use of artificial intelligence and

knowledge-based systems to convert designer's judgments and rules of thumb into algorithms; techniques

for visualization of the design space; multidisciplinary optimization; and automated synthesis or inverse

engineering, using, for example, approaches like structural shape and topology optimization.

5.2.3.3 Analysis Technology. Potential advances in analysis technology might be pursued along

several fronts, including combining discipline analyses, major advances in fidelity, inclusion of life cycle

metrics, and full probabilistic design enablement.

5.2.4 Interactive Information and Communication System

As a design proceeds through the various stages from the concept stage to the operational stage,

there is a need for an interactive information and communication system (I2CS). The system would consist

of various computerized and electronic tools to facilitate all aspects of the design process. These hardware

and software tools could improve the information flow, interactive team communications including those

from remote locations, multidisciplinary model implementation, etc. Specific examples of various

computerized tools would consist of the following:

171
• A residenceand/orplaceholderfor the designdescriptionand specifications,associated

attributes,ICD's, and supportingdata(this tool could be basedupon the designprocess

characterizationmodelalongwith theNxN andIxI diagrams)

• A realtime interactivecommunicationssystem

• A managementrelatedinformationsystem(thistool wouldincludetheWBS, costspending

profiles,allocations,reserves,schedule,etc.)

• An electronic mock-up with fidelity consistent with the design stage

• A flight performance simulation with fidelity consistent with the design stage that displays key

performance indicators versus flight time

• An advanced interactive multidisciplinary optimization systhesis system that can search for

architectures per given requirements and constraints but driven by optimization algorithm

• A virtual reality design system that can focus on the vehicle system, element, subsystem, or

part where the design participants can assess the realization of their design decisions in real time

• An interactive synthesis tool with "design-to" models that include performance, cost,

reliability, safety, operations, etc.

In addition to the above examples there are certain features that are required to enable these tools.

Typical examples of these features are as follows: tools must be secure, configuration controlled,

accessible by all participants and compatible with industry counterparts; system permits simultaneous

viewing and communications by multiple users interactively; framework implements compartmentalization

and reintegration with residence and/or placeholders for all design related data and includes prompts,

impact assessment, traceability, etc.; hypertext characteristics for data, graphics, etc.; action items and

tracking; trade study tracking; scalable for growth; seamless file transfer; searchable and interrogatable;

and platform insensitive. Other features would also include e-mail, telephone, video conferencing, and

manufacturing and testing real time video acquisition.

The I2CS design tools are needed to improve the design process efficiency and effectiveness. This

system will provide the designer the unique capability to achieve the best real-time design within the

performance, cost, reliability, etc., requirements and constraints. It is imperative that the requirements for

the I2CS design tools be developed by the STS designers in collaboration with the tool developers. While

much of the technology needed for I2CS exists currently, implementation of the system would provide a

potential revolutionary improvement in the design process.

The potential improvements listed above can apply to any design stage. Noting the high leverage

effect of the conceptual design stage, particular attention should be given to technologies that enable selection

of the correct concept. Discovering and developing revolutionary design process technologies are essential

ingredients in meeting the mandate for major improvements in launch cost, capability, and schedule.

172
6. ILLUSTRATIONS OF PROCESS

This chapter illustrates aspects of the design process using historical examples. An overview of the

Space Shuttle conceptual design process and subsequent Phase C configuration cycles is given in

section 6.1. Section 6.2 illustrates technical integration by describing the design process for flight mechanics with a loads modeling example drawn primarily from Space Shuttle history with some comparisons to

Saturn/Apollo and X-33.

6.1 Overview of Space Shuttle Design History From Phase A Through Phase C

When examining the design process for launch vehicles, it is instructive to consider the history of

past launch vehicle design. This section provides an overview of the Shuttle concept selection and major

configuration design modifications (Phase A through Phase C) which illustrates the magnitude of its

conceptual design process and the extent to which the design selection was determined by external

considerations, such as political, budgetary, etc. Much of the material comes from the excellent book

Space Shuttle, The Histm T of Developing the National Space Transportation System.13

6.1.1 Political Activities

Political considerations shaped not only the existence of the Shuttle program but also the form of

the vehicle design itself. These directions and constraints resulted from national needs and priorities, the

economic environment, and multiple government agency roles and interests during the 1969-1971 time

frame (see table 24).

In 1969 President Nixon formed a Space Task Group composed of senior NASA and Air Force

personnel and headed by Vice President Agnew. This group was charged with identifying the Nation's next

directions in space exploration. They recommended three ambitious options including a lunar station and

Mars exploration, the least ambitious option being a $5B per year program for both an Earth Space Station

and a Space Shuttle. Nixon rejected all three options as being unaffordable in the economic environment of

the time.

Meanwhile, NASA formed a Space Shuttle Task Group (SSTG) led by Leroy Day which defined

classes of Shuttle missions and recommended trade studies among broad vehicle characteristics such as

reusable versus expendable stages, categories of engines, cross-range capability, payload size, launch

orientation, and series versus parallel burn. The SSTG defined three classes of vehicles: Class 1--reusable

orbiter/expendable boosters; Class II--stage-and-a-half expendable tanks; Class Ill--reusable

two-stage-to-orbit (TSTO). Class HI was the SSTG's first choice.

In 1970, NASA Administrator Paine and Secretary of the Air Force Seamans established a NASA/

Department of Defense (DOD) STS Committee. The White House rejected the resulting proposal for a

Shuttle program (without a Space Station).

173
Table 24. Space Shuttle history--political activities.

CONCEPTUAL DESIGN STAGE PRODUCTS

February 1969 February 1969 January 1970

• Space task group formed by Nixon

• Team:

- Spiro Agnew

- Senior NASAand Air Force personnel

• Recommendations:

- $8-10 B/yr Lunar Space Station,

50 person Earth Space Station

Mars Exploration

- $8 B/yr 50 person Earth SpaceStation

Mars Exploration

- $5 B/yr Earth Space Station

and SpaceShuttle

• Result:

- Nixon rejected all three proposals

- NASA had to propose

• SpaceShuttle first step

to Space Station

• SSTG

• Team results:

- Leroy Day (Leader)

- Six missions defined

• Logistical support for

for SpaceStation

• Service low Earth orbit (LEO) satellites

• Propellant delivery to LEO

• Satellite service

and maintenance (LEO)

• Delivery of LEOpayloads

• Short manned missions

- Trade studies recommended

• Reusable vehicle

• Pilot fly back versus expendable

booster

• Off st_eifversus new engine

• 230 miles versus 1265 cross

range capability

• 15 K versus 50 K payload

• Vertical versus horizontal launch

• Sequential staging versus parallel burn

Defined classes of vehicles

I Reusable orbiter/expendable

boosters

II Stageandhalf expendable

tanks

III Reusable TSTO

(SSTG choice)

• MSC started inhouse

STS Design

- Concerned over _B RFP

requirements

- 8 x 30 ft payload bay

- Payload t0 K to 15 K

- Class 111

- Cross range 200 mi

- Orbit 310 mi 55°

- 30 flights/yr

- Cost $58 B

September 1970 February 1971 September 1971

• NASAAdministrator (Fletcher)

- Significantly reduced cost

- DOD committed to use it

for all launches

• Must meet all DOD requirements

- STSwas first program subject to

formal economic analysis

and requirements by OMB

- STS must be the only launch vehicle

during the 1980's and later

- Space TaskGroup (STG), DOD,

Presidential Scientific Advisory

Committee NASA American

Institute of Aeronauticsand

Astronautics (AIAA)--all support

STS development

- DOD requirements

• Payload bay 15 x 60 ft

• Payload 40000 polar orbit

60,000 due east

• Cross range 1,100---1500 miles

(issue: reentry heating)

- DOD CIA, NASA, etc supported

Shuttle as the only launch vehicle

• NASA administrator (Paine)/

Secretary of Air Force (Seamans)

Established NASNDOD STS committee

• Shuttle project rejected by White House

• D0D did not provide dollars

but-

- Contributed facilities for

orbiter construction at

Palmdale

- Presented united front with

NASAto Congress

174
New NASA Administrator Fletcher in 1971 determined that keys to acceptance of a Shuttle

program were to significantly reduce cost and obtain broad support for the program from all involved

Government agencies and organizations. DOD committed to use the Shuttle for all of its launches provided

that it meet all DOD requirements. The necessary support was obtained from the numerous agencies, and

a commitment was made that the Shuttle would be the only launch vehicle developed in the 1980's. The

Shuttle program was the first of its kind to be subjected to formal economic requirements by the Office of

Management and Budget (OMB). The DOD did not provide funds but contributed Palmdale facilities for

orbiter construction. With these agreements, the agencies presented a united front with NASA to the

Administration and Congress, enabling the acceptance of the program.

6.1.2 STS Phase A

Phase A of the Shuttle program began before the previously discussed political activities, and had

its foundation in reusable vehicle studies undertaken during the history of spaceflight (see figure 82 and

table 25). In 1968, MSFC and the Manned Space Center (MSC) (JSC predecessor) issued a joint request

for proposal (RFP) for integral launch and reentry vehicle concept studies. Five awards were made:

General Dynamics (GD), McDonnell Douglas (MAC-DAC), Lockheed, Martin Marietta (MM), and North

American Rockwell (NAR). A 4-month study led to NASA continuing funding for all of the four except

Martin Marietta, who continued work with internal funding. The Air Force provided oversight by the

Aerospace Corporation, plus in-house work on stage-and-a-half concepts by Flight Dynamics Laboratory

(FDL). The five NASA contractors focused on Class III vehicles (fully reusable) and spent 200 man-years

of effort, along with extensive aerodynamic, materials, and structural testing. Categories of orbiter

configurations were lifting body (rejected), variable wing (rejected), straight wing (proceeded to Phase B),

and delta wing (proceeded to Phase B). In addition to these concept studies by industry and government, a

series of technology working groups were chartered to develop the key technologies required (see fig. 83).

Each of these working groups had extensive activities and significant expenditures.

Figure 82. Space Shuttle history---example Phase A configurations.

175
Table25.SpaceShuttlehistory--PhaseA.

m

Year

Requirements

• Focus

• PId (K#)

• Orbit (miles)

- Baseline

• Cross range (miles',

• Engine

Contractors

October 1968

Integral launchand reentry

vehicle Joint RFP(MSFC

and MSC)

Cost and safety

5-50

115-345

3OO

45O

MSFC

GD

MAC-DAC

Lockheed

MM

NAR

February 1969

NASA concept

study

GD (MSFC)

MAC-DAC (LARC)

Lockheed (MSFC)

MM In-house ($)

NAR (MSC)

Air ForceSpace Division

• Aerospace oversight

of NASA

• FDL (stage + t/2)

October-December 1969

_A results:

Effod

• 200 man years

• Extensiveaerodynamic,

materials, and structural

testing

Four baselines

• Straight wing (Phase B)

• Deltawing (Phase 13)

• Variable wing (rejected:

complexity, etc.)

• Lifting body (rejected:

packaging, etc.)

Configurations

• Ill (2)

• Ill (12); $5.9B; 21 months $67/#

• III + II (4); $5.5 B; $25/#

• ttt(25)

• III (1 + Opt); 52 months

I

I

Concept Studies

I I I

,,c I LM,FcL I

• Parallel Concept Studies

- Government and Contractors

• Identified Key Technologies

Headquade_ I

I

Technology Working Groups

Structures

Aeroelasticity

Propulsion

J TPS

• Uncertainties

- Winds

- Thrust Vector Misalignment

- Rigid Body Aerodynamic Coefficients

- Thrust

- Isp

- Weight

- Fuel Residuals

Others

• Develop Key Technologies

Figure 83. Space Shuttle history--Phase A concept studies and groups.

176
6.1.3 STS Phase B

The convergence of concepts during Phase A led to the issuance of a Phase B RFP in 1970 for a

fully reusable two-stage vehicle (see fig. 84). Major requirements of the RFP are listed in table 26. Two

orbiters were to be developed: one capable of 230 miles cross range and the other capable of 1,726 miles

cross range. Go-around capability was required for both orbiter and booster, which implied the use of

air-breathing engines on both vehicles. Two teams were awarded contracts: MAC-DAC/MM and

NAR/GD. Two months later, requirements were revised to increase payload from 15,000 to 25,000 pounds

and to specify JP--4 fuel for the air-breathing engines (safety issue). During the Phase B activities, both

teams matured their designs through trade studies, arriving at low and high cross-range orbiter

configurations with a common booster. The orbiters had hot-structure TPS's and two main engines each.

Two engines provided best performance and lowest cost but later gave way to the three-engine

configuration to better provide abort capability with engine out. The baseline Phase B configurations are

shown in figure 85.

Year July 1970 September 1970

RFP

Requirements See Table 26 • Revised Requirements

- Payload 15-25 K

- Fuel (JP-4)

- Pressurized Payload Bay

• Technology Assessment

General Area of Concern:

Aerothermodynamics

Dynamics and Aeroelasticity

Propulsion

Structures/TPS and Materials

Biotechnology

Integrated Electronics

Operations and Maintenance

Cost in ($):

3,715,000

5,740,000

18,130,000

51,745,000

1,960,000

8,355,000

2,215,000

December 1970 May 1971

Results Results

Contractors A. *MSC-Responsible

1.MAC-DAC and MM

2NAR and GD

_.A-1 A-2

15 x 30 Payload Bay 15 x 60 payload bay

15 K LCR-46 K

HCR-20 K

2 Engines + Turbofans 2 Engines and Turbofans

2 Configurations 2 Configurations

MAC-DAC--Orbiter NAR--Orbiter

MM--Booster GD--Booster

B. MSFC--Alternate Space

Shuttle Concepts (ASSC)

1.Chrysler

2.Lockheed

3.Grumman/Boeing (MSC)

* Lead Center Concept Developed

• MSC Integration of Shuttle Activities

• MSFC Responsible for Propulsion

• 1. SSTO

2. Stage and a Half

3. Stage and a Half

- External LH2 Tank

- 3 SSME's

- $6.7 Billion

Figure 84. Space Shuttle history--Phase B.

177
Table 26. Space Shuttle history--Phase B.

Phase B ProgramRequirements Requirements Leviedby Various NASACenters

The shuttle shall bea fully reusable two-stage vehicle

The integrated vehicle shall be launched vertically

and landed horizontally

The initial operational capacity shall be in late 1977

The reference mission shall be a 310-mile 55° inclination

circular orbit from a launch site located at 28.5 ° north

latitude (Kennedy Space Center)

The payloadbay shall have clear volume 15ft in

diameter by 60 ft in length, with a reference mission

capacity of 15,000 Ib

Two orbiters shall be developed: one capable of 230 miles

and the other of 1,726 miles crossrange

The mission duration (from lift-off to landing) shall be

7 days

The booster and orbiter shall have a go-around capability

during landing operations (basically implying the use of

air-breathing engines)

Launch rates will vary from 25 to 75 per yr

Total turn around time from landing to launch shall be

less than 2 weeks

Both elements shall provide a shirt sleeve environment

with trajectory load factors of less that 3G

A 43-hr turn-around capability shall be provided for

rescue missions

All subsystems, except primary structure and pressure

vessels, shall be designed to fail-operational after failure

of the most critical component, and to fail-safe for crew

survival after failure of the two most critical components.

Each element (orbiter and booster) shall have a two-man

flight crew and be flyable under emergency conditions

by a single crewman

The stages shall becapable of positive separation without

the use of special separation rocket systems of the type

employed on Saturn

In-flight refueling (subsonic or supersonic) shall not be

used to meet design mission requirements

The booster and orbiter shall be capableof pilotcontrolled landings under FAAcategory-2 conditions

The vehicle shall incorporate on-board provisions to

quickly and easily placethe vehicle in a safe condition

following landing to permit crew and passenger egress

Thereshall be no propellant cross-feed between elements

(booster and orbiter)

The vehicle elements (booster and orbiter) shall be

capable of landing on runways no longer than 10,000 ft.

While a fully reusable two-stage concept was the clear choice for lowest operational cost per flight,

it became apparent that concurrent development of both an orbiter and a booster vehicle would be

expensive. Peak-year development funding was becoming a concern. Addressing this issue, alternate Space

Shuttle concept (ASSC) studies were initiated to look at alternatives to fully reusable two-stage concepts.

Chrysler, Lockheed, and Grumman/Boeing studied single-stage-to-orbit (SSTO), stage-and-a-half, and

external fuel-tank concepts. These studies provided the groundwork for future program decisions.

178
PH x_: LI

< __LTiL<-'C.L_/ :'3

-.- u.-\X\

__. _-2- ..,:_--_L :_:-::.:-::_"

\-\.. I_2%. - -'_ ..............

._. .---_

// ! ]_- f- ......

T--;.............. ""

Orbiter:

Booster:

Orbiter:

Booster:

Two 415K Engines

Four 18K Turbofans

Two 415K Engines

Ten 18K Turbofans

in Canards

Two 415K Engines

Four JTF22B-2

Two 415K Engines

Four Turbofans

Figure 85. Space Shuttle history--Phase B baseline configurations.

6.1.4 STS Phase B'

In 1971, OMB informed NASA to expect no budget increase in the next 5 years. At that time, the

total NASA budget was $3.2B, with no more than $1B per year being allocated to Shuttle development.

The Phase B fully reusable two-stage configurations required a development cost of S10B, peaking at an

annual cost of $2B in some years. The budget constraints forced an extension of Phase B, designated

Phase B', to search for ways to deal with the budget limitations (see table 27).

Sacrificing lowest operational cost in order to obtain lower development cost, NASA endorsed a

variation of stage-and-a-half which moved the fuel tanks outside the orbiter and also used expendable

boosters. The contractor groups were expanded from the two Phase B teams by the addition of Lockheed

and Grumman/Boeing from the ASSC studies, and the teams were told to reevaluate their proposals with

requirements for using the MSC "040" orbiter, external tanks, and three main engines. Examples of

Phase B' configurations are shown in figure 86.

6.1.5 STS Phase B"

At the end of Phase B', development cost projections had been reduced significantly but were still

too high (see table 28). An extension was provided to further study booster configurations, including

recoverable liquid boosters and solid boosters. A major issue was whether the orbiter main engines would

burn in parallel or in series with the booster. In December 1971, parallel burn was adopted, and abort

SRM's were added. Total development costs were now estimated at $5.8B. NASA further estimated that

use of solid boosters would save $700M in development although carrying more operational costs and

unknowns. In March 1972, NASA adopted solid boosters to go with the external tank and three-engine

orbiter, entering Phase C with a configuration basically similar to today's Shuttle, as shown in figure 87.

179
Table 27. Space Shuttle history--Phase B'.

May/June 1971 Seplember 1971 October1971

B'ended • OMB informs NASAno budget

increase for 5 years

TSTO (_B) Shuttle development

cost $10B with peak of $2B

some years

Proposed total NASAbudget

was $3.2B for 1972

Only $1 B/yr for srs

MSC considered external tanks

first time in their in-house studies

- 15 × 30 payload bay

- 20 K payload

- 4 engines

- Internal Ioxtank

NASAendorses variation of stage

and a half (called semi-reusable)

- Some configurations developed

in 1965-1968 by Air Force

- Decreasein DDT&E cost

- Increase in OPScost

MSC studied 53 Orbiter

configurations during 1971-1973

Contractor teams expanded

to four:

- MAC-DACand MM

- NARand GD

- Lockheed

- Grumman and Boeing

Requirement:

Reevaluateproposals

- MSC--040 Orbiter

- Externaltank

- Three high-pressure

chamber main engines

Rebalancefor New Budget Constraints l::_

180
_),_ PHASEBPRIME

NORTHAMERICANROCKWELL

Rear_ ew _'_

' ....... -- _ _ SideView

_ _lModified grurnman H-35 "_ *'"

I Orbiter and Bee,n0 e-2 _--

I_ Coaster Derivative _\ I--- _:'_"_----_. Front - """ Vt" >ew

, ]L--

SideView

TopView _ PHASEBPRIME

f_[---_-r_ \ ,"_---.... MARTIN MARIETrA

{ "/"/J';SingleTankeoncept' \,_ SideView

_%RearView J I _ ....

SolidRocketMotor_;(4}

....Top'op ViewView _b__.__..r..r._ ,¢RearView

Solid Rocket //'i-7-- .... _

Motors(4) _ \\_ SideView

PHASEBPRIME

McDONNELLDOUGLAS _lr-__

<._-_ %...._-_-_

SideView _--_

RearView

PHASEBPRIME DualTankNotIllustrated

LDC 

si°e ;w

Figure 86. Space Shuttle history----example Phase B' configurations.

Table 28. Space Shuttle history---Phase B'.

November 1971 December 1971 March 1972 May-October 1973

Phase 13' costs still too high

• $2.8M contracts to continue

- Grumman/Boeing

- Lockheed

- MAC-DAC/MM

- NAR

• New Ground Rule:

Stage below 4,100 mph

• Technical issues

- Booster configuration

• Fully recoverable, new liquid

engine, pressure fed

• Fully recoverable, based on

SIC stage

• Solid boosters

- Series burn/parallel burn

• Separation dynamics

(favored series)

• Ground handling

(favored parallel}

• Main engine start on pad

(parallel)

• Cost analysis (favored parallel)

Adopted parallel burn

Added abort SRM's

Adopted solids

- Cheaper development

- Faster

- But higher OPS cost

- More unknowns

MM and others TPS study

- Ablative versus reusable

- Tile technology

I Desig,SignificantlY.!rn!_ac!eclYBudge!..,_

181
r-_ 126.7 ft -.---_

[_"--L I t _ID

_/' ,_ I '1_--'_-- b'l .Diameter

OMS Engines (2)_ 1

3=_8.1, Ic&3%_11

Diameter._[-_

'*q_--'_--_ 1-6°8.ft -I

_°-°"1

[ -- 182.3""

143ft 181,6ft .___ _

Auxiliary Liquid

Rocket Motor

\

[_,

McDONNELL DOUGLAS/MARTIN MARIETTA

GRUMMAN/BOEING

I-_ 128.1 ft _/Z ,.. -1

IS6-in. Diam_tRe;/_ i I _"_ 13.5° Precant

I /- OMS Engines (2)

= "r_ !_f Abort SRM (2)

L__ 92.5ft __.__1 j/,.J

r 60.8n 7 _q'CT___--Q---__C_Z_ _,

I_ 163ft _

138.2 ft

OMS Engines (2)_._. _

,,o_s,./,, -_._.

32 8 ft_

_'_' --'------------,l_k F --84"9ft-_1

T__L_I I -_ I"'-_!

---- _ L.j I

__ 130,1823" I J

210.1 ft

NORTH AMERICAN/ROCKWELL

LOCKHEED

-- 128.1 ft --

[ , 1

Diameter SRB o

_/- Engines (2)

OMS

/_ AbortSRM(2/

- 62.1 ft 7 .... .q--z-r"

-50 4 ft 7 '_. _

L,°,.,,7::,S--J

Diameter

Precant

Figure 87. Space Shuttle history--example Phase B" configurations.

182
6.1.6 STS Phase C

Phase C, detail design, began with a baseline configuration established at the end of Phase B'.

Table 29 shows the main contractors and major configuration changes. In 1972 and 1973, contracts were

signed for the development of the Shuttle elements and for systems integration. During the 2-year detail

design phase, the Shuttle configuration underwent a number of design modifications in order to achieve a

workable system and attain the desired balance of system performance. There were six major overall

configurations involving geometrical and structural changes, adding and deleting air-breathing engines

and abort SRM's, and subsystem evolution (see fig. 88). The balancing act between subsystems/design

functions and requirements/attributes continued until the final production vehicle configuration was

released. Even after the point where the design was frozen, tradeoffs and balancing were done between

requirements, performance, and operational constraints.

The following observations are among the many which can be made concerning the development

history:

• Political decisions heavily influenced the development process. Budgetary constraints drove

the design itself. This is common for programs of this magnitude.

• Requirements underwent major changes during the process, significantly driven by the above

considerations.

- The concept started as fully reusable, but cost drove to the stage-and-a-half configuration

of Phase C.

- DOD requirements also drove the configuration.

- The continuous requirements flux demanded a continuous design balancing act

• The development effort was extensive, spanned several years, involved most of the space

community, and had large expenditures.

- Hundreds of variations of vehicles were studied.

- Seventeen contractors participated in 29 major study contracts worth $127M issued from

1969 to 1973.

- There also was significant funding for technology groups and large in-house activities by

NASA and the Air Force.

• The complexity of the configuration and its resulting sensitivity and interactivity provided design

challenges which carried over into operational complexities and flight constraints.

183
Table 29. Space Shuttle history--Phase C.

Contractawards Major ConfigurationChanges

August 1971

• SSMEto Rocketdyne

(Contract signed

August 1972 after protest)

July 1972

• Orbiter to Rockwell, system

integration to Rockwell

August 1973

• Externaltank (ET) to Martin

• Solid rocket boosters

(SRB's) to USBI

• SRM'sto Thiokol

Requirements

• 65,000 Ibs due east

• 15' x 60' payload

• 1,265 mi cross range

Orbiter structural weight trades

(-1,000 Ibs)

• Thrust structure, wing spar, drag

attachments, separate crew module,

composite bay doors, composite

OMS pods

See 1994 AIAA Propulsion Conference

Short Course on How Phase

B"/C Requirements Impacted SSME

Design16

Scenario of vehicle modifications

(see fig. 88)

"Vehicle r' (authority to proceed (ATP))

"Vehicle 2" (program readiness review

(PAR))

• Moved OMS Pods

• Forebody shape

• Orbiter/ETincidence

• Abort SRM's deleted

• Air-breathing engines deleted

• ETOgivenose

• SRB's shortened, moved aft

• SRBTVCadded

"Vehicle 2A" (150K orbiter)

• Orbiter resized smaller

• Wing planform change

• Body reshape

• Air-breathing engines returned (ferry)

• Abort SRM provisions returned

• SRB's further shortened and moved aft

• ET shortened

"Vehicles 3 and 4" (mid-1973)

• Minor geometry adjustments for

aerodynamics and aerothermo

• ETshortened

• ETretrorocket (spike)removed

• SRM thrust termination dropped

"Vehicle 5" (early 1974)

• Modified OMS pods

• Abort SRM provisions dropped

• Added orbiter braking chute

"Vehicle 6" (production, mid-1974)

• ExposedRCS

• ETand SRBlengths changed slightly

• Umbilical door modifications

• Thermal glass on windows

IBalancing Act Continues Requirements/Design and System

184
_rc_----qr["--1

c 1L____I

e3 ¢_

I.L E

__8

<i

l

!

\

1

7-

7-

J

L r

J--/

/

-1

.----i

i_,

8®,-

--._ .CI_ _}

=,t -_ or-,-

_=0_ ivt

E_eLr_

(1) -- --

"0

'F /_

r_

N

i'_-]

i It1

_.-, i i

I.!I

..i_ I

I

¢-

o._

J

'-1 [--_'°__

i y__2_l

z::_- O

o ,1

,_ __ _._

X

[_..__,

I_ _.

t j

I" i

C

Figure 88. Space Shuttle history---Phase C configurations.

I..

1

185
6.2 Design Process for Flight Mechanics With Loads Modeling Example

In this section, the complex technical integration process for flight mechanics and loads modeling

is illustrated by describing how this process has been accomplished for past programs.

6.2.1 Space Shuttle Flight Mechanics Technical Integration

The Space Shuttle is used as the primary example for technical integration of flight mechanics.

Table 30 shows a set of initial assumptions developed during the preliminary design phase in order to

simplify the design process. These assumptions cover topics such as assuming that the ascent loads are

bounded by reentry loads. Some of these assumptions proved to be wrong, such as the assumption that

ascent crosswinds would not impact design. In order to achieve proper integration, discipline panels were

formed initially to handle such topics as aerodynamics, loads, etc.

Table 30. Space Shuttle preliminary design.

PreliminaryDesign

Allocationsandassumptionsimplementedtosimplifythedesignprocess:

• Ascentloadsrequiredto bewithinre-entrythermalandaeroloads

• SRBnotdesignedbywaterimpactbutassessedby attrition

• Weightallocation:

- Elementdry weightandgeometry

- Vehicle"glow"

• S_BTI¥C

- FullTVC

- TrimTVCwithactiveailerons

• Ascentcrosswindswouldnot impactdesign

- Consequences: 1. Highwingloads;wingfailed

2.Elementinterfaceloadssensitiveto

combinedaeroloadsascentaccelerations

Panelstermedtoenabletechnicalpenetrationsandcommunications:

• Panels:Aero,FlightMechanics,Loads,etc.

Going into the detail design phase, problems in integration started to occur, and two major working

groups were formed to aid the integration process (table 31). The Ascent Flight System Integration Working Group (AFSIG) and Propulsion System Integration Working Group (PSIG) were formed as integrating

and sounding groups for the panels, with recommending authority to the System Integration Manager and

Shuttle Program Manager. The first major tasks were to set up procedures and methodologies as well as

defining appropriate parameter uncertainties to use in design. These uncertainties were identified by the

various disciplines for each flight event (fig. 89). AFSIG's role was to assure completeness and consistency of the parameter uncertainty matrix, assuring that the uncertainty levels chosen were sufficient for

design but not overly conservative. Figure 90 is an excerpt from the parameter uncertainty matrix. More

detail of the parameter uncertainty matrix is given in the appendix.

186
Table 31. Space Shuttle detail design.

Detail Design

• Formed working groups

- AFSIGand PSIG

- Expandednumber of panels; integrated by AFSlGand PSIG

• First major task

- Set up proceduresand methodologies

- Set up parameter uncertainty matrix by flight events

• Outputs of technical integration activities

- Impacts on vehicledesign and sequence

• Parametercombinations for engine out; detunedwind gust and

engine-out by 6 seconds and all other uncertainties were 1_.

• Baselinedlift-off dynamic analysis using 2c worst-on-worst approach.

• "A" factor andsquatcheloid approach baselinedfor max Q.

• 95% wind speedand 1/2 magnitude of shear and gust applied

deterministically; other half of the shear and gust used as uncertainty

with other parameters for max Q.

• Monthly meanwind biasing for design reference trajectory.

- Impacts on procedures and models

• DelayedSRB ignition

• SRB separation motor orientation, location, fuel combination, timing, and

number of motors.

• Necessaryload relief control increased thermal environments, increased

TPS, and reducedpayload.

• Threeaxis load relief baselinedfor max Q.

ORGANIZATIO_

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

15

MARSHALL SPACE FLIGHT CENTER

AFSIG REVIEW

NAME

R. RYAN

DATE

APRIL 1986

Discipline

Trajectory Performance

Pogo

Flutter

Control

Thermal

Liftoff Clearance (Drift)

Separation

Loads

Environments

Overpressure

Acoustic

Shock

Winds

Propulsion

Dynamics

Criteria

Failure Modes

Parameter Matrix

IP <¢

Event

Prelaunch

Launch

Max Q

Max G

Pre-SRB Separation

Post-SRB Separation

SRB Separation

Second Stage Ascent

ET Pre-Separation

ET Separation

Total Ascent

Figure 89. Space Shuttle AFSIG---example parameter matrix event.

187
ORGANIZATION

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

16

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

NAME

R. RYAN

DATE

APRIL 1986

SRM Propulsion

•TC227A-75 Thrust Versus Time Curve Per SE-019-083-2H

(SRB System Data Book) for Bulk Grain Temperatures

(TC227H Is Proposed as Update)

• Flight-to-Flight Propellant Burning Rate

•Thrust Level Development Uncertainty

•Thrust Oscillation (Dynamic Factor Assumed for

Loads Analysis)

• Steady-State Thrust Mismatch Between Motors

•Thrust Misalignment

• Flight-to-Flight Thrust Level Dispersion

Analysis Tolerance

ETR WTR -- 8152°F°F(Mean)/83.4 (Mean)/44.5 °F°F(Max) (Max)

+_+5.3% 47 (OneTwo SRM's) SRM)

+ 3%

+ 5%

85,000 Ib (Ref. vol. X,

fig. 3.3.2.2e)

+ 0.75 ° Per SRB

_++ 4.9% 5% Single Both Motor Motors

Aerodynamics

• Pressure Distribution Test Data Match with Aerodynamic

Coefficient Test Data

• Elevon Deflection Schedule #6 (Hinge Moment Limiting

Feedback) Per Rockwell Internal Letters ACDA/FSA/76-527

and 531

° SD72-SH-O060-2 (Mated Vehicle Aero Design Data Book)

• Include Aerodynamic Tolerance Effects on Coefficients: Wind

Tunnel Deviations Plus Power-on Deviations Plus Reynolds

Number Effects

+ 3%

_e O= f (ACHM = 0.02) Aero

Data Adjusted to New

(SeO+ _Seo)

None

Values Per PRCB Briefing on

8/18/'76 MCR 3378 "5.3 Ascent Load

Adjustments"

Figure 90. Space Shuttle AFSIG--example parameter variations.

188
Many impacts to the design occurred due to how the parameters/uncertainties were implemented.

Impacts that were too severe were resolved by changing how the uncertainties and their application were

used in the design process. The prior approach of worst on worst was too severe for the high performance

characteristics of a vehicle like Space Shuttle. Table 31 lists a number of these procedural and criteria

changes made by AFSIG to minimize the effect of uncertainties and maintain a highly reliable system.

Vehicle operational changes were made to reduce impacts of uncertainties on loads, etc. For example, the

SRM ignition was delayed 5 sec after SSME ignition in order to capture a minimum stored energy condition, thus reducing lift-off dynamic loads. Three-axis load relief was another addition. These changes

reduced loads but resulted in a loss of performance.

Table 32 delineates other changes that were made to reduce weight/increase performance

(i.e., reducing the safety factor on the external tank from 1.4 to 1.25, increasing the SSME thrust level from

100 to 109 percent, introducing the high performance SRM, etc.). Special teams were formed to solve

particular design problems such as the Orbiter Tile Team, SSME Design Team, and SRB Recovery Team.

Certain risk mitigation activities were performed such as the mated vehicle ground-vibration test and

SSME improvements.

Table 32. Space Shuttle change examples.

DetailDesign

• Othertasks

-ET 1.25 ES.

- All welded SSME

- HPM/SRM

- Orbiter improvements

- 109% SSME

Planned performance evolution

nhancements after first flight

• Special teams

- Orbitertile team

- SSMEteam

- SRB recovery team

• Risk mitigation activities

- Mated vertical ground vibration tests

- Engine improvements

Even with all these special activities, problems occurred such as loss of load margins on the orbiter

wing and on the interface members between the orbiter and external tank and between the external tank

and the SRB's. The program was now in the flight test phase, so operational work-arounds were sought

(see table 33). In order to launch safely with these lower margins, the Launch System Evaluation Advisory

Team (LSEAT) was formed to perform day-of-launch wind monitoring with specific constraints. As the

system evolved, day-of-launch I-load updates were employed which utilize the measured wind profile

2 hr prior to launch. Many design changes were implemented to reduce problems uncovered early in the

flight test program such as water troughs for overpressure reduction, super light weight tank (SLWT) for

added performance, etc.

189
Table 33. Space Shuttle change examples--test and operations.

FlightTestand Operations

• Changesrequired*

- OrganizedLSEAT

- Day of launch monitoring/launch constraints

I Balloon flight day of launch/realtime flight assessment

- Day of launch I-loads update

- Special instrumentation for SRBAFTskirt

- ETTPS (Ice team)

- Engineoperations procedures; engine redesigns

- RedesignedAFTskirt due to water impact

- Twochanges in SRB parachutes

- Changedhow orbiter tiles were attached

- Debris/tile team

- SSME104% versus 109%

- SRM overpressure accommodations

- Changesto meet EPAregulations

-- ETTPS

- RSRM

- SLW-r

* This list is representative;not all inclusive.

Two Duct HGM

Damping seals

Single crystal turbine blades

Large throat nozzle

Silicon nitride bearings

P and W high pressure turbo pumps

6.2.2 Loads Modeling Example

The basic process, figure 91, models the plant (the vehicle) with its uncertainties as well as the

natural environments with their uncertainties. Combining these together produces a response with

variations. What is needed is for the response to have an assured probabilistic level to produce adequate

margins. Achieving this requires considerable work with the input variables, the uncertainty combination

approach, and the design. The process starts with the generation of the trajectory, figure 92, which

produces the basic ideal performance. Since the ideal cannot be reached because of the effects of

variations, in order to secure analysis efficiency, specialized reference trajectories are generated. These

reference trajectories become the basis for analyses using uncertainties to determine perturbated responses.

These responses are used as inputs to generate loads acting on the vehicle (see fig. 93). The figure shows

the outputs of the responses that become the inputs for loads. The sketch shows this wind-induced

perturbation from the nominal trajectory as well as the dynamic elastic-body response.

Parameter

Matrix and

Uncertainties

Plant

Characteristics

andUncertainties

Natural

Environments

andUncertainties

Response

Variations

_. / *Assured on a _

I ProbabilisUcLevel

Figure 9 I. Overall concept for flight mechanics.

190
StepI

Ideal Optimized

Trajectory

(Response)

- Ideal OptimizedTrajecloryand

PotenlialPayloadMargins

- Inputto Slep2

Step 2

Reference

Trajectory/

Trajectories

- SpecializedTrajectoriesGeneraledto

AchieveAnalysisEfficiency

- ReferenceTrajectoryInputto Step3

Step 3

NonIdeal

Perturbed

Response

(Uncertainties)

- 3c Response

Note: Steps2 and 3 Performedfor andTailoredto EachMissionPhase

as Well asfor SpecialSituations

Figure 92. Method to achieve performance goal.

J_3- / _ Target

//.,,"T'_/,_ / /" _ "_ \ " Location

"/"//_ _ [ I { • ) ) ] "Payload

• Rotational Acceleration _.,.7.,- _,v_-/.-L_'_-,_ ." -_=' t\ _\ "v/// /; ano-

• TranslationalAcceleration //V._// _ _ \ _ J / . •

Gimbal Angle and Rates ,, _ .f"/_".,_"_ .. _ / Reference _ Margin

CG offset o_'_,'_-"_._ J/_/ _ / _ Trajectory To

Thrust <_'/ / // / /2_ Orbit

Aero Loads, _ f// / " / / :

Moments, and 9\ f''-'-'''_ / / / I

Distribution /' _"'__ _ _/ : Natural Environment

,_ _ ._ t:_: y and Directi°n

JData Requirements for Load Analysis k

i i in n,,, ........... ,,, , ,: .....

Figure 93. Illustration of design process: structural loads.

191
To achievethe mostconservativedesign,ideally one would want to designfor the comersof

parameteruncertaintiesspace,asshownin figure 94;however,this is generallynot practicalbecauseof

performanceimpacts.Thenextmostdesiredapproachis to accomplishapurestatisticalanalysissuchas

Monte Carlo of the vehicleparametersand thenaturalenvironments.This hasnot beenpracticaluntil

recent years and is still costly. Therefore,the synthetic wind model was developedalong with a

root-sum-square(RSS) andA-Factor approachfor uncertainties(seetable 34). The approachis a

conditional probability approachwhich saysthat given the 95 percent wind speedcombinedwith

99 percentshearand gusteffectsRSS'd,the loadmustbe maintainedwithin the 3-sigmabound.This

approachwasveryefficientfor SaturnApollo andhasbeenvalidatedby aMonteCarloanalysis.

IiParamee Mean and ii > [,,ems Model

Uncerlainties (Plant)

t

I Environments "a'"r"' I

I Design

Parameter

Outputs

-- Ideallythe desire is to design for the corners of the box such thatthe inputparameters and the

plant are good for the extremes.This results in overly conservativeloads.

Figure 94. Structural loads illustration.

The Space Shuttle followed a similar approach during design with some significant changes in the

wind model (see table 34). Other than the wind model change, the same conditional probabilistic approach

was used. The wind model change was introduced to remove conservatism without impacting safety.

Figure 95 shows how the approach was applied to different load parameters called squatcheloids that are

q-alpha and q-beta plots as a function of Mach number. Combining the squatcheloids as a time function of

Mach number produces a loads envelope tube as a function of ascent trajectory time. At each point on the

squatcheloid, time consistent accelerations, velocities, and positions are used for load analysis. This

approach saved significant amounts of computer time. The X-33 patterned their approach after Shuttle but

used only 2-sigma variations instead of 3-sigma (table 35).

192
Table34.Structuralloadsillustration.

• Thedesire is an all up Monte Carlo of the vehicle parameters and the natural environment parameters.

In the past and to some extent in the present, this was not possible or, if possible, not design analysis

efficient. As a result alternate procedures were developed.

• Saturn Apollo/Skylab

Saturn useda conditional probabilistic approach, where a synthetic deterministic wind profile is the

condition. The vehicle's response is determined to this profile using the mean and the 3G parameter

uncertainties (individually) producing a set of responses which can be root sum squaredthen multiplied

by a factor of three producing: 3,_ response against the condition (winds).

-Wind model (deterministic) (the synthetic wind profile model was generated for eachcritical

altitude/match number)

• 95% worst month scalar wind speed

• 99% worst month wind shear and gust (due to the conservatism, the shear and gust

were RSS'd)

- Plant models (Two)

• Rigid body with and without propellant sloshing dynamics

• Rigid plus elastic body with propellant sloshing dynamics

- Parameter uncertainties

• 3,_ about mean

• Normal distribution assumed

- Analysis approach

• Run response to synthetic wind profile (one altitude) using mean of parameters

• Run response to synthetic wind profile (same altitude) using mean of all parameters but one,

which is the +1_ level

• Repeatfor-l_ level of parameter

• Repeat process for + and - of each individual parameter

• RSSfor each response, develop a single time response run which produces a time consistent

response that produces the same 3c peak. (Time consistent set of response data required

for balanced load set.)

• Repeat process for each critical altitude/Mach Number

• Produce conditional probability set of design data

• Engine out phased with wind gust

- Operations

• Bias trajectory to monthly meanwind to obtain margins.

- Validation of synthetic wind approach was made using individual measuredwind profiles (50m

wave length, 150 profiles per month) in conjunction with Monte Carlo approach. (Winds only,

vehicle parameters nominal.) Good correlation with synthetic profile.

• SpaceShuttle

- SpaceShuttle used the conditional probabilistic approach; however,the wind profile model was

changed. (Remove conservatism)

- Winds model (synthetic profile; looked at using directional speed change).

• Trajectory biased to monthly mean wind (design)

• Synthetic profile directional

- 95% worst month wind speed

- 50% of 99% shear and gust magnitude RSS'd.

• 50% of 99% shear and gust treated as uncertainties along with all other vehicle parameters.

- Winds model (Individual profiles)

• Monthly detailed wind profile (50m wave length) 150 per month (special studies)

- Analysis approach

• Same conditional probability approach aswas used for Saturn except using squatcheloid

as output. (See fig. 95)

• Simultaneous pitch and yaw synthetic wind profiles required

• Engine out delayed 6 seconds past gust peak.1_ vehicle parameter uncertainties, used with

engine out

• Bending dynamics response accounted for by multiplying rigid body loads by 10% (conservative

based on special studies). Liftoff and landing analysis made using bending dynamic models.

• Liftoff used 2c worst-on-worst parameter uncertainty method

193
qO_

qc_

Example

Mean _nd

Trajectory

I ! !

0.6 1.0 1.4 1.8

Machnumber.

Flightenvelopeby useof squatcheloid

Range of

Range of

qP

I

2.2

X

Nominal vehicle parameters, synthetic

profile 95% speed, 50% shear, and gust

RSS'd, one specific Mach Number,*

mean wind, and reference trajectory.

3_ vehicle parameters, 50% shear and

gust synthetic wind profile, mean wind,

and reference trajectory

A-Factor approach used to generate time

consistent accelerations, gimbal angle, and

angle-of-attack data for loads.

* Process repeated for each Mach number

Figure 95. Structural loads illustration--squatcheloid approach for loads.

Table 35. Structural loads illustration--X-33.

• X-33

- X-33 usedthe conditional probability approach for max "Q";same as Shuttle for lift off

- Monthly meanwind biasing

- 2c parameter variations

- Wind model

• Synthetic profile

- Analysis approach

• Squatcheloid approach as was used for shuttle

194
Table 36 is a summary of lessons learned this example. Although only a snapshot of the loads

process was provided, the lessons are applicable to all the various design activities. Uncertainty analysis is

required, and this analysis complicates the design process. Creativity and innovation of engineers are keys

to establishing accurate, efficient approaches for the specific vehicle being designed.

Table 36. Structural loads illustration--summary.

DesignProcessforFlightMechanicswithLoadsModelingExample

• Uncertaintyanalysiskeyto areliabledesign

• Uncertaintysignificantlycomplicatesthe designprocess;loadanalysisusedasexample;

establishedandverified

• Similaruncertaintyanalyseswerealsousedfor all otherdesignfunctions

• Creativityandinnovationof engineerskeyto establishingaccurate,efficientdesignprocess.

195
7. EXPERIENCE-BASED KNOWLEDGE

7.1 Survey of Experienced Practitioners in Aerospace

A survey was conducted of experienced practitioners in aerospace using the question, "What is the

essence of engineering design based on your many years of experience.'?" Many have responded with very

clear and succinct lessons. Their responses have been collected and are included by their individual names.

The statements are unaltered and provided without comment.

7.1.1 James Blair (Retired NASA, presently at University of Alabama in Huntsville)

"In a vehicle system, all parts are connected; a change in one affects the others. The more fully the

design organization acknowledges this system connectivity, by means of communications,

organization, and especially the individual engineers' perspective, the more successful will be the

design."

7.1.2 Bob Brotherton (Former McDonnell Douglas, presently with Boeing)

'¢ O'" " O" En_lneerm_ is logical."

7.1.3 Jack Bunting (Lockheed Martin, Denver)

"Test what you fly, and fly what you test."

7.1.4 W. E. Campbell (Retired Aerojet)

"Success lies in attention to detail, with a methodical top-down approach to identify the areas of

concentration."

"One-fourth to one-half of historical rocket engine failures seen to be attributable to out-of-print

hardware, process escapes, and the like. One probable contributor is insufficient priority on

producibility in favor of performance, weight, and envelope. It must be the mandate of project and

technical management to balance these priorities."

"Stacking worst-on-worst tolerance (or schedules, costs, contingencies, margins, etc.) results is an

untenable, noncompetitive design, product, or program. Some form of probabilistic approach will

point toward a competitive but successful solution."

"Project scheduling should include small enough task increments that an event "miss" can be

recovered with reasonable downstream workarounds. Last minute surprises on long-span tasks are

project disasters."

196
"Nearly everythingintheworld hasadistribution.A simplifiedprobabilisticapproach(whichdoes

not becomefrustratedby imprecisealgorithmsor incompletedatabases)is anexcellenttool to

identify drivers,screenoptions,andevaluatesensitivities."

"A part fracturefailure occurswhen"stress"(in someform) exceeds"strength"(in someform).

This canbe the starting assumption for failure analysis, which must identify and rectify the

combination of higher (than expected) stress elements and/or lower (than expected) strength

elements--both of these including the effects of operating conditions and environment,

manufacturing processes, part history, and the like--that resulted in failure."

7.1.5 Chris Chamis (NASA Lewis Research Center)

"Simplicity in formulations wins over complexity in every respect--succinctly better-faster-cheaper."

"Simple solutions to engineering problems require insight that is gained by experience and maturity."

"Major hurdle in simplicity is resistance from inexperienced colleagues and not very knowledgeable

supervisors."

"Simple solutions to complex problems require continuing management support: person power and

other required resources."

"Successful engineering solutions are not based on the proverbs: 'The nail that sticks out gets the

pounding' or 'The wheel that squeaks gets the grease,' which is the current practice."

7.1.6 David Christensen (Lockheed Martin, Huntsville)

"One good test is worth a thousand opinions."

"Too much analysis can cause Design Paralysis."

7.1.7 Peter Christie (Boeing Seattle)

"It is important to always do an analysis before testing. It is equally important to conduct at least

one valid test in order to confirm the accuracy of the assumptions in the analysis."

"Engineering design knowledge must be combined with an understanding of materials and

manufacturing process in order to achieve the most successful design."

"The performance of each system in an aerospace design affects the performance of other systems

in the design. For example, in pressurized commercial aircraft fuselage, all joints are sealed with a

polysulphide sealing system. The sealant adds weight and cost and affects the fatigue life of structural

joints. It also minimizes the bleed air requirements of the engine, while increasing the corrosion

resistance of the joint."

197
7.1.8 Werner Dahm (NASA MSFC Chief Aerodynamic Scientist)

"Mother Nature does not read our paper. If we don't follow her way, she lets us fall."

"Paper is patient. Sense or nonsense, it accepts all we write." (This is an old German proverb.)

"As your design proceeds, weights always go up."

"The chief decision maker should steer clear of the glory hounds. Their quest for personal fame and

glory has cost us dearly and will always do so."

"If you aim for about 80 percent of the theoretically possible performance, your costs will stay

moderate and your chance of success will be good. If you aim for more, your costs and risk will

grow exponentially." (This caveat was passed to me by Hans Multhopp, the designer of the FW 190

fighter plane of late WWII.)

7,1.9 Harold Dioron (Retired NASA, presently with InDyne, Inc.)

"A complex model isn't very useful without a simple model to guide interpretation and provide

sanity checks."

7.1.10 Jim French (NASA and Aerospace Consultant)

"In a system design, no change takes place in isolation. Every change has system level effects and

any change no matter how good it sounds in isolation, must be reviewed in terms of its impact upon

the system and every other subsystem."

7.1.11 Philip Glynn (Retired NASA, presently Boeing Space Station)

"Engineering is the process of creating, evaluating, and assuring performance of any defined human

need."

"Engineering uses the laws of physics and mathematics to expand man's horizons and improve the

quality of life on earth. As such it is the enabling environment to improve man's relationship with

man."

"Engineering excellence is a state of satisfaction known only to the group which has endured the

pain of attention to the details."

7,1.12 Micheal Griffin (Orbital Sciences Corporation)

"Look aggressively. The absence of a symptom does not imply the absence of a problem."

"Don't shoot the messenger. Messages, but not problems, will cease arriving."

198
7.1.13

7.1.14

7.1.15

7.1.16

7.1.17

Ron Harris (Retired NASA, presently with Boeing North American)

"Arrive at a decision, don't rush into them."

John L. Junkins (George J. Eppright Chair, Texas A&M)

"Cooperate with Mother Nature to the maximum extent possible, minimum energy solutions are

almost always the most reliable."

"It is hard to conduct an orchestra when every musician thinks himself a composer."

"Faster, Better, Cheaper? Maybe, but not very likely with five levels of management."

"Keep simplifying the most important questions and simultaneously try to define corresponding

analytical, computational, and experimental tests that answer the question."

"World-class determination will usually trump world-class intelligence, but thank God for the

miracles that can be performed when you find both attributes in the same person."

"The best advice I can give to a project manager: Know who your best engineers are, seek them out

immediately when the tough questions arise, and challenge several proven individuals (not a

committee) to propose solution strategies. Then convene the committee."

Dick Kohrs (Retired NASA, Associate Administrator, presently with Kistler)

"Systems Integration is 95 percent communication and 5 percent engineering."

"It is better to be on orbit and be criticized for not having enough capability, than to be on the

ground and be criticized for not being in orbit.' This is what J.R. Thompson preached to me during

Space Station."

"Consistency is the work of dull minds, but we must be consistent."

Wayne Littles (Retired NASA, Associate Administrator, MSFC Director, presently

with Pratt and Whitney)

"Capable discipline engineering with the products accurately transmitted to well trained

manufacturing technicians and software developers, along with a thorough test program, are necessary

elements in producing quality flight hardware and software, but the essential ingredients to ensure

program success are sound Systems Engineering and effective communications."

John McCarty (Retired NASA, presently a consultant)

"Proper use of dispersions, tolerances, in analysis and test is key to propulsion system design."

199
7.1.18

7.1.19

"A high quality propulsion system is one that has high reliability."

"Failures are when engineers learn how things really work."

"The price of any design change, because it is a change, is the introduction of new failure causes."

Dale Myers (Retired NASA Deputy Administrator, presently with Kistler)

"Keep it simple stupid" (The KISS Program).

"If it isn't worth doing at all, it isn't worth doing well."

"A program without reserve is like a dinner without wine."

Owen Morris (Retired NASA)

"When attacking a problem, remember that things usually are truly as they appear to be."

7.1.20 Joyce Neighbors (Retired NASA, presently with Lockheed Martin)

Career path in engineering: "First become a specialist in some discipline, learn how other disciplines

interact with yours. Learn systems engineering but stay grounded in your specialty; this gives

experience and technical qualification for becoming an engineering or program manager for high

technology products."

Mission success: "Understand and prioritize requirements for the life of the product early in design

cycle. Analyze during design and test to corroborate analysis before putting product into operations."

7.1.21 Larry Pinson (Retired NASA)

"'All the easy problems have been solved.'"

"As engineering managers, we like to focus on formal management structure while people motivation

usually is the real issue."

"If people are sold on a project outcome, formal organization is nearly irrelevant."

7.1.22 Robert S. Ryan (Retired NASA, presently a consultant)

"The higher the performance requirements, the greater the sensitivity (nonlinear) to variations in

environments, design, manufacturing, etc. Performance requirements drive the design."

"Political viability shapes a project as much as engineering."

"The Physic (Mother Nature) of the problem reigns supreme (The God of Design). Either you bow

down to her or you fall down."

200
7.1.23

7.1.24

7.1.25

7.1.26

7.1.27

"All design is a paradox, a balancing act. Understanding sensitivities, interactions, is the key to

SUCCESS."

Lucien A. Schmit, Jr. (Retired Professor, University of California)

O. °

"The en_,meer s main task is to anticipate possible failure modes and loading conditions.

If we are not imaginative, nature will punch a hole right through our design."

"The value of simple limiting cases as test problems for assessing computer codes cannot be over

estimated."

"Behavior sensitivity analysis and optimum design sensitivity analysis are powerful tools for

obtaining quantitative answers to 'what if' questions traditionally asked by designers."

Luke Schutzenhofer (Retired NASA, presently at University of Alabama in Huntsville)

"Skillful leaders communicate the goal and objectives, reward creativity and good work ethics,

consider all ideas, encourage debate, and discourage the fear of failure."

"Focus on working the right problems right."

"Better can be the enemy of good."

David Sisk (Lockheed Martin, Huntsville)

"In designing any structure, start with and continuously focus on the joints. If you get the joints

right, the rest will fall into place."

Parker S. Stafford (Retired Martin Marietta, Consultant)

"The design, development, and test of a system should be done with the mission operations objectives

in mind; i.e., systems tests should duplicate real mission operations and sequences. Use flight

hardware, software, and ground systems wherever possible."

"Flight software should be validated in a realistic mission dynamic simulation environment which

is functionally equivalent to the actual environment. This should include the initial flight load and

all planned and contingency uplinks to the spacecraft."

"Analysis data used to define qualification tests, operating ranges and tolerances, etc., should be

configuration managed as released engineering."

John Thomas (Retired NASA and Lockheed Martin)

"Any endeavor without understandable, achievable objectives and well thought out plan will not

enjoy success."

201
7.2.1

7.2.2

7.2.3

7.2.4

7.2.5

7.2 Design Suggestions From Selected References

J.E. Gordon (Author of Structures, or Why Things Don't Fall Down s and The New Science of

Strong Materials Is)

"All structures will be broken or destroyed in the end. Just as all people will die in the end. It is the

purpose of medicine and engineering to postpone these occurrences for a decent interval; the question

is: What is to be regarded as a decent interval?"

Helmut Horn (Deceased, NASA and V-2 German rocket engineer)

Provided by Robert Ryan

"If you can't explain it with a simple analog, you don't understand it."

"You cannot be a good system engineer unless you have penetrated one discipline in depth."

Henry Petroski (Professor of Civil Engineering, Duke University, and author of To Engineer

is Human: The Role of Failure in Successful Design 16 and Design Paradigms: Case Histories of

Error and Judgment in Engineering 17)

"Every solution of every design problem begins, no matter how tacitly, with a conception of how to

obviate failure in all its potential manifestations."

"If any small change is made to a system, the whole system must adjust to that change."

"Lessons are best learned when we are familiar with a wide variety of textbook case studies of past

failures, not only within our own field but also outside it, so that when we do make analogous errors

we get a nagging feeling that something similar might be wrong in our reasoning and that we

should double check our work."

Stuart Pugh (Author of Total Design 3)

"Concept selection improperly done can never be righted with the best engineering. Neither can the

best concept selection be saved (realized) using poor engineering."

David Pye (Author of The Nature of Design 6)

"When you put energy into a system you can never choose what kind of changes shall take place

and what kind of results remain... All you can do, and that only within limits, is to regulate the

amounts of the various changes. This you do by design."

202
7.3 Lessons Learned

The combined experience of the authors in conjunction with this activity, the survey of experienced

aerospace workers, and the referenced literature have resulted in a series of lessons learned for technical

integration of launch vehicle design. Each lesson learned has a subset of attributes and/or tasks for

accomplishing or applying the lesson.

7.3.1 Specific Lessons Learned

1. Although engineering skills are essential, people skills are mandatory for achieving successful

products.

- Choose a strong leader with decision-making capability who listens and encourages everybody

to integrate.

- Organization is a tool to accomplish the job; however, with proper leadership and motivation,

the organization is secondary.

Provide a reward system to encourage the alignment of roles and responsibilities with project

missions and objectives.

Encourage engineers to enhance their cooperative interactive skills as well as their technical

skills.

Train engineers to be specialists with a systems focus.

Reward specialists who participate in integration activities in order to formulate a world view

of the total system.

- Provide an open environment which encourages innovation and stimulates communication.

2. Manage to ensure good technical integration.

- Technical integration is crucial to the design process. Make every effort to encourage technical

integration and assess that it is being done.

- Communication is the key, predominant part of technical integration.

- Most integration communication is informal, both within and between planes.

- Understand the physics of interaction.

Continuously check requirements flow.

Continuously check assumptions.

Proper compartmentalization (subsystems/design functions/disciplines) facilitates integration.

203
Working groups can enhance technical integration.

Focus people skills toward integration.

Integration is everyone's responsibility, but leadership must ensure technical integration.

3. Manage to ensure proper concept selection.

- The right concept selection is critical. The best detailed design will not correct a flawed

concept selection.

- Put sufficient effort into front-end engineering (quality lever).

- Ensure that options are fully explored, converging with successive refinement (greater detail)

of concepts and requirements.

- Pick a concept only after appropriate convergence of the various concepts; i.e., do not eureka

the concept.

- In early phases, discipline specialists must assess validity of sizing program results. Do not

depend on sizing program alone.

- Avoid concepts having too many low-level TRL's.

4. Requirements, constraints, and criteria greatly influence design.

External/political considerations and constraints strongly drive design (for example, Space

Shuttle).

Technical constraints also drive the design, so apply them carefully and judiciously.

Analyze and challenge requirements, constraints, and criteria at all levels to obtain the greatest

possible engineering design flexibility.

Do not accept unrealistic schedules and budgets.

Poorly defined and vacillating top-level requirements cost the program dearly in terms of

wasted design effort and compromised design.

Overspecified criteria suppress the creativity of the design engineer.

- Criteria must be tailored for the specific project.

5. All design is a balancing act between conflicting requirements. You get some of what you want

with some of what you do not want.

204
- Balancingmustoccuramongdisciplines(energyredistribution).

- Balancingmustoccuramongprogramrequirements,thedesign,andoperatingplans.

- Cost,risk, andperformancearelinkedattributes.An improvementin oneattributetypically

producesadetrimentin another.

- Thebalancingactrequiresopencommunicationandkey decisionjudgments.

Assessingrisksversusconsequencesi akeyingredientof thejudgmentprocess.

- Problemswhichcannotbecuredindesignmustbecompensatedforin operationalcompromises

andconstraints(e.g.,mayleadto reducedprobabilityof launch).

All designsmustachievemarginsor probabilitiesacceptablefor safetywhile maintaining

performance.

6. Considerationof systemsensitivitiesanduncertaintiesis crucialto designprocess.

- Successfuldesignrequiresthat sensitivitiesanduncertaintiesbeproperlyaccountedfor and

managed.

- Uncertaintysignificantlycomplicatesthedesignprocess.Incorporateappropriatephilosophy

andproceduresfor handlinguncertaintythroughouttheprocess.

- Systemsensitivities(bothwithin andbetweendesignfunctions)areindicatorsof how much

concernshouldbegivento uncertainties.

- High performancesystemshavehighsensitivities,requiringmoreattentionto detailsof design.

- Designmusteitherreducesensitivitiesanduncertaintyor provideadditionalmargin.

- In theearlystagesofdesign,ensurethatadequatemarginsareprovidedtocoverthesensitivities

anduncertaintiesof thespecificvehicle,consideringits coarsestateof definition.

a" 7. En_,meers judgment and creativity is essential to design process.

- The complexity of the system requires applying judgment and innovation to the specific

launch vehicle situation. This cannot be supplanted by dogma, rules, or recipe.

- Tools enhance efficiency but cannot replace the judgment and creativity of the human mind.

- Guidelines and criteria should be tailored or adapted to the particular project to avoid a dogmatic

approach which unnecessarily constrains design solutions.

- Many decision gates are not deterministic but are judgment based, requiring indepth discipline,

system knowledge, and wisdom.

205
- Thelevelof penetration is an engineering judgment, determined by project characteristics,

design stage, sensitivity, and uncertainty.

8. The design process is complex and laborious; improve it wherever possible.

Continually explore approaches to high-leverage improvements, both evolutionary and

revolutionary.

Reduce process fragmentation; move toward more seamless design.

- Improve design modeling, especially for cost, operations, and reliability.

Explore more direct synthesis approaches to better convert requirements to concepts and

designs.

Improve the conceptual design process through better synthesis and higher fidelity representations.

Develop and mature an information system for efficiently conveying and displaying necessary design information to all participants.

7.3.2 Associated Discussion

Lesson 1: The first lesson is very important. It emphasizes people skills, putting them in the same

category as the engineering skills. Dick Kohrs has said that "Communications is 90 percent of integration."

Whether it is 90 or 60 percent, it is key to quality products. The T-model presented earlier emphasizes this

by requiring the discipline specialist to also have a system focus. The reward system of the organization

must support this emphasis.

Lesson 2: Just as important as the people skills is the truism, "You manage to ensure good technical

integration." As has been stated many times, "The integrity of the product is in the system; i.e., the integration." Engineering is accomplished by compartmentalizing the design tasks by subsystems and then

further by design functions and disciplines. In order to ensure that each is compatible

requires the process to be managed to achieve the goal of technical integration. There are many ways to

achieve technical integration. Working groups (technical and systems) worked well on Saturn and Space

Shuttle. Skunk works and design centers have also been successful. Management must ensure that each

person understands and accepts his or her role and responsibility for technical integration.

Lesson 3: Concept selection is key to successful products. It is generally accepted that at least

80 percent of the life-cycle cost is determined during the concept selection stage. Pugh has said,

"Engineering can never right a poor concept selection." The quality lever indicates the same focus. The

process is iterative, and it weeds out poor concepts, then looks in more depth at the remaining concepts.

The process repeats with further increased depth until a clear winner is established. More than two new

technologies are generally too risky for the development phase. The results of the trade studies and

sensitivity analysis should be carried forward for future reference, along with the selected concept. The

concept selection is therefore critical and must be emphasized by the leadership.

206
Lesson4: Requirements,constraints,andcriteriadictatetheproductdesign.Pughsays."It is the

mantle of the design." As important as constraints, standards, and criteria are, if they are too restrictive, the

design suffers; creativity and innovation are lost. Greenleaf in Servant Leadership 18 emphasized this point.

Many times they can dictate the design; instead of saying what is to be accomplished, they say how it is to

be accomplished. Criteria sometimes are used to replace failure mode analysis, which is a mistake. Constraints perform in the same way. The SSME weight constraint led to essentially an all-welded structure.

The all-welded structure led to many fatigue and fracture problems in the welds, requiring many redesigns.

Each project should carefully tailor criteria, constraints, and requirements, gleaning out all the "how's" and

reducing the "what's" to only those that are essential.

Lesson 5: All design is a balancing act between conflicting requirements. You get some of what

you want with some of what you do not want. Pye has said, "When you put energy into a system and

transform it, you cannot totally determine how that transformation will take place. You get some of what

you want and minimize what you don't want. This you do by design engineering." This process is therefore

a balancing act requiring firm technical and programmatic data. The decision in the end is usually a

judgment call. The balancing act is first of all among the design functions and technical disciplines (energy

redistribution), then between the program requirements, the design, and operations. Problems occurring in

the balancing act, if not resolved, are pushed downstream and are solved through operational procedures

and flight constraints, many times at high cost and reduced performance.

Lesson 6: Consideration of system sensitivities and uncertainties is crucial to the design process.

All major programs must find a way of designing for off-nominal conditions at a given probabilistic level

of risk without over penalizing the performance and cost. Sensitivities of the system to the parameter

variations are a measure of the level of concern one should put on an issue or an interaction. In general the

higher the performance requirements, the higher the sensitivity of the response to any variation of the

environments, manufacturing tolerances, etc. The sensitivity/performance curve is highly nonlinear. For

example, in the case of fatigue of metals, the sensitivity curve is the inverse of the SN curve. Design for

robustness is a desired method for dealing with uncertainties and sensitivities. A robust design is one where

the responses to perturbations are adequately managed. Robust design falls into two categories. In the first

category, a robust design could be one whose response is inherently insensitive to perturbations. In the

second, a robust design could be one where the response is sensitive to perturbations; however, the system

is designed such that the responses are maintained within acceptable limits. This can be achieved by

designing within predetermined margins, controlling the variations in significant response parameters,

actively or passively controlling the response, adding redundancy, and/or developing operational procedures

and constraints. Therefore, several approaches, either individually or together, are listed below that can be

used to accomplish robustness.

• Increase margins

• Reduce parameters uncertainties

• Reduce sensitivities (response to uncertainties)

° Redundancy

° Operational procedures and constraints.

All good design practices intelligently account for and deal with uncertainties and sensitivities as

design parameters using appropriate philosophies, procedures, and tools.

207
Lesson7: In the final analysis it is the engineer's judgment, innovation, and creativity that develop

the design and the product. All else are tools and aids to the human mind and the human skills. This means

that the organization must be a learning organization that constantly hones personal mastery and team

learning, using to the fullest the uniqueness/diversity of the individuals and the organization. In the end it

is usually the engineer's judgment, not deterministic metrics, that determines the product. Openness,

acceptance, inquiry, and advocacy are essential to the engineer's development and the quality of the product.

Lesson 8: Finally, the design process is complex and laborious. Significant improvements are

needed. Improve the process wherever possible. Apply lessons learned, and seek innovative ways to

revolutionize the process, as discussed in section 5. High leverage areas to explore include those listed in

section 7.3.1, item 8. Ideas for improvement can come from related fields of research such as multidisciplinary

design optimization, or may come from apparently unrelated fields. The keys to attaining highly effective

and efficient designs lie in the creativity, initiative, and judgment of the engineers who execute the design

process and continually seek to improve it.

208
8. CONCLUDING SUMMARY

This report provides a baseline characterization for the design process for launch systems as it is

currently practiced. The various areas of emphasis are shown below. The current design process was characterized by using hardware/software compartmentalization and interconnected design function planes

along with their corresponding decision gates for determining task completeness. The process characterization provides a framework for a comprehensive integrated information and communication system that

is recommended for any major effort. In specific areas suggestions for improvements have been made. A

survey of experienced practitioners in aerospace on the essence of engineering was included, as was a

detailed bibliography. Categorized lessons learned were provided, as were recommendations for future

enhancements of the design process.

The launch vehicle design process has been characterized, delineating the following elements:

• Compartmentalization/reintegration associated with subsystems, design functions, and

disciplines

• Technical integration illustrating both the formal and informal aspects associated with design

and discipline functions

• Design function (plane) features and related significant decision gates

• Information flow model associated with subsystems and design functions; i.e., the IxI and

N×N matrices

• Major activities, interactions, and tasks.

In addition to the characterization, necessary ancillary features of the design process were

provided. They include:

• Thumbnail sketch of process

• Essentials considerations

• Project technical framework

• T-model of technical integration

• Requirements, architecture, philosophy, etc., definition

• Design sequence including conceptual, preliminary, and detail design stages

• Illustration of the design process, shown through historical examples.

Finally, the process characterization provided the following: (1)A means for practicing engineers

to understand where they fit in the process, and their interactions, (2) a basis for understanding and improving the process, and (3) the necessary symbolism to develop a variety of electronic design tools. The

characterization applies to the design of any launch vehicle regardless of the organization/project structure.

209
9. RECOMMENDATIONS

It is recommended that the launch vehicle design process characterization developed herein be

utilized as a basis for understanding and improving the process. The current process must be constantly

improved to increase effectiveness and efficiency. Lessons learned should be implemented and process

improvement technologies should be incorporated as they are developed. The need to improve cost,

reliability, and operability leads to the need for revolutionary advances in launch system technologies.

These technologies include the categories of hardware/software technologies and process technologies. It

is essential that hardware/software technologies be developed, and these activities are currently underway.

Likewise, design process technologies must also be advanced to achieve effective and efficient designs.

Specific recommendations for design process technologies are as follows:

• Utilize the design process characterization as a basis for understanding and improving the

process.

Refine the present process to improve effectiveness and efficiency

- Work requirements and criteria to avoid stifling creativity and innovation

- Design for simplicity

- Improve design-to models

- Integrate discipline analyses.

Pursue revolutionary technologies for major improvements in the design process such as

- Advanced approaches for high-fidelity concept definition, sizing, and assessment

- Unified compartmentalization/reintegration process into a seamless whole; i.e., seamless

integration related to the subsystems, design functions and discipline functions

- Improved process ideation toward advanced idea stimulus approaches; e.g., direct synthesis

methods for concept identification

- Advanced analyses technology; i.e., high-fidelity design-to methods for performance and for

life-cycle attributes such as cost and reliability.

The challenge of providing unlimited access to space requires the best of people, technology, and

processes. Those who practice design must continuously improve the process.

210
APPENDIX A--NxN DIAGRAM FROM REFERENCE 2

Figure 96 is the NxN information flow diagram from reference 2. It was developed by MSFC to

represent typical information flow in the design process for example launch vehicles. This figure delineates inputs and outputs relative to various engineering design and discipline functions. For each entity on

the diagonal, its information outputs are shown on the horizontal row, and its information inputs are shown

on the vertical column. Therefore, connectivity is represented among all included entities.

211
dl

_- i_-='_ '-" _---'-- i_.-:'_ (-_,--." _'_" I',_',_:- _'_ :_"----

._g,,_ ":'_-':-_-'-':;_..",_-- i_-]_--'-="_"'-" _"= "_]:;Z_'7_._ --_" .... w

i]iiil]

• _ 7"---" _-- ...... ""-'::'_ - "....

'_'_ i ............ :='-

i

i

i,

]]]]i [

!

_:...._-_.-_-_ -___ ==_ _-_- _-_ ....................... _:-. :=--

i KEY: , ELV, RLV, and RBCC - RLV and RBCC -, RBCC only I

Figure 96. NxN matrix from reference 2.

212
APPENDIX BmSPACE SHUTTLE PARAMETER MATRIX ITEMS

Appendix B is an extract of certain portions of the Space Shuttle's parameter matrix (figs. 97-99).

Space Shuttle engineers developed matrices for each event and each basic design area. The matrix identifies

the parameter, the parameter values or reference source, the 3-sigma parameter uncertainties, and, where

applicable, the procedure for usage. The parameter matrix was developed by the specialists in each discipline

area based on a combination of historical data, current analysis, and current testing. The parameter matrix

document for a vehicle design must be a living document, changing both the base (mean) and uncertainty

values (reducing if possible) as the design matures. Critical to the process is development of a comprehensive

list of interacting parameters, both natural and induced. New systems need a comparable parameter matrix

definition to assure uniformity in the design. The discipline specialists with their knowledge of the system

and the data are central to its development. In the final analysis, design trades (balancing act) are made

using uncertainties coupled with sensitivities and appropriate weighting metrics. The importance of parameter

and uncertainty definition cannot be overemphasized.

213
ORGANFZAI1ON

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

15

MARSHALL SPACE FLIGHT CENTER

AFSIG REVIEW

NAME

R. RYAN

DATE

APRIL 1986

Discipline

Trajectory Performance

Pogo

Flutter

Control

Thermal

Liftoff Clearance (Drift)

Separation

Loads

Environments

Overpressure

Acoustic

Shock

Winds

Propulsion

Dynamics

Criteria

Failure Modes

Parameter Matrix

Event

Prelaunch

Launch

Max Q

Max G

Pre-SRB Separation

SRB Separation

Post-SRB Separation

Second Stage Ascent

ET Pre-Separation

ET Separation

Total Ascent

Figure 97. Parameter matrix.

214
ORGANIZATION

SYSTEMS DYNAMICS

LABORATORY

CHART NO,:

16

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

NAME

R. RYAN

DATE

APRIL 1986

SRM Propulsion

• TC227A-75 Thrust Versus Time Curve Per SE--O19-083-2H

(SRB System Data Book) for Bulk Grain Temperatures

(TC227H Is Proposed as Update)

• Flight-to-Flight Propellant Burning Rate

• Thrust Level Development Uncertainty

•Thrust Oscillation (Dynamic Factor Assumed for

Loads Analysis)

• Steady-State Thrust Mismatch Between Motors

• Thrust Misalignment

• Flight-to-Flight Thrust Level Dispersion

{

{

Analysis Tolerance

ETR - 81 °F (Mean)/83.4 °F (Max)

W-I-R - 52 °F (Mean)/44.5 °F (Max)

+ 5.3% (One SRM)

+ 4.7% (Two SRM's)

+ 3%

+ 5%

85,000 Ib (Ref. vol. X,

fig. 3.3.2.2e)

+0.75 ° Per SRB

++ 4.9% 5% Single Both Motor Motors

Aerodynamics

• Pressure Distribution Test Data Match with Aerodynamic

Coefficient Test Data

• Elevon Deflection Schedule #6 (Hinge Moment Limiting

Feedback) Per Rockwell Internal Letters ACDA/FSA/76-527

and 531

• SD72-SH-0060-2 (Mated Vehicle Aero Design Data Book)

• Include Aerodynamic Tolerance Effects on Coefficients:Wind

Tunnel Deviations Plus Power-on Deviations Plus Reynolds

Number Effects

+_3%

ASeo= f (__CHM = 0.02) Aero

Data Adjusted to New

(SeO+ ASeO)

None

Values Per PRCB Briefing on

8/18/-76 MCR 3378 "5.3 Ascent Load

Adjustments"

Figure 98. Basic parameters.

215
ORGANIZATION

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

17

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

(Continued)

NAME

R. RYAN

DATE

APRIL 1986

Main Propulsion System

• 3 SSME Thrust Level Throttling Range

• Thrust Oscillation (Dynamic Factor Assumed

Only for Load Analysis)

• Equal Throttle Settings on All SSME's

•With One SSME Out, The Two Remaining SSME's

Operate at 109% Thrust

•Thrust Misalignment

• Mixture Ratio (6:1)

•Variations in ET Propellant Load Left at

Meco Result From Off-Normal SRM/SSME

Performance and SSME Throttling History

Mass Properties

• Minimum Payload of 2,500 Ib (Mission 3B)

• Maximum Payload of 32,000 Ib (Mission 3A)

• Maximum Payload of 65,000 Ib (Mission 1)

Flight Control and Guidance

• Rockwell Control #7 Per SD73-SH-0097-1 (Integrated

Vehicle Flight Control System Data Book)

• Elevon Schedule #6 (Hinge Moment Limiting Feedback)

• Platform Misalignment

• Accelerometer Misalignment

• Accelerometer Null Offset (Time Variable)

• Accelerometer MDM Bias

• IMU Attitude Error

• Actuator Hysteresis

• Rate Gyro Misalignment

Analysis Tolerance

50% (MPL) to 100% (FPL)

± 5%

None

None

+ 3° Per SSME

None

None

None

None

None

None

_+0.02 Hinge Movement Coefficient

±0.5"

+0.5 °

0.010 to 0.025g (Pitch)

0.08 to 0.015g (Yaw)

0.0248

± 0.0083 °

1.5 MA

+2 =

Figure 98. Basic parameters (continued).

216
ORGANIZATION

SYSTEMS DYNAMICS

LABORATORY

CHART NK_,:

18

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

(Continued)

NAME

R. RYAN

DATE

APRIL 1986

Flight Control and Guidance (Continued)

• Rate Gyro Hysteresis

• Rate Gyro MDM Bias

• Rate Gyro Zero Offset

• SRB and SSME Forward Loop Gain

External Environment

• 95% Seasonal Winds Based on Monthly Wind

Ellipse Data for WTR and ETR (TMX-73319)

• Basic q_ql3: 95th Percentile Wind Envelope

Plus 3 m/sec Gust Plus 50th percentile Shear

Random qe-/ql3: FCS System Effects; 6 m/sec Gust

(i.e., 9 m/sec Minus 3 m/sec) and Shear up to 99th Percentile

Display qcdq!3Envelopes: Basic Plus FCS Effects:

Basic Plus 6 m/sec Gust and Shear Up to 99th Percentile

Vehicle Dynamics

• First 50 Bending Modes with 1% Damping

• Aeroelastic Effects

• Flutter Stability

- First 20 modes

- Control System Feedback Represented

- Parametric Variation of Actuator Stiffness

Failure Modes

• Numbers 1,2, or 3 SSME Out Anytime After Lift-off

•TVC Failure By-Pass Transient

Analysis Tolerance

_+0.02 deg/sec

+ 0.12 deg/sec

+ 0.15 deg/sec

+ 10%

None

None

None

None

Figure 98. Basic parameters (continued).

217
ORGAN_A_ON

SYSTEMS DYNAMICS

"LABORATORY

CHART NO.:

19

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

(Continued)

NAME

R. RYAN

DATE

APRIL 1986

Analytical Approach

•Trajectory Logic Superimposes Engine-Out

Squatcheloid on No-Failure Squatcheloid

• Conduct Loads Survey Around Squatcheloid Using

Rigid-Body Squawkr Program to Calculate Max/Min

Wing and Elevon Loads and ORB/ET and SRB/ET

Fitting Loads

• Flexible-Body Dynamic Response Calculated for Final Loads

Combination Method

• qcdql3 FCS Tolerance added (+_700 psf-deg q(x; + 700 psf-deg q13)

• 85% Gust Timed 6 sec After SSME Failure in 85% Max Shear

or Full Gust 6 sec After SSME Failure Followed by Full

Design Shear After SSME Failure. Sequence of Events

Selected For Maximizing Loads

• SRB Thrust Dispersions:

• SD73-SH-0069-1, -2, -3, and -4 (Structural Design Loads

Data Book)

• SD73-SH-0097-1 (Integrated Vehicle Flight Control System

Data Book)

Analysis Tolerance

Figure 98. Basic parameters (continued).

218
ORGANIZATION

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

2O

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

Lift Off

NAME

R. RYAN

DATE

APRIL 1986

SRM Propulsion

•TC227A-75 Thrust Versus Time Curve Per SE-019-083-2H

(SRB Systems Data Book) For Max/Min Grain

Temperatures (TC227H 1Proposed as Update)

•Thrust Level Development Uncertainty

• Steady-State Thrust Mismatch Between SRM's

• Flight-to-Flight Thrust Level Uncertainty

• Thrust Buildup Rate Development Uncertainty

• Thrust Misalignment

Aerodynamics

• Ground Wind Drag Coefficients Per SD72-SH-0060-2

(Mated Vehicle Aero Design Data Book) and

Rockwell Internal Letter SAS/AERO/75-430

Main Propulsion

• 3 SSME's at 100% Thrust (RPL) to 109% Thrust (RPL)

Analysis Tolerance

4090 °F (ETR) (WTR)

_+3%

35,000 Ib

+ 5%4.9%Single Both Motor Motors

Ref: SDIL SRM76-037

+ 0.50% (Both); 0.707 ° (One)

None

None

Figure 99. Liftoff load parameters.

219
ORGANrZAllON

SYSTEMS DYNAMICS

LABORATORY

CHART NO,:

21

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

Lift Off

NAME

DATE

R. RYAN

APRIL 1986

Mass Properties

• Minimum Payload of 2,500 Ib (Mission 3B)

• Maximum Payload of 32,000 Ib (Mission 3A)

• Maximum Payload of 65,000 Ib (Mission 3A)

Miscellaneous

• SRB/MLP Holddown Bolt Preload (750,000 Ib)

Flight Control and Guidance

• Rockwell Control No 7 Per SD73-SH-0047-1

(Integrated Vehicle Flight Control System

Data Book)

• All Nozzles Gimbal But SRB Nozzle Gimbal

Limited to 2° for First 5 sec

• SRB Mistrim to 0° Until SSV Clears the Launch

Pedestal

• STB TVC Misalignment

External Environment

• 95% Wind Speed (One Hour Exposure)

• Peak Wind Speed

• Tuned Gust (Worst Case)

Analysis Tolerance

None

None

None

None

None

+0.17 + 0.23 ° (SRB) (SSME)

None

2 (_RSS Each SRB in

Worst Direction

None

24 Knots (Max)

None

Figure 99. Liftoff load parameters (continued).

220
ORGAN_A_ON

SYSTEMS DYNAMICS

LABORATORY

CHART NO.:

22

MARSHALL SPACE FLIGHT CENTER

BASIC PARAMETERS

Lift Off

LAME

R. RYAN

DATE

APRIL 1986

Vehicle Dynamics

• First 50 Bending Modes with 1% Damping

Failure Models

• None

Analytical Approach

• Digital Simulation of Vehicle Flexible Body

Response Due to Applied Forces and Release of

Base Constraints

Combination Method

• Sequence of Events Selected or Max Loads (WOW)

• RSS Similar Uncertainties as a Group Then Add Groups

(+ 2 G Deviations) in Worst-On-Worst Combination

Documentation of Results

• SD73-SH-0069-1, -2,-3 and -4 Structural Design Loads

Data Book

Analysis Tolerance

None

Figure 99. Liftoff load parameters (continued).

221
APPENDIX C--GLOSSARY

Glossary Format: The glossary is divided into two sections. The first section is an alphabetical index of all

terms, which identifies a group number where the definition is located. The definitions are given in the

second section, grouped together with related terms to help clarify the definitions.

C.1 Alphabetical Index

Term Located in Group No.

Attributes ............................................................................................................................................... 2

Balancing Act ........................................................................................................................................ 4

Critical design review (CDR) ................................................................................................................ 1

Compartmentalization ........................................................................................................................... 3

Component ............................................................................................................................................ 3

Concept selection ................................................................................................................................... 1

Conceptual design ................................................................................................................................. 1

Conduits ................................................................................................................................................. 6

Constraints ............................................................................................................................................. 2

Design certification review (DCR) ........................................................................................................ 1

Derived requirements ............................................................................................................................ 2

Design cycle .......................................................................................................................................... 1

Design function ..................................................................................................................................... 3

Design phases ........................................................................................................................................ 1

Design stages ......................................................................................................................................... 1

Detail design .......................................................................................................................................... 1

Element .................................................................................................................................................. 3

Formal integration ................................................................................................................................. 4

Flight readiness review (FRR) ............................................................................................................... 1

222
Gates.................................................................................................................................................. 2,6

Informal integration............................................................................................................................... 4

IxI matrix............................................................................................................................................... 6

Life cycleattributes............................................................................................................................... 2

Manufacturingstage.............................................................................................................................. 1

Margin ................................................................................................................................................... 5

Missionconceptreview(MCR) ............................................................................................................ 1

Metrics................................................................................................................................................... 2

Minidesigncycle ................................................................................................................................... 1

9 Mission statement ...................................................................................................................................

NxN matrix ............................................................................................................................................ 6

Operations .............................................................................................................................................. 1

Parameters (design) ............................................................................................................................... 5

Part ......................................................................................................................................................... 3

Parts of a system .................................................................................................................................... 3

Performance ........................................................................................................................................... 2

Phases (of design) .................................................................................................................................. 1

Planes ..................................................................................................................................................... 6

Preliminary design ................................................................................................................................. i

Preliminary design review (PDR) .......................................................................................................... 1

Reintegration ......................................................................................................................................... 3

Requirement allocation .......................................................................................................................... 3

Requirements ......................................................................................................................................... 2

Risk assessment ..................................................................................................................................... 4

Sensitivity .............................................................................................................................................. 5

System requirements review (SRR) ...................................................................................................... 1

Stages (of design) .................................................................................................................................. 1

223
Subprocesses.......................................................................................................................................... 1

Sub-subsystem....................................................................................................................................... 3

Subsystem.............................................................................................................................................. 3

System................................................................................................................................................... 3

Systemsintegrationandverification..................................................................................................... 1

Tasks...................................................................................................................................................... 6

Technicalintegration............................................................................................................................. 4

T-model.................................................................................................................................................. 4

TechnologyReadinessLevel (TRL) ...................................................................................................... 2

Uncertainty............................................................................................................................................ 5

Verification............................................................................................................................................ 1

Workbreakdownstructure(WBS) ........................................................................................................ 6

224
C.2 Definitions

GROUP 1

Design stages. The design stages consist of conceptual design, preliminary design, detailed design,

manufacturing, and systems integration and verification. These design stages are followed by the operational

stage.

Design phases. Historically, there have been five design phases that have been replaced by the design

stages defined above.

• Phase A--Preliminary analysis

• Phase B--Definition

• Phase C--Design

• Phase D---Development

• Phase E--Operations.

Subprocesses. There are four "provide aerospace products and capabilities" subprocesses.

• Formulation--Define program

• Approval--Determine program readiness

• Implementation--Deliver program products and/or capabilities

• Evaluation--Assess the ability of program to meet its technical and programmatic commitments.

Conceptual design. That part of the design process where many feasible alternative concepts are determined

for detailed study. It occurs early in the process when only top-level system parameters are known.

Multicriteria decision-aiding techniques are used to reveal the best alternatives (could be a single alternative)

from the many proposed concepts. The down-select decision is based on performance, cost, schedule, reliability,

safety, operability, design uncertainty, and TRL figures of merit obtained from trade and sensitivity studies.

Preliminary design. This part of the design process follows conceptual design, and its purpose is to determine

which of the selected alternative concepts is the best and then to establish a baseline design concept. In this

stage, the configurations are further matured, and the significant subsystems are designed for inclusion in

the assessment. In addition, refined analyses, simulations, and tests data are developed for trade and sensitivity

assessments. All system support, manufacturing, test, and operations requirements are also defined. Refined

and updated multicriteria decision-aiding techniques are used to reveal the best configuration based on

performance, cost, schedule, reliability, safety, operability, and design uncertainty data obtained from trade

and sensitivity studies relating to the launch vehicle, all supporting activities, and all supporting systems.

This downselected configuration then becomes the baseline for detail design.

Detail design. During this part of the design process, the goal is to provide an engineering description

(drawings, specifications, plans, etc.) of a tested and producible design. Additionally, plans are updated for

final development, manufacturing, verification, and operations.

225
Manufacturing. During this part of the process, flight, facility, and GSE hardware and software are

developed, manufactured/coded, and documented.

Systems integration and verification. This is the final stage of vehicle development. All systems (hardware

and software) associated with the vehicle and operations are assembled, tested, and checked for compatibility,

functionality, and verification that the design requirements and constraints are satisfied and the system is

flight ready. All results are documented including anomalies and lessons learned.

Operations. Operations consists of two parts. The first part pertains to vehicle development. It is here that

it is determined if the launch vehicle satisfies the mission need statement or not. If it does not, then flight

constraints are required. The second part of operations occurs after all the flight constraints are determined.

Then routine operations are established which include evaluation of results and documentation of anomalies

and lessons learned.

Concept selection. Many alternative concepts are developed early in the design process. Initially, concepts

are conceived, evaluated, and rejected or accepted based upon top-level system requirements. Multicriteria

decision-aiding techniques are used to reveal the best alternatives from the many proposed concepts. The

downselect decision is based upon discriminators such as performance, cost, schedule, reliability, safety,

operability, design uncertainty, and TRL figures of merit obtained from trade and sensitivity studies. As the

design process proceeds, additional knowledge related to the discriminators is acquired through analyses,

simulations, and tests. This additional knowledge is applied with the multicriteria decision-aiding technique

at various levels of system maturity until one concept is finally selected. The final concept selection usually

occurs during or around PDR; however, some have occurred immediately after conceptual design. Then

the selected concept proceeds to final design, development, and operations.

Design cycle. Each stage (e.g., conceptual design, preliminary design, etc.) of the design process is completed

in a number of design cycles (iterations). For each design cycle during a particular design stage, the discipline

functions develop knowledge and reduce risk (design uncertainty) through analyses, simulations, and testing

at increasing levels of penetration as the design process proceeds from the conceptual design through the

systems integration and verification stages. Through the process of formal and informal technical integration

for each design cycle, the attributes determined by the design functions via the discipline functions are

assessed at the system level. The focus of the assessment is conformance of the attributes to the overall

system-levied requirements, constraints, philosophy, procedures, criteria, ground rules, etc., as well as

their balance, interactive compatibility, consistency, and associated data trends. If the attributes are not

consistent with the aforementioned and/or the appropriate level of maturity and risk has not been achieved,

then another cycle is initiated and the design process repeated until a set of appropriately matured and

balanced attributes with the required level of risk is achieved. At the initiation of each design cycle there

could be changes in the requirements, constraints, philosophy, procedures, criteria, ground rules, etc., based

upon results from the previous cycle.

Minidesign cycle. If a problem is indicated by analyses, simulations, testing, manufacturing, assembly,

operations, etc., then after assessment, a redesign may be required. If the redesign is of a localized nature

and does not impact the entire system, then the appropriate design and discipline functions execute the

redesign also without perturbing the entire system. Technical integration can be accomplished via a change

request guaranteeing that all the appropriate requirements are satisfied and balanced.

226
Mission concept review (MCR). First formal review. Assesses mission objectives and concepts along

with functional and performance requirements.

System requirements review (SRR). Demonstrates that the mission and system requirements are defined

and understood. In addition, management techniques, procedures, agreements, etc., are evaluated.

Preliminary design review (PDR). Conducted when the basic design approach has been selected.

Demonstrates that the preliminary design meets all the system requirements with acceptable cost, schedule,

and technical risk. The design drawings are about 10 percent complete. The results of successful review are

the "design to" baseline and the authority to proceed to final design.

Critical design review (CDR). Verifies that the design meets all the requirements and establishes a baseline

for manufacturing. The design drawings are about 90 to 95 percent complete. The results of a successful

review are the "build to" baseline and approval of the production and verification plans.

Design certification review (DCR). Evaluates the "as-designed" results from verification analyses, tests,

and simulations to certify the design. Determines what requirements were met, reviews significant problems,

and assesses corrective actions. This review is usually conducted after the manufacturing, assembly, and

verification process.

Flight readiness review (FRR). Certifies that the system is flight ready and all flight objectives can be

accomplished. This includes the launch vehicle, operational system, and all associated teams.

GROUP2

Mission statement. The fundamental statement of need for a system; for example, a basic requirement for

a launch vehicle to deliver xxx pounds of payload to a specified orbit at a reliability of at least yyy for a cost

not to exceed $zzz.

Requirements. The conditions that the designed system must meet. Requirements specify what attributes

the system must have. Requirements are "equalities;" that is, they require that the specified attribute equal

a certain value. In more general usage, requirements are taken to mean the combined set of requirements,

constraints, and derived requirements.

Constraints. The conditions that the designed system must be less than or must be greater than. Constraints

are "inequality requirements" in that they require that the specified attribute be less than or greater than a

certain value. Another type of constraint is that the TRL of any technology used in the design be greater

than a specified TRL.

Derived requirements. Requirements or constraints that are not top-level requirements associated with

the mission statement but which are created during the design process as a result of designing to meet the

top-level requirements. They may be identified by a design function or discipline to be imposed on itself,

or to be imposed on others.

227
Attributes. Propertiesof the designed system or subsystem. These may be performance properties, cost,

reliability, etc. An attribute is a property that can be compared with a requirement or a constraint.

Performance. In this document, performance typically means the physical behavior of the launch vehicle

or its subsystems, where that physical behavior has an effect on meeting the physical requirements imposed

on the vehicle. Examples of measures of performance include payload-to-orbit, mass fraction, specific

impulse of the propulsion subsystem, TPS mass density, etc. Performance is a physical attribute (or attributes)

of the launch vehicle which is distinct from the life cycle attributes of cost, safety, reliability, operability,

etc. Note also that this definition of performance is broader than the conventional usage of performance to

strictly mean payload-to-orbit.

Life cycle attributes. Vehicle attributes other than performance as defined above. Life cycle attributes

include cost, safety, reliability, operability, etc.

Technology Readiness Level (TRL). The maturity of a given technology, as measured by NASA's TIlL

scale; values ranging from 1 (least mature) to 9 (most mature).

Metrics. As used in this document, metrics are quantifiable measures of attributes (see following note).

(Note: "Quantifiable measure of attributes" is a definition of metrics applied in the recent past and applied

in this document. There is, however, a move in the engineering community to apply specific definitions to

certain parameters that quantify the system (see reference 19). In the past some of these terms have been

used interchangeably. Specifically, three of these terms are (1) figures of merit, (2) technical performance

measures (TPM's), and (3) metrics. In reference 19, figures of merit are used to quantify requirements.

TPM's are used to track the progress of design and manufacturing. Metrics are measures related to the

process, not the product.)

Gates. Events in the design process where an attribute of the design is compared with a requirement or

constraint. To pass the gate, the design's attribute must meet the requirement or constraint; if it does not,

the design must be changed or the requirement/constraint must be relaxed.

GROUP 3

Parts of a system. A system can be compartmentalized into parts. Usually this follows a hierarchy of

compartmentalization into smaller and smaller parts. Generically, the system is compartmentalized into

subsystems; the subsystems are compartmentalized into sub-subsystems, etc. Sometimes the various levels

of the hierarchy are given specific names, such as in the following examples which are not unique:

Level Specific Name

System Launch vehicle

Subsystem Propulsion

Element Liquid engine

Component Turbopump

Part Turbine blade

228
Designfunction.Theactivity of creating a design for a specific subsystem or system. The primary products

of a system (top plane) design function are the specifications and drawings for its subsystem or system.

The primary products of the other design functions (lower planes) are the descriptions of their respective

aspects of the design, as fed to the system plane. See also the discussion in section 4.3.1.

Discipline function. The activity such as analysis, simulation, testing, etc., that is performed during the

design process by specialists in the various technical areas of expertise. See also the discussion in

section 4.3.1.

Compartmentalization. Separation of the design process into managable parts. There are three types of

compartmentalization: (1) Separation of a system into subsystems (subsystems can be further

compartmentalized into sub-subsystems); (2) separation of the design functions for each subsystem; and

(3) separation of the design functions into the discipline activities necessary to achieve the design.

Reintegration. The process of recombining the compartmentalized parts of the design process to form a

complete system design. Discipline functions are reintegrated into design functions, design functions are

reintegrated into subsystems, and subsystems are reintegrated into the total system.

Requirement allocation. Identification and assignment of requirements by the system design function to

the subsystems and lower design functions. Requirements are divided and allocated with the intent of

producing a total design that will achieve the best balance among the subsystems and requirements.

GROUP4

Technical Integration. The interactive activity among all participants in the design process, whereby the

compartmentalized parts reintegrate into a balanced, successful total design. Technical integration is

enabled by formal and informal information flow methods, by a system focus of all participants on how

their part affects the total system, and by leadership that continually ensures that interactive aspects of the

design are being addressed and balanced.

T-model. A representation of technical integration that consists of three parts. The horizontal crossbar

portion of a "T" can be visualized as consisting of two parts as a result of a horizontal subdivision. The

upper portion of the subdivision represents formal integration. Formal integration is accomplished by the

leader via the systems plane. The lower portion of the crossbar represents informal integration. Informal

integration is accomplished by design and discipline functions. The third portion of the T-model is the

vertical leg of the T. This represents the activities of discipline engineers, and it signifies their indepth

discipline capability with a systems perspective.

Formal Integration. A communication activity that consists of interactions between the system design

function and all other design functions. It ensures that the attributes and uncertainties (developed by the

design functions) satisfy the requirements, constraints, etc., and they are compatible. An associated activity

of formal integration is resolving engineering conflict between design functions when incompatibilities,

inconsistencies, unnecessarily high interactions and sensitivities, etc., occur. These activities are

accomplished by the leader via the system plane.

229
Informal Integration. A communication activity that consists of interactions among discipline functions

in a design function and interactions between design functions. The focus of these activities consists of

data and information exchanges to determine the attributes and their uncertainties associated with the

design function planes in an efficient and accurate manner.

Balancing Act. There are two types of balancing acts. The first relates to the system where the program

requirements are balanced by the launch vehicle design and the operational design. The second relates to

interactive discipline and design activities where trade balances are made among the subsystems, design

functions, and disciplines to achieve the required attributes with acceptable uncertainties.

Risk Assessment. An evaluation process that addresses technical, cost, and schedule risk. It uses an estimate

of probabilities of success versus consequences of failure.

GROUP 5

Parameters (design). Design measures that fall into two categories: (1) One that the designer can control

and (2) one that the designer cannot control. The controllable parameters are measures that characterize the

design; e.g., independent variables of the design process. The latter parameters are environmental inputs

where the designer has control only over how they are characterized.

Uncertainty. A general term for the estimated amount by which the observed or calculated value of a

quantity may depart from the true or mean value.

Sensitivity. A measure of a system of functional relationships, a hardware system, or a software system

that can be defined as the amount that the dependent variables differ from their reference values (baseline)

when one of the independent variables differs from its reference value (baseline). The specific calculus

depends upon the application.

Margin. The difference between the value that a variable must not exceed (its requirement limit) and the

predicted maximum value of that variable, including known parameter variations. Margin is the measure

of headroom available in meeting the requirement, and may be included to allow for contingencies or

unmodeled uncertainties.

GROUP6

Planes. In the design process model delineated in this document, a plane represents a design function. The

plane contains the various activities that are executed within the design function.

Conduits. Pathways between planes that represent information flow among the design functions.

Gates. Events in the design process where an attribute of the design is compared with a requirement or

constraint. To pass the gate, the design's attribute must meet the requirement or constraint; if it does not,

the design must be changed or the requirement/constraint must be relaxed.

Tasks. Specific activities accomplished by design functions or discipline functions.

230
IxI matrix. A matrix thatdefinesinformationflow amongsubsystemsandbetweena subsystemand its

nexthigherlevel system.Interfaceinputs,outputs,andconnectivityareshown.

NxN matrix. A matrix that def'mesinformationflow amongdesignfunctionsanddisciplines,showing

inputs,outputs,andconnectivity.

Work BreakdownStructure (WBS).An organizedlistingof theareasof work(tasks)requiredto produce

adesign.

231
REFERENCES

.

2.

.

4.

5.

6.

7.

,

9.

10.

11.

14.

17.

Utterback, J.: Mastering the Dynamics of Innovation, Harvard Business School, Boston, MA, 1994.

Humphries, W.R; Holland,W.; and Bishop, R.: "Information Flow in the Launch Vehicle Design/

Analysis Process," NASA/TM--1999-209877, MSFC, December 1999.

Pugh, S.: Total Design, Addison-Wesley Publishing Co., New York, NY, 1991.

"NASA Systems Engineering Handboook," NASA SP-6105, June 1995

Gordon, J.E.: Structures, 07"Why Things Don't Fall Down, Decapo Press, 1986.

Pye, D.: The Nature of Design, Reichold Book Corp., New York, NY, 1969.

Blanchard, B.; and Fabrycky, W.: Systems Engineering and Analysis, Prentice Hall, Englewood

Cliffs, NJ, 1990.

"System Engineering Handbook," 2rid ed., MSFC-HDBK-1912A, MSFC, December 1994.

"Project Management Handbook," MM 7120.2A, MSFC, 1989.

"NASA Program and Project Management Processes and Requirements," NASA NPG 7120.5A,

April 3, 1998.

Wheelwright, S.C.; and Clark, K.B.: "Revolutionizing Product Development: Quantum Leaps in

Speed, Efficiency, and Quality," New York: Free Press, 1992.

Fleeter, R.: Launchspace Magazine.

Jenkins, D.R.: Space Shuttle The Histo_ y of Developing the National Space Transportation System,

Walsworth Publishing, Marceline, MO, 1997.

Ryan, R.S.: "Lessons Learned in Propulsion System Design" AIAA Joint Propulsion Conference,

San Diego, CA, July 1995.

Gordon, J.E.: The New Science of St_vng Materials, Princeton University Press, Princeton, NJ, 1988.

Petroski, H.: To Engineer Is Human: The Role of Failure in Successful Design, St. Martin Press,

New York, NY, 1982.

Petroski, H.: Design Paradigms: Case Histories of Error and Judgment in Engineering, Cambridge

University Press, 1994.

232
Greenleaf,R.F.:Servant Leadership, Paulist Press, New York, NY, 1977.

Moody, J.A.; Chapman, W.L.; Van Voorhees, F.D., and Bahill, A.T.; Metrics and Case Studies for

Evaluating Engineering Designs, Prentice Hall, 1997.

233
BIBLIOGRAPHY

Abramson, N.: "Dynamic Behavior of Liquid in Moving Containers," NASA SP-106, 1996.

Admire, J.R.; Tinker, M.L.; and Ivey, E.W.: "Residual Flexibility Test Method for Verification of Constrained

Structural Models," AIAA Journal, Vol. 32, No. 1, January 1994.

Admire, J.R.; Tinker, M.L.; and Ivey, E.W.: "Mass-Additive Model Test Method for Verification of

Constrained Structural Models," AIAA Journal, Vol. 31, No. 11, November 1993.

Akao, Y.; et al.: Quality Function Deployment, Productivity Press, Cambridge, MA, 1990.

Akao, Y.: Quality Function Deployment, Integrating Customer Requirements into Product Design,

Cambridge University Press, Cambridge, MA, 1988.

Anon.: From Earth to Orbit, National Academy Press, Washington, DC, 1992.

Anon.: "Spacecraft Design and Operations Problems," SAE SP--636, Aerospace Technology Conference,

October 1985.

Asimow, M.: Introduction to Design, Prentice Hall, Englewood Cliffs, NJ, 1962.

Augustine, N.R.: "Augustine's Laws," AIAA, New York, NY, 1983.

Bamford, R.M.; and Trubert, M.: "A Shock Spectra and Impedance Method to Determine a Bound for

Spacecraft Structural Loads," AIAA-75-811, May 1975.

Bamford, R.M.; Wada, B.K.; and Gayman, W.H.; "Equivalent Spring-Mass System for Normal Modes,"

JPL TM No. 33-380, February 1971.

Bendat, J.S.; and Piersol, A.G.: Engineering Applications of Correlation and Spectral Analysis, Wiley

Interscience, New York, 1980.

Bendat, J.S.; and Piersol, A.G.: Random Data, Analysis and Measurement Procedures, Wiley Interscience,

New York, 1986.

Biggs, R.E.: "Propulsion System Failure Analysis--A Methodology," AIAA/SAE/ASME/ASEE 28th Joint

Propulsion Conference and Exhibit, Nashville, TN, pp. 1492-3796, July 6-8, 1992.

Blair, J.C.; and Ryan, R.S.: "The Role of Criteria in Design in Management of Space Systems,"

AIAA-92-1585, March 1992.

234
Bookout,RS.:"StatisticallyGeneratedWeightedCurveFit of ResidualFunctionsfor ModelAnalysisof

Structures,"NASA TM-108481, NASA, Washington, DC, February 1995.

Braun, R.D.; Powell, R.W.; Lepsch, R.A.; Stanley, D.O.; and Kroo, I. M.: "Comparison of Two

Multidisciplinary Optimization Strategies for Launch-Vehicle Design," AIAA Journal of Spacecraft and

Rockets 32:3, May]June 1995.

Bruhn, E.E: Analysis and Design of Flight Structure, John Wiley & Sons, New York, 1993.

Chamis, C.C.: "Probabilistic Structural Analysis Methods for Space Propulsion System Components"

Probabilistic Engineering Mechanics, Vol. 2, No. 2, pp. 100-110, 1987.

Christensen, D.L.: "Advances in the Application of Systems Engineering Procedures" AIAA-96--4433,

1996.

Cikanek, H.A.: "Characteristics of Space Shuttle Main Engine Failures"AIAA-87-1939, AAIMSAE/ASME/

ASEE 23rd Joint Propulsion Conference, San Diego, CA, July 1987.

Collins, J.: Failure of Materials in Mechanical Desig_r--Predictions, Prevention, 2d ed., John Wiley &

Sons, New York, 1993.

Craig, R.R.; and Bampton, M.C.C.: "Coupling of Substructures for Dynamic Analysis," AIAA Journal

61:7, July 1965.

Crandall, S.H.; and Mark, W.D.: Random Vibration in Mechanical Systems, Academic Press, New York,

1963.

Cross, N.: Engineering Design Methods, Wiley, New York, 1989.

Cyr, K.J.: "The Role of Cost Analysis in Manned Spacecraft Development," SAE 901863, Aerospace

Technical Conference, October 1990.

Deming, E.: Out of the Crisis, Massachusetts Institute of Technology, Cambridge, MA, 1989.

Den Hartog, J.P.: Mechanical Vibrations, McGraw-Hill, New York, NY, 1956.

Dieter, G.E.: Engineering Design--A Materials and Processing Approach, 2d ed., McGraw-Hill, New

York, NY, 1991.

Drucker, EE: Managing for Results, Harper & Row, New York, NY, 1984-86.

Dym, C.L.: Engineering Design--A Synthesis of Views, Cambridge University Press, 1994.

Ehrich, F.F.; and Childs, D.: "Self Excited Vibration in High-Performance Turbomachinery," Mechanical

Engineering, pp. 66-79, May 1984.

235
Ertas,A.; andJones,J.C.:"The EngineeringDesignProcess."

Ferebee,R.C.:"Applicationof a ComputerizedVibroacousticDataBank for RandomVibrationCriteria

Development,"NASA TP 1998, NASA, March 1982.

Ferguson, E.S.: Engineering and the Mind's Eye, Massachusetts Institute of Technology, Boston, MA,

1992.

Flugel, C.; and Weisbrich, A.: "Voice of Customer Conversion Steps," Japan Business Consultants, Ann

Arbor, MI, 1990.

Fox, J.: Quality Through Design, McGraw-Hill, New York, NY, 1993.

"Fracture Control Requirements for Payloads Using the Space Shuttle," NASA-STD-5003, October 1996.

"Fracture Control Requirements for Space Station," SSP 30558-B, June 1994.

French, M.: Im'ention and Evolution, Design in Nature and Engineering, Cambridge Press, New York, NY,

1994.

Garrick, I.E.; "Aeroelasticity--Frontiers and Beyond," 13th Von Karman Lecture, AIAA Journal of

Aircraft, 113:9, September 1976.

Garrick, I.E.; and Reed lIl, W.H.: "Historical Development of Flutter," AIAA-81--O591-CP, Atlanta, GA,

April 1981.

Geissler, E.D. (Editor): "Vehicle Response to Atmospheric Disturbance," Wind Effects on Launch Vehicles, AGARDograph 115, February 1970.

Goldberg, B.E.; et al.: "Systems Engineering "Toolbox" for Design Oriented Engineers," NASA Report

1358, MSFC, December 1994.

Greenwood, D.T.: Principles of Dynamics, Prentice-Hall, Inc., Engtewood Cliffs, NJ, 1965.

Handy, C.: The Age of Paradox, Harvard Business School, Boston, MA, 1995.

Harris, C.M.; and Crede, C.E., Eds: Shock and Vibration Handbook. McGraw-Hill, New York, 1976.

Himelblau, H.: "Guidelines for Dynamic Environmental Criteria."

Hopkins, J.: "Approaches to Reduced Launch Operations Costs," SAE 901877, Aerospace Technical

Conference, October 1990.

Hubka, V.; and Eder, W.E.: Design Science, Springer-Verlag, London, 1996.

236
Humphries, R.; Wegrich, R.; Pierce, E.; and Patterson, W.: "A Survey of Spacecraft Thermal Design

Solutions." NASA MSFC, October 1991; ESA and AST, Fourth European Symposium on Space

Em,ironmental Control Systems, Florence, Italy, October, 1991.

Hurry, W.C.: "Dynamic Analysis of Structural Systems by Component Mode Synthesis," JPL Technical

Report No. 32-530, January 1964.

Ibrahim, S.R.; and Mikulcik, E.C.: "A Method for the Direct Identification of Vibration Parameters from

the Free Response," The Shock and Vibration Bulletin 47, Part 4, September 1977.

"Loads Analysis of Spacecraft and Payloads," NASA-STD-5002.

Lovingood, J.A.: "A Technique for Including the Effects of Vehicle Parameter Variations in Wind

Response Studies," NASA TM X-53042, May 1964.

"Management of Major System Programs and Projects," NASA NMI 7120.4, November 1993.

McCarty, J.; and Murphy, J.M.: "An Assessment of Liquid Propulsion in the United States," AIAA,

July 1989.

Melosh, R.J.; Deither, P.A.; and Brennan, M.: "Structural Analysis and Matrix Interpretive Systems (SAMIS)

Program Report," JPL TM No. 33-307, December 1966.

Metals Handbook, 9th ed., Volume II, Failure Analysis and Prevention, Failures of Rolling Element

Bearings, American Society for Metals, Metal Park, OH, pp. 490-514, 1979.

Miller, I.; Freund, J.E.; and Johnson, R.A.: Probability and Statistics for Engineers, 4th ed., Prentice Hall,

Englewood, Cliffs, NJ, 1990.

Mintzberg, H.: Mintzberg on Management, Free Press, New York, 1988.

Niu, M.C.Y.: Composite Airfi'ame Structures, Hong Kong Comlit Press, Hong Kong, 1992, Rev. 1996.

Noor, A.K.; and Venneri, S.L.: "New and Projected Aeronautical and Space Systems, Design Concepts

and Loads," ASME, New York, 1994.

O'Hara, K.: "Liquid Propulsion System Reliability---Design for Reliability;" AIAA-89-2628, July 1989.

Pack, H., Jr.; and Young, L.E.: "Solar Array Flight, Dynamic Augmentation Experiment," NASA TP 2690,

NASA, Washington, DC, February 1987.

Pahl; and Beitz: "Engineering Design," The Design Council, Springer-Verlag, London, 1984.

"Payload Test Requirements," NASA-STD-7002, July 1996.

237
"Payload Vibroacoustic Test Criteria," NASA-STD--7001, June 1996.

Peters, T.; and Waterman, R.: In Search of Excellence, Warner Books, New York, NY, 1985.

Phadke, M.S.: Quality Engineering Using Robust Design, Prentice Hall, Englewood Cliffs, NJ, 1989.

Pikey, W.; and Pikey, B.; Eds: "Shock and Vibration Programs, Reviews, and Summaries;' SVMIO, The

Shock and Vibration Information Center, United States Department of Defense, 1975.

"Program]Project Management," NASA NPD 7120.4A, November 14, 1996.

Rao, J.S.: Rotordynamics, 2d ed., J. Wiley, 1991.

Rao, S.S.: The Finite Element Method of Engineering, Pergamon Press, New York, NY, 1982.

Ravindra, M.K.; and Galambos, T.V.: "Load and Resistance Factor Design for Steel," Jomwal of the

Structural Division, Vol. 104, No. ST 9, pp. 1337-1353, 1978.

Ricks, E.; Klein, M.; and Reynolds, J.: "Derivation of Improved Load Transformation Matrices for Launchers-Spacecraft Coupled Analysis, and Direct Computation of Margins of Safety," Proc. Intl. Conf.: "Spacecraft Structures and Mechanical Testing," ESA SP-289, January 1989.

Ryan, R.S.; Nurre, G.S.; Scofield, H.N.; and Sims, J.L.: "Dynamics and Control of Large Space

Structures," Journal of Guidance, Conovl and Dynamics, Vol. 7, No. 5, September-October 1984.

Ryan, R.S.: "Practices in Adequate Structural Design," NASA 2893, January 1989.

Ryan, R.S.: "Systems Analysis Approach to Deriving Design Criteria (Loads) for Space Shuttle and Its

Payloads," NASA TP 1949 and 1950, December 1981.

Ryan, R.S.; Jewell, R.; Bugg, E; Ivey, W.; McComas, R.; Kiefling, L.; and Jones, J.: "Dynamic Testing of

Large Space Systems," NASA TM-78307, September 1980.

Ryan, R.S.: "The Role of Failure]Problems in Engineering: A Commentary on Failures Experienced -

Lessons Learned," NASA TP-3213, March 1992.

Ryan, R.; and Verderaime, V.: "Launch Vehicle Systems Design Analysis Applied," AAIA-93-1140,

February 1993.

Ryan, R.; and Verderaime, V: "Systems Design Analysis Applied to Launch Vehicles," NASA TP-3326,

February 1993.

Ryan, R.; Schutzenhofer, L.; Jones, L; and Jewell, R.: "Elimination of Discrete Frequency Acoustical

Phenomenon Associated with the Space Shuttle Main Engine Oxidizer Valve Duct System," lOth Shock

and Vibration Symposium, Colorado Springs, CO, October 1979.

238
Ryan,R.S.;et al.:"DynamicTestingof LargeSpaceSystems,"NASA TM-78307, September 1980.

Ryan, R.S.: "Fracture Mechanics Overview," JANNAF Nondestructive Evaluation Subcommittee

Meeting, CPIA Publication 514, NASA Langley Research Center, May 1989.

Ryan, R.S.; and Townsend, J.: "Application of Probabilistic Analysis/Design Methods in Space Programs:

The Approaches, The Status, and the Needs," AIAA-93-1381, SDM AIAA/ASME, LaJolla, CA, April,

1993.

Ryan, R.S.; Mowery, K.; and Tomlin, D.D.: "The Dynamic Phenomena of Tethered Satellite," NASA

TP 3347, NASA, Washington DC, February 1993.

Ryan, R.S • "Fracture Mechanics Overview," JANNAF Nondestructive Evaluation Subcommittee Meeting,

Langley Research Center, May 2--4, 1989.

Ryan, S.G.: "Limit Cycle Vibrations in Turbomachinery," NASA TP 3181, December 1991.

Safie, E; and Fox, E.P.: "A Probabilistic Design Analysis Approach for Launch Systems," AIAA-91-3372,

June 1991.

Salomone, T.A.: "What Every Engineer Should Know About Concurrent Engineering," Marcel Dekker,

Inc., 1995.

Scharton, T.: "Vibration-Test Force Limits Derived from Frequency-Shift Method," AIAA Journal of

Spacecraft and Rockets 32:2, March-April 1995.

Schock, R.: "Solar Array Flight Dynamic Experiment," NASA TP 2598, NASA, Washington, DC,

May 1986.

Schutzenhofer, L.A.; McConnaughey, P.K.; and McConnaughey H.V.: "Role of CFD in Propulsion

Des ign---Government Prospective," AIAA-90-1825, 1990.

Senge, P.: The Fifth Discipline, The Art of the Learning Organi:ation,'" Doubleday, New York, NY, 1990.

Shen, E; and Pope, D.: "Design and Development of Composite Fairing Structures for Space Launch

Vehicles," SAE 901836, Aerospace Technology, October 1990.

Sobieski, S.; and Goetz, R.C.: "Synthesis of Aircraft Structures Using Integrated Design and Analysis

Methods," Status Report, NASA, Langley Research Center, VA.

"Space Shuttle Launch System Evaluation Advisory Team (LSEAT) Integrated Support Plan,"NSTS 03211,

Rev. B, Johnson Space Center, NASA, December 5, 1991.

"Space Vehicle Design Criteria (Structures), Buckling of Thin-Walled Doubly-Curved Shells" NASA

BP-8032, August 1959.

239
"SpaceVehicleDesignCriteria(Structures),Bucklingof ThinWalledTruncatedCones," NASA BP--8019,

September 1986.

"Space Vehicle Design Criteria (Structures), Buckling Strength of Structural Plates," NASA BP-8068,

June 1971.

"Space Vehicle Design Criteria (Structures), Discontinuity Stresses in MetaIlic Pressure Vessels," NASA

BP-8083, November 1971.

"Space Vehicle Design Criteria (Structures), Design-Development Testing," NASA SF--8084, May 1970.

"Space Vehicle Design Criteria (Structures), Fracture Control of Metallic Pressure Vessels," NASA

BP-8040, May 1980.

"Space Vehicle Design Criteria (Structures), Preliminary Criteria for the Fracture Control of Space Shuttle

Structures," NASA SF-8095, June 1971.

"Space Vehicle Design Criteria (Structures), Stress-Corrosion Cracking in Metals," NASA BP-8032,

August 1985.

"Space Vehicle Design Criteria (Structures), Structural Design Criteria Applicable to a Space Shuttle"

NASA BP--8087, January 1971.

Steward, D.V.: Systems Analysis and Management, Petrocelli Books, Inc., New York, NY, 1981.

"Structural Design and Test Factors of Safety for Spacecraft Hardware," NASA-STD-5001, June 1996.

"Structural Design and Verification Requirements--ISSA," SSP 30559-B, June 1994.

Sullivan, R.: "A Coupled Solution Method for Predicting the Thermostructural Response of Decomposing,

Expanding Polymeric Composites," Journal of Composite Materials, Vol. 27, No. 4, 1993.

"System Engineering Handbook," 2d ed., MSFC-HDBK-1912A, MSFC, December 1994.

Taguchi, G.: Introduction to Quality Engineering, American Supplier Institute, Inc., Dearborn, MI, 1986.

Ullman, D.: The Mechanical Engineering Design Process, McGraw-Hill, New York, 1994.

Ulrich, K.; and Eppinger, S.: Product Design and Development, McGraw-Hill, New York, 1994.

yon Pragenau, G.: "Damper Seals for Turbomachiner)," NASA TP-1987, March 1982.

Wallace, P.J.: The Technique of Design, Sir Isaac Pitman & Sons Ltd., London, England, 1952.

Walton, M.: The Deming Method, Periger Books, Putman Publishing Co., New York, NY, 1986.

240
Wirsching,EJ.;et al.:"An Overviewof ReliabilityMethodsin MechanicalandStructuralSystems,"28th

Annual Structures, Structural Dynamics, and Materials Conference, April 1987.

Wirshching, P.H., and Ortiz, K.: "Reliability Methods in Mechanical and Structural Design," 13th Annual

Seminar and Workshop, Univ. of Arizona, Tucson, AZ, January 1992.

Woodson, T.T.: Introduction to Engineering Design, McGraw-Hill, New York, 1996.

Zarestsky, E.: "Life Factors for Rolling Bearings," STLE Publications SP-341, 1992.

241
REPORT DOCUMENTATION PAGE FormApproved OMB No. 0704-0188

Public repoding burden for this collection of information is estimated to average I hOUrper response, including the time for revtewthg instructions, searching existing data sources

gathedng and maintaining the data needed, and completing and reviewing the collectk_nof information Send comments regarding this burden estimate or any other aspect of this

collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for InformationOperation and Reports, t 215 Jefferson

Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Projec_(0704-0188), Washington, DC 20503

1. AGENCY USE ONLY (Leave B/ank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED

May 2001 Technical Publication

4. Trt'LE At,K/SUBTrt'LE

Launch Vehicle Design Process: Characterization, Technical

Integration, and Lessons Learned

6. AUTHORS

J.C. Blair*, R.S. Ryan*, L.A. Schutzenhofer*, and W.R. Humphries

7. PERFORMINGORGANIZATIONNAMES(S)ANDADDRESS(ES)

George C. Marshall Space Flight Center

Marshall Space Flight Center, AL 35812

9. SPONSORING/MONITORING AGENCYNAME(S)ANDADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546-0001

5. FUNOING NUMBERS

8. PERFORMING ORGANIZATION

REPORT NUMBER

M-1018

10, SPONSORING/MONITORING

AGENCY REPORT NUMBER

NAS A/TP--200 I-210992

11. SUPPLEMENTARYNOTES

Prepared for Structures and Dynamics Laboratory, Science and Engineering Directorate

* AI Signal Research, Inc.

12a, DISTRIBUTION/A VAILABIL ITY STA TEMEN_

Unclassified-Unlimited

Subject Category 15

Standard Distribution

12b. ITISTRIBUTION CODE

13. ABSTRACT (Maximum 200 words)

Engineering design is a challenging activity for any product. Since launch vehicles are highly complex and

interconnected and have extreme energy densities, their design represents a challenge of the highest order. The

purpose of this document is to delineate and clarify the design process associated with the launch vehicle for space

flight transportation. The goal is to define and characterize a baseline for the space transportation design process.

This baseline can be used as a basis for improving effectiveness and efficiency of the design process. The baseline

characterization is achieved via compartmentalization and technical integration of subsystems, design functions, and

discipline functions. First, a global design process overview is provided in order to show responsibility, interactions.

and connectivity of overall aspects of the design process. Then design essentials are delineated in order to emphasize

necessary features of the design process that are sometimes overlooked. Finally the design process characterization

is presented. This is accomplished by considering project technical framework, technical integration, process

description (technical integration model, subsystem tree, design/discipline planes, decision gates, and tasks), and the

design sequence. Also included in the document are a snapshot relating to process improvements, illustrations of the

process, a survey of recommendations from experienced practitioners in aerospace, lessons learned, references, and

a bibliography.

14. SUBJECT TERMS

design process, space transportation, technical integration, launch vehicles

17. SECURITY CLASSIRCATION

OF REPORT

Unclassified

NSN7S40-0t-280-SS00

18. SECURITY CLASSIFICATION

OF THIS PAGE

Unclassified

19. SECURITY CLASSIFICATION

OF ABSTRACT

Unclassified

15. NUMBER OF PAGES

26O

16. PRICE CODE

20. LIMITATION OF ABSTRACT

Unlimited

Standard Form 298 (Rov. 2-89}

Pre_cn'bedbyANSI Std, 239-18

298-102