NASA

Technical

Paper

2,893

January 1989

fPractices in _Adequate

Structural Design

/

RobertS. Ryan

N/ A

al/15

T J/

I

https://ntrs.nasa.gov/search.jsp?R=19890009133 2018-11-04T21:11:18+00:00Z
_4

/I
NASA

Technical

Paper

2893

1989

National Aeronautics

and Space Administration

Scientific and Technical

Information Division

Practices in Adequate

Structural Design

Robert S. Ryan

George C. Marshall Space Flight Center

Marshall Space Flight Center, Alabama
k

r
5

TABLE OF CONTENTS

I. INTRODUCTION .....................................................................................

II. GENERAL CONSIDERATIONS ...................................................................

Page

1

3

III. MANAGEMENT ...................................................................................... 22

IV. ANALYSIS AND TEST .............................................................................. 40

V. DOCUMENTATION AND DATA BASING ..................................................... 50

VI. PROCEDURES AND CRITERIA .................................................................. 72

VII. SUMMARY ............................................................................................ 81

REFERENCES .................................................................................................. 89

...pRECEDING PAGE BLANK NOT FILMED

o°o

111
,i:_,iiil _

J

Figure

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

ll.

12.

13.

14.

15.

16.

17.

18.

19.

20.

LIST OF ILLUSTRATIONS

Title Pag_

Keys to the door of project management ........................................................ 4

The maze ............................................................................................ 5

Viewpoint ........................................................................................... 7

The steps to the goal ............................................................................... 9

Sensitivity versus performance ................................................................... 9

High cycle fatigue lifetime ........................................................................ 10

Side view of shuttle on launch pad ...................................................... ......... 12

Pre-liftoff energy storage ......................................................................... 13

Design values and analysis cycle values ........................................................ 14

Ascent flight envelope limits ..................................................................... 15

4000 Hz vibration anomaly main injector ...................................................... 16

4000 Hz vibration phenomenon .................................................................. 17

Engine 2116 main injector splitter vane cracks ................................................ 17

Spectrum of gimbal bearing accelerometer ..................................................... 18

Design and verification ............................................................................ 19

Relationships ....................................................................................... 23

Management/control block diagram ............................................................. 27

Structural loads/dynamics block diagram ....................................................... 30

Structural validation process ..................................................................... 32

Typical subsyste_i_rganization • ,,. 33

iv
LIST OF ILLUSTRATIONS

/

, i!i

Figure

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

Title Page

System volume organization ..................................................................... 34

Sample audit trail, DVS program ................................................................ 35

Sample audit trail, post STS-6 ................................................................... 36

Design verification specifications (DVS) ....................................................... 37

Conflict of expectations ........................................................................... 39

Management dilemma ............................................................................. 40

Systems analysis flow ............................................................................. 42

Analysis tier ........................................................................................ 43

Structural analysis flow ........................................................................... 44

Structural analysis ................................................................................. 46

Structural analysis flow ........................................................................... 47

Aft skirt post with axial, radial, and tangential load ........................................... 48

Aft skirt refined mesh model results ............................................................. 50

SRM fracture mechanics program ............................................................... 51

Fatigue life assurance-information flow diagram .............................................. 52

Structural validation process technical .......................................................... 53

Relationships of applied load history, strength, and damage

size with time ....................................................................................... 54

Typical residual static strength data ............................................................. 54

The four pillars of structural integrity ........................................................... 59

FPL SS pressure, speed, thermal ................................................................ 61

V

<:
LIST OF ILLUSTRATIONS

_: !_ii! ̧

Figure

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

Title Pag_

Detailed post redesign nonlinear STA-2B loads ............................................... 62

Documentation tree ................................................................................ 65

Statistical summary of SSME vibration data ................................................... 66

Typical isoplot of a pump accelerometer response ............................................ 67

Isoplot showing frequencies indicating rubbing ............................................... 68

Anomalous frequencies in response data ....................................................... 69

Reference acoustic function ...................................................................... 70

Scaled vibration spectrum with criteria ......................................................... 71

Typical stress strain relationship ................................................................. 75

Vibration spectra tolerance ....................................................................... 76

Illustrative limit-load probabilities .............................................................. 77

Factors of safety .................................................................................... 78

The effect of wall thickness on value of proof test ............................................. 79

Fracture control selection and disposition of parts ............................................. . 80

vi
TECHNICAL PAPER

PRACTICES IN ADEQUATE STRUCTURAL DESIGN

I. INTRODUCTION

Since the Challenger accident, the focus of NASA has centered on space vehicles, their problems,

their design, and their verification. The recurring question can be simply stated as: What constitutes

adequate structural design and verification? Many have attempted to answer this question. Structural

design manuals and handbooks address the subject, most very thoroughly. With all the wealth of

material, why open it again? The Challenger accident reopened every question dealing with reliability

and safety. As a result, the question became highly focused through the failure investigation and the

resulting audits for return to flight. NASA and its contractors have spent the last two years redesigning

hardware and conducting the following major audits: (1) structural, (2) fracture mechanics, (3) weld

assessments, (4) FMEA/CILs (failure mode effects analysis/critical items list), (5) hazards, (6) DCR

(design critical review) exercises, (7) FRRs (flight readiness reviews), and (8) PDRs (preliminary design

reviews) and CDRs (critical design reviews) for redesigned parts. These assessments have brought many

aspects of the question into a sharpened image. In order to see the sharper focus, however, one must

formulate subsets of questions. Some of the questions are:

/

(l) What are the roles management plays and the procedures they use?

(2) How and to what extent are philosophy, procedures, and criteria a part of good design?

(3) How important are methodology, codes, etc.?

(4) What are the roles of testing?

(5) How does documentation fit into the picture?

(6) How do performance requirements impact design adequacy, and what is the criteria for

determining adequacy?

(7) What constitutes an optimum design?

(8) What is the role of system engineering in design and verification?

(9) What effects do operations and refurbishment requirements have on design and verification?

(10) How does failure philosophy (fail safe, etc_) impact the process?

The answer to these and other questions must be tied together to form a consistent, overall approach that

will result in good, safe hardware.
'i_i " : ,

!:i:

• 3 '

Since the 51-L incident, investigation results focused attention on safety of design, thus on desigr

audits. It is appropriate that this paper begin with a definition of a design audit. An audit is a review oJ

something that has been done relative to an accepted or proven set of criteria. In many cases the establishment of these criteria is very debatable. A structural audit, for example, would challenge the design anc

verification against the design specifications (performance) given in terms of operational lifetime,

margins of safety, fracture mechanics, inspections [NDI (nondestructive inspection)] etc., all made relative to standards of management, documentation, analysis, test, data bases, as-built hardware, history,

etc. Conducting the audit is not easy since major questions have to be dealt with:

(1) Should the review be top down or bottom up?

(2) What are the standards goodness is judged against, is it concrete or the judgement of the

reviewer?

(3) How are the results (recommendations managed: (a) short term, (b) long term, and (c) future

projects?

(4) Who does the reviews: (a) independent auditors, (b) design engineers, etc?

Some of these questions also arise during the design and verification of any system. The answers to these

questions are different depending on the audit being conducted.

In order to conduct the audits, a review must first be made of all requirements followed by the

development of audit checkoff forms and questions for each discipline and each audit. As a result, traceability has to be shown from requirements to performance with the adequacy of the performance

established from both analysis and test, as well as supporting documentation. As stated previously, many

audits were conducted from failure mode effects analyses to weld assessments and all are interrelated and

connected. The structure is declared safe only if all the wickets are passed or appropriate waivers with

risk assessment (rationale) developed.

The observations or guidelines discussed in this document are the result of NASA/industry participation in these audits/reviews. Through many discussions with others, their thoughts, ideas, etc., the

author was influenced greatly in developing these ideas. It is impossible to give each credit; however,

laboratory director, Dr. George McDonough, and Vince Verderaime, laboratory technical staff, have

been both an inspiration and the source of many challenging thoughts. This paper will deal with these

observations in the areas of (1) general approaches, (2) management and control, (3) analysis and test,

(4) documentation and data basing, and (5) procedures and criteria. Mechanical disciplines alluded to

will include: (1) stress; (2) dynamics; (3) fracture mechanics; (4) NDI; (5) quality; (6) environments, (a)

thermal, (b) flow, and (c) vibration; (7) natural environments; (8) testing; (9) fatigue; and (10) system

analysis. Other disciplines are similarly scrutinized but are outside the scope of this discussion. The basic

principles are applicable, however, to all disciplines and areas.
_'ili_ii__

 ili

I1. GENERAL CONSIDERATIONS

This paper is written basically from the engineering point of view; however, no discussion of the

engineering process is complete without a brief reference to how a project evolves and the role of

engineering with management in this early evolution.

After a national commitment for a space system, spacecraft, or space mission has been identified

and top level (level I) requirements and goals are defined, the proposed project is studied through a phase

A feasibility effort to develop significant operational, developmental and programmatical characteristics, and to determine:

(1) The performance required to accomplish the mission.

(2) Time required to develop and operate the system.

(3) Funding necessary for all phases.

Level I is the overall performance requirements; level II is the basic system requirements; level III

is the spacecraft, etc., element requirements; and level IV, if it exists, is the next level down.

The three keys to the triangle of project management are: performance, schedule, and costs (Fig.

1). The test of how well the key fits is minimizing the risks and consequences involved. Is a new technology involved? Will the risk for developing it result in untimely completion and cost overruns? At this

point in time, phase A satisfactorily establishes feasibility with acceptable risks. The new technology for

Space Shuttle was the orbiter tiles. No large space project has survived initial concept where more than

one major new technology was required. Improving existing technologies does not count.

The project then proceeds to a phase B study to develop level II and III requirements, to propose

design options for satisfying requirements, and to perform trade studies for selecting the optimum design.

The resulting "request for proposal" (RFP) must identify and address all significant risks that might affect

performance, schedule, and costs. The role of engineering support to the project is most critical in this

phase for identifying risks, tasks, sensitivities, etc., that affect cost, schedules, and performance.

Requirements identified for the project and in the RFP must be stated void of solution so that

options are left open. For example, do not specify a viewing window and rule out the use of a TV

canmera which may be more versatile and cost effective. The requirement should be the capability to

observe a particular event. Options can then be evaluated on reliability, performance, consequences,

cost, etc., and the optimum selected.

These trades should be a combined exercise of project management and engineering. The result is

the final configuration selection for phase C and D (design and development), stating clearly an estimation of the significant spacecraft configuration characteristics and special resources necessary through

operations.

3
,i

d_2

COST

© ©

SCHEDULES PERFORMANCE

Figure I. Keys to the door of project management.

Configuration selection at the completion of phase B is a critical step. All pertinent information

required for phase C/D has been developed during this phase and now must be processed into a

comprehensive RFP. This requires a team effort including legal, project, contracts and procurement, and

engineering. Engineering is responsible for performance requirements, subsystems definition, data base,

and verification requirements. The RFP is followed by a Source Evaluation Board (SEB) where the contractors proposals are evaluated. Engineering, as members of this board, evaluate the replies relative to

compliance with the RFP and identify the "extra-plus" contributions or lack thereof. They assess the test

program, articles required and flow, and facility capability. The result is selection of the contractor and

initiation of the project. The process and principles which are involved to some extent during phases A

and B, and are controlling during phase C/D, constitute the body of the report.

How to find your way through the design and verification maze of a project is a puzzling question

illustrated by the maze in Figure 2. What the major blocks are, how each is cleared, and how each is

integrated to form the whole are the major questions represented. In the sections that follow, the assumption is made that the standard engineering approach is used, i.e., (1) define the problem, (2) conduct

simplified response and sensitivity analyses to establish understanding and limits, (3) perform detailed

analyses and test to characterize system, and (4) validate the characterization of the system. In order to

scientifically interrogate, we have to do so from a point of view. Our expectations become the spectacles

in front of the eyes that influence what we see. Therefore, in order to deal with the issues which follow, it

is important to establish an overall concept, philosophy, or approach. That viewpoint is one which sees

from each prospective the whole as well as the parts, how they interact, and everything in between. The

basis for this viewpoint is system engineering, or just system analysis and testing. All interactions, both

interdisciplinary and interphase, from concept to operations, must be tied together, including failure

criteria, such as fail safe, fail safe fail operations, etc. In all likelihood, more failures have been caused

4
5, ..

How to find your way through the

Design and Verification of Structural Systems

MANAGEMENT

I

PROCEDURES

L

__"_c_"_'__' Ii

I

• I'L

PIIO_:(:I $16NA| UIII_

Figure 2. The maze.
from lack of systems engineering than any other one cause. Many illustrations could be given. The first

of my experience occurred on the Redstone military rocket. The vehicle was lying in its horizontal cradle

undergoing checkout of the control system. A bending mode was excited when the gyro pickup potentiometer (composed of wound coil and pickup arm) jumped from one wire to the other creating step

signal changes to the control system. This signal moved the jet vanes (control force source) which further

inertially excited the mode creating a closed-loop structural control interaction problem maintaining the

oscillation. The noise of the oscillation was very loud and scary, impressing everyone that so much

energy could be present in just the inertial part of the control system. "It only hurts at resonance" was

dramatically illustrated. Since this was a small amplitude, nonlinear oscillation, it limit cycled and no

problems occurred. The fix was simple, an analog filter was used to break the loop by filtering out the

bending mode frequency component of the signal.

System analysis, system test, and system integration must be accomplished. Paramount in this

viewpoint are sensitivity investigations that identify key parameters and predict interactions. This can

and should be approached from both bottoms-up and tops-down considerations. It should be emphasized

that from wherever the process is viewed, the total picture must be kept in focus, understood, and worked

at all levels and interfaces. The pyramid view (Fig. 3) is valid for all the major blocks in the maze.

Obviously, from the top down, each level contains greater and greater details while fitting into the

whole. Management as well as analysis must fit into this concept. In making this statement it is not

implied that a very formal authority line is enforced, but only that some management or leadership should

exist at each level starting with project management down to the individual engineer, technician, etc. As

discussed later this, in general, means the acceptance of the responsibility by the man doing the job,

including communication, etc. The management approaches in books by Drucker and the latest by Peters

and others [1, 2, 3, 8, 1 l, 12, 44 through 51] adequately set the tone of what is implied by the term

management. This raises a basic problem in terms of communication between the levels, the source of

the known CEIs (contract end items), etc. It should be clear that there is also a flow between the various

major areas of emphasis. This flow is both vertical and horizontal. In general, more is required horizontally than vertically. The complexity of the interaction and exchange is hard to depict; however, analysis,

test, management, and documentation must flow between disciplines and organization levels. To insure

that the system focus and approach is applied, very basic principles must be applied. The following is a

discussion of the top 12 principles.

1. Interfaces are Compatible and Well Defined

The interfaces must be compatible and well defined. This means that when crossing from one

level to another, or between categories, some form of pattern recognition, hence symbols, must be

developed and established so that only the essentials (maybe special symbols) and all aspects of the

details will be viewed. The development of these patterns/symbols (recognition approaches) is key to all

the various aspects of the design verification process. This problem is complex enough if everything is

contained in one organization; however, for aerospace in general, the multiplicity of organizations

involved in providing parts, subsystems, elements, and the verification analysis and test is very large.

The ability to provide these symbols, establish communications, and to insure compatibility is a major

problem in assuring adequacy of structural design.
i_•;i • _ _ ...... _ i_ i _ ....

¥

3EARING

SHUTTLE

PROPULSION

ENGINE

FUEL PUMP

HOUSING

PROGRAM

SYSTEM

ANALYSIS

SUB SYSTEM

ELEMENT

COMPONENT

PART

SYSTEM

DOCUMENTATION

REQ'S.

TECH.

REPORTS

CEI

CEI

DRAWINGS

TECH.

REPORTS.

DRAWINGS

CEI

MARGINS

LIFETIMi

TECH.

REPORTS.

STABILITY

-.a Figure 3. Viewpoint.
i ̧,

2. People Are The Prime Resource

For the approach to work, it must be recognized that people are the prime resource for accomplishing the tasks. Other resources should be aids for the human. This will be discussed more under

management; however, it is the fulcrum about which all else pivots. This points to the next big principle.

3. Analysis and Test are Limited

All simulations, models, symbols, patterns, etc., whether dealing with analysis, test,

management, etc., are just that, models which are not complete (limited) and are not exact representations of reality but are mathematical or physical representations or symbols with various assumptions of

these facts. In the book Mathematics for Dynamic Modeling, Edward Beltran says,

"The essence of modeling, as we see it, is that one begins with a nontrivial work problem

about the world around us. We then grapple with the not always obvious problem of how

it can be posed as a mathematical question. Emphasis is on the evolution of a roughly conceived idea into a more abstract but manageable form in which inessentials have been

eliminated. One of the lessons learned is that there is no best model, only better ones. The

model is 0nly a suggestive metaphor, a fiction about the messy and unwieldy observations of the real world. In order for it to be persuasive, to convey a sense of credibility, it

is important that it not be too complicated and that the assumptions that are made be clearly in evidence. In short, the model must be simple, transparent, and verifiable." [53]

This principle must be fully understood so that everything is being constantly challenged for applicability. The major problem we deal with is how this less-than-reality information is meshed together to

get verified, reliable systems. Obviously, this can only be done in some probabilistic sense. As is illustrated in Figure 4, this is the goal of a system. If it is a space system, then the goal is reliable operation

with adequate safety margins that meet the performance requirements goals. Obviously, robust statistical

approaches must fundamentally apply to insure that all outliers are understood and accepted. This raises

the next major principle.

4. Performance Requirements Drive Design

The system performance requirements determine the design, technologies, penetrations, etc.,

necessary to meet the goal. Performance requirements are always broad in scope, encompassing not only

the response but also all characteristics from design through operations. For example, if the payload-toorbit performance is good, but the payload must be operated only in very restricted conditions and with

great effort, the net performance may be poor. The higher the performance, by definition, the greater the

sensitivity of the design to uncertainties. Uncertainties exist inall the areas of design: materials properties, environments, analysis, testing, manufacturing, etc. If one thinks about this deep enough, a generic

curve can be constructed of sensitivity versus performance (Fig. 5).

Designs in the flat portion of the curve basically can be dealt with in a linear fashion. As the

design moves out on the curve into the steeper slopes, nonlinear analysis is implied. In the first case, the

design is inherently conservative and easily predicted, since superposition works and the nonlinearities

not used to gain margin are still present and do add to the margins. (Nonlinearities in general are conservative.) In the latter case (high performance design), use must be made of the nonlinearities in order to

8

_, • •_' "• '• .... " • •: i  ̧• ̧ i•• _ i••.  ̧i_r
REQUIREMENTS CONCEPT

"i DEVELOPMENT H VERIFICATION

__@___

REALIBLE SYSTEMS

ADEQUATE MARGINS

MEETS REQUIREMENTS

FAIL SAFE

Figure 4. The steps to the goal.

II--

O3

.Z

ILl

O3

..... _ !/

!!!

PERFORMANCE

Figure 5. Sensitivity versus performance.

meet design margins criteria. It should be pointed out that nonlinearities are not easily predicted or

analyzed. They are certainly sensitive to unknowns and changes. If the performance requirements are

such that the design is inherently in this region, then great care and accuracy must be taken to develop

data bases, define environments, and perform analyses, etc. Manufacturing, nondestructive investigation, quality control, and acceptence criteria parameters must be enhanced. If, however, one designs for

robustness, the lower curve exists, providing margin at the performance index. For example, the design

option limits are (1) achieve robustness at a large increase in weight using more volume, pressure, etc.,

or (2) minimize weight at all cost, achieving performance through sophistication, including exotic

materials, etc. In option 1 (assume a launch vehicle), the added weight and size, although achieving

robustness on the surface, increases hardware cost. Option 2 bypasses this kind of cost increase but adds
cost due to the higher accuracy requirements, etc. The optimum lies somewhere between the two

extremes. The curve can also be shifted to the right through data acquisition and increased knowledge, in

many cases a desirable approach (technology advancement). At the onset and periodically throughout the

program, sensitivity studies must be made to determine where the design rests, what parameters should

be made robust, and what the real optimum is considering all factors. Other curves or data illustrate this

same type of information or sensitivity. For example, the S-N curve for a structure at or near yield shows

the same phenomenon (Fig. 6). Operating at the flat portion of the curve creates a large sensitivity of life

to small changes in alternating stress. A 5 percent increase in alternating stress can reduce life up to two

orders of magnitude.

A

L

T

E

R

N

A

T

I

N

G

S

T

R

E

S

S

NUMBER OF CYCLES

Figure 6. High cycle fatigue lifetime.

In this case, the part usually has limited life, small oscillating strains, and high frequencies which

lead to short lives. Implied also is the dependence on high cycle fracture mechanics as well as plastic

(nonlinear) low cycle fracture control, thus, NDI requirements become very stringent.

Three examples from the Space Shuttle program will be given to illustrate the reality of the

performance/sensitivity principles. Numerous examples exist, however, those chosen should be sufficient to illustrate the principle: (1) pre- and liftoff loads, (2) max Q loads, and (3) engine 4000 Hz.

10
•i!

a. Pre-Liftoff and Liftoff Loads

The Space Shuttle on the pad and at liftoff is a multi-body dynamic system; This is a very

complex system consisting of five Shuttle elements [payload, orbiter, external tar/k (ET), two solid

rocket boosters (SRBs), and the mobile launcher pad (MLP)]. The Shuttle is attached to the MLP through

four posts on each SRB. All external loads and the vehicle weight are reacted through these eight elastic

posts. The sequence for liftoff requires that the SSMEs be up to full power before igniting the SRBs and

lifting off. This thrust force bends the vehicle in two ways, storing energy through deforming the (elastic)

structure. The vehicle bends in the pitch plane deflecting the nose of the SRBs approximately 2 ft. This

energy is stored in struts, the SRM/MLP posts, and basic skin and structure at the strut attach points. The

second bending occurs due to the lateral component of the thrust driving the orbiter and tank between the

SRBs, rolling the SRBs in a gear train fashion. Two other parameters affect this stored energy:

(1) vehicle weight and (2) cryogenic shrinkage. Before propellant loading, the vehicle is misaligned at

the aft SRB-to-ET struts by 7 deg (struts not perpendicular to the center of the vehicle). With propellant

loading, the tank shrinks bringing the struts to the perpendicular condition, storing energy (aft tank ring

and bulkhead) in the tank. Figure 7 shows the vehicle side view on the pad, while Figure 8 shows the

stored bending moment as the SRBs are rolled in the gear train mode. Typical elastic connections are

shown as springs instead of actual hardware. To reduce loads at liftoff, the SRBs are ignited at the

minimum Y bending moment point. What parameters affect the vehicle loads and how sensitive the loads

are to these parameters are the main concerns. Key parameters are (l) the definition of the elastic

characteristics of all structures, including the MLP; (2) SSME thrust; (3) SRB thrust rise rate and thrust;

(4) winds; (5) payloads; (6) sequencing; and (7) overpressure. Because of dynamic tuning, the

unsymmetric load paths, and point loads, the vehicle response (loads) is very sensitive to small changes

in parameters. Plus or minus 20 percent in loads is common with model updates. Larger changes, 50

percent, can occur for certain parameter changes that affect payload loads. References 19 and 20 contain

many examples of these effects, however, only one is shown. Space telescope ascent loads increased

significantly due to small shifts in models to account for design changes, etc. Figure 9 shows the resulting load changes between three loads cycles compared to the original design estimation. Notice that the

vector load of the secondary mirror increased from 6 g to 13 g, basically due to model updates.

b. Max "Q" Orbiter Wing Loads

The first Shuttle flight showed an aerodynamic moment different from prediction, causing the

vehicle to loft more than expected. The cause was an aerodynamic distribution shift (total force was

approximately correct) due to inability to correctly simulate plume effects in the wind tunnel tests. The

small shift in aerodynamic distribution had a major effect on the wing load, and hence its structural capability. Figure 10 shows the original "qeL" capability of the wind using the predicted aerodynamic distribution. Shown on the same figure is the current best understood wing capability after beefing up structure in

the wing's leading edge. The wing root, etc., because of inaccessibility, was not beefed up to solve the

total problem. It should be pointed out, however, that to fix the total wing problem would also involve

changes to the fuselage. In order to fly safely, the trajectory shape had to be changed to fly within the

revised "qe_" boundaries shown in Figure 10. This does not come free. The cost is a several-thousandpound loss of payload capability. This high sensitivity of trajectory shape to loads and performance illustrates clearly the point being made. As a result of this effect, all Shuttle flights are specifically tailored

with stringent day-of-launch commit criteria. Details of this total area can be obtained from JSC/

Rockwell. More information on the interactions is contained in Reference 20.

11
•pedqouneI uo 0lllnqs jo hAOIA op! S "L oin_!H

o

ONIEId8 :::IOV-IEI31NI BEI8 01 d7_

±sn_H_ 3nss ca'_a'La

(SONI_aS)

NOIZO3NNO0 ZN3n373 _3ZNI"IIIM-

\

8_S A4 4_---I_

J.3A-4

8_sX-I

c_

- B_i i

ioli

i Ill

i, 0 i i A-I

! !I!I I !

-- _ hl_l

J i_i lilo!_ ,:..,,2. ii /I3

ii ii i ii _ _._

i i i'"_ "

!!.iV _Ok_
MLP TO SRB POST.

SPRINGS _

/ MxET"_

MxSRB

II,FyET

FzET

FzOR_-

INTER ELEMENT CONNECTION

(SPRINGS)

MxORB

_,, Figure 8. Pre-liftoff energy storage.
COMPONENT

PRIMARY

MIRROR

SECONDARY

MIRROR

P.L.C.

I.L.C.

C.D.R.

DIR

DESIGN

VALUE

MAXIMUM ACCELERATION (G's)

LIFTOFF LOADS

P.L.C. I.L.C. C.D.R.

X

Y

Z

X

Y

Z

3.7

2.4

3.7

3.8

3.5

6.7

3.1

1.1

2.6

"3.1

2.3

5.0

3.5

1.2

2.0

3.4

2.6

3.3

4.5

0.9

3.2

4.5

2.3

12.9

= PRELIMINARY LOAD CYCLE, USED 5.4 SHUTTLE DATA

= INTERMEDIATE LOAD CYCLE, USED 5.7 SHUTTLE DATA

= CRITICAL DESIGN REVIEW LOAD CYCLE, USED 5.8 SHUTTLE DATA

Figure 9. Design values and analysis cycle values.
i:__ ,

2000

1000

-1000

0

-2000

q _ -3000

-4000

-5000

-6000

-7000

-8000

- MAX 5.4 DESIGN

_ENVELOPE _

UPPER LIMIT OV-99/102

ov /

%"'" MIN 5.4

DESIGN FLIGHT

ENVELOPE

S

S

S

S

S

S _

_ m _L_ _ _ _ _ OCA MIN LIMIT

(W MOMENT TIES)

0.6

I I I I I I I I

0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2

MACH NUMBER

Figure 10. Ascent flight envelope limits.

c. SSME 4000 Hz Oscillation

The SSME is a very high performance system that, on the flow side, has a very high dynamic

pressure environment. As a result, various structures are very sensitive to flow and acoustic/structural

interaction problems. Figures 11 and 12 show the lox flow system near and into the injector. The lox inlet

has a two blade splitter in order to create a more uniform lox flow distribution into the lox dome (Fig. 13).

Any type vane protrusion into this high flow environment is susceptible to flow-induced oscillations and,

thus, fatigue failure. This has occurred on the inlet splitter. Three engine units have had cracked splitters.

These fatigue cracks are believed, based on analysis and test, to be caused by vortex shedding off the

vane trailing edge occurring at the vane natural frequency at 4000 Hz. In addition to the three splitters

with cracks, several other units have shown the 4000 Hz phenomenon, but at a lower level, without

cracks. The amplitude determines the alternating stresses, hence, life. Figure 14 shows a spectrum of

an engine with and without the 4000 Hz buzz. Notice the narrowband sharpness of the tuning. The interesting part of the story is that 10 percent of the engines buzz, the others do not at any time in their test

15
J

• _'y. "i _ _ • _ :_ • •

-/

• Y i; •

FROM MAIN

OXIDIZER

VALVE

AREA OF

CONCERN

•IRUST CONE

OXIDIZER

MANIFOLD

MAIN ELEMENT

OXIDIZER POSTS

INJECTOR BODY

FROM HOT-GAS

MANIFOLD

FROM HGM

COOLANT CIRCUIT "-

SECONDARY

PLATE

PRIMARY PLATE

BAFFLE ELEMENTS

MAIN ELEMENTS

HYDROGEN CAVITY

Figure l l. 4000 Hz vibration anomaly main injector.
©E©©

;>N0Q

©

0,,-_

0,,-_

z
15 ̧

1.0E+003

N

"r"

CO

(.9

(3-10)

1.0E-O02

O.

TEST 7500262

I I I I I I i

4025.0

4412.5

2012.5

4075.0

3687.5

3562.5

Z 4312.5

- 3737.5

4262.5

3850.0

662.05

2.09

1.59

1.29

0.91

O.87

0.81

0.76

0.76

0.74

BW = 12.5

AUGS = 8

COMP = 97.35

S+140 109%

NO FIX

FIX

FREQUENCY (Hz)

5OO0

Figure 14. Spectrum of gimbal bearing accelerometer.

history. There does appear to be some correlation of buzz amplitude with power level; however, the frequency of the oscillation is independent of power level. The buzz cause has to be due to small manufacturing differences in the bluntness of the vane trailing edge and possibly small vane angle/offset differences or slight modal shifts. There is one proposal that says the variation in shell thickness at the nose

of the vanes changes the tuning, etc., causing the vane oscillation to tune and amplify. The problem has

been fixed by sharpening the vane trailing edge and scalloping the leading edge to allow more flow area

between the two vanes. Engine 2025 buzzed around 100 gs before the fix and had no discrete 4000 Hz

component after the fix. The message is clear, high performance systems are very sensitive to small

changes, whether in manufacturing or environments, many times leading to failure or strict operational

requirements.

As stated previously, for these high sensitivity regimes, extreme care must be exercised in deiCermining characteristics and operational criteria. As a result of these high tech requirements, the reliability

of the system requires greatly increased technology for testing, analysis, manufacturing, quality, etc.

Operations also, in general, become more costly with tighter constraints and loss of flexibility, along

with design and development phases. Obviously, there comes a point where the total system is more

optimum at points where structural (or other) performance is traded for weight, fuel, etc. Also, more

18
ili_ _ii!

emphasis on optimization selection criteria is implied for configuration selection (based on many

parameters, not just weight). Does this mean that high tech design is not pursued? In no way; however,

the implication is clear that big increases in knowledge (technology) are required, with tighter acceptance controls if the design is to be adequate. This means that judging a design's adequacy requires understanding the operation point on the sensitivity curve. Figure 15 is an attempt to flow these optimization

trades together. Notice that the process is iterative and not a one-time effort.

I PERFORMANCE

REQUIREMENTS

i_!i CONCEPTS _'.,

ANALYSIS TRADES TESTING

(TOTAL)

I OPTIMIZATION I

DESIGN

VERIFICATION

V

CONCEPT I

SELECTION

Figure 15. Design and verification.

5. Design for Robustness and Growth

Design for robustness and growth is key. Robustness achieves overall performance, usually at the

expense of weight, but with reduced sensitivity to errors and unknowns. Growth potential provides flexibility allowing for mission changes as data changes (Fig. 15).

6. Configuration Complexity Determines Penetration

Just as important is understanding the configuration complexity. It should be pointed out that in

many cases the attempt to solve one problem, even through simplicity, can create complexity in another.

Back to the system focus. This complexity is evident in many areas. Two will be discussed: (1) dynamics

and (2) static load paths.

(1) Dynamic systems are fairly predictable if they are basically a single body without extreme

geometric ratios. If the configuration is composed of several separate bodies connected by links, etc., the

characteristics are those of a redundant structure and become more predictable and sensitive. The

bodies can dynamically tune, greatly amplifying the response and reducing prediction accuracy. A more

19
unsymmetricalconfigurationproducesamorecomplexproblem(seediscussiononShuttleliftoff loads).

Someargumentcanbemade,however,thatthestructuraldampingshouldbegreater.This helpsoutbut

doesnot solvetheproblem.Thelowerthedamping,thegreatertheunpredictabilityof thedynamictuning. It is clearthat thesesystemsbecomemore susceptibleto environnmentcoupling suchasflowinducedoscillations.Reference20addressesthehistoryandclassesof problemsthathavetheir rootsin

complexdynamicconfigurations.

(2) Staticloadpathsarein thesamecategory.Thesimplertheloadpath,thegreaterthepredictability; the morecomplex, the lesspredictable.Unsymmetriesworsenthe situationby loadingboth in

bendingand shear,coupling everythingtogether.Thesecomplexitiesproducestressconcentrations,

quality controlproblems,andnon-planestressfields,drivingrequirementstowardmoredetailedanalysis

codes,testing, etc., to properly characterizethe system.

Configurationcomplexityisobviouslyadriver in determiningadequatedesign.Flagsto look for

andwork thoroughlyinvolvesymmetryversusnonsymmetry,multi-bodies,loadpaths,etc.Anotherkey

flag deals with joints, whether they are welds, bolts, connectors,or fasteners.Structuremust be

assembledwith joints. One canminimize the systemcomplexityby appropriateselection.Stressconcentrationsareanotherflag. Theyshouldbereducedasmuchaspossible,otherwisecontrolledbyproper

design.

7. Philosophy

Determining proper design and verification philosophy entails several major principles, for

example, design for high performance, minimum margins, or large margins to cover breakdown in

quality control, uncertainties in environments, etc. Designing for minimum margins places a large burden

on analysis, test, manufacturing, quality control, NDI, etc., in order to have a safe system. A quality,

high performing, realistic system can always be achieved but with a burden. The system is always ready

for failure with any breakdown in control and understanding, and is less amenable to performance

upgrading. Designing for flexibility in operations and increased performance is always a worthy philosophy since most systems will require growth even if not forecast. Other approaches include such things

as (1) design for versus assessment for fracture mechanics, (2) failure considerations, (3) reuse versus

throw-away, (4) plan for destructive hardware evaluation, (5) design for factors on endurance limit, and

(6) use of FMEA to establish inspections, etc. If, for example, the philosophy and criteria are to

implement a fracture control plan as an integral part of the design requirements, then, the design must

include this philosophy. Fracture control can only be implemented partially if the design originally did

not consider it. Several factors come into play: material selection, weld location, inspection, etc. The

same type considerations are involved with other philosophical design options. Many other philosophical

principles exist and will crop up throughout the remainder of the report. The next principle is mandatory

in all design areas.

8. Bracketing Hand Analysis is Key to Understanding

One of the most important general principles is to make simplified hand analyses to understand

the phenomenon and guide all more indepth computer evaluations. These should include free body

diagrams and flow schematics to provide visualization. A fundamental part of this approach is the determination of the extreme or limiting cases. By establishing the physical understanding of a problem and its

bounds, greater insight and more efficiency are established. Computational approaches and testing have

become so sophisticated that without this approach gross errors, hence faulty design, occur.

2O
9. Statistical Significance Determines Design Adequacy

A principle that cuts across all facets of the process states that all characteristics should be stated

from both a deterministic and a statistical viewpoint. In the final analysis, these deterministic limits with

some reasonable statistical statement are all that can be relied on.

The statistical or probabilistic detertermination must consider all known variations of parameters.

These variations must include environments, models, hardware, build tolerances, materials characteristics, etc., as well as safety factors or other built-in factors so that the statistical statement incorporates all

known effects and the unknown factors. There are many techniques for conducting and making these

determinations for linear systems. If nonlinear determinations must be used, the assessment is greatly

expanded, with very limited availability of tools. For example, nonlinear Monte Carlo analysis, one technique available, is very costly in terms of computer time.

The deterministic statement is made by running a discrete analysis where one or several

parameters are perturbed to the envelope limit. These analyses are extremely conservative but allow

bracketing of the system. In general, a design would not be made to these extremes. Their use is for

understanding and setting limits.

10. The Sum of Parts is Not Equal to the Whole

All the previous principles point to the next general principle to be discussed: the sum of the parts

is not equal to the whole. Or said differently, a part or component responds differently when it is separate

than it does when it is a part of the whole. As a result, we must understand interaction and sensitivities to

provide the proper design. Verification becomes even more complex in that it must account for these

extremes, including failures and their redundant paths, etc. This means that a system as well as an

individualistic approach has to be developed for analysis, testing, etc., as well as management. The

Jupiter was a classical example of control and structural coupling and how to solve the problem through

the elimination of red tape. The step rate of the pitch command of the Jupiter was in synchronous with the

liquid oxygen first propellant slosh mode which was unstable, as confirmed by flight guidance and control data evaluation. The result was a saturated control system and loss of vehicle and prestige. Analytical

and empirical models of propellant sloshing were in their infancy. This meant that a solution had to be

found quickly and verified in order to successfully launch the next vehicle. Scale model slosh tests were

started without all the detailed test readiness reviews (TRRs), test plans, etc. Many approaches were

proposed and tested. The one chosen was the so-called "beer cans" [20] where long perforated cylinders

with buoyancy spheres were floated near the surface. The verification test was made by placing an actual

tank filled with water on a railroad car and bumping it against the line stop. This means of excitation

showed qualitatively the difference between no fix and the fix. The next flight was flown successfully as

planned using the beer cans and a changed step rate pitch command. Detailed analysis and testing

followed after the flight leading to the use of baffles instead of beer cans as an operational approach. As a

result, simplified slosh models were developed for control analysis which are still valid today. A philosophy was instituted that said sloshing would be damped using baffles to isolate sloshing from the control system and make the baffles an integral part of the structure, saving weight.

The previous l0 principles have dwelt essentially on the engineering side although they are

inherent in project management. The next and final two principles shift gears somewhat with the

emphasis on project and industry side of hardware.

21
11. Proper Relationship Between Project Management and Science and Engineering is

Mandatory

The end goal of a project is a safe, reliably efficient product whether it is a space vehicle, its

elements, or an orbiting space system, etc. To meet this goal, it is mandatory that the roles and missions,

controls, etc., between project and science and engineering be clearly defined and understood. The philosophy of how this pie is cut varies from project to project, agency to agency, and contractor to contractor. There is no black and white answer. For example, can engineering override project or does

project make the final decision? How are cost and schedules used as both management tools and control

of the product? In other words, does engineering or schedule determine the design? Cost and schedules

are excellent tools yet many examples exist where inferior products resulted from over-emphasis of their

role. Clearly this definition makes the difference between adequacy and inadequacy. As shown on Figure

15. the concept/performance requirements traced through to the design verification involve project and

engineering even to the selection of the original goal, mission, or product. A proper relationship between

project and engineering is the secret to good hardware. Since this is properly under management, further

discussion is contained in that section.

12. Clearly Define the Roles and Mission Between Government and Contractor

Many approaches/philosophies are used to define the working relationship between government

and contractors. They have ranged from the stance where government was the designer/integrator with

industry playing the role of special support (subcontractor) to the government defining the performance

characteristics and industry designing, manufacturing, and verifying the product. Whichever of the many

possible roles between these two extremes is chosen, it is clear that this line must be clearly drawn.

Otherwise confusion exists, costs skyrocket, and a poor product can result.

This brings us back to the pyramid used earlier and leads us to attempt to apply these and other

principles to the areas necessary to adequate design and verification. These will be discussed in subsequent sections.

A set of general controlling principles has been proposed. These are listed in the summary in outline form.

III. MANAGEMENT

Management, in conjunction with sound engineering, is the pivotal element of structural

design. It becomes decisive at all levels adding the final edge between adequacy and inadequacy. In

general, aerospace management can be broken out into the areas of project, engineering, and corporate

(overall organization). Further complicating this structure is the relationship between government,

private contractors, and subcontractors (Fig. 16). These complex interactions raise at least three

fundamental questions:

22

(1) What is the role of science and engineering versus the role of project?

(2) What is the role of government with respect to industry in delivering a product?
ENGINEERING

CORPORATE

4,

PROJECT

MANUFACTURING OPERATIONS

I GOVERNMENT

I AGENCY

FIELD

CENTERS

INDUSTRY 1

PRIME

SUB CONTRACTS

bO

Figure 16. Relationships.
H I_/ i __ _, •

•i .

(3) What information/documentation, etc., should be required between government and contractors and prime contractors and their subcontractors?

There is no simple, black and white answer to these questions; nevertheless, they must be dealt with if

adequate design is to occur. All my experience has been from the engineering side, therefore, the discussion of these questions will obviously have that flavor. Also, in dealing with these questions, it is

assumed that a goal, mission, or product has been agreed upon. Essentially, the starting place is preliminary design.

A. Roles of Project, Science, and Engineering

The general principle stated earlier, made mandatory that a clear, definitive statement of the roles

between project, science, and engineering be made. This is obviously a management task that must be

made at the corporate level with full involvement or definition by both project and engineering. The

respective organizations and the project complexity mission, etc., help guide the decision. There are

several options available.

From the engineering viewpoint, the agency must determine, before going into a C/D contract,

the extent of technical support required by the civil service. For very large and long term projects, many

changes may be anticipated before end item delivery and therefore some technical civil service analysis

and reviews are required continuously. The level and extent of documentation necessary could be

exhaustive or just include areas of known high risk as a minimum. If project management is unwilling to

commit a technical civil service level equal to 7 to 10 percent of the contractors' engineering staff, then

contracting for extensive documentation is wasteful - there will not be enough civil service to review it

intelligently. However, all analysis performed by the contract is government entitled and must be

deferred up to three years after the end item is delivered. The format, content, and cost will be negotiated

if and when required. This is a very important consideration and it controls the car loads of paper to be

processed by the government and can cause costs to sky rocket.

To better understand the need for civil service technical support and contracted documentation,

we must understand the type contracts requiring it. When projects are contracted to develop and deliver

an end item, the contractor is responsible for all engineering analysis and it would seem that documentation of analysis is not required for civil service technical reviews. In fact, contractors may even prefer no

civil service technical interference. Since technical changes to the existing contract are frequent

occurrences on large, complex projects, the civil service must make an independent judgement based on

analysis on whether or not to accept and pay for this change. Rather than initiating an independent analysis, a less manpower intensive approach is to review the contractors' documents for assumptions, analytical errors, oversights, and margins. This simple condition unfolds two important and costly efforts: (1)

a comprehensive set of documents and data must be delivered to the agency as developed; and (2) the civil

service analysis and reviews must be current with the contractors' activities; otherwise, decisions for

accepting a change would be horribly delayed contributing to schedule losses and overruns. An equally

important function the engineer serves the project manager is that in possessing the contractor analytical

documentation, the civil service can perform timely assessment of critical and risk areas for accuracy and

choose to perform independent analysis when indicated. Contractor discrepancies may then be brought to

immediate attention for early resolution.

24
r

i"

In NASA, one model that has been used successfully works around the following philosophy.

Science and engineering is a technical recommending body not concerning (over statement) itself with

cost and schedules, providing the engineering data recommendations and risks; whereas, project is the

decision-making body using these recommendations. The project also manages the manufacturing, cost,

schedules, etc. This allows engineering to make a more thorough technical assessment without burden of

other concerns. If this approach is to work, then project has to be keenly attuned to engineering, constantly seeking them out, providing the resources, and changing cost and schedules if necessary to get a good

product. Many examples exist where project would not buy into sound engineering recommendations,

living to regret the decision when future test or operations bore out the engineering position. In deference

to my good friends in project who have made these decisions with probably just programmatic cause,

and, because engineering makes wrong decisions also, only one illustration will be cited.

The Hubble Space Telescope program started out as a program totally controlled by the project.

Project management would be responsible for both engineering and hardware integration. The contractors and government engineering would interface through project. Documentation provided by

industry would be centrally located with very limited informal exchange between contractors and government engineers. As the program developed under this approach, critical technical, cost, and schedule

problems developed. In order to solve the issues, both technical and hardware, it became necessary to

form joint project and engineering government teams at each prime contractor plant. This team approach

was in place for a least one year. After dissolving the formal teams, project and engineering have continued to work very closely with an open and informal exchange between all involved. Also, as a part of

the early corrective actions, panels or technical working groups between government and industry were

organized, enhancing the information exchange and communications. It is clear from this experience that

for very complex technical systems pushing the state-of-the-art, projects must be operated differently

from basic state-of-the-art projects. The approach chosen for project/engineering interfaces must consider many factors such as industry complexity, technical complexity, program complexity, etc. As was

illustrated by space telescope, the involvement of stringent science requirements in conjunction with the

resulting technical/hardware and operations complexity creates a very complex and demanding integration management situation. In general, for any project the integration tasks are viewed only from the

hardware viewpoint such as fit or dimension criteria, etc. In reality, as discussed earlier, the systems

viewpoint must concentrate also in engineering, simulating all interacting disciplines, subsystems, etc.

Project's role in balancing between cost, schedules, and performance must include constantly dealing

with risks. Risks become the criteria through which decisions are reached. The other prime tasks of

project deal with manufacturing and delivery of quality hardware. Obviously, project must be in a constant act of balancing between these various complex goals. The other extreme arises when project takes

the full responsibility using engineering only when they see the need, setting the tasks, priorities, etc.

Regardless of the roles chosen for each, it is clear that project and engineering must be integrated

into a team approach which properly trades between requirements, performance, cost, and schedules

using risks as one of the criteria for decision making.

B. Roles of Government and Industry in Adequate Design

Just as important as the roles definition between project and engineering is the roles between

government and industry. Two extremes are: (1) government provides a contract with performance

requirements clearly stipulated; the contractor designs, engineers, manufactures, and delivers the

25
hardwareverified to meetthe requirements;theonly interactionsareperiodicstatusreviews;delivered

documentationmainly centersaroundoperationsandmaintenance;and(2) thegovernmentdesignsand

engineersandindustrymanufacturesthe hardwareundergovernmentsurveillanceandcontrol;thecontractorprovidesno warrantyexceptengineeringresponsibilityonly from themanufacturingstandpoint;

the governmentprovidesall drawings,specifications,etc. In betweenis a third andprobablythemost

commonNASA approach:(3) the governmentprovidestherequirementsandvariouslevelsof surveillancein all areasthroughreviews,parallelengineeringpenetrationof critical problems,andtesting.The

contractoris prime for design,engineering,drawings,manufacturing,testing,verification,etc. This is

essentiallyateameffort whereindustryprovidesthebulk of themanpower,etc.Onhigh-techprogramsit

allows for efficient changes,understanding,etc.Frominitiation, project/management hasto providethe

resourcesfor theextragovernmentinvolvement.It is morecostlybut canleadandshouldleadto abetter

product.

In summary, how a project is managed, controlled, etc., determinesthe output. Since

managementandcontrolareinherentin all areasof structuraldesign,verification,andoperations,it must

befirst and includenot only peoplebut all resources,criteria, procedures,requirements,reviews,etc.

Figures2, 3, and 17showhow engineeringmanagementcutsacross,or is inherentin, all aspectsof the

process.

Therepresentationdoesnot imply thelackof levelof autonomyin eachstructuredorganization

level nor, asdiscussedearlier,thatit is a highly dictatorialfine line of authoritybut that it mustflow up

anddownandbeintegratedwith theresponsibilityincurredby the individualdoingthework. This does

not rule out theuseof skunkworks, adhocgroups,teams,or anyothermeansthatbring out thecreativity, innovation, etc., of all involved. The implication is merely that managementor guidanceis

involved at all levels.Observinghigh levelmanagementreviewsfor manyyears,oneconclusionstands

out: thepersonwheretherubbermeetstheroadisthesourceof thejudgementof therightnessor wrongnessof the system.All elseis wordsmithingandpapermill traceability.Thelatterbeingemphasizedat

theexpenseof theformer. WhatI amtrying to sayis this: traceabilitycontrol,reviews,etc., arenecessaryand very important,but shouldneverget in theway of engineering.In particular,the discussion,

judgement,innovation,assumptions,etc., thattakeplaceat all levelsaretheingredientsthat determine

designgoodness.Theonly realresourcewehaveto tapandmotivateis thehumanengineeringexhibited

in thediversepersonalitiesin theorganizations.Managementmustrecognizewherethepoweris andput

its emphasison the major resource- People.All elseis tools for makinghim moreefficient.

1. People

Saying this means that the first and foremost task of management and control is leading people,

the prime resource. I learned a very valuable lesson in this regard many years ago while coaching a

basketball team. The game belongs to the players, the coach is only a leader. The team that wins is a team

where all the players and all support personnel have accepted the challenge to win and have taken the

responsibility to keep physically and mentally fit, sharpen their skills, concentrate on team plan, and

work for the good of all. The same is true of engineering a complex system. Individual responsibility and

growth (internalized acceptance of the challenge, the objectives) at every level and job, working for a

common goal is the secret. Managers must recognize that their task is of leadership in these areas and

they are not directors. Again, in the final analysis, the game belongs to the players. Even planning must

be accomplished by all at every level.

26
•tue.i_e!p _oolq [o.Iluo_/luotuo_eUelAI "Ll o_n_t_I. ,:.,1

_IA3U N91S3(]

i SI_IYd J I 3Wlldl3$10

I I

I,,I:IISAS

NOIIY(]IIYA

I

t_1V$ llYJ

SS3NLSI'IgO_I

AHclOSOIlHd

/

A9OIOOOHI]N S3UFIO]::)O_Id I VIU311U:)

I

J [ i

S3SVO VJ.VO 9NIIS31

SNOIIVU3dO

10V33V_I1

1N31.,IFI30(]

7

: . _ _ .:

• :.. ...... " 5:; ' "

: -_ 7..
2. Vision

One of the priority tasks of management and a fundamental part of leading people at any level is

providing or establishing vision through living it. The vision provides meaning and focus to an organization. In the book of Proverbs it says "where there is no vision, the people perish," (Proverbs 29:18).

Surely the same is true for an organization. Visions have two very real effects: (1) they provide the

overall tone or goals of an organization, what it is and what it is becoming, and (2) visions are created in

each individual at whatever level he or she is, providing inspiration, motivation, energy, challenge,

direction, etc., producing development and growth. Belongingness becomes a major attitude. Maybe in a

real sense, a culture is created. Many words can be used to describe the effect of vision: inspiring,

empowering, directing, motivating, etc. To create the organizational, and thus, the individial vision,

requires management to build and invent images, symbols, etc. These, in turn, develop the meaning, the

culture, required to foster in every worker his own visions. It is only effective to the degree that it is

caught and lived by every organizational element and individual. Fundamental in all this are some

subprinciples. One that has common usage is "a catalyst to change is education," remembering that it is

only through change in individuals that the goal is achieved. Somewhere in the distant past, I read or

heard a statement of another important principle related to change that went something like this, "to gain,

you must lose." Something must be given up for growth which requires loss. Losing hurts and the hurts

must be dealt with. Also, to give up something and reach for an unknown is risk taking. Leading people

to vision, whatever the technique, requires that the management understand the educational and loss

principles. The manager is dealing with the lives of individuals including his own and this cannot be dealt

with lightly. Good management is never easy; in fact it too is costly. It is not the intention here to deal

with the hows of implementation, the management books referenced cover this from all aspects.

3. Perspective

The perspective from which one views the problem is different at each level. At the top, one does

not see or at least manage or plan the details of a parts analysis or test. At this level, the view must be

broad (of the whole) while understanding the need for the indepth, concentrating on the overall results

while leaving the details to the lower level. Conversely, the detailed analyst must plan and execute the

details of the part without managing or planning the details of the overall. He does, however, have a big

impact upon the overall through communication, dedication, etc.

4. Approaches

Management styles are very diverse: individualistic or group, autocratic or democratic, etc. There

are many choices, however, no one approach is absolute. All must be adapted to the personality of the

individual. In other words, do not get carried away mimicking someone else. Be yourself while applying

some basic principles and common sense. While coaching earlier in my professional life, the principal of

the school where I taught gave me a valuable lesson. He had been a very successful coach and envisioned

coming into the gym each day helping a new young coach get his feet on the floor. After one week we

had a discussion in which he said, "Coach, I can't help you with the practice, it won't work. You haveto

do it your way. I can only help by giving you observations away from the players. I have to transpose

myself into your thought process to help." What insight into the very basics of management.

28
5. System Emphasis

The hardest management problem I have observed in the aerospace world is: How do you insure

that the systems approach (systems engineering) is understood and accomplished? The tendency is to

become narrow, only focusing on either a part, a special discipline, or test, etc. While this has to be done

for penetration, etc., it must occur in the system context. Several attempts have been made to solve this

problem. All have merit, however, the one general characteristic that appears is: Regardless of the

forum, there must be an air of openness and technical integrity. This must be emphasized to such an

extent that no one is afraid to raise a concern, issue, or opinion. Diverse disciplines discussing and

commenting on each others area is fundamental to a system focus.

A fairly successful approach was instituted by Level II integration for the Space Shuttle program.

Figure 18 is a schematic depicting part of the system. Notice that the final Level II programmatic decision is made by the Program Requirements Change Board (PRCB), however, an elaborate system of

supporting arms is in place to provide information, etc. One arm is the Systems Integration Review

(SIR). The SIR has two major support groups: the Propulsion System Integration Group (PSIG) and

the Ascent Flight Systems Integration Group (AFSIG). Only AFSIG is shown on the chart. The fundamental characteristic of PSIG and AFSIG is that they are engineering recommending groups, not

program decision making bodies. This creates an atmosphere of openess with emphasis on engineering.

Supporting AFSIG and reporting to it are the various technical panels (loads, control, performance, etc.)

who meet to work their problems. All levels of exchange exist between the panels and AFSIG. Recommendations carried from AFSIG to the SIR and PRCB are generally introduced by AFSIG, but the technical side is presented by the panels. The same holds true for PSIG. Members of AFSIG/PSIG are the

various technical discipline leads and program leads from affected NASA centers. Contractors are ad hoc

representatives. The panels, however, draw their membership from both NASA and its contractors and

include all relative disciplines. Problems, concerns, etc., are therefore vertical and horizontal, producing

overall completeness. The freedom to move up and down or to the sides is one key to success. All

criteria, analysis, tests, etc., flow through the groups. Because of this flexibility, a panel or panels can be

asked to penetrate a concern by any group above through AFSIG or can, on their own, penetrate a

problem.

Other approache s have worked equally well for short periods of time (less than 1 year) to work a

particular problem. This is accomplished by creating an information center, interdiscipline, government/

contractor co-located ad hoc group to solve the problem. At least three activities in the Shuttle world

involving major problems were worked in this manner: (1) Shuttle main engine (verification of SSME for

the first Shuttle flight, (2) orbiter tile (reentry heat protection system), and (3) SRM redesign (redesigning SRM to eliminate the cause of the 51-L accident). The idea of ad hoc teams is at least two-fold: (1)

isolate them from other problems, concerns, etc., and (2) have all disciplines and project together to

insure crosstalking, communications, and reduce problem solution time. The skunk works approach is

essentially the same.

Another technique which can be used to accomplish the same system goals is the design review.

However, many come too late except for removal of critical problems. These program reviews are

sequential starting with (1) Preliminary Requirements Review (PRR), (2) Preliminary Design Review

(PDR), (3) Design Requirements Review (DRR), (4) Critical Design Review (CDR), (5) Design Certification Review (DCR), and (6) Flight Readiness Review (FRR). Various programs will use different

29

, i _ 'i  ̧ ̧ :
_y_

!!::_I!_I::I_i"N:TE G R A TI ()'N'_ii::_i_ii_i!! "

TECHNICAL DISCIPLINE PANELS

\

[i:.iPROGRAM REQUIREMENTSiiii |iil

ii_ CHANGE BOARD ii!: :.::i!

I:SCENTP "FO"MA.CEI

c.A,_o, JscI[, _-]

I

I, FLT. CONTROL/STRUCT.

CHAIRED, JSC

INTEGRATIONOROOUP-AFSIG_il]

CO-CHAInED, MSFC/JSC_iU

STRUCTURAL LOADS\DYNAMICS

TECHNICAL PANEL

*J S C *ROCKWELL

*MSFC *MMC

*LaRC *OTHERS, AS REQ'D

AERODYNAMICS

CHAIRED, JSC

SRM PERFORMANCE

CHAIRED, MSFC

Figure 18. Structural loads/dynamics block diagram.
!ii•i_•i•ii_ ̧•

?i

• r

names for this same approach. Special reviews and audits can also be interspersed to further augment the

confidence. A simpler way of looking at this is shown on Figure 19 which treats the areas as configuration traceability improvements, technical interchange meetings, and validation. A partial listing of what

is in each is included.

6. Training and Selection

A major problem throughout management is the training and selection of future managers. This

process is of major importance to the future of any organization, but is just as important to the adequacy

of design and verification. In general, two overriding skills are required for management: (1) social skills

and (2) technical skills. Selections tend to be made on the technical skills level, yet most of a managers

time is spent handling people. Regardless, once a manager is selected he must perform three tasks well if

he is to succeed: (1) conceive, (2) sell, and (3) follow through. The ability to see interrelationships and

their visualization is the secret to communication. Communication is not listed in the three tasks since it

is a skill cutting across everything. Obviously, many other things are important, such as integrity, and

should be included in the criteria for selection. Organizations are clearly guilty of not emphasizing the

manager selection/training enough.

7. Communication

Information flow, communications development, and update of symbols (data patterns, etc.) are

other prime tasks of management. Modern day computers with all the special software for data basing,

graphics, etc., have put an excellent tool in the managers hands to accomplish this task. The symbols

(patterns) and the supporting data bases must be accomplished for all areas such as personnel, resources,

testing, engineering, documentation, etc. For example, when the time comes to certify a design for

operations, two major tasks exist for management: (1) insure that the hardware indeed technically has

met all requirements, and (2) show traceability of how the requirements flow down and have been met.

The first implies revisiting indepth all engineering while the second is essentially a paper trail. Figures 20

through• 24 were developed by Rocketdyne to illustrate at a top level how these two tasks were accomplished for the SSME for the first Shuttle reflight following the Challenger incident. Figure 20, going

clockwise, traces the requirements through the hardware to the as-built/design capability. Figure 21 starts

with the system description moving through all pertinent requirements and controls. Figure 22 is the

documentation trail from requirements verification, while Figure 23 gives the total part history. Figure 24

lists the verification requirements documents by assemblies. This document includes the requirements

and verification plan, including verification complete sign-offs. Many other approaches have been used

and work. This example was not chosen because it is necessarily best, but as a means of illustrating part

of the manufacturing and control required to assure adequate design and verification.

8. Summary

Before leaving this snapshot of the managment role in assuring adequacy of structural design and

verification, it is necessary to return to key areas mentioned.

a. Emphasize People

The first and foremost is that people are the fundamental resource that makes or breaks design. If

that is true, what can managers do? Nothing much new is on the scene, however, basic principles alluded

31
CO TECH MANAGEMENT

CONTROLS

REQUIREMENTS

INTERFACES

ACCEPT. CRITERIA

DEVIATIONS

LEAD ENGRS.

REVIEWS

SCHEDULES

CIL'S

TRACEABILITY

SPECIFICATIONS

DESIGN DWGS.

MATERIALS RPT.

STRESS RPT.

BUILD RECORDS

INSPECTION REC.

TEST RPT.

ENG. CHANGE REC.

ANOMALY RPT.

IMPROVEMENTS

MATERIALS DATA

FRACTURE MECH.

FATIGUE

MODELING

ACCEPT. CRITERIA

TESTING

v

TECH INTERCHANGE

MTGS.

ENVIRONMENT WITH:

FLUIDS

DYNAMICS

STRESS

MATERIALS

MATERIALS WITH:

STRESS

FRACTURE MECH

v

VALIDATION

PERFORMANCE

MARGINS

DURABILITY

Figure 19. Structural validation process.
• . • .

LIFE CAPABILITY

SUBSYSTEM DESCRIPTIO__

______SPECTION RESULTS

/ VERIFICATI-'_ON

MATRIX CEI/ICD TO DVS .J

UCR HISTORY

DCR :}UIREMENTS/_

VERIFICATION MATRIX )

IV REQUIREMENTS_

MR HISTORY IGURATION EVOLUTIO__N

DVS TO NEXT FLIG_._

TEST HISTORY / VERIFICATI__ON

MATRIX CEIl ICD /

C_ Figure 20. Typical subsystem organization.
)

_A CONFIGURATION

UDIT & SUMMARIES

ENGINE 2010/2014

RDOWN RESULTS

-_AZARDS ANALYSIS

FMEA/CIL

_STEM DESCRIPTION_

IN REQUIREMENTS__

REVIEW __'

DCR

!UIREMENTS/-'_--__

VERIFICATION MATRIX NSTS-")

VOL. X TO LEVEy

HOT-FIRE TEST ,_

CERTIFICATION SE._,.._

OMI/OMRSD

LAUNCH COMMIT CRITERI_

AND REDLINES

SPECIAL GREEN-RUN'__

SCREENING

Figure 21. System volume organization.
i SINgWgUIRO3U

3VNU31NI

NOIIVOI_ IU 3A

O

VlCCI t _t

£

qN-m

mQ_ lw_

im_ it •

• tq' m I_*-QI

a_u _-_4m

m mJmm_ m _ I

•me.I_o._d SA(I 'I!13-_1l!pne oldme S "_ o.m_?j

V4 l,_Ir• 3(it

(]311133

NOIIV31-11_I:IA

O"

.... :,:_ '-',-'.'

..t-le.c _ _.¢¢ _m

i , ,.,,, i

I I'i'i i I I#II I

I mm_

• o- • _

""i " I "

NOIJ._OI_-III:F:IAkO£ SAI

t *1-$,l* ptet$ hel_m i-i-t •I

m m _ _'¢ Iiq

• SJLN311_uInO_kl ,KUY(]NO0=I$

NOIJ.Y:)I.-IIU3A I_0(: $A(] -- (]'IO=IlNY_I SYO J.OH

: ..... t lIIiiItw= _1¢i¢ _r u

_ _ I,I _o_ _ _vl, Ill W_

l

.... ,-I-'-':. I

t111031_ 130

I -- 0"IO.-IINYIN SVO J.OH

SZN3_81flO_ (AI 7gAg3) 7VNS_INI

rail)e= Is ¢ .¢

_u._ ws_ _ _'_I "_'

X 7OA 00LL0 SISN

HlVd _3gv_oV_l_3d_O0 *

L_

: C • •

,!

F 5: : : -
"9-S_LS lsod 'I!_J1 l!pne aldtue S "Eg _Jn_!_I

.=In,,

'_0

Z o

l_U.

O0

=?_'_'* "'--_ qlYO

• •........... I ]

1

, ...... .,.,

ll_l_l IIQ*II'NI _l.J_ _LMYLI llel_411 1 II

3 _¢I l_tsv _ ¢I_ x_wd_ I t¢ IS¢

_lq MI_,$_ iLllnl Illl rJeAIII/A,klI_Illl _q_l k li_

tlI_l ll_l tll &fill [_N_411 I [|

!Oli ........... ..............

... , .......... ,,.-: ,,,,: ,-

............ I ......./-I

7OEIJ.NOO dVO :19131 I:I=I.-ISNVI:II IN_DH ? NOIZVOIdlZt:F=lOlNOIIYOIdltJ::l^

oo_.vnu'_- nOH V

AklOISIH HW _ l

"iO_U, NOO dYE) :lSAJ. U:IdSNVU.I. INgH

AtlOJ.SIHuon ? 1

"IOI:IJ.NOO dVO :18111 I:I=I-ISNVI:IJ. INOH

IOEI/NO0 Sz'_ns_lu dVO 381'11 NOIIO]dSNI Id=I-.ISNVI:I.L INOH ?
i / •

,i

• ESSENTIALLY 25 LEVEL IV CEI's CATEGORIZED BY MAJOR COMPONENT AND/OR

SUBSYSTEM

• PROVIDES ALL DESIGN AND VERIFICATION REQUIREMENTS AT COMPONENT

LEVEL

• PROVIDES TRACEABILITY TO THE CEI/ICD

DOCUMENT TITLE DOCUMENT TITLE

DVS-SSME-101

DVS-SSME-102

DVS-SSME-106

DVS-SSME-201

DVS-SSME-201

DVS-SSME-202

DVS-SSME-203

DVS-SSME-204

DVS-SSME-205

DVS-SSME-206

DVS-SSME-303

DVS-SSME-304

DVS-SSME-305

DVS-SSME-401

SPACE SHUTTLE MAIN ENGINE

GIMBAL BEARING ASSEMBLY

POGO SUPPRESSION SYSTEM

CONTROLLER - VOLUME 1

CONTROLLER SOFTWARE - VOLUME 2

ELECTRICAL HARNESS ASSEMBLY

INSTRUMENTATION SYSTEM

FLOWMETERS FOR LH 2 AND LO 2 SERVICE

IGNITION SYSTEM

FASCOS CONTROLLER

THRUST CHAMBER ASSEMBLY

HOT GAS MANIFOLD

FUEL AND OXIDIZER PREBURNER

ASSEMBLIES

LPOTP ASSEMBLY

DVS-SSME-402

DVS-SSME-403

DV,S-SSME-404

DVS-SSME-508

DVS-SSME-510

DVS-SSME-511

DVS-SSME-512

DVS-SSME-513

DVS-SSME-514

DVS-SSME-515

DVS-SSME-516

DVS-SSME-517

LPFTP ASSEMBLY

HPOTP ASSEMBLY

HPFTP ASSEMBLY

CHECK VALVES

PNEUMATIC CONTROL ASSEMBLY

FLEXIBLE AND HARD DUCTS AND LINE

ASSEMBLIES

HYDRAULIC ACTUATION SYSTEM

HEAT EXCHANGER

STATIC SEALS

PROPELLANT VALVES

FUEL AND OXIDIZER BLEED VALVE

ASSEMBLIES

POGO SUPPRESSION SYSTEM VALVE

ASSEMBLIES

.q Figure 24. Design verification specifications (DVS).
• 2 , •

_R_GtNAL PAGE _S

OF POOR QUALrW

to by Drucker [45,46,47], Peters [44,48,49]. etc., need repeating. First, whatever the individual has of

value to the organization is within himself. As Drucker says, "His development is not something done to

him, it is not another or better way of using existing properties. It is growth, and growth is always from

within. The work therefore must encourage the growth of the individual and must direct it" [45]. This

means that all work must challenge the worker, motivate him to want to contribute and grow. Whether

one does this by objectives, managing by walking around or all the other techniques required to get the

worker in the right job and be a part of the organization is up to the individual manager. Recognizing the

principle of the human resource is not optional if an organization is to insure adequate design. This means

that somehow the responsibility has to be put at the bottom of the pyramid used initially and not at the top

as is generally thought. Inverting the pyramid as Peters suggests is very close to the concept being

pursued. This means that individual responsibility is the key to performance. It also means that he is a

part of the organization, that information flows up and down, that he feels a part of success or failure of

the product, and that management is a support to him for accomplishing his tasks. In other words, he

should participate in the planning. This is even more true of the professional workers with which the

report is dealing.

Technical management or professional management is not addressed extensively in literature, yet

that is what aerospace and, in particular, structural adequacy of aerospace systems is all about. How the

bottoms up and tops down is implemented is not absolute. The basic principles are clear and involve (I)

value of individual, (2) traceability from requirements to validation, (3) technical knowledge and understanding, (4) communication, (5) vision/culture acceptance and values.

b. Prioritize Tasks

One task inherent in the others discussed, but mandatory in the aerospace field is the planning/

meshing of tasks and resources to the right areas. Drucker made the observation that 10 percent of the

effort accomplished 90 percent of the results, while 90 percent of the effort is expended to obtain 10

percent of the results [46]. Cost, etc., follows the same general trend. Obviously, for all organizations,

this statement is partly true, only the percentages are debatable. This means that one of the principles of

management and, therefore, a prime task is to understand the tasks, set proper priorities, and allocate

resources to emphasize results. As stated previously, it is very easy for management to fall into the trap

of letting the project/crisis do the prioritization and resources allocation, aggravating the problem (Fig.

25). Management must make judgements on which tasks have a real payoff (results) and put the

resources against these tasks. In most cases, for example, in analytical understanding of structural

characterization, 90 percent of the knowledge can be obtained fairly cheaply while acquiring the additional 10 percent of the answer is very expensive. Many times a simple redesign (for example, changing

fastener bolts to higher strength to eliminate detailed nonlinear analysis) can be implemented quickly,

reducing analysis and testing costs substantially. This reinforces some of the statements made relative to

performance versus sensitivity.

c. System Focus

Management must create the system focus and must set the performance requirements that put

technical excellence and integrity above schedule and cost. Otherwise; project schedules/cost become the

management tool and criteria leading to insufficient products. Space Exploration depends on highly reliable technology and cannot afford these deteriorations. This does not in any way remove the importance

38
PROGRAM

REQUIREMENTS

TASKS ENVISIONED TASKS ENVISIONED

BY BY

ENGINEERING PROJECT

TASKS WITH

REAL PAYOFF

(PRODUCTIVITY)

Figure 25. Conflict of expectations.

of schedules/cost but puts them in the right focus. A complicating factor for aerospace is illustrated on

Figure 26. In such a technology extending field, there must be a balance and interaction between ongoing

projects, future projects/strategic, and technology mentioned above. If too much emphasis is placed on

ongoing projects, the schedules and demands of the project control and manage leaving nothing to future

goals and the development of the technology to insure it. Even the technology required to solve project

development and verification problems is very short sighted and short lived. In other words, without

special attention, any technology resulting from project tasks is incidental. With planning based on technology shortages uncovered in project work, good short-term practical technology applicable to several

projects will result. A better approach is to combine with the project-focused technology, a base technology plan that is more generic and future oriented. This produces and insures a healthy organization

with proper skills, resources, etc., to handle future programs. This latter effort (base technology) can be

accomplished in NASA either as a part of the development center's manning or at the research centers. It

probably is a mistake to put it all at either one or the other center. The development centers drive technology needs and do the practical application, while research centers do best at developing long term

research techniques. Both need to be involved and communicating. Fundamentally, project management

and engineering must be a team that collectively sets proper priorities and goals, allocates resources properly, and integrates analysis, testing, hardware, and operations. As one manages this tri-focus, interaction and proper balance are necessary at most levels. In order to have healthy organizations and insure

present and future structural integrity, both engineering and project must share equally in making this

happen.

This task is complicated by the fact that engineering tends to spend its energy on problem solving

and potential problem analysis with minimal efforts on visions and conceptualization, although any

project, hardware, etc., is the result of the vision process. In other words, the foundation of any

aerospace effort is the conceptualization. The success, however, hinges on the ability of organizations

39
• i•

CURRENT

PROJECTS

FUTURE

PROJECTS/

STRATEGIC

PLANNING

TECHNOLOGY

VISION IS MANAGEMENT

TECaNZQUE

Figure 26. Management dilemma.

and individuals to solve problems and avoid potential problems. This latter effort is not routine, maybe

not as glamorous as the visionary stages, but requires a high degree of innovation and insight challenging

the very best of talents and skills. This effort results in the operating hardware fulfilling the original

visions and dreams. The task that management faces is how to keep all these efforts in focus. The danger

in problem analysis is the negative emphasis that kills the enthusiasm for moving forward. The optimistic

viewpoint is very necessary for success.

The lessons learned in the management/control area for aerospace are outlined in the summary.

IV. ANALYSIS AND TEST

What is the overriding principle in analysis and test? Where must the focus be? What is the

viewpoint that shapes all that is done that drives the process? Is it not developing and having a firm

foundation of basic principles, not detailed analytical formulations but pure and simple understandings

and representations of the concepts and principles? Gordon's two books, "Structures, Why Things Don't

Fall Down" and "The New Science of Materials or Why You Don't Fall Through the Floor," are two

examples of the concepts and viewpoints being discussed. No engineer, regardless of his discipline,

should be without these books. Books of the same nature exist for other areas. They teach you how .to

visualize and think a concept through. All good engineering starts there. The rest are a]ds. Coupled with

this are the simple hand analyses with free body diagrams, flow, etc. Each engineer must accept this

challenge and the corresponding responsibility for growth and reaching the defined objectives. Once

these principles are internalized, good structural design results (see section on management).

4O
The pyramid concept (Fig. 25) fits analysis and test perfectly. System analysis must be performed

first at the top to define generic data flowing from there down. After the initial loop, both bottoms up and

tops down intermingle. This intermingling, however, must always keep the system focus. Figure 27

shows a flow of the basic system task from an analysis and test standpoint showing the waterfall and the

iteration loop. Not all interacting disciplines are shown; however, those illustrated are fundamental to

structural integrity. Structural integrity is inherent within each of the individial disciplines such as

propulsion as well as the overall systems structure. In other words, the structure must withstand all

propulsion induced environments while not reducing the basic performance. Through the process of

system analysis, in conjunction with sensitivity and optimization studies, a balance in design, reliability,

performance, and margins can be achieved which minimizes cost and assures robustness. Figure 27 does

not show how this is accomplished, yet this is a mandatory task in structural integrity. All have seen the

comical charts illustrating how designs would evolve if the focus was on a single discipline such as

propulsion or control. Clearly, design must optimize between structures (including weight), propulsion,

flight mechanics, control, loads, and stress. Structures become fundamental in these trades. How you

shape structure, join structural elements, integrate elements, etc., plays a major role in the resulting

integrity. The various interacting disciplines must provide some general constraint/sensitivity type algo6thms to this process to balance or optimize the system. For example, if one is designing a control

system, the mass, etc., of the control effectors becomes a key item. Trades between structural geometry,

passive damping, etc., versus active control levels produces a design with more integrity. Not shown in

this loop are the other interloops between criteria, philosophy, and documentation. For example, whether

one designs for no failures, fail safe, fail safe-fail operations, etc., has a big influence on the design and

or the analysis and test approaches, schedules, and resources. Vertical and horizontal communications

are imperative. The statistical method used to treat parameter variations and failures has the same impact.

These areas will be discussed later.

A. Analysis

As mentioned previously, an early part of the analysis process is the combined optimization sensitivity studies. These studies start at the total system simulation level and progress down to comparable

studies that are conducted at each level including the piece parts in many cases (Fig. 28). It should be

pointed out that these do not stop with the design selection but continue as more knowledge is acquired

and design changes ensue. Completion occurs only when design is validated and in operation and then

only if no problems occur.

The importance of developing these data trends focuses the process identifying major areas of

concern. Coupled with this data must be a developed set of patterns and symbols that include interacting

flow diagrams, free body diagrams, limiting cases, and hand or simplified analyses. As stated previously, limited conditions or bracketing analyses are a fundamental part of this simplified work. It

should be pointed out again that these occur at all levels, in all program phases, for all disciplines and

must be communicated in all directions. In the final essences of the process, the engineer working the

problem is responsible for the planning and communications. It is not enough just to know certain facts.

1. Illustration of Approach

For illustration purposes only, structural analysis will now be carried up and down through the

tiers of activity. Obviously, all areas such as control will require the same process. Various approaches

41
. .i_ _ :, - .

l REQUIREMENTS

I

I

4,,

STRUCTURAL

SIZING

ITERATION

PROPULSION I

_.1TESTj---

FLIGHT MECHANICS

ENVIRONMENTS

-NATURAL

-INDUCED

L.

I"

;Ic°NTR°' I--

ILo °s I

&

STRESS

I

IJ FRACTURE

MECHANICS

VERIFICATION

Figure 27. Systems analysis flow.
:.i  ̧ ,_ i!

ANALYSIS TEST

SYSTEM

• SIZING •CONTROL

• PERFORMANCE • ENVIRONMENTS •

SUBSYSTEM

• PROPULSION •STRUCTURAL •AVIONICS

ELEMENT

• ENGINE •SRB • TANK •ORBITER • PAYLOAD

COMPONENT

• TURBOPUMP •NOZZLE • VALVE

PART

• BLADE •BEARING •SEAL •IMPELLER •HOUSING •VOLUTE

ENVIRONMENTS -- MATERIALS

m LOADS/STRESS -- TESTING

FATIGUE-FRACTURE MECHANICS

Figure 28. Analysis tier.

' .

exist for determining structural loads and the resulting structural margins. Figure 29 is a very simplified

flow diagram of the approach. These margins are stated as stability, safety factors on ultimate and yield

stresses, fracture limits, fatigue lifetime, reuse criteria, stability limits, and operational criteria. Regardless of the techniques chosen, consistent and compatible approaches must be used starting with the

system analysis, system loads analysis, and continuing through elements to the smallest part analysis.

The approach chosen for structural design and verification must be comprehensive, consistent,

and focused. Therefore, it is necessary that common models, environment data bases, analysis

approaches, and criteria be employed by all vehicle or system elements to insure a compatible system

risks assessment. The assurance that this happens involves proper organization and control

(management).

Up front, the basic problem facing structural analysis and verification should be clearly stated.

The problem: All analyses are simulations which are not complete (limited), which attempt to predict

trends of what will happen. The same is true of test. As discussed in the general section, all these partial

attempts to model or test reality are melded together. How these many pieces are put together determines

the validity of the design.

43
0O

z

LU

W

rc

0

W

cc

DYN

MODELS

THERMAL

MODELS SYSTEMS MODEL _._ ANALYSIS

• STRESS MODELS J__

ENVIRONMENTS

--NATURAL

--INDUCED

LOADS _ ANALYSIS STRESS

LTM

STM

FATIGUE

MARGINS

I FRACTURE

MECHANICS

z

O

I--

O

u_

r_

W

>

GO

z

;0

er

UJ

£I.

0

Figure 29. Structural analysis flow.
: . J •

• :" j •

The basic concept and philosophy of this approach are shown in Figure 30. The process starts

with each element and its subelements providing the structural models and all pertinent parametric data

(example: SRB thrust, thrust rise rate, pressure) to the integration organization for the system loads

analysis. These models must be compatible with all other element models and with the final element

stress analysis models. The system integration approach, parameter variations, statistical criteria, and

verification required are determined in various ways. Using these criteria, loads analysis for each design

condition (parameter combinations with natural environments) are to be conducted and loads developed.

Figure 30 shows some of the natural and induced environments used to determine the loads. These

analyses are made in a statistical manner such that the resulting responses (loads, etc.) are at a 99.7 percent probability or some other predetermined level of occurrence when varying all system parameters and

environmental values within the expected range. Included are all vehicle parameters and natural environments, such as wind speed, wind shears, and wind gusts.

2. Integrated Analysis

The approach used to generate loads will now be elaborated on for the Space Shuttle liftoff regime

in order that the external loads analysis process is better understood. The first step (Fig. 30) utilizes testverified dynamic models of each element (SRB, ET, SSME, orbiter, payload, MLP). These models are

coupled together using proper interface models in conjunction with either substructuring or modal

coupling techniques. This step produces an overall vehicle dynamic model. Step 2 takes this complicated

dynamic model and descriptions of all known forces and formulates a set of describing differential

equations which, when integrated time-wise, will describe the characteristics of the structure. Integration

of the resulting equations, using either digital or hybrid computers, produces the responses and external

loads (step 3). Since the generalized forces are not precisely known (i.e., only known to a test-verified

statistical level) a discrete load case will not describe the design load. In phase IV, these characteristics

are used as forcing functions to obtain more detailed knowledge of each element. Phase V uses the output

from phase IV to accomplish even greater detail information of parts, critical areas, etc. This output

establishes all margins, etc., used for design or verification.

This chart does not deal with the procedures, codes, etc., required to accomplish these steps.

These choices depend on many factors, such as complexity, skills, computational equipment, etc. However, with modern day computers, integrated output should be maximized as shown on Figure 31.

• -:)

J • i

Notice that automated outputs such as loads and stress matrices feed directly to the stress analysis

as does loads spectra to the fatigue. This reduces chances for errors and increases efficiency. All the

interacting flows and iterative loops are shown. Loads and stress analysis, although considered by many

to be separate disciplines, must be really worked together or at least very closely with constant communication. Obviously, thermal and control fall into the same category. The chart clearly shows the interaction between different steps and between loads and stress. The Shuttle SRB aft skirt failure illustrates

the requirement for communications and interaction. Early Shuttle loads analyses conducted using

simplified models of the launch pad and the SRB skirt produced a set of loads that, overall, was thought

to be accurate for the prelaunch SSME thrust buildup phase of launch. It was understood that major skirt

load would arise from vehicle weight combined with the SSME thrust force. At full thrust, the four holddown posts,_way_fi'om_the 'altimeter(Fig. 8) are loaded in compression not only from weight but also from

the vehicle bending dale ti) <the SSME thrust. What was not understood was the sensitivity of the local

weld stress •near the holddown post to the pad stiffness. Stated differently, the radial load component

(Fig. 32) shows how the compressive load creates the large tension stress in the weld. The skirt angle

• :?; , i;

45
"s!sXI_U_l_n1_n33,S"0£o_n_'!_[

W]ISAS JO AIIX31dW03 NO

SON3d3Q 03HINO3H SISAIBN8

JO H3BWNN "NmOHS

SISAIUNH IN3_3138AS Oral .

O

l 8 # d3.L$

I 1H31/lU3 1H3Ol

L # d3.LS

• ,,I

f T

/s_lwuN^a

9 # dlJ.S

SSIHIS _] S311_HNAO I

H:IHIJ

"1U3 IJ.IH3 "lU 3 0"1

L # d3.LS

Q# d3J.$

NO IIUNI I,_li3.L30

$$3UZ$ GNU 31k_BNAO

Y3slY "11_30"1 'lNiJ J.N]_3"I38flS

fl ]SUHd

SS3H/S

S311_iHNA0

IN31_i313

# d3LS

N011UNI _ili3J3O

SN I 5 _lStl,,,I SS3_dJ.S i

0NIl 311,,tUNA n .LN3_I]'I] :

_# d3ZS !

|

iii 3SUHd :

S3OSOJ 33UJU31NI "=']

S33_Q_ UH3HS|

(;'Z'6'X)S fl

S_N3_0_ 8NION38 I

(_'z'6'x)_ .--1

AH0133PUUl"m_

33NU_U0JM3d"_

10ULN03m" 1

S31_BNA00M]V'm_

N01$10d0Ud"_

U]3flflNI )

t : :::::::::::::::::::::::;:!:!_:i:i:!:i:i:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

i_ ,0 £ # Sd3.LS i _ # d31$ I # d3J.S

/

"IUHflIHN J

_3fl3_ A11_lSBS0_d %L'66

ZB SOB0_ NSIS3O "SISA_BNB

SOB0_ ]HNU3_H3 _YOl_Sl_Y£S "Z

] "_3_SAS 40 5N0118f103

8N|RIX_$_O 4fl N_llfllfl£

QNB N01LUIflHaOJ "I

III 3SBHJ

P_£# d3.L$

3 _lglLYAJ.ISN3Q U3dl,¢31 t

SONIm

3SU8 U.I.klfl "IHJ.N31_IN01JI(IN3

GNU "1300F¢ I,'¢]LSAS .t0 IN]l, Cd0"13_30

Z# d3.LS

il :iSHHd

ZN31_ld0"13113Q

1]QOF¢ 1N31,¢3'1]

lit d3_S

1 3SUHJ

/,.,

,,,,/

O
313A3

31111UU311

I_1111_11NIH 4 .......

i

IIB.L33dS

SOU01

X31dHO3

SISA'IHNH 3NI.'130

SOY01

SISA'IUNU

SS3HJ.S

_f

I NOIIUUf131N 13O0H I

"lU3

$35B3

IJ.I U'I ,I N 3U I

UO:i

] ,s.

u 0

IIU.L30 N0 I,LI N I..i3a

N0 IlUFI1Ufl3 A.Ll'llEXdU3

SINIUHISN03

"lUN011UH3d0

$ N0 ilUA'lYt13 "S,O3U ".Ld$NI A,L3.4 U$

/SN0 I.L3103Ud ,0 NO J.LIN 1:130

/3Wli]Jl'l /nU'hJ 'lIJOI.LDd3 J0 $NlgHUl_i

S1300W

U3Hl0 ]

s..........L__ ............. 1"_'""'°°"
/

k.'. !

R

A

m_J

!

r

RADIAL LOAD

COMBINED WEIGHT

AND SSME THRUST LOAD

o

RADIAL/

LOAD /

V ERTICAL_'_

LOAD _/

COMBINED LOAD

RESOLUTION

WELD AND OUTWARDLY

DEFLECTED SKIRT

C

L

SKIRT

Figure 32. Aft skirt post with axial, radial, and tangential load.
• !:!i

5

%

•,7_• i:i•

splits this compressive load into two components, one axial and the other radial. The radial component,

depending on the pad stiffness, moves the posts Outward, bending the skirt skin locally creating high

tension stress. Figure 33 shows the sensitivity of the local weld stress to radial load changes. Two skirts

have failed in structural test due to this effect. To date no credible failure mode has been identified.

Coupon testing shows that large strains (2.5% or greater) are required in the weld area and, in the heat

affected zone, the highest stress measured in the structural test at failure was 0.8% strain. Additionally,

the loads generated for the design case were based on varying parameters to maximize the average load in

the skirt post, not the local load where the failure occurred. As a result, special materials testing has been

required, a detailed test verified MLP and local skirt models were developed, and additional loads cases

developed. Several messages are apparent: (1) understand the sensitivity; (2) develop models, analyses,

etc., to cover that sensitivity; and (3) provide for healthy interdiscipline communication. The

requirement for communication and understanding between disciplines is clearly illustrated.

This is a good place to deviate slightly and discuss the requirements of high performance systems

for an adequate but nonconservative statistical statement of loads and structural margins. The general

approach has been to calculate loads and determine a 3o. equivalent static peak load. This equivalent static

3o- peak load is applied to the stress model to get static stress. Safety factors are then applied to the static

stress. If one wants to take out some of the conservatism inherent in this approach, one must apply statistical techniques. The best way to achieve this is by using the approach shown on Figure 29 where an

integrated analysis is performed where the output is stress, etc. Several codes are being and have been

developed that will accomplish this with stress as the output. Many statistical or probabilistic approaches

are available that produce time consistent stresses in any form desired. This includes the spectra for

fatigue. Obviously, if other states (strain, deflection) are desired, these can be calculated in the same

manner. The message is clear. If analysis is to stay up with the performance requirements, then an

integrated approach is required. This approach leads to a more definitive probabilistic statement, usually

less conservative than the classical methods of the past. The problem that many feel in a probabilistic

approach is the loss of the commonly used safety factors and margins of safety replaced by the probabilistic statement. Retraining/education is required to bridge this gap.

3. Subsystem Analysis

The next level of analysis and test develops the same kind of detailed flow for the resulting disciplines and margins such as fracture mechanics, fatigue, vibroacoustics, structural, static, and dynamic

testing. Figure 34 shows this next level for one fracture mechanics plan for part of the SRM. Notice that

it starts with the stresses from the stress analysis and proceeds to use special fracture mechanics analysis,

materials data base development, analog testing, NDE, proof testing, etc., to arrive at a verified system

for flight. Along with this flow and testing, there is a need for parametric data which shows crack initiation, crack growth, crack instability, etc., so that one can deal with damage to learn design approaches.

Figure 35 shows the same detailed flow for fatigue life assurance including test and verification. This is

essentially the same flow depicted in Reference 52.

References 7 through 43 are more detailed reports dealing with the specifics of the approach laid

out. Implementation of these approaches requires the development of detailed procedures, methods,

codes, etc., to carry out the task. It is very important that these be developed and updated to assure good

analysis.

49
•sllns_J ppotu qsmu p;)ul.JaJ 1.tt.:>[s 1JV "_:_: aJn_.[H

1Vl(]V_ _Og t o 9VlOV;9 %00 L 4-

SIX¥ 8NS I+ I,NON_-I $33N030

-lVlOV_l _dOg

09 t

I

-OL-

-0

OL

OZ

0£

0t'

- Og

- 09

- Ok

- 08

- 06

OOL

[]

0

(Z

-t

FI

m

nl

N

[11

0

ilJ

I/I

-4

:1]

m

UI

t/I

N

ffl

v

qg;_

: : ::.: , -
STRESS

ANALYSIS

ANALYTICAL

PROCEDURES 1

PREDICTIONS

MATERIAL PROP.

AND

TESTS

ANALOG

TESTING

Figure 34.

COMPONENT

TESTING

'r

VERIFICATION

NDE/

PROOF TEST

FLIGHT

HARDWARE

SRM fracture mechanics program.

FLIGHT

SAFETY
#

ENVIRONMENT DEFINITION I

LABORATORY

MATERIALS

TESTS

I MATERIAL I

DATA I

CONTRACT

SPECIFICATION

REQUIREMENTS

DESIGN CRITERIA F4 DESIGN CONCEPT F

_..,ss,oN ANA. s,s I--I

I BASIC SPECTRA LOAD I I

I INTERNAL LOAD

SPECTRA

ANALYSIS H

STRESS GROSSSPECTRA AREA I

FATIGUE ANALYSISLIFE I_

DESIGN STRESS -i- ....

/

VS. LIFE

VS. WEIGHT J

PERFORMANCE

CHARACTERISTICS

I _--'--INAL

CONFIGURATION STRUCTURAL _F_

I

LABORATORY

DEVELOPMENT

TESTS

I

I

I

I

I

I

ASSUMEDQuALITyFATIGUEl

.J

__ LOADS SERVICESPECTRA TEST l

LIFE REDUCTION

FACTORS

FAIL-SAFE

PARTS

FATIGU E

LIFE PARTS

I

•_1QUALIFICATION TEST_ "l PROGRAM

CERTIFICATION

LIFE ASSURANCE

WARRANTY

FINAL CONFIGURATION STRUCTURAL 14_J

Figure 35. Fatigue life assurance-information flow diagram.

52
Procedures,codes,etc.. arenotthetotal story.Two key ingredientsmakethesystemwork: (1)

the accuracyof the input datasuchasmaterialspropertiesand environments,and (2) the modeling

assumptionsandmodeldevelopment.Theoutputisnobetterthantheinput.Thevalidationprocessisthe

final analysistask.Figure 36 illustratesthe flow andthe variouspartsstartingwith requirementsand

proceedingto the as-built hardware.The model validation is a continuousprocessfrom early in a

programto theend.It involvesthe sensitivityanalysisbutmoreimportantlythetestingto bediscussed.

In general,analysisis only asgoodasthevalidationtestingwhetherit is to setparametricdataor final

model verification.

4. Aids

Many aids. in terms of handbooks, data bases, and general principles, are needed to guide analysis. aid understanding, and interpret data. References 17 through 43 have many examples of this type of

information. Figure 37 shows the relationships of applied load history, strength, and damage size with

time. Obviously, this curve exists for each material and is therefore unique for each. For a detailed discussion of the curve see Reference 52. The same is true for Figure 38, which represents typical residual

static strength data.

SCOPE

SYSTEM

SUBSYSTEM

COMPONENT

TECHNOLOGY

FLUIDS

DYNAMICS

STRESS

MATERIALS

FRACTURE MECH

FATIGUE

TESTING

REQUIREMENTS

PREDICTIONS

CRITICAL AREAS

PROCEDURE

INSTRUMENTATION

CONTROLS

DATA REDUC.

POST TEST

ANALYSIS

CORRELATION

MODEL TUNING

STATISTICS

UPGRADE PREDIC

SENSITIVITIES

Figure 36.

CYCLE

BASELINE

DESIGN CHANGE

NEW REQ'TS

NEW METHODS

ANOMALY

DESIGN REQ'TS

PERFORMANCE

MARGINS

DURATION

1

DESIGN ANALY.

ASSUMPTIONS

LINEAR/NON

CODE

ELEMENTS

TOLERANCES

SENSITIVITIES

INDEPEND. ANAL

ENVIRONMENTS

DATA BASE

VARIATION

ANALYSIS

VERIFICATION

STRUCTURAL

VALIDATION

PERFORMANCE

MARGINS

DURATION

NOMINAL

AS-BUILT

AS-BUILT

DATA BASE

WELD OFF-SET

MAT'L REDUC.

KT'S

MISALIGN'T

JOINT FLEX.

Structural validation process technical.

53
• 7/c :

i  ̧ ,

L

DEFORMATION

CRITERIA

STRENGTH,

LOAD, FORCE

OR

DAMAGE SIZE

(in.)

/ULTIMATE STRENGTH CRITICAL DAMAGE ULTIMATE LOAD

ALLOWABLE STRENGTH SIZE EXPECTANCY, EXTREMELY

Z3 REMOTE £-_LT; _i__-g_S,;_-LO_ ......... 7-,-_2_#_ ......;P

DESIGNLOAD _ W.'?7_X_ /"

..... ,.M,TO_S,_,,o.o _ i -s'z_.."

>.............................. _L_O_A_D/.... 'X,,_...,. MAXIMUM LOAD

_,.-"'7 EXPECTED ONCE

CUMULATIVE LOAD_ /._z_._ _ i IN LIFETI_A_

HISTORY _. .... _/'- I ....

.----'" • g) I

..................... :'- 2_.IS/'_- ACCELERATED CRACK GROWTH

MINIMUM INSPECTABLE.._ , _ i

DAMAGE SIZE _ 1.4 ........... i

- _ ' "FDAMAGE SIZE i

'_-"--INTE RVAL OF FATIGU E _INTE RVAL FO R ---_ TIME --

CRACK INITIATION TIME INSPECTION-REPAIR '

Figure 37. Relationships of applied load history, strength, and damage size with time.

J

/ -

f

¢

03

(,9

UJ

rr

I,--

09

W

rr"

,<

o9

O9

O

rr

(.9

8O

7O

6O

5O

4O

3O

2O

10

0

I I I I I I I I 1

f_

\ _ INITIAL STABLE CRACK ! 1

\ (" _ _ PROPAGATION • "P

I _.......... t..... G_9_.wr... ..........

l NONPROPAGATING REGION .....

I I I I I I I I I I

2 4 6 8 10 12 14 16 18 20

CRACK LENGTH, X-In.

Figure 38. Typical residual static strength data.

I

54
i!iJ_

5. Technology

Analysis must also deal continuously with the technological issues inherent in the tasks. These

must be kept at the forefront, constantly challenging the approach being used. For example, some basic

technology questions that have been raised in the structural disciplines are:

(a) Validity of Goodman's. Necessary constraints.

(b) Failure criteria for ductile material.

(c) Methods for handling fasteners, bolts, threads.

(d) 3D stress field effect on fatigue, fracture mechanics, etc.

(e) Combination of low and high cycle fatigue.

(f) Accumulated linear damage factor rules.

(g) Nonlinear fracture mechanics.

(h) Residual stress.

(i) High cycle fatigue fracture mechanics.

(j) Single cycle versus multiple cycle proof testing.

Similar lists are available for all major disciplines including, but not limited to, systems, thermal,

control, fluid flow, propulsion, flight mechanics, etc.

Key lessons learned are included in the summary.

B. Testing

Testing uses most of these same principles discussed under the analysis section, however, some

additional principles are involved.

1. General

Primarily the principles of testing, whether to acquire understanding or for final verification, are

fundamentally the same as those just listed. Good testing always starts with analysis (pretest analysis) of

the test article and test setup (facilities). This analysis, in conjunction with all the analysis previously

discussed, is used to define test conditions, plans, instrumentation and range, constraints, etc. It is very

important that all test boundary conditions (facilities, test support equipment) be totally understood and

defined. A classical example of understanding boundary conditions occurred on the Saturn I vehicle as a

result of the dynamic test conducted to verify modal analysis used for control system design and loads

55
c

determination. Due to the configuration complexity (cluster tanks) and modal analysis technology (or

lack thereof) analysis to test correlation was not as good as desired. Matching frequencies led to a mismatch of modes and vice versa. It was hypothesized that the test suspension system was coupling with the

structure altering the modes. One engineer thought that he could remove this effect by special data

reduction/evaluation techniques. Due to data accuracy problems, this process created several psuedo

modes with high gains which coupled with the control system creating an instability. The launch of the

first Saturn I vehicle was delayed a few weeks while the problem was resolved. Much publicity occurred,

even a big article in Fortune Magazine. The problem was resolved by showing that the experimental

modes were accurate and the control was stable. Many successful launches without control system

change verified the decision. Dynamic tests since this time have given proper emphasis to boundary conditions/suspension systems. Many good tests are invalidated because of inappropriate boundary conditions [21 ] or the lack of understanding thereof. The pretest analysis is very useful in controlling the test,

making decisions, and understanding data.

2. Test Conduction/Data

This leads to the next step which is test conduction and data acquisition. As much diagnostic data

and automation should be emphasized as possible to enhance test conduction. Analyzing and evaluating the data are very important to test success. Establishing various ways of cross plotting, parameterizing, etc., should be the norm. Many times digitizing the data at high sample rates gives much flexibility

to this process. Part of this process of evaluation is correlating the results to the pretest predictions. Many

times this can be done in real or near real time by storing the predictions in the computer used to analyze

the data. The final step is to update the model/simulation based on the test data. This cannot be

emphasized enough since this model will be used for variations in projected operations, MR (manufacturing requirements or materials requirements deviation) resolution, and operational constraints, etc. All the

previous points in terms of documentation, data basing, communication, etc., apply to testing. The

individual again is the key resource and makes or breaks the test. Much more could be said about testing.

There are many types of test: (1) dynamic, (2) static, (3) fatigue, (4) fracture mechanics, (5) proof, (6)

burst, (7) vibroacoustic (development, qualification, and acceptance), (8) thermal, (9) flow, (10) propulsion system hot firing, (11) development flights, etc., all of which have their specialties and nuances.

These are not a part of this paper. Many references exist [17 through 42]. Regardless of the area, however, one overriding viewpoint is important. One must start with the smallest entity possible and understand it fully, then add the next level and understand it. This buildup continues until the total system is

tested together. This last step may not be accomplished on the ground, but becomes a part of the initial

operational or developmental phase with proper safe guards. This sounds like an advocacy of bottoms up

only. This is not true. Various levels of tests from the tops down should be intermingled in parallel in

order to better understand the parts and the system. Not all testing should be full scale. Scale model testing conducted properly is very valuable and can be a fundamental or predominant part of the test

program. Even flow testing, properly scaled and analyzed, has been very successful as demonstrated in

the field of aeroelasticity. It is mandatory, however, to understand the scaling assumptions and therefore

the limitation to properly interpret the data.

3. Developmental

Development testing to understand the basic phenomenon, define parameters and sensitivity, and

to validate analysis is mandatory for successful design and validation although it is a principle bypassed

many times to save money. This type of testing covers both the environments and the structure as well as

56
materials characterization. For example, flow testing of a turbine with various diversion angles, contours,

etc.. can help select the better design and also provide validation of the analytical prediction. Structural

testing can show potential problem areas as well as analysis validation. Destructive testing to understand

failure modes and limits is a good approach, if possible.

4. Static

Static structural testing, and, in particular, testing of large hardware, is difficult to accomplish. It

is mandatory to apply and balance loads properly. This involves not only the load lines (application

method), but the hardware alignment, instrumentation, and backup structure characterization, all of

which are fundamental to getting good data. Two principles are very important here: (1) to look at all the

details but always with the overall system in view, and (2) to understand the test as much as possible from

the analysis viewpoint and determine what can be expected. Testing for testing's sake buys very little. A

third principle that generally comes into play is to have all potential diagnostic tools in place so that as

surprises occur they can be understood and the test can proceed.

5. Summary

Fundamentally, one must fully understand what problem one is trying to solve, intepret, etc., in

order to properly test for it. Running a test with careless analysis data leads to the wrong answer and

future failure. Proper testing requires the team effort between all interacting disciplines with complete,

open lines of communication. This goes from knowing what hardware configuration is being tested to

understanding the test setup and everything in between.

The basic principle in analysis and test, as mentioned in the general section, is to accomplish both

the simplified and detailed analysis. The goal is to design a test program to verify the analysis and correlate and adjust the analysis based on the validation. Understanding this approach principle excludes

unforeseen, real world deviations. The proof of the pudding comes from flight testing. One must always

plan for special instrumentation and flight conditions initially to finalize characterization and update

models. This is a must that has its wisdom demonstrated on many space programs [21].

The principles of testing are outlined in the summary.

Some examples of open or critical structural technologies in testing are:

(a) Dynamic impedance testing.

(b) Fracture mechanics plastic testing.

(c) Combined low/high cycle fatigue.

(d) Loads combination.

(e) High frequency loads prediction.

57
/ :_ i_,

i

)

C. Analysis/Test Summary

In dealing with analysis and test, several principles and lessons learned have been discussed. Out

of all of these has come the overriding principle dealing with integration or systems analysis. If one

attempts to write down all the potential interacting disciplines, the list gets quite lengthy. In addition, for

a given space structure, space vehicle, etc., only a few will apply; however, from the list four nearly

always appear. For example, some of the potential interactions are:

• Thermal-structural

• Structural-control

• Aeroelasticity

• Trajectory-control-structural

• Corrosive-structural

• Propulsion-structural

• Propulsion-control.

The four that stand as pillars requiring special attention are (1) loads, (2) stress, (3) material, and

(4) testing (Fig. 39). One might argue that environments should be included, however, the natural and

induced environment world is very broad and is included in loads and stress. Also, the same principles

apply. Looking at these four, why do they separate out as pillars and what overriding integrating

principle is involved? They separate out because the end product of structural integrity is a statement

about the structure's strength, stability, and durability (strength, fatigue, and fracture). Everything

hinges on this statement - operations, maintainability, life management, etc., including the proof of an

adequate design. A special relationship between these four pillars is required if structural integrity is to be

assured. Support from all other disciplines is obvious but these are the foundation. What there is that is so

fundamentally important with these four is that they cannot be treated as individual black boxes with data

requirements flowing from one to the other, but must be treated as an integrated whole. They must be

worked together with each understanding the technical discipline of the other. Obviously, the same

statement would apply if a structural control interaction problem existed and would require essentially a

new or combined discipline to work. The principle is clear then: for structural integrity, a stress engineer

must know loads, materials, and testing; a loads engineer must know stress, materials, and testing; a

materials engineer must know loads, stress, and testing; while the test engineer must know loads, stress,

and materials. This knowledge must be at a fundamental and working level, not just some generalities.

Application of these interacting disciplines must be a probabilistic or statistical way requiring a working

knowledge of statistical approaches.

The second principle involved here is that they must work together as a team with constant

communication in order to assure good results. Testing not accomplished in terms of the real dynamics

issue gives false security. Materials data bases not compatible with the physical problem or the simulation under development lead to wrong designs, false security, costly redesigns, or failure. The same can

58
STRUCTURAL INTEGRITY

LOADS STRESS

• FATIGUE

• F.M.

• STRENGTH

• STABILITY

VlATERIAL5

• STRE.NGTH

• FATIGUE

• FRACTURE

:TESTING

• DEVELOPMENq

• VALIDATION

Figure 39. The four pillars of structural integrity.

be said for the other areas. What is the solution to the problem? As always, no one answer exists; however, two clear strategies stand out: (1) cross train each engineer for a minimum of 6 months in the other

disciplines, and (2) work the problems as ad hoc or informal teams. The argument against each is

resources, however, the evidence points toward it being more costly not to approach them in some

manner like this. As a minimum, basic understanding in all disciplines and open communications lines

are required. This means that management and organizations must recognize this requirement and plan

for meeting it.

!:! "_

V. DOCUMENTATION AND DATA BASING

i .L • •

/

Documentation and data basing are fundamental and of prime importafice to adequate design. The

importance can be shown in at least two ways: (1) records or reference of requirements, specifications,

assumptions, analysis, test, hardware, manufacturing, etc.; and (2) increased awareness and organization

focus through the documentation effort. There are many ways to categorize documentation for

management and control and design validation. Several levels exist, some under very strict formal control by program requirements boards, others with only engineering line organizational sign off or

approval. Top level requirements documents requiring very strict legalistic control are the normal

requirements documents, CE! specifications and design drawings, COQs, OMRSDs, etc. At a control

level that is rigid, but not at the same level, are the class of documents which include Design Verification

System (plans) (DVSs) specifications, procedures, criteria, etc. A different group of documentation is

the presentation and results of all major design reviews (PDR, CDR, DCR, FRR, etc.) including a very

formal tracking system for all action items and Review Item Discrepancies (RIDs). Some of this

documentation is formal handouts of presentations. Very important to the whole process is the next level

59
of documentationwhich containsall analysisassumptionsandresults,testplansandresults,presentations, and databases.Data basesgo from naturalenvironments,materialsproperties,environmental

data,analysis,to testresults.As discussedpreviously,thesedocumentsmusttakevariousformsfrom the

very detailedequationsandresultsto sometop level summarystatementandall the levelsin between.

The choiceof how to breakout andcontrolthesevariouslevelsis very importantto communicationand

traceability. It is also very importantthat key resultsbe publishedin openliterature so that lessons

learned,etc., get disseminatedthroughoutthe aerospacecommunity.

A. Symbols

The discussion, thus far, tends to be centering on what is done or controlled at each level,

although in some cases this is the same as a bottoms up or tops down type thinking. What is clearly

missing is what symbols, for example, at the lowest level, to:,send up to the higher levels of documentation

or management or conversely, to send down. For example, it is obvious that the detailed equation or

results of a stress analysis are not required; however, the fact that the work was accomplished and some

summary or encompassing symbol should be presented or developed. In this case, maybe it is the

minimum margin of safety in a structure on yield and ultimate. Even the general stress level throughout

the structure may not be required, but colored contour plots of stress level patterns in conjunction with

the minimums may convey more than enough (Figs. 40 and 41). Lateraly, however, or in the case of

audits, detailed communications of every facet of the analysis are required. Also, if design changes or

performance enhancement, etc., occur, the detailed documentation is a must to eliminate complete

reanalysis and test. Matrix-type summaries that list all analysis, test, etc., performed, the responsible

individual, the documentation number, date, and applicable part or structure are very important for traceability, management, and visibility (Fig. 22). Typically, the documentation for structural durability for a

given part would or should flow down as shown on Figure 40, as an example. Obviously, the tree would

vary substantially in terms of number of analyses, test, etc., required to complete the picture; however,

the basic flow down stays the same. Hirsch summarized the need for symbols in Reference 56: "Only by

accumulating shared symbols and the shared information that symbols represent, can we learn to communicate effectively with one another in our national community." With this brief documentation overview,

the following discussion will deal with basic principles and lessons learned from the reviews.

1. Interdiscipline Communication

Although a wealth of data exists in the materials world, material data bases, or the lack thereof,

and communications between disciplines concerning these materials properties has been a recurring

problem. Evaluating these discrepancies has shown that it is not necessarily a poor documentation

problem but a multi-faceted problem cutting across many areas. In fact, it probably should be classed as

an integration problem. It cannot be stressed enough that adequate communication and understanding exist

across the disciplines. In dealing with the high performance minimum margins system, a very specific

category of data is required to solve or analyze each problem area. This means that all disciplines supplying input data to structural analysis, for example, must understand in detail in terms of the problem being

analyzed and the various data requirements. Otherwise erroneous answers result. Another part of this

problem is the currency of the data base in use. Many instances exist where the proper data was available

but not in the operational data bases. This is a general problem, not just for materials. Materials is being

selected for an example because of its criticality in structural margins assessments. This again points

back to the system focus mentioned earlier.

60
• i  ̧

! •

AHSYS 4.2

RUG 14 1987

11:84:4S

PLOT NO. 1

POST1 STRESS

STEP=2

ITER=IS

SSEY

ZV=I

DIST=. 164

XF=.117

YF=. $66

ZF=3.98

MX=. 00624

MR =-. 0031S

-. 00246

-.80146

-.888456

.808544

.001S4

.80254

° _--!84F4

,00SS4

.006S4

SECOND STAGE FIRTREE FACE 38 (T.E. SURFACE) I

O0

"l'l ::8

"e_

O_

*PRESSURE SIDE

(FPL

SUCTIOM SIDE

SS PRESSURE+SPEED+THERMAL)

Figure 40. FPL SS pressure, speed, thermal.
b_ I

DETAILED POST

1

REDESIGN NONLIHEAR STA-2B LOADS

AHSYS 4.3

FEB 15 1988

12:05:58

PLOT HO. 2

POSTI STRESS

STEP=20

ITER=I00

EPG (AVG?

XV=-I

YV=.5

ZV=-I

DIST=IO.3

XF=-58.8

YF=86.4

ZF=83.9

HIDDEH

MX=.00944

MH=O

O0

m

8-z

,0"o

4, ̧ ,,

I"'1"[1

000871 .........

00197

00307

00417

00527

00637

00747

00857

00944

Figure 41. Detailed post redesign nonlinear STA-2B loads.
i,

i

2. Problems

Other problems continue to exist in all documentation. Analysis or test reports, parts histories,

and other documentation often cannot be found and if they are, then assumptions, summaries, etc., are

not described. Currency is a major problem. Wrong environments or inadequate models are prevalent.

For example, the SSME structural audit, although showing the engine to be adequately analyzed and

verified, found parts that had limited life without Discrepancy Approval Requests (DARs). The cause

varied between the above to plain oversight. Computer data bases can help in eliminating these problems.

However, as discussed elsewhere, the final responsibility rests with the engineer, technician, etc., doing

the job. He must not just do the work but communicate it.

Examples of documentation have not been shown due to the volume required, however, most are

familiar with it. The major problem appears to be one of schedule and priorities. In a technology pushing

the boundaries, crises continue to occur. This moves one from completing documentation to working the

next problem. A major weakness in documentation is in the high level reports and open literature where

so little of the key problems solved have been published in any form. This must be eliminated for at least

two reasons: (1) the technology community needs the information we have developed, in fact, we owe it

to them since our work is funded by tax dollars; and (2) the professional is due the recognition for his

work by those other than his own management.

i 5  ̧ _:

B. Data Bases

Modern computer capabilities with networking extending beyond the local organization to

interacting organizations across the country open up fascinating and mandatory opportunities for

automated data basing. Software programs and computers are very user friendly allowing managers, etc.,

to interrogate the system. Controls have to be established in terms of who and how updating is accomplished, who can interrogate, and the formal and legal use of extracted data. In addition, many options

must be built into the programs to interrogate properly and format outputs to fit the users' needs. These

requirements must be established based on needs of all potential users. Flexibility must be built into the

data bases so that they can be expanded, altered, etc. Many examples exist within NASA and its contractors. One very effective one is the SSME dynamic data base [54].

1. SSME Dynamic Data Base

The planned missions for the Space Shuttle dictated a unique and technology-extending rocket

engine. The high Isp (impulse performance) requirements in conjunction with a 55-mission lifetime, plus

volume and weight constraints, produced unique and demanding structural design, manufacturing, and

verification requirements. In order to achieve the higbaperformance (Isp), a two-stage pump system is

used in conjunction with preburners which burn the fuel rich gas, furnishing the power for the pumps.

This extremely hot fuel-rich gas feeds the main combustion chamber, efficiently developing the engine

thrust. This system results in unprecedented operating regimes of temperatures,::pressures, and rotating

machinery speeds. The high rotary speeds and the combustion processes create mechanical, acoustical,

and fluctuating pressure environments. The volumetric and weight constraints drive the design toward a

high concentration of energy and minimum structure sizing (thickness, etc.). The energy concentration

can be illustrated by observing the size of the high pressure fuel pump, which generates 70,000 h.p.

within an envelope 18 in. in diameter by 30 in. long and rotates at speeds up to approximately 40,000

rpm.

63
Rotarydynamicsis oneof the morefascinatingfields in dynamics.It is anareaall arefamiliar

with from onestandpointor another.Any automobiledriver hasexperiencedwheel imbalance,brake

squeal,etc.For theSSME,theseproblemareasarecompoundedseveralordersof magnitudein thehigh

pressurefuelandlox pumpsdueto thehighenergyconcentration(energydensity)andspeedranges.As a

result, supposedlysmall changes(causes)aregreatlymagnifiedin theresponses.Sincebearinglife of

thesepumpsis limited and is to a largedegreea function of thedynamicresponse,the healthof the

pumps is monitoredusing accelerationdata. Thesedataare obtainedfrom a set of accelerometers

mountedon variouslocationsof the pump housing.

Theimportanceof this informationto theSSMEandtheinability to analyticallydeterminemany

effectsin this machineryhaveledto thedevelopmentof averycomprehensivesetof datareduction,data

evaluationtools, andanautomateddatabankof thesedatafor all hot firings. Over 1,000enginefiring

resultsareavailablein thisdatabank.Problemshavebeencharacterizedandnormalpumpcharacteristics

havebeenstatisticallyformatted.Throughtheuseof this databasesystemandaccelerometerdatafrom

eachenginefiring andShuttleflights, pumpstatusis determinedandrefurbishmentscheduledaverting

major problems.

First, the responsestatisticsfor threeaccelerometermeasurementson the lox pump for all 109

percentpowerlevel firing (percentof original enginedesignthrust level)areshownon Figure43. Two

tablesaregiven, onefor thecompositelevel (0 to 1,000Hz RMS levels)andtheotherfor synchronous

(levelstakenfrom spectrumatrotating speed).Informationcomparableto this for all pumpsandtheir

measurementsandpowerlevels is available.Also,datacanbecompiledbypump,engine,build,etc., as

desired.

A typical pumpresponse(isoplot)is shownonFigure44. Thepredominantresponseis synchronouswith a small2N response.Isoplotsarea seriesof spectrumplotsevery0.4 sec,giving apictorialof

frequenciesversustime. Amplitude is shownbut is hardto readdueto the overlappingof spectrums.

Individual spectrumsareusedto get correctamplitudes.Anomalousbehaviorwould showup asadditional frequencieson the isoplot.

Figure45is anisoplotfor a pumpwith rubbing.Noticethedistinct3N (3 timessynchronousfrequency)and4N frequencies.Also, noticethatdistinctfrequenciesexistslightly above3N and4N. These

areindicatedonthe individualspectrumplacedabovetheisoplot. Many times,thesefrequenciesarenot

constantwith powerlevel butmovearound,indicatingsomethinglike brakesquealgoingon (Fig. 46).

2. Vibroacoustic Criteria

Fundamental to structural integrity of space vehicle components such as gyros, actuators, valves,

electronic boxes, etc., is the development of vibration criteria for calculation of loads and for development, qualification, and acceptance testing. These criteria are developed in a pseudo empirical/analytical

manner using data bases consisting of the input acoustical spectrum and a known system including attach

structure and the recorded response spectrum of the input. Categorizing this data by component mass and

attach structure, new criteria for different components mounted on the same type structure can be

developed through scaling the input acoustic spectrum, component mass, and mounting structure thickness. Automating this data base has reduced criteria development efforts by a factor of 3 or 4. Figure 47

shows typical data bank data, while Figure 48 shows the use of that data bank to generate new criteria.

64

• :, '•.• • _ •i • ;'••i
/

l REQUIREMENTS DURABILITY

e LIFETIME

e U LTIMATE

eYIELD

• FRACTURE ME.CH.

THERMAL H

ANALYSIS

DEVELOPMENT &

VERIFICATION

PLANS

DYNAMIC H

ANALYSIS

MARGINS

e LIFETIME

• U LTI MATE

eYIELD

eF.M.

PROCEDURES

METHODOLOGY

ANALYS IS/TEST

SUMMARY

T t

I [FRACTUREI [

STRESS _] MECHANICS/___

ANALYSIS I -I FATIGUE I" I

J [ ANALYSIS J I

MATERIALS

TESTING/

DATA BASE

DYNAMIC

TESTING

STATIC

TEST

HOT FIRE

Figure 42. Documentation tree.
FUEL PUMP RAD 0

COMPOSITE @ 109% POWER LEVEL

m

TEST # G

STAND TESTS RMS SIG

A1 52 6.3 2.8

A2 49 5.8 2.8

A3 58 7.3 4.0

COMBINED 159 6.5 3.3

FUEL PUMP RAD 90 FUEL PUMP RAD 174

MAX MAX

G # _" G # _

RMS TESTS RMS SIG RMS TESTS RMS SIG

15.5 49 7.7 3.3 21.0 4 10.6 2.8

17.0 48 6.1 3.2 17.0 1 6.0 0

20.0 59 8.2 3.2 21.0 11 6.4 1.0

20.0 156 7.4 3.3 21.0 16 7.4 2.4

MAX

G

RMS

13.8

6.0

8.2

13.0

FUEL PUMP RAD 0

SYNCHRONOUS @ 109% POWER LEVEL

FUEL PUMP RAD 90

MAX

# G G # G

TESTS RMS SIG RMS TESTS RMS

A1 52 4.9

A2 48 4.2

A3 56 6.1

COMBINED 156 5.1

SIG

2.8 14.0 46 3.6 1.7

FUEL PUMP RAD 174

2.5 9.5 45 3.0 1.7

3.8 18.0 58 4.3 2.1

3.2 1.8 149 3.7 1.9

TEST 'S A129-436, A2195-331, A3047-232

MAX MAX

G G G

RMS TESTS RMS SIG RMS

8.0 4 6.9 3.4 11.4

7.6 0 0 0 0

11.0 11 3.7 1.3 5.3

11.0 15 4.6 2.4 11.4

Figure 43. Statistical summary of SSME vibration data.
TEST 9020336

TIME INC = 4 SEC

HPFP RAD 0

XINC = 50 (HZ}

(12-1) 051684

MAX = 25.0 LOG/40%

39.6

1.3

G SO/HZ

-1.1

M

O

;Or"

K:) ,.'_i

r'-.T_

A

60.0 FREQUENCY (HZ) 1310.0

Figure 44. Typical isoplot of a pump accelerometer response.
r

• • i  ̧ ̧

O_

GO

1.0E

2497.5 1.751

2387,5 1.558

1840.0 1.059

2395.0 .936

1990.0 .473

2507.5 .309

NAVGS = 5

BW = 2.50

COMP = 9.149

(12-1)

1.0E - 2

TEST 9010436

E

1000,0

T

I

M

E

HPFP RAD 0 S + 550,0 109% .

4N

3N

3N+

I I

FREQUENCY (HZ)

4N+

: G

S

- Q

/

" H

Z

1

2560.0

o O

"n :;tl

m

"off)

o_.

o¢,,

:;Or ="

r-i_

182.4

1500.0

Figure 45.

FREQUENCY (HZ)

Isoplot showing frequencies indicating rubbing.

2560.0
k •

, ii?:  ̧ ̧ _

TEST 9020319

TIME INC = 2.4 SEC

180.0

HPFT RAD 90 ACC

(10,=12) 033184

LOG W/60.0%

T

I

M

E

1060.0

t

FREQUENCY (HZ) 2560.0

O

"11

"0

O

O

;;0

,O

,<

O

::o

O

r"

ANOMALOUS FREQUENCY

Figure 46. Anomalous frequencies in response data.
H

:/

i:iii

L

i_,

:

ACOUSTIC SPECTRUM: REFERENCE

FLIGHT CONDITION:ALL

OOCUMENT:TN 0-715g

dB

160

155

150

145

14@

!35

130

125

120

IB

/

/

IIIIl

IJ

fr

/

Jill

IIIIl

lllIl

100

FREOUENCY IN HERTZ

IIll

i

llll

IIII

1000

Figure 47. Reference acoustic function.

I/3

As stated previously, data bases exist in most engineering, operations, and hardware manufacturing areas and are key to structural integrity and to project management. Much work on data bases and the

appropriate reference symbols needs to be accomplished. These data bases should be accessible by both

government and industry organizations that have concerns and should be accomplished with cross

country data linking, as is presently done with the SSME data. Modern scanning devices can greatly

enhance the completeness of these approaches. The design and operation of the Shuttle vehicle have

clearly driven this approach. Future systems must greatly expand it in terms of scope and symbols.

7O
i!!i::

. • !:ri:

2

C

HZ

ORIGINAL PAGE IS

OF POOR QUALITY

VALVE BOX

MEAS.. D]RECTJON=RADIAL

FLIGHT CONDITION=LIF_OFF

MATERIAL=AL

VEHICLE DIAMETER:N/A

COMPOS l'E:

I =

rZ

I_. Zl -.=

1 ._E-_

m

I .OE-Z

1 .8E-5

14 .7 1 Gr ms

I I I I I I II

/

I !

SKIN THIC_NESS,.18 IN

I I I I 1 I'1 I I :

E

F

L -

I I I III I I I I I Ill

I_0 1080

FREOUENCY IN HERTZ

m

I

Figure 48. Scaled vibration spectrum with criteria.

CRITERIA

COMPOSITE

Ig 28 Grms,

ACOUSTIC

SPECIRUM:

INTERNAL PIL

MrlMn=l .15

1/56

)> '

i

C. Summary

In the general section, a flow down of the documentation (Figs. 20 through 24) was shown down

to the DVS level. Not shown is much of the supporting documentation to the DVS, such as analysis and

test reports. For these, one important finding or principle is that each analysis, test, etc., should have two

types of summary attached to the basic document: (1) a set of check-off sheets which provide a quick

look at the scope, etc., of the analysis/test; and (2) a summary paragraph or statement of the results. This

latter summary can be used as an input to the next level of documentation and organization. It should be

kept in mind constantly what the objectives of documentation are: (1) communication, (2) organization of

tasks, (3) records of work, (4) data base for operations and maintenance, and (5) insights for product

improvement, etc.

• • T•

71.
f

/

VII. PROCEDURES AND CRITERIA

Procedures and criteria have been combined into one section for convenience. Both are means of

control or setting minimums in terms of approaches or margins. Both have to be controlled very stringently and require periodic review for correctness and applicability. Both are mandatory since they control the goodness of the hardware, either by how it is analyzed, tested, inspected, manufactured, etc., or

the margins, etc., that are built in to cover unknowns. Procedures cover every aspect of the program from

management, analysis, and testing to manufacturing, maintenance, and operations. Procedures set the

pace for the total program. Some procedures must be rigidly enforced and constantly reviewed while

others are merely guidance. For example, the procedures that control hardware assembly are very critical

while an analysis procedure would be a minimum requirement or guideline. Many times the analyst

would do more than the procedure calls for. Some flexibility should be allowed in these areas.

A. Procedures

Principles that are important to procedures are, in many cases, generic with the one discussed in

other areas. There are unique areas, however.

1. Definitive

First, procedures must be very definitive and clear from two aspects: (1) by whom and how it is

controlled and maintained, and (2) writeup, instructions, and illustrations, etc. Procedures that are not

clear or are changed inadvertently can produce bad results.

2. Requirements

Second, procedures should be written only where required. One should not try to over control

using procedures. The review and maintenance of procedures is a major burden. Elimination of procedures whenever possible is a good guideline. However, every critical action should be covered by procedures. Procedures should be written only when they are mandatory to insure adequate design. Procedures

have a history of becoming bureaucratic, removing flexibility and stifling initiative: They are the means,

not the end. Individual responsibility has been and will continue to be the fulcrum of good design and

hardware.

3. Validation

Third, procedures must be tested and proved before implementation. They should also be as

simple as possible to insure correctness. The range of activities that procedures cover is so large that it is

hard to generalize. A manufacturing procedure is quite different from one for analysis.

4. Involvement

Fourth, all various parts or elements of a project should be involved at some level in development of procedures. Engineering, manufacturing, quality management, etc., should have inputs and

reviews to insure adequacy and completeness.

72
r iii!_' _"i_

5. Flexibility

Fifth, procedures should have the flexibility to allow for evolving technology including analysis,

materials, manufacturing, etc. Only with this flexibility can high performance be developed and validated

for low margins, light weight, etc.

B. Criteria

Criteria, as well as procedures, determines the adequacy of the hardware. The design, its

margins, and its sensitivity are governed by the criteria. Criteria covers every discipline, every phase,

and every effort. Design, in general, is no better than the criteria. Areas requiring criteria are: (1)

strength, (2) fracture mechanics, (3) fatigue, (4) structural stability, (5) dynamic and control stability, (6)

deflections, (7) dynamic responses, (8) loads, (9) vibration and shock, (10) thermal, (11) acoustics, (12)

testing, (13) fasteners, (14) inspections, (15) offsets, (16) control, (17) hydraulics, (18) electrical, (19)

finish, (20) materials, (21) bonding, (22) flow (all natural environments), (23) manufacturing, (24)

operations, etc. Criteria are always under strict control. Changes can only be made after detailed review

and approval by all concerned, including PRCBs. If criteria are not met, then, in general, the design is

not adequate by definition. If used as designed, then waivers must be approved by proper boards, etc.

In the early space exploration days, all testing was prototype using dedicated, disposable

hardware. In today's world, the extra cost of building extra sets of hardware has opened up a new world

called protoflight testing and/or verification by analysis, where hardware is flown after testing. This is a

basic issue facing structural engineering since hardware cannot be tested to failure to determine limits.

Verification becomes a combined analysis/test approach and raises new definitions of test procedures and

criteria. This, coupled with time consistent probabilistic environments, opens up many new vistas of

criteria, all of which must be considered and validated. The following areas of criteria must be considered.

1. Requirements

High performance systems, because of the requirement for very accurate data, etc., drive toward

a change in how criteria are developed and implemented. Instead of the conservative, additive,

equivalent static margins, a probabilistic integrated approach is indicated. This not only means a change

in how the structural data are generated, but also the criteria statement and how it is applied. Obviously,

not all of the currently used criteria approaches are invalid. In fact, the opposite is true. Most are applicable as is or with modifications. What is argued here is an expansion of criteria approaches to include

probabilistic approaches. The principle involved here is to open criteria up (flexibility) to incorporate

currently developed probabilistic approaches required to design high performance, low margin, light

weight structures. As with procedures, all disciplines and elements of the project must be involved in the

development of criteria. One discipline may have the lead, but each must help in the development and

control.

2. Clarity

Criteria must be clear, simple, definitive, etc., so that no confusion or misunderstanding results in

design and verification. Two extremes illustrate what the limitations for developing criteria and these

73
applicationsare. In the first extreme,a statementof the following characteris made:"A safe,reliable

systemshallbedesignedandverified that meetsa 3_ probabilisticlevel of 95 percentconfidencethat

includesall considerationsof uncertaintiessuchasenvironments,materials,analysis,test, manufacturing, etc." This statementallowsflexibility in methods,approaches,etc., usedto meetthisencompassing

statementof criteria.Theotherextremewritesaverydetailedsetof criteriafor eachdisciplinesomewhat

independentof otherdisciplines.This approachtendstowarda conservativedesigndueto the inherent

narrow look of eacharealeadingto lossof flexibility, creativity, andinnovation. Obviously, neither

extremeis desirable,however,thebalancedapproachmusttakethesystemviewpoint andleantoward

the first statement.Thereare many implicationsof taking this approach,including the contractural,

legalistic one. Thesemust also beconsideredin criteria development.

3. Specifics

Clearly, criteria must be specific in that it covers all hardware phases, preliminary design, design,

verification, operations, refurbishment, and life management. Various approaches are apparent. For

example, life management can be only a procedure/criteria for using hardware as verified versus up front

impacting design with criteria that considers refurbishment, operations, maintenance, etc. As stated

previously, the integrated look is mandatory versus a discrete look.

4. Reviews/Updates

Clearly with these same systems and approaches where nonlinear approaches are relied on, failure

criteria needs further definition and quantification. Safety factors and related margins are arbitrary

numbers, supposedly based on cost and success experiences, but really do not correlate to the safety of

the component and system. All safety factors on failure and duration should be referenced to probability

of failure. It would be more significant to estimate the weight, cost, life, or other performance to the

probability of success, and the delta increase required to decrease the risk one more order of magnitude.

The same is true for many exotic materials and composites. An example of the difficulty of developing

criteria is the use of safety factors for nonlinear systems. As long as the system is linear dealing with

loads, stress, and strain give the same results since everything is linear and correlated in this linear

fashion (Fig. 49). If, however, the operating point is in the nonlinear portions of the curve stress, strain,

and loads are related in a nonlinear manner. Notice that for points A and B, when the apparent stress is

projected to the stress strain curve, the difference in apparent stress is substantial while the real stress

changes very little and the strain is large. In the nonlinear portion of the curve, strain increases dramatically with increasing load while stress changes very little. The obvious question for this region becomes

how do you write or derive the safety factor? Do you write it against loads, stress, or strain? Different

numbers result if you do. Classically, safety factors have been developed for linear systems. Current high

performance systems operate in or near the nonlinear range, opening up a redefinition for criteria. Other

examples exist and must be dealt with in a rational manner to adequately verify structures. If safety factor

is defined as loads relative to structure failure, then high strain exists with nominal stress (point A) (Fig.

49). Employing nonlinear stress analysis will define the proper relationship between stress and strain

while the linear analysis will produce the apparent stress. This makes it clear that real stresses and

strains can be determined but keeps the safety factor criteria question open. Obviously, it is better to

design a system where these effects are bypassed. For example, operating in the linear range gives a

properly understood safety factor. Using linear analysis in a nonlinear range would predict failure where

it did not occur and negative margins of safety. The nonlinear analysis predicts correct stress but can be

misleading as to the sensitivity to failure. The principle is clear, continually review and update criteria

commensurate with the materials usage and performance requirements.

74
; !

A

B

c

D

/ LINEAR EXTRAPOLATION OF STRESS STRAIN

//_ (APPARENT STRESS CURVE)

/ .A'

t _'fl B' J

.__,r__t

/124. f

.'...'r,!

yii

/ [

-7 '

1

!

m I

STRAIN

Figure 49. Typical stress strain relationship.

As just discussed, the criteria for any space system (vehicle) is very large and all encompassing,

going from natural and induced environments to operations. The scope of the documentation is too

voluminous to reference or show. In the structures world, typical criteria includes safety factors, vibration testing, proof testing, fracture mechanics, and environments. All of these have documents that cover

all contingencies. Selected items from some of these have been chosen for illustration.

Vibration testing of components to the expected level as a function of frequency and direction is

conducted at three different levels, namely, developmental testing, qualification testing, and acceptance

testing. No component is qualified until it passes qualificatioja testing. New hardware is accepted only

after passing acceptance testing designed to screen manufacturing flaws. Figure 50, taken from Reference 41, defines the deviations allowed on the vibration spectra during testing. Criteria differs also

whether one deals with prototype versus protoflight testing. Many other issues such as test time

durations, levels, etc., are defined in the reference.

Structural loads must consider known variations of all environments, models, etc., used to

generate the responses. One example of criteria for the combined probabilities of these parameters for

each launch phase is shown on Figure 51 (taken from Reference 22).

Using the high confidence level limit loads, structural tests are run to verify structural margins.

One example of design safety factors is shown in Figure 52, taken from Reference 22. Many other

combinations and levels of safety factors exist for various verification approaches, hardware, etc. Proof

testing of pressure vessels has many uses and values. Figure 53 shows typical criteria for various pressure

vessel structures [33].

One final example of criteria is shown for fracture mechanics (Fig. 54) [24]. This is a flow chart

from the MSFC fracture mechanics criteria showing the control and selection of fracture critical parts.

75
--3

THE TEST SPECTRA SHALL BE VERIFIED BY NARROW BAND SPECTRAL ANALYSIS

USING AN ANALYSIS SYSTEM THAT IS INDEPENDENT FROM THE ANALYZER/EQUALIZER

USED TO CONTROL THE TEST. TOLERANCES CONSIDERED ACCEPTABLE AREAS FOLLOWS:

• VIBRATION +10%

COMPOSITE ROOT MEAN SQUARE ACCELERATION

ACCELERATION SPECTRAL DENSITY

(TOLERANCES PERTAIN TO BANDWIDTHS OF 25 Hz OR LESS)

+100%

-30%

SINUSOIDAL PEAK ACCELERATION +20%

-10%

SINUSOIDAL CONTROL SIGNAL MAXIMUM

HARMONIC DISTORTION

+10%

FREQUENCY +5%

TEST DURATION

eSHOCK SPECTRUM

+10%

-0%

SPECTRUM PEAK ACCELERATION

(WHEN ANALYZED WITH A 1/3 OCTAVE SHOCK SPECTRUM

ANALYZER AND 5% DAMPING)

+40%

-20%

• SHOCK PULSE

AMPLITUDE +40%

-20%

DURATION +10%

Figure 50. Vibration spectra tolerance.
_ii!i I _:i : "

MISSION PHASE

PRELAUNCH

LAUNCH

ASCENT

SEPARATION

SPACE

ENTRY

ATMOSPHERIC

FLIGHT

DEFINITION OF PROBABILITY VALUE

PROBABILITY OF NOT HAVING TO RETURN A VEHICLE FROM THE PAD

TO THE ASSEMBLY AREA, OR TO IMPLEMENT SPECIAL TIE-DOWN

PROCEDURES BECAUSE OF STRUCTURAL CAPABILITY LIMITATIONS

WITH RESPECT TO THE PRELAUNCH GROUND ENVIRONMENT.

PROBABILITY OFNOT HAVING TO DELAY A LAUNCH BECAUSE OF STRUCTURAL

CAPABILITY LIMITATIONS WITH RESPECT TO THE LAUNCH GROUND

ENVIRONMENT.

PROBABILITY OF NOT HAVING TO DELAY A LAUNCH BECAUSE OF STRUCTURAL

CAPABILITY LIMITATIONS WITH RESPECT TO THE ANTICIPATED ASCENT

ENVIRONMENT.

PROBABILITY OF NOT HAVING TO ABORT A MISSION BECAUSE OF STRUCTURAL

CAPABILITY LIMITATIONS WITH RESPECT TO THE SEPARATION ENVIRONMENT.

PROBABILITY OFNOT HAVING ABNORMAL SPACE OPERATIONS OF

STRUCTURAL CAPABILITY LIMITATIONS WITH RESPECT TO THE ASSOCIATED

ENVIRONMENTS.

PROBABILITY OF NOT HAVING TO ALTER THE ENTRY FLIGHT PLAN BECAUSE OF

STRUCTURAL CAPABILITY LIMITATIONS ASSOCIATED WITH THE ANTICIPATED

ENTRY ENVIRONMENT

PROBABILITY OF NOT HAVING TO DELAY ENTRY ORNOT HAVING TO SELECT AN

ALTERNATE LANDING SITE BECAUSE OF STRUCTURAL CAPABILITY LIMITATIONS

WITH RESPECT TO ANTICIPATED ATMOSPHERIC ENVIRONMENTS.

LIMIT-LOAD

PROBABILITY LEVEL

(95% CONFIDENCE)

99%

99%

95%

99.9%

99%

99%

99%

-.1 Figure 51. Illustrative limit-load probabilities.
...,.1

OO

COMPONENT

GENERALUNPRESSURIZED STRUCTURE

WINDOWS, DOORS, AND HATCHES

PRESSURIZED STRUCTURE**

PRESSURIZED LINES AND FITTINGS

MAIN PROPELLANT TANK

PRESSURE VESSELS (OTHER THAN pROPELLANT TANKS)

YIELD

>1.0

FACTORS

ULTIMATE

1.5

3.0

1.5 2.0

1.1

2.5

1.4

2.0

PROOF

1.5

1.05

1.5

** FOR PRESSURIZED STRUCTURE, BOTH ULTIMATE FACTORS OF SAFETY INDICATED SHOULD BE APPLIED

AS FOLLOWS:

1.5 x LIMIT LOAD +1.0 x LIMIT PRESSURE (i.e.,1.5 x LIMIT LOAD APPLIED AT LIMIT PRESSURE)

AND

0 x LIMIT LOAD +2.0 x LIMIT PRESSURE (i.e., 2.0 x LIMIT PRESSURE APPLIED AT ZERO LIMIT PRESSURE)

Figure 52. Factors of safety.
/

• i_ii_.• .•!_• •_,••_••i• ._ ,• •_•!•ii _ ••i.

PROBABLE

FRACTURE

MODE

POTENTIAL

VALUE OF

PROOF TEST

REQUIRED

MIN. PROOF

TEST FACTOR

to

o')

LIJ

O:

@ PROOF

@ OPER.

m

CASE I

INCREASING FRACTURE TOUGHNESS AND/OR

DECREASING WALL THICKNESS

, >

CASE II CASE III

. /_,-,

I / K,,= .,.WALL _ / K,= /WALL I_ V K,o / WALL

-- a o " "--"--'_--- a _o. • a.Oop

--!74oP,=R "oC--_l- oo_ "7- °o,

I / t / '

",l I"o, /a'_l ! i

FLAW DEPTH, a FLAW DEPTH, a FLAW DEPTH, a

CASE IV

__ Kt'=

,4

I

WALL_

THICKNES_

FLAW DEPTH, a

FRACTURE FRACTURE LEAKAGE LEAKAGE

FRACTURE LEAKAGE LEAKAGE LEAKAGE

CAN ASSURE

SUSTAINED PRESSURE

LIFE

CAN ASSURE

CYCLIC AND SUSTAINED

PRESSURE LIFE

CAN ASSURE

CYCLIC AND SUSTAINED

PRESSURE LIFE

= = 1 + ALLOW. a = 1 + ALLOW. =- 1 + KrH/Ktc

K,/Kj= Kli/Kic

CAN ASSURE

SUSTAINED PRESSURE

LIFE

,, = 1+ K.r./Kl=

Figure 53. The effect of wall thickness on value of proof test.
L • _r _ .....

, k. ,: • . ] k

GO

START

I

STRESS ANALYSIS

l REDESIGN ]

WILL STRUCTURAL FAILURE OF PART NO

CAUSE A CATASTROPHIC EVENT ?

YES (FRACTURE SENSITIVE PART)

IS PART LOW MASS, IYES

CONTAINED/RESTRAINED,

OR FAIL-SAFE ? I

(FRACTURE CRITICAL PART)

I

COMPOSITES OR _1

NONMETALLICS _I

OTHER THAN GLASS '

LICS

ASS

1

IS PART SAFE-LIFE ? IYEs

I

].°

IS PART A PRESSURE VESSEL

OR ROTATING MACHINERY ?

IS PART DAMAGE-TOLERANT ?

!NO

YES

PART MEETS I

FRACTURE I

CONTROL I

REQUIREMENTS I

r

TO MSFC FRACTURE CONTROL

BOARD FOR DISPOSITION

Figure 54. Fracture control selection and disposition of parts.
Thesesnapshotshave shownonly brief glancesat criteria. In the aerospaceworld of manned

flight, crit'eriaandthevalidatingdocumentsrequiredto verify that hardwarehascomplied,constitutea

major effort of structuraldesign.Understandingof criteria andplansto incorporateit becomekey to

adequatestructuraldesign.

C. Summary

It is not the purpose of this report to provide guidelines for developing or baselining procedures or

criteria. Nor is it intended as a reference of all these documents, however, some typical ones are listed in

the references. Also under documentation, a typical flow down was provided and is applicable universally. As is evidenced by this and other listings, the process starts with requirements and the associated procedures and criteria and flows down into ICDs, specifications, OMIs,, OMRSDs, FMEACILs. hazards analyses, etc., necessary to verify that requirements have been met.

VIII. SUMMARY

The experience gained through audits and other exercises, coupled with past engineering

expertise, have led to the formulation of lessons learned and general principles leading to adequate design

and verification of structural systems as applied to space vehicles and space systems. This compilation is

obviously not all inclusive nor complete but represents a partial listing of the conclusions reached by

several involved in these activities. The interpretations are the author's. Using these guidelines, design

and verification of a space system should be improved; however, it is the nature of this business that

problems will occur. In fact, it has been and will be that the preponderance of what we have learned

comes because of the presence of problems. A summary listing of lessons learned is contained in the

following.

Lessons Learned

A. Philosophy

1. Validated design requires both top down (system) and bottom up (part) approaches

a. Top Down

(1) Discipline and component interaction emphasized

(2) Focuses output

b. Bottom Up

(1) Drives detailed penetration at local levels, etc.

(2) Emphasizes special disciplines.

81

_". ' <7' :'• • '
7 _ •

jr •

2. Sensitivity of all parts of system to key parameters must be started initially and continued

through program in order to focus efforts on key effects. Eliminates poor design.

3. Robustness is the secret to good design and quality. Quality control (inspections) is for insurance

and risk reduction.

4. Design and manufacturing in quality do not depend on inspection.

5. Plan initially for adequate development and verification instrumentation from part through flight

testing.

6. Clearly define failure philosophy up front (fail safe, fail operational-fail safe).

7. Fracture mechanics and all special requirements must be incorporated as a design philosophy up

front to insure adequate coverage.

8. Design where practical for high (peak) stresses to occur in parent material instead of welds.

9. Eliminate coupling (3-D effects), static and dynamic in design where possible.

10. Design for margins linearly, test to prove it, inspect to verify, invoke nonlinearities for surprises.

11. Derive criteria to force hardware to meet philosophy, requirements, objectives, etc.

B. General

1. Performance requirements determine design and sensitivity to variations and must be thoroughly

understood and worked to reduce risks, etc. The higher the performance requirements, the higher

the sensitivity of the design.

2. Innovative approaches in analysis, testing, and management are key to flexibility and accuracy.

3. Models are just that, models, only as good as the assumptions used.

a. All analyses are simulations which are not complete (limited), which attempt to predict trends

and what will happen. Models are not exact representations of physical laws.

b. Test (components, subsystems, systems, scale, etc.)only partially replicates real life situations

It is biased by the limited insight and provisions of the test engineer.

c. How do you put these together to get a validated design is the major problem that must be

addressed.

4. Design breaks down with lack of coordination and definition of part/vehicle interface

requirements, etc.

82
:, _i _

_ij_i_!! •

:i_i _i_ i

• i _

C. Management and Control

1. The use of independent reviews/analyses, etc., is a prime means of eliminating errors. Several

levels of reviews are available and should be used.

a. Management overview/audits

b. Independent check

c. Independent analysis

d. Independent codes

Comprehensive reviews of results/approaches to insure discipline interaction and completeness are

a fundamental part of these reviews.

2. Communication between disciplines, etc., is mandatory. Management must insure that the

openess, lines of communication, etc., are clearly emphasized and implemented.

3. Methodology, procedures, criteria, etc., must be under essentially constant review to insure

applicability of assumptions, etc., and adequate design.

4. People are the prime resource, all other resources are aids to the human. The individual acceptance of the responsibility of the tasks and to growth, communication, and planning is the key to

success. Managements' emphasis on people must be the first priority.

5. Requirements up front for flight certification, overhaul, life extension, etc., are mandatory as a

management tool for control to insure correct design.

6. Proper determination and manning of skills is essential from program start to finish. Do not allow

reduction as cost savings, etc.

7. Management must assure that proper interface symbols, etc. exist and flow vertically and horizontally.

8. Prioritization of tasks toward results, both long range and immediate, is a prime task.

D. Analysis and Test

I. Methodology is one of the keys to accuracy providing:

a. Flexibility

b. Usability

c. Adaptability

83
• i

)i

and must match what is expected from analysis, requires periodic review for validity, is

implemented through structural manuals, procedures, handbooks, etc., and must cover all areas

such as:

(1) Loads combination

(2) Fatigue

(3) Fracture mechanics

(4) Modeling

(5) Environments

2. Analysis is only as good as the development and validation testing. Required are:

a. Pretest predictions, procedures, requirements, instrumentation

b. Test analysis correlation

c. Analysis update based on test.

3. Validation of margins requires the establishment of as-built data bases on key structures, etc.

Typical parameters are:

a. Weld offsets

b. Weld Kq's

c. Misalignments

d. Flaws.

84

4. Data bases maintained, communicated, and controlled are key to analysis validity (automated

preferred). Examples:

a. Materials properties

b. Vibration

c. Internal fluid flow

d. Environments, natural and induced

e. Margins, durability, etc.
5. The engineer'schoiceof codes,elements,assumptions,etc., determinesoutput validity. The

other side of this coin is validity of input data.Codes,etc., cannotbe usedindiscriminately.

Involved are:

a. Elementchoices

b. Linear versusnonlinear

c. Compatibility betweenelementsandenvironments,etc.

6. Materialscharacterizationis the singlemostimportantitem in durability. It mustmatchdetails

and assumptionsof models.

7. Sensitivity analysisis key to understandingsystemand bracketinglimitations.

8. Updatinganalysis,etc., asdesignchanges,computational/methodologyimproves,etc., mustbe

a continuousactivity.

9. Statistical significanceof resultsis necessaryfor properinterpretation.

10. Well definedand implementedstructuraltestprogramsare a validation must.

11. Developmenttesting,componentand system,is requiredto properlydetermineenvironments.

12. Efficiency and accuracycanbe improvedthroughuseof:

a. Stressand loadstransformations

b. Automatedscreening

c. Load indications

i_ " •

d. Statistical significance

e. Graphing and displays.

13. Input environments accuracy as a function of response sensitivity is one key to cost effective

design.

14. System approaches are required for understanding and validation.

15. Compatibility must exist between all models, environments, etc.

16. Analysis technologies must match the analysis/performance requirements. Examples:

a. Combination of low cycle frequency and high cycle frequency

b. Low and high cycle fracture mechanics

85
i  ̧

c. Plastic fracture mechanics

d. Nonlinear (local) yielding

17. Current problems in analysis/test (short-comings)

a. Data to support Goodman's diagrams

b. Failure criteria for ductile material

c. Bolts/fasteners/threads

d. 3-D effect on fatigue

e. Combination low cycle frequency and high cycle frequency

f. Accumulated linear damage rules

g. Nonlinear fracture mechanics

h. Techniques for residual stresses

i. Analysis and test turnaround time much too long for proper program impact. Example: 1 year

cycle for system loads analysis.

18. Integrated analysis/optimized design from overall viewpoint increases understanding,

efficiency, and margins.

E. Documentation and Data Basing

1. Documentation is a must and requires clear statements of assumptions, data, etc., including traceability identification.

2. Lack of traceability of documentation is a major problem in validation.

3. Documentation must occur at all levels, have various levels of control, and include as a minimum:

a. Requirements

b. ICD's (interface control documents'

c. Procedures

d. Methodology

e. Plans and schedules

86
f. Analysisand test results

g. Criteria

h. Specifications

i. Drawings

j. Manufacturingand quality records,etc.

k. Photographsand films.

4. Documentationshouldbe locatedin a centralplaceor haveclearlydefinedareaof whereit is.

Working papersin someone'sdeskarenot sufficient.

5. It is very helpful for traceability to have top level breakoutsof documentby disciplinesand

categoriesso that a quick determinationcan be madeof what documentto searchfor.

6. Automateddatabasingis amustfor currenthighperformancesystemscuttingacrossmanyareas

suchas:

a. Vibration

b. Environments

c. Material properties

d. Life specifications

e. Specialanalyses

f. Test data

g. Hardwareusage.

7. Adequatelife managementandrefurbishmentrequirescontinuoususeof theseautomateddata

bases.

8. Databasesmust havecontrol proceduresestablishedto insurefidelity but mustbe accessibleto

users.

F. ProceduresandCriteria

1. Procedures/criteria/philosophyarethebackboneof designandverification.They shouldcontain:

a. Criteria definition

87
b. Handbooksrequired,etc.

c. Proceduresand guidelines(standardizationof approaches)

d. Interaction/sequencingor flow

e. Communicationlines

i

f. Working groups/boards/panels, etc.

g. Control/management.

2. Analysis and test procedures should not be so restrictive as to kill innovation, improvements, and

special applications, but should define minimum type approaches, standard methods, etc.

Handbooks fall into the same category.

3. Criteria should be clear and definitive, spelling out boundaries, exceptions, etc. In general,

criteria are very strict legal requirements.

4. Criteria and procedures should be under continuous revision to insure applicability and adequacy.

5. Procedures applied indiscriminately can result in erroneous data.

6. Establishment of life management criteria is the secret to safe hardware operations.

7. Criteria should be developed for all areas including manufacturing and quality. For example, weld

offsets are not always specified, creating hardware lifetime problems.

L

L

88
REFERENCES

:15

+iI i ̧

ii •

1. Drucker, Peter F.: Management, Tasks, Responsibilities, Practices. Harper and Row Publishers,

New York, Colophon Edition, 1985.

2. McCormack, Mark H.: What They Don't Teach You at Harvard Business School. Bantam Books,

New York, 1984.

3. Townsend, Robert: Up the Organization. Alfred A. Knoff, New York, 1970.

4. Whyte, William H.: The Organization Man. Doubleday Anchor Books, Garden City, New York,

1957.

5. Gall, John: Systemantics. Pocket Books, Simon and Schuster, New York, 1978.

6. Hughes, Charles L.: Goal Setting Key to Individual and Organizational Effectiveness. ANACOM,

New York, 1980.

7. Pollock, Ted: Managing Others Creatively. Hawthorne Books, Inc., New York, 1971.

8. Pollock, Ted: Managing Yourself Creatively. Hawthorne Books, Inc., New York, 1971.

9. Blanchard, K., and Johnson, S.: The One Minute Manager. Berkley Books, New York, 1982.

10. Goble, Frank: Excellence in Leadership. AMA, New York, 1972.

11. Calvert, Robert: Success with People Through Human Engineering and Motivation. Success

Unlimited, Chicago, Illinois, 1969.

12. Levinson, Darry: The Exceptional Executive, A Psychological Conception. Harvard University

Press, Cambridge, Massachusetts, 1968.

13. Mark, Hans, and Levine, Arnold: The Management of Research Institutions, A Look at Government

Laboratories. NASA, Washington, D.C., 1984.

14. Bloch, Arthur: Murphy's Law and Other Reasons Why Things Go Wrong. Price/Stern/Sloan, Los

Angeles, California, 1978.

15. Block, Arthur: Murphy's Law, Book Two. Price/Stern/Sloan, Los Angeles, California, 1980.

16. Block, Arthur: Murphy's Law, Book Three. Price/Stern/Sloan, Los Angeles, California, 1982.

17. Gordon, J. E.: Structures or Why Things Don't Fall Down. Da Capo Press, New York, New York,

1981.

18. Gordon, J. E.: The New Science of Strong Materials, or Why You Don't Fall Through the Floor.

Princeton University Press, Princeton, New Jersey, 1968.

89
, !

, 71,

_ii i _

_i"_ .

19. Ryan, Robert S., et al • System Analysis Approach to Deriving Design Criteria (Loads) for Space

Shuttle and STS Payloads. NASA TP 1950, NASA, MSFC, 1981. '

20. Ryan, Robert S." Problems Experienced and Envisioned for Dynamical Physical Systems. NASA

TP 2508, NASA, MSFC, August 1985.

21. Ryan, Robert S., et cl." Dynamic Testing of Large Space Systems. NASA TM-78307, September

1980.

22. Structural Design Criteria Applicable to Space Shuttle. NASA SO-8057, NASA Space Vehicle

Design Criteria.

23. Structural Strength Program Requirements. MSFC-HDBK-505, Revision A, January 1981.

24. Fracture Control Program Requirements. MSFC-HDBK-1453, October 1987.

25. Metallic Materials and Elements of Aerospace Vehicle Structures. MIL-HDBK-5.

26. Plastics for Flight Vehicles. MIL-HDBK-17.

27. Structural Sandwich Composites. MIL-HDBK-23.

28. Fracture Control Guideline for Aircraft Structures. MIL-STD-1530.

29. MSFC Astronautic Structures Manual. 3 Volumes, NASA TMX-73305, TMX-73306, and TMX73307.

30. Material and Process Control. MSFC-STD-506.

Li!

31. Design Criteria for Controlling Stress Corrosion Cracking. MSFC-SPEC-522A.

32. Solid Rocket Motor Metal Cases. SP-8025.

33. Fracture Control of Metallic Pressure Vessels. SP-8040.

34. Design-Development Testing. SP-8043.

35. Qualification Testing. SP-8044.

36. Acceptance Testing. SP-8045.

37. Structural Design Criteria Applicable to a Space Shuttle. SP-8057.

38. Stress-Corrosion Cracking in Metals. SP-8082.

39. Discontinuity Stresses in Metallic Pressure Vessels. SP-8083.

9O
," i _ I

i_ _ i

.i!!_

, !

40. Preliminary Criteria for the Fracture Control of Space Shuttle Structures. SP-8095.

41. Vibration, Acoustic, and Shock Design and Test Criteria. NASA RP-1127, September 1984.

42. Ranftl, Robert M.: R&D Productivity, Second Edition. Robert Ranftl, Los Angeles, California,

1978.

43. Design and Verification Guidelines for Vibroacoustics and Transient Environments. NASA TM86538, March 1986.

44. Peters, Tom: Thriving on Chaos, Handbook for a Management Revolution. Alfred A. Knoff, New

York, New York, 1947.

45. Drucker, Peter F.: The Practice of Management. Perennial Library, Harper and Row, New York,

New York, 1954, 1982.

46. Drucker, Peter F.: Managing for Results. Perennial Library, Harper and Row, New York, New

York, 1964, 1986.

47. Drucker, Peter F.: The Frontiers of Management. Perennial Library, Harper and Row, New York,

New York, 1986.

48. Peters, Tom, and Austin, Nancy: A Passion for Excellence. Warner Books, New York, New York,

1985, 1986.

49. Peters, Tom, and Waterman, Robert H., Jr.: In Search of Excellence. Warner Books, New York,

New York.

50. Nightingale, Earl: Direct Line Tapes 1 through 18. Nightingale-Conant Corporation, Chicago,

Illinois, 1973.

51. Augustine, Norman C.: Augustine's Laws. AIAA, New York, New York, 1983.

52. Osgood, Carl C.: Fatigue Design, Second Edition. Pergamon Press, Maxwell House, Fairview

Park, Elmsfield, New York.

53. Beltran, Edward: Mathematics for Dynamic Modeling. Academic Press, Inc., Boston,

Massachusetts, 1987.

54. Lewallen, Patrick E.: Space Shuttle Main Engine Vibration Data Base. NASA TM-86576,

December 1986.

55. Ryan, Robert S.: Structural Margins Assessment Approach. NASA TM-100332, June 1988.

56. Hirsch, E. D., Jr.: Cultural Literacy, What Every American Needs to Know. Vintage Books, New

York, 1988.

91
_i i _
1. REPORT NO. 12,

NASA TP-2893 I

4. TITLE AND SUBTITLE

7.

9°

Practices in Adequate Structural Design

AUTHOR{S)

Robert S. Ryan

PERFORMINGORGANIZATIONNAMEANDADDRESS

George C. Marshall Space Flight Center

Marshall Space Flight Center, Alabama

_J_I61LITI

GOVERNMENT ACCESSION NO. 3. RECIPIENT'S CATALOG NO.

35812

12. SPONSORINGAGENCY NAME AND ADDRESS

National Aeronautics and Space Administration

Washington, D.C. 20546

5. REPORT DATE

January 1989

6. PERFORMING ORGANIZATION CODE

8_ PERFORMING ORGANIZATION REPOR

10. WORK UNIT NO.

M-606

I. CONTRACTOR GRANT NO.

13. TYPE OF REPOR'," & PERIOD COVE

Technical Paper

14. SPONSORING AGENCY CODE

15. SUPPLEMENTARYNOTES

Prepared by Structures and Dynamics Laboratory, Science and Engineering Directorate.

16. ABSTRACT

Structural design and verification of space vehicles and space systems is a very tricky and awe

inspiring business, particularly for manned missions. Failures in the missions with loss of life is devastating personally and nationally. The scope of the problem is driven by high performance requirements

which push state-of-the-art technologies, creating high sensitivities to small variations and uncertainties.

Insurance of safe, reliable flight dictates the use of sound principles, procedures, analysis, testing, etc.

This paper deals with many of those principles which have been refocused by the Space Shuttle Challenger (51 -L) accident on January 26, 1986, and the activities conducted to insure safe shuttle reflights. The

emphasis will be focused on engineering, while recognizing that project and project management are also

key to success.

17. KE_ WORDS

Structural Design

Verification

Loads

Stress

Materials

Testing

19. SECURITY CLASSIF, (of tht= rep_t_

18. DISTRIBUTION STATEMENT

Unclassified - Unlimited

Subject Category 15

Unclassified

MSFC - Fo_'m 3292 (Rev. December 1972) For sale by National Technical Information Service, Springfield, Virginia 22 ]

NASA-Langley,