Space Shuttle Integration Lessons Learned

8/2/2019 Space Shuttle Integration Lessons Learned

1/84

Space Shuttle IntegrationLessons Learned

Bo Bejmuk


2/84

2

8/31/2006

OUTLINE Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Day-of-Launch I-Loads Evolution Avionics Architecture Main Propulsion Software Lightning

Flight Instrumentation RCS Thrusters Materials and Processes Risk Management Operational Cost Drivers Margin Management Significance of Lessons Learned Other Applicable Lessons Learned

Zenit Derived Launch System Sea Launch Delta IV Separate Briefing

The Big Lesson

Lessons learned fromShuttle development &operations can reduce

Constellation life-cycle costand development schedule,and result in more reliable

and safer systems


3/84

3

8/31/2006

Introduction

Two types of Shuttle Program Lessons Learnedare addressed

Problems How they were resolved and theirapplicability to Ares I

Success Stories How they were achieved and theirapplicability to Ares I

Lessons Learned are presented at a fairly highlevel

Each can be expanded to any desired level of detail

Top-level Lessons Learned from Zenit DerivedLaunch Systems Sea Launch are included


4/84

4

8/31/2006




The Big Lesson



and safer systems


5/84

5

8/31/2006

System Integration Approach

Shuttle Integration included:

Configuration tradeoffs early in the development phase

Mated system analysis and testing

On the ground

In flight

Mated vehicle checkout requirements at the launch site

Post flight data analysis

Independent evaluation of all elements changes

Definition and verification of system interfaces and interface

parameters and associated documentation Integrated Hazard Analyses

Integrated vehicle configuration management


6/84

6

8/31/2006

System Integration Organization

NASA was the Systems Integrator

Boeing, (Rockwell) was the Systems Integrationcontractor

The importance of integration was not fully appreciatedafter the initial development phase

NASA revitalized System Integration twice during theShuttle Programs life

After the Challenger accident After the Columbia accident

Each time a strong leader was put in charge ofIntegration and the Integration resources wererevitalized


7/84

7

8/31/2006

System Integration Organization

(continued)Lesson

It appears that the strength of Integration leadership

is very important to the success of a program Integration should remain the watchful eye as the

Program evolves to an operational status

Continue flight data evaluation for the life of theProgram


8/84

8

8/31/2006

Shuttle System Definitions &

Corresponding Analyses

1) Shuttle on Groundand Liftoff

2) Post Liftoff Configuration 3) Boost Configuration

Liftoff Loads Ground Winds Liftoff Clearances Acoustics ET Pressurization Main Propulsion System Avionics Sequencing & Timing Electrical Power Integrated Hydraulics Software Requirements Integrated Checkout

Requirements

Winds Aloft High Q Loads Heating Aero & Plume Flutter & Buffet Acoustics SRB Separation

Control Stability & ControlAuthority

ET Pressurization & MPS Integrated Hydraulics Software Requirements POGO

High G Loads Heating Aero & Plume ET Pressurization & MPS Integrated Hydraulics Power Control Stability & Control

Authority POGO Software Requirements ET Separation

Evaluation of flight test results and the establishment of operationalboundaries for all flight phases


9/84

9

8/31/2006

Shuttle Elements

Ground Systems

Solid RocketBoosters (SRB)

External Tank

Shuttle System

Main Engines

Orbiter*

* Two cargo configurations analyzed 65K lbs and 0 lbs payloads

Solid RocketMotor (SRM)


10/84

10

8/31/2006

System Integration Support to Element

Designers NSTS-07700 consisted of a series of requirements

documents that were imposed on the elements System Integration analysis results were documented in

Induced Environments Data Books and used by elementdesigners Loads

Aerodynamics

Aeroheating Plume heating

Vibro acoustics

Separations Main propulsion

Other Technical panels were established early in the development

cycle to provide a forum for the smooth interchange ofinformation between system integration and element experts

The Systems Integration technical effort was iterative and

involved several Design Cycles


11/84

11

8/31/2006




The Big Lesson



and safer systems


12/84

12

8/31/2006

STS-1 SRB Ignition Overpressure (IOP)

Problem

SRB IOP measured at the vehicle exceeded the 3-sigma liftoffdesign environment

Accelerations measured on the wing, body flap, vertical tail, andcrew cabin exceeded predictions during the liftoff transient

Support struts for the Orbiters RCS oxidizer tank buckled

Post flight analysis revealed that water spray designed tosuppress SRB IOP was not directed at the source of IOP

Source of IOP was believed to be at the plume deflector

STS-1 data analysis showed the primary source located

immediately below the nozzle exit plane

Tomahawk ignition transient used for preflight characteristicswere very different from that of the SRB


13/84

13

8/31/2006

STS-1 SRB IOP (Continued)

Corrective Actions Solution to the SRB IOP was treated as a

constraint to STS-2

IOP Wave Committee organized withparticipation of the NASA and the contractors

A 6.4% model was modified to allow simulation ofsimultaneous ignitions of two SRBs with the firingof one motor only Add a splitter plate in the flame bucket

A new scaling relation was developed based onblast wave theory

A series of 6.4% scale model tests were conductedto evaluate various concepts of IOP suppression

schemes Final fixes

Redirected water spray for SRB IOP suppression

toward the source of SRB IOP (Figure 1) Installed water troughs in the SRB exhaust duct

Very significant IOP reduction was achieved (Fig. 2)


14/84

14

8/31/2006

Figure 1: STS-1 and STS-2 SRB IOP

Suppression Configuration

STS-2 ConfigurationSTS-1 Configuration

Water spray for STS-1was designed for IOPSource at flame deflector

Water spray atThe flame deflectorand side pipesalong the duct

Water spray at theside of duct deleted

Water spray atthe crest of theflame deflector

Water troughs cover theSRB duct inlet

100,000 GPM of waterinjected into the SRBexhaust beneaththe nozzle exit plane


15/84


16/84

16

8/31/2006

STS-1 SRB IOP (Continued)

Lessons

1. SRB Ignition is a powerful driver in liftoff environments

2. System Integration, responsible for liftoff environmentdefinition, accepted the Tomahawk ignition test as asufficient simulation of SRB ignition IOP Did not fullyappreciate the effect of the differences between the SRBand the Tomahawk ignition characteristics

3. SRB ignition transient for Ares I should benefit from postSTS-1 efforts on the Space Shuttle

MLP configuration should be evaluated to account for a singleSRB

If the SRB propellant shape or type is changed, the effect onIOP should be re-evaluated


17/84

17

8/31/2006

Ascent Aerodynamics

Problem Plume simulation used during the preflight wind tunnel test

program was not adequately implemented

Observed significant wing lift and vehicle lofting in STS-1 Measured strains showed negative structural margins

Under-predicted ascent base pressures (base drag over-predicted) Temperature effects were not modeled in cold jet plume

simulation parameters used during testingCorrective Actions The Post-flight tests using hot plume simulations improved

base and forebody pressure predictions The ascent trajectory was changed to a flight with a greater

negative angle of attack through High Q The negative angle reduced wing lift The negative angle had to be evaluated for Orbiter windows and

the ET side wall pressures


18/84

18

8/31/2006

Ascent Aerodynamics (continued)

Lesson Although the hot plume re-circulation effect is less

significant on an axis-symmetric vehicle, it shouldbe accounted for when defining pressure on thebase and aft portion of the vehicle


19/84

19

8/31/2006


Flight Instrumentation RCS Thrusters Materials and Processes Risk Management Operational Cost Drivers Margin Management

Significance of Lessons Learned Other Applicable Lessons Learned


The Big Lesson



and safer systems


20/84

20

8/31/2006

Structures

Problem

Throughout Shuttle development and the initial years ofoperations many costly structural modifications had to bemade to maintain the required 1.4 structural safety factor

The Shuttle structure was designed for a 1.4 safety factor with noadditional margin to accommodate changes occurring during thedevelopment phase

Corrective Actions

As mathematical models and definitions of the environmentsmatured, resulting changes required many hardware changesto eliminate areas of negative margin (below a 1.4 safety factor)

These hardware modifications were expensive and timeconsuming. Additionally, they increased workload at the launchsite

This tedious activity ensured safe flights and compliance with thesafety factor requirement, however it created a significant impacton Shuttle operations


21/84

21

8/31/2006

Structures (continued)Lessons

If development time is short, structural margin

management could be pursued to avoid costlyhardware changes as loads analyses mature

A suggested approach could be as follows:

Assign additional factor to be applied to the design loads forenvironments with the greatest uncertainties

For example, gravity and pressure loads could have a factor of1.0 but dynamic and aero loads could have a factor of 1.2

All factors would converge to 1.0 as a function of program

maturity

A method of structural margin management couldminimize costly hardware redesign, and program standdowns, but it may result in a somewhat heavier vehicle


22/84

22

8/31/2006

Structures - Aero Elasticity

Problem Flight data indicated a significantly higher buffet response of the

vertical tail and body flap during ascent (at transonic speeds) The importance of buffet loads was not fully appreciated in the early

Shuttle design (flutter was properly analyzed, safe boundaries wereestablished and stability was verified during flight)

Corrective Actions

Flight instrumentation and ascent photography were used tomeasure response in flight Ascent environments were updated to correspond to measured

response The body flap critical design case was entry (thank goodness), no

action was required since including buffet loads on ascent was stillenveloped by entry

The vertical tail had sufficient margin to accommodate increased buffet

loads


23/84

23

8/31/2006

Structures - Aero Elasticity (continued)

Lesson Even though the Ares I has a significantly simpler

configuration, transonic buffet, particularly for thebulbous shape, should be addressed in the early loadsanalyses and test programs


24/84

24

8/31/2006

Liftoff Loads Analyses

Problem

Shuttle liftoff (L/O) loads were very difficult to analyze

Configuration complexity

SRB Ignition Overpressure

Twang during the SSME thrust buildup

Vandenberg experience showed that loss of the MLP compliance significantlyincreased L/O loads

Flexible washers were planned to restore compliance and avoid vehicle redesign

ET/Orbiteraxial interface

SRB

Growth

H2 TankCompliance

Shuttle

MLP

Ares I

SRB growthloads aretransmitteddirectly to 2nd

stage potentiallycreating more

sever L/O loads

Common Shuttle/Ares I

SRB grows 0.9 duringignition

MLP deflectsdownward

Forward interfacetranslates upward

SRB growthloads aretransmitteddirectly toOrbiter thru H2Tank. H2 Tank

providessofteningcompliance


25/84

25

8/31/2006

Liftoff Loads Analyses (continued)

Corrective Actions SRB ignition delayed until the SRB bending moment (due to

SSME thrust buildup) was at zero Four independent support posts modeled in L/O

simulations Monte Carlo method was incorporated Ground wind restrictions were implemented

Lesson In spite of the relative configuration simplicity of the Ares I,

L/O loads may be a significant design issue due to direct

load path between the SRB and the upper stage


26/84

26

8/31/2006

Structural Dynamics Testing

Success Story

Carefully developed Ground Vibration Test (GVT) program identifiedand facilitated correction of math model errors and precluded criticalproblems in-flight and potentially costly hardware redesign

Disciplines benefiting from GVT included Loads, POGO, Flutter & FlightControl Analyses

Building Block Approach

Starting with element GVT

Ending with full scale mated test at MSFC

Scale Model GVT followed by full scale GVT The stiffening effects of the internal SRB chamber pressure were evaluated in a

scale GVT

Element GVTs

SRB L/O & Boost Phase, & Burnout

ET with various liquid levels Orbiter FREE-FREE & constrained at ET interface

Mated GVTs

Orbiter/ET Boost Phase

4 Body mated, L/O, High Q, & SRB Burnout


27/84

27

8/31/2006

Structural Dynamics Testing (Continued)

Lesson

Extensive investment into the Shuttle GVT Program can save

money on Ares I

Dynamic Characteristics of SRB Verified including:

Liftoff, High Q and burnout configurations

SRB/MLP Interface

Dynamic response at rate gyro locations

Dynamic interaction of SRB structure with visco-elastic propellant

The effect of chamber pressure of the SRB dynamic properties

Upper stage alone in Free-Free and constrained at SRBinterface configurations could be a sufficient and costeffective GVT for Ares I


28/84

28

8/31/2006

Conversion of Static Test Article (STA)

to the Flight OrbiterSuccess Story

The Orbiter STA was originally intended for Orbiter structure strength

demonstrations

Planned to be subjected to ultimate loads

Demonstration of 1.4 times limit load

Very difficult to simulate combined thermal and mechanical loads

Prior to test start, the decision was made to limit loading to limit plus loadlevel

Test article was not stressed beyond yield This test was supplemented by component testing to 1.4 times limit loads in areas

of low margin and sensitive joints

The Orbiter test article was treated as flight hardware (configuration management,problem dispositions)

Post test, the STA was converted to flight hardware and used as theChallengers airframe

Lesson

Thoughtful planning of the test hardware and transitioning it to flight status

could result in significant cost savings


29/84

29

8/31/2006

OUTLINE Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System

Day-of-Launch I-Loads Evolution Avionics Architecture Main Propulsion Software Lightning Flight Instrumentation RCS Thrusters Materials and Processes Risk Management Operational Cost Drivers Margin Management



The Big Lesson

Lessons learned from

Shuttle development &operations can reduce


and safer systems


30/84

30

8/31/2006

Ascent Flight Control System (FCS)

Problem

During Filament Wound Case SRB integrated vehicle analysisthe first structural mode was 1.7 Hz, compared to 2 Hz forbaseline vehicle

Strong coupling with LOX slosh mode created (FCS) inadequatestability margin after liftoff

Very difficult to filter out due to the proximity of frequencies forthe 1st bending, slosh and FCS closed loop modes

Corrective Action

The Program was cancelled, but the lesson remained

Lesson

Consider imposing minimum modal frequency on the launchvehicle to avoid coupling with slosh and control systemmodes

May require stiffness requirements (in addition to strengthrequirement) for Stage I/Stage II interface hardware


31/84

31

8/31/2006

Ascent Flight Control System (Continued)

Success Story

SRB rate gyros were incorporated into the Mated VerticalGround Vibration Test (MVGVT) test articles

Large rotations were measured at the locations of the gyrosin low frequency modes

Modal gains were large enough to cause potential loss ofvehicle due to FCS instability

Corrective action was simple

Stiffening the shelf on which gyros were installed

Lesson

Instrument every FCS sensor location preferably with flight-like sensors in future GVTs


32/84

32

8/31/2006

Ascent Flight Control System (Continued)

Success Story

Conservative approach used in slosh baffle implementation

STS-1 8 LO2 baffles

STS-17 4 LO2 baffles SLWT 3 LO2 baffles

Slosh baffles are easily removed, but difficult to add as theprogram matures

Lesson Retain a conservative approach for slosh baffle

implementation

Avoids redesign to increase slosh damping

Allows easy weight reduction as FCS stability is confirmed byflight data


33/84

33

8/31/2006





The Big Lesson




and safer systems


34/84

34

8/31/2006

Day-of-Launch I-Loads Update

(DOLILU) EvolutionProblem

The launch probability predictions for early Shuttle flights was lessthan 50%

More than half of the measured winds aloft violated the vehicles certifiedboundaries

Corrective Actions

System Integration led the evolution from a single ascent I-load,through seasonal I-loads, alternate I-loads, and finally arriving at

DOLILU

This process extended over a 10+ year period (Figure 3)

Concurrently the Program executed 3 load cycles (Integrated Vehicle

Baseline Characterization - IVBC) combined with hardware

modifications to expand vehicle certified envelopes (Figure 4) Current launch probability is well in excess of 95%

Lesson

Commit to a DOLILU approach during early development

Significantly improves margins


35/84

35

8/31/2006

Figure 3: Ascent Design Operations Evolution

1975 1985 1995 2005

50

0

100

Med

High

Low

Ope

rations

Overhea

d

Percen

to

fWin

ds

Violating

Cert

ifica

tion

(%)

AnnualSeasonal

MonthlyAlternate

Day-of-Launch

Lesson Learned: Reliance on Operations Processto Maintain Margin is Expensive

Certification Violations

Ascent OperationsOverhead

Fi 4 D f L h I L d E l ti


36/84

36

8/31/2006

Early FlightsSingle I-Loads

Present FlightsDOLILU

Qb

3-Hour Wind

Variation

DOLILU drives toward center of QaQbenvelope and reduces winds violation to < 5%

CertifiedEnvelope

Ares I can benefit by starting with DOLILU or Adaptive Ascent Guidance

Expanded CertifiedEnvelope

Over 50% of winds

violated certifiedenvelope

Annual WindVariation

Qa

Qb

Qa

Figure 4: Day-of-Launch I-Loads Evolution(10 years +)


37/84

37

8/31/2006





The Big Lesson




and safer systems


38/84

38

8/31/2006

Avionics ArchitectureProblem

Prevention of loss of vehicle/crew or mission due to avionicsfailures considering mission duration up to approximately 12 days

Actions

Dissimilar solutions (primary, backup and two fault tolerance inavionics hardware/software)

Establishment of SAIL Simulation of hardware/softwareinteraction

Four LRU Mid Value Select (MVS) implemented with appropriatecross strapping to ensure two fault tolerance

The Redundancy Scheme was required to be test verified

Two fault tolerance became an avionics system mainstay on the

Shuttle OrbiterLesson

The Orbiter system provided a reliable avionics system. For ashort duration, missions such as Ares I ascent suggested atradeoff to be performed between one and two fault tolerance.

Overall system reliability could be used in the evaluation.


39/84

39

8/31/2006

1st Stage (SRB)2nd StageSM

Avionics Architecture (Continued)

The Shuttle approach of two fault tolerance* was robust, but

may be excessive for a boost only vehicle. The overallsystem reliability (for example 0.999) should driveredundancy requirements.

* With some compromises

Orion

High TimeExposure

Low TimeExposure Trade off study suggested: One vs.

two fault tolerance on Booster A tailored level of fault tolerance

could emerge as the best solution

Establishing the Fault Tolerance Requirements is a PrimaryAvionics Cost Driver


40/84

40

8/31/2006





The Big Lesson




and safer systems

M i P l i


41/84

41

8/31/2006

Main Propulsion

Problem Pressure oscillations upstream of the SSME first

stage pumps were not fully appreciated and notincluded in the design environments

This caused inadequate design resulting in fatigue of theH2 temperature probe located 18 upstream of pump

Combined environments (vibroacoustics and pressureoscillations) also created fatigue cracks in the flowliners

Neither were protected by screens

Corrective Actions

Eliminated temperature probe and switched LCC toupstream manifold measurement impact 2 monthsProgram stand down

A massive analytical and test effort, resulting inpolishing flow liner slots, welding existing cracks andimplementing inspection after each mission impact

4 months Program stand downLesson

Based on Shuttle analytical and test experience,develop and incorporate pressure oscillations in theMain Propulsion System (MPS) hardware designenvironments

M i P l i ( ti d)


42/84

42

8/31/2006

Main Propulsion (continued)

Problem

Fill & drain valve shaft roller bearings failure in MainPropulsion Test Article (MPTA) spread debris throughout themain propulsion system.

System did not contain debris screens due to pressure dropconcerns.

Several other cases of debris were found in MPS during earlydevelopment phase

Corrective Actions

Pre-valve screens were implemented. However, locations ofthe screens were not optimal due to the existing hardwareconfiguration constraints

Lesson

Decision to protect engine inlet from debris using screensshould be made early in the MPS development


43/84

43

8/31/2006





The Big Lesson


Shuttle development &operations can reduceConstellation life-cycle costand development schedule,and result in more reliable

and safer systems


44/84

44

8/31/2006

Flight Software Shuttle Experience

Problem

Concern over reliability of flight software (generic failure)during critical phases of flight

Corrective Action

Both Primary and Backup Flight Software were baselined inthe early stages of development

Primary & Backup run independently on separate computers Backup was never engaged over the life of the Program and

software reliability has improved since the ShuttleDevelopment timeframe

Lesson For Ares I, Backup software is not recommended for ascent

flight. However, for Orion, it should be considered for crewescape.

Flight Software (Continued)


45/84

45

8/31/2006

Flight Software (Continued)Problem

Significant duplication of development andverification facilities on Shuttle

Examples include:

FSL, FCHL, SAIL (STS & GTS), SES, SMS,JAEL, KATS plus dozens of non-real-timeperformance verification tools

These facilities played an important role but,once established, their existence perpetuated

This created unnecessary cost drag on theProgram

Lesson

Manage Ground and Flight Software and

avionics facilities on the Ares I Program topreclude unnecessary proliferation andduplication

Force labs to terminate when their role is

finished


46/84

46

8/31/2006





The Big Lesson



and safer systems

Li ht i R i t


47/84

47

8/31/2006

Lightning Requirements

Problem

The Shuttle started with strict requirements

TPS could not be certified

Avionics were difficult

Corrective Actions

Decision was made to transition to operationalrestrictions

Field Mills & catenaries on ground

Cloud cover restrictions before launch

Years of unnecessary cost and effort prior todecision

Lesson

Starting with a fair weather vehicle may be acost effective approach

Some avionics hardening could be worthwhile

Crew escape should be considered for

hardening


48/84

48

8/31/2006





The Big Lesson



and safer systems

Flight Vehicle Instrumentation


49/84

49

8/31/2006

Flight Vehicle Instrumentation

Problem In spite of extensive analysis and testing, during the development phase,

the flight vehicle frequently does not behave as predicted, as was the

case with the Shuttle This could create a flight safety issue (Eg. SRB overpressure, aero

ascent anomaly) Incorrect models, incorrect definition of the environments, incorrect

assumptions

Corrective Action The Program implemented a basic development flight instrumentation

infrastructure Technical discipline experts stated their specific requirements late, after

the vehicles were built

Late definition of instrumentation created the necessity for aninvasive design and installation

Program reluctance to accommodate late requirements Finally limited instrumentation implemented over several flights of

Columbia Limited instrumentation was continued into the operations phase


50/84

50

8/31/2006

Flight Vehicle Instrumentation (continued)

Lesson Mandate design organizations to define requirements

for flight instrumentation concurrently with systemdesign

Emphasis of verification and addressing uncertaintiesmay result in easier implementation


51/84

51

8/31/2006





The Big Lesson



and safer systems


52/84

52

8/31/2006

RCS Thrusters

The Orbiter has two bipropellant RCS systems

Primary 870 lbs thrust used during

ascent from SRB separation through entry

Vernier 25 lbs thrust used on orbit for attitude adjustmentand maintenance

Only applicable lessons learned from the Primarythrusters will be discussed

Approximate thrust range of potential roll control Ares Ithrusters


53/84

53

8/31/2006

RCS Thrusters (Continued)

Problem

The fuel valve seat extrusion caused leakage, leading to fail-

off and deselect This was caused by a small oxidizer leak, which softened the

valve seat

Corrective Actions

Adopted thruster chamber purge

Developed a screening test and incorporated into the ATP

Tightened leakage requirements for oxidizer valves

Lesson

For the bi-prop system, avoid Teflon fuel valve contaminationwith the Oxidizer


54/84

54

8/31/2006

RCS Thrusters (Continued)Problem

Thrust chamber combustion instability

Acoustic resonance driven by high combustion chamber

pressure oscillations Caused by pressurant Helium bubbles in the fuel system

Corrective Actions

Combustion stability screening added to hot fire ATP (Helium

injection)

Incorporated wire wrap around combustion chamber to shutdown the thruster at the onset of burn through

Lesson

Avoid pressurant gas in the propellant if possible (eg. Usebladders)

Address combustion stability during the development andtest program


55/84

55

8/31/2006

RCS Thrusters (Continued)

Problem

Thruster Columbium injector intergranular cracking

Caused by residual stresses and inadequate rinsing of

pre-weld etchant, coupled with high temperature (~600Degrees F) insulation bake-out

Corrective Actions

Eliminated pre-weld etch for new build

Developed NDE to inspect for cracks at White SandsDepot and on vehicle

Lesson

Avoid processes or chemicals that would result withFluorine coming into contact with Columbium at

temperatures above 500 Degrees F

OUTLINE


56/84

56

8/31/2006


Day-of-Launch I-Loads Evolution Avionics Architecture Main Propulsion Software Lightning Flight Instrumentation

RCS Thrusters Materials and Processes Risk Management Operational Cost Drivers Margin Management Significance of Lessons Learned Other Applicable Lessons Learned


The Big Lesson



and safer systems

Materials and Processes


57/84

57

8/31/2006

Problem

Flexible metal hoses, many of them

Criticality 1, experienced damage,which caused leakage

Each Orbiter contains 208 flexible hoses

Ease of installation

Effective strain isolation

30 hoses were damaged and createdleaks over the Programs life

M t i l d P ( ti d)


58/84

58

8/31/2006

Materials and Processes (continued)

Corrective Actions

Educated workers on the vulnerability of flex hoses

Implemented inspection and replacement with spares andalso substituted with rigid lines whenever practicable

Could have caused Program stand down; was covered by theReturn to Flight schedule

Lesson

Try to avoid using metal flexible hoses, especially in hightraffic areas and incorporate hard protection wheneverpossible

Educate workers and visitors on the vulnerability of flexhoses from the Programs onset

OUTLINE


59/84

59

8/31/2006





The Big Lesson



and safer systems

Risk Management


60/84

60

8/31/2006

Problem Although risk was managed by good engineering practices, very

little formal risk classification and management was employed Probabilistic Risk Analysis (PRA) was rarely used on the Shuttle

Program

Distrust of the methodology, lack of suitable data, Apollo experience Frequently funds were expended pursuing corrective action for

extremely low probability threats no means to measureeffectiveness of a corrective action on the overall system reliabilityor safety

Corrective Actions A 5X5 matrix risk classification was implemented on the Shuttle

Program Up and down the organization, from individual technical disciplines to

the Program Manager (Figure 5) PRA implemented on several technical projects

Orbiter windows, debris, Kevlar Overwrapped tanks, MMOD

Response to CAIB criticism

Risk Management (continued)


61/84

61

8/31/2006

Risk Management (continued)

Lesson Formal risk management, including PRA, early in

development could produce many cost savingsfeatures such as: Ensuring that system reliability drives redundancy

requirements

Prioritizing safety and reliability enhancements Identifying highest value initiatives

Use competent PRA analysts Must have the data

PRA does not replace good engineering


62/84

OUTLINE


63/84

63

8/31/2006





The Big Lesson



and safer systems

Initial Naive Concept of Operations


64/84

64

8/31/2006

Initial Naive Concept of Operations

Operational Reality


65/84

65

8/31/2006

Operational Reality

NASA, KSC Photo, dated September 25, 1979, index number KSC-79PC-500

Operational Cost Drivers


66/84

66

8/31/2006

p

Problem

Insufficient definition of operational requirements duringdevelopment phase

Concentration on performance requirements but not on operationalconsiderations

Shuttle design organizations were not responsible for operational cost

Very few incentives for development contractors

Corrective Actions

Very labor intensive (high operational cost) vehicle was developedand put into operations

Lesson

Must have the Concept of Operations defined

Levy the requirements on contractors to support the Concept ofOperations

Must have continuity and integration between designers, groundoperations, and flight operations requirements during thedevelopmental phase

Operational Cost Drivers (Continued)


67/84

67

8/31/2006

Problem The cost of reusability of complex, multifunctional, aging vehicle

Every Orbiter function whether used or not on a given mission must

be verified and checked out prior to flight

Every function must also be monitored and failures managed to

avoid a catastrophic event Reusability of aging complex systems requires ever increasing

attention to maintain performance and safety

Complex paper system touched by too many organizationsgoverns every step of the operation

Early 1980s heritage

Only limited streamlining over the life of the Program

Lesson

Complexity creates flight operational cost

Minimize complexity Manual approach adds to operational cost

Automate

Realistically define operational life prior to development

OUTLINE


68/84

68

8/31/2006

Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Day-of-Launch I-Loads Evolution Avionics Architecture Main Propulsion Software Lightning Flight Instrumentation



The Big Lesson



and safer systems

Structural and Ascent Performance MarginManagement


69/84

69

8/31/2006

Management

Problem Unrealistic ascent performance requirements eliminated the

possibility of effective margin management DOD insisted on 32K lbs polar orbit capability

Equivalent to 65K lbs due East NASA needed DOD support of the Shuttle Program

Continuous pursuit of the elusive 65K lbs due East ascentcapability precluded the possibility of holding back somestructural margin to avoid costly redesign changes as Programdevelopment matured

Prior to performance enhancement program the Shuttle had anascent performance shortfall of ~10K lbs

Actions Taken

All priorities were subordinated to the quest for ascentperformance Very few features supported effective operations

Costly structural modifications to maintain the required factor ofsafety were made

Structural and Ascent Performance Margin


70/84

70

8/31/2006

g

Management (continued)Lesson Set realistic ascent performance requirements

Hold back some margin to be used for problem areas

Use factors on not well understood environments toprotect against costly design modifications as Programknowledge matures

Transition to operations should be made consistent with

vehicle operational capabilities imbedded in the design

OUTLINE


71/84

71

8/31/2006




The Big Lesson



and safer systems

Significance of Shuttle Lessons Learned

G t SRB IOP2-Fault Tolerant Margin Mgmt.


72/84

72

8/31/2006

Applica

bility

toA

res

I

1

2

3

4

5

1 2 3 4 5

Significance to ShuttleLess Greater

Less

Greater SRB IOPAvionics

Ops Cost Drivers

Engine Inlet

Screens

Ascent Aero

Anomaly

MPS Pressure

Oscillations

RCS Combustion

Instability

RCS Inter-granular

Cracking

Flex Hoses

Software

Reliability

Buffet

DOLILU

Liftoff Loads

g g

Risk Management

Lightening

Flex Modes

Effects on FCS

RCS Seat

Extrusion

S/W Verification

Facilities

Risk of Crew/Vehicle Loss

Risk to Cost/Schedule

Instrumentation

RGAs in GVT

GVTSTA as Flight

Article

Slosh Baffles

OUTLINE


73/84

73

8/31/2006




The Big Lesson



and safer systems

Launch Platform


74/84

74

8/31/2006

Courtesy of the Sea Launch Company

Assembly and Command Ship


75/84

75

8/31/2006


Launch


76/84

76

8/31/2006Courtesy of the Sea Launch Company

Sea Launch Zenit Derived Launch System


77/84

77

8/31/2006

Major integration of existing and newelements

Two stage Ukrainian Zenit

3rd stage Russian Block DM

New payload accommodation &composite fairing

Modified semi-submersible oil drilling

platform into a launch pad

New command and control and rocketassembly ship

System was built and brought to

operational state in less than 3.5 years

22 flights to date, 21 successful


Sea Launch Operations Integration of rocket stages


78/84

78

8/31/2006

and payload at home port inLong Beach, CA

Launches performed from the

Equator, 154 degrees west(south of Hawaii)

300405Totals

40

1405070

80

2005075

Americans

RussiansUkrainiansNorwegians

Launch

Team*

Ground Processing

Team

* Launch Team is a subset of the Ground Processing Team; GroundProcessing team members that are not required to participate in launch atsea are sent back to their companies and are off the Sea Launch payroll

Small Team performs ground checkout and launch


Lessons Learned from Sea Launch


79/84

79

8/31/2006

Zenit extremely automated launch vehicle

Very little interaction with crew during checkout, pre-launch, andflight

Single string accountability, no duplications of effort (tosome extent driven by export compliance restrictions)

Low operational cost benefited from original design criteriaof Zenit

Rollout to pad, fuel and launch in 90 minutes

Allows very little time for ground or flight crew involvement

Imposes requirements for automatic processes

OUTLINE


80/84

80

8/31/2006




The Big Lesson



and safer systems

The Big Lesson


81/84

81

8/31/2006

At least 2 critical design flaws existed in the flightsystem through design, testing and flight testing

Not detected or acknowledged as major problems

A gap existed between actual and perceived state ofvehicle robustness and safety

Although strong indications were present, neither thedesign nor the operations team identified the problem

The Big Lesson (continued)


82/84

82

8/31/2006

Big Lesson

WE WERE NOT AS SMART AS WE THOUGHT WE WERE!

Develop and maintain a strong integration team throughout theprogram life cycle

Empower integration to challenge the elements and program onissues of design flaws and interaction between the elements

Continuously monitor performance and safety throughout the transitionto operations and the operations phase

Integration and element engineering should be staffed with the bestin their fieldinquisitive by nature, respected by peers andmanagement, and who have the courage to take on the Programregarding issues

Transition to operations should be made consistent with vehicleoperational capabilities imbedded in the design


83/84

83

8/31/2006

BACK-UP

Seven Types of System Analyses will DefineInterstage Stiffness Requirements


84/84

84

8/31/2006

g q

1.) Response to Ground Winds

2.) Liftoff Loads and Clearances3.) Roll Control Authority

4.)Transonic Buffet

5.) FCS Flex Stability6.) High Q static Elastic Loads

7.) High Q Response to Gust

InterstageHardware

Documents

Space Shuttle Integration Lessons Learned