Space Shuttle Integration

Lessons Learned

Bo Bejmuk

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
2 8/31/2006

Introduction
Two types of Shuttle Program Lessons Learned are addressed
Problems How they were resolved and their applicability to Ares I Success Stories How they were achieved and their applicability to Ares I

Lessons Learned are presented at a fairly high level

Each can be expanded to any desired level of detail

Top-level Lessons Learned from Zenit Derived Launch Systems Sea Launch are included
3 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
4 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
5 8/31/2006

System Integration Organization

NASA was the Systems Integrator Boeing, (Rockwell) was the Systems Integration contractor The importance of integration was not fully appreciated after the initial development phase NASA revitalized System Integration twice during the Shuttle Programs life After the Challenger accident After the Columbia accident Each time a strong leader was put in charge of Integration and the Integration resources were revitalized

6 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 the Program

7 8/31/2006

Shuttle System Definitions & Corresponding Analyses

1) Shuttle on Ground and Liftoff

2) Post Liftoff Configuration 3) Boost Configuration

Winds Aloft High Q Loads Heating Aero & Plume Flutter & Buffet Acoustics SRB Separation Control Stability & Control Authority 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

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

8/31/2006

Evaluation of flight test results and the establishment of operational boundaries for all flight phases

Shuttle Elements

External Tank

Shuttle System Main Engines

Ground Systems

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

8/31/2006

Solid Rocket Motor (SRM)

Solid Rocket Boosters (SRB)

9

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 element designers
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 of information between system integration and element experts The Systems Integration technical effort was iterative and involved several Design Cycles
8/31/2006

10

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
11 8/31/2006

STS-1 SRB Ignition Overpressure (IOP)

Problem SRB IOP measured at the vehicle exceeded the 3-sigma liftoff design environment
Accelerations measured on the wing, body flap, vertical tail, and crew cabin exceeded predictions during the liftoff transient Support struts for the Orbiters RCS oxidizer tank buckled

Post flight analysis revealed that water spray designed to suppress 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 characteristics were very different from that of the SRB
12 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 with participation of the NASA and the contractors A 6.4% model was modified to allow simulation of simultaneous ignitions of two SRBs with the firing of one motor only
Add a splitter plate in the flame bucket

A new scaling relation was developed based on blast wave theory A series of 6.4% scale model tests were conducted to 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)
8/31/2006

13

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

Water spray for STS-1 was designed for IOP Source at flame deflector 100,000 GPM of water injected into the SRB exhaust beneath the nozzle exit plane Water troughs cover the SRB duct inlet

Water spray at the crest of the flame deflector

Water spray at The flame deflector and side pipes along the duct

Water spray at the side of duct deleted

STS-1 Configuration
8/31/2006

STS-2 Configuration
14

Figure 2: An overall factor of 5 reduction for the primary IOP waves was achieved with the redesigned system prior to STS-2

15 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 environment definition, accepted the Tomahawk ignition test as a sufficient simulation of SRB ignition IOP Did not fully appreciate the effect of the differences between the SRB and the Tomahawk ignition characteristics 3. SRB ignition transient for Ares I should benefit from post STS-1 efforts on the Space Shuttle
MLP configuration should be evaluated to account for a single SRB If the SRB propellant shape or type is changed, the effect on IOP should be re-evaluated

16 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 overpredicted)

Temperature effects were not modeled in cold jet plume simulation parameters used during testing

Corrective 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
17 8/31/2006

Ascent Aerodynamics (continued)

Lesson Although the hot plume re-circulation effect is less significant on an axis-symmetric vehicle, it should be accounted for when defining pressure on the base and aft portion of the vehicle

18 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
19 8/31/2006

Structures
Problem Throughout Shuttle development and the initial years of operations many costly structural modifications had to be made to maintain the required 1.4 structural safety factor
The Shuttle structure was designed for a 1.4 safety factor with no additional margin to accommodate changes occurring during the development phase

Corrective Actions As mathematical models and definitions of the environments matured, resulting changes required many hardware changes to eliminate areas of negative margin (below a 1.4 safety factor)
These hardware modifications were expensive and time consuming. Additionally, they increased workload at the launch site This tedious activity ensured safe flights and compliance with the safety factor requirement, however it created a significant impact on Shuttle operations
20 8/31/2006

Structures (continued)
Lessons If development time is short, structural margin management could be pursued to avoid costly hardware changes as loads analyses mature
A suggested approach could be as follows:
Assign additional factor to be applied to the design loads for environments with the greatest uncertainties
For example, gravity and pressure loads could have a factor of 1.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 could minimize costly hardware redesign, and program stand downs, but it may result in a somewhat heavier vehicle
21 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 were established and stability was verified during flight)

Corrective Actions Flight instrumentation and ascent photography were used to measure 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 still enveloped by entry The vertical tail had sufficient margin to accommodate increased buffet loads
22 8/31/2006

Structures - Aero Elasticity (continued)

Lesson Even though the Ares I has a significantly simpler configuration, transonic buffet, particularly for the bulbous shape, should be addressed in the early loads analyses and test programs

23 8/31/2006

Liftoff Loads Analyses

Shuttle
SRB growth loads are transmitted directly to Orbiter thru H2 Tank. H2 Tank provides softening compliance H2 Tank Compliance

Common Shuttle/Ares I SRB grows 0.9 during ignition MLP deflects downward Forward interface translates upward

SRB growth loads are transmitted directly to 2nd stage potentially creating more sever L/O loads

SRB Growth

ET/Orbiter axial interface

MLP
Ares I

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 significantly increased L/O loads Flexible washers were planned to restore compliance and avoid vehicle redesign
8/31/2006

24

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

25 8/31/2006

Structural Dynamics Testing

Success Story Carefully developed Ground Vibration Test (GVT) program identified and facilitated correction of math model errors and precluded critical problems in-flight and potentially costly hardware redesign
Disciplines benefiting from GVT included Loads, POGO, Flutter & Flight Control 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
8/31/2006 26

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 SRB interface configurations could be a sufficient and cost effective GVT for Ares I
27 8/31/2006

Conversion of Static Test Article (STA) to the Flight Orbiter

Success 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 load level
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 the Challengers airframe Lesson Thoughtful planning of the test hardware and transitioning it to flight status could result in significant cost savings 28
8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
29 8/31/2006

Ascent Flight Control System (FCS)

Problem During Filament Wound Case SRB integrated vehicle analysis the first structural mode was 1.7 Hz, compared to 2 Hz for baseline vehicle
Strong coupling with LOX slosh mode created (FCS) inadequate stability margin after liftoff Very difficult to filter out due to the proximity of frequencies for the 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 launch vehicle to avoid coupling with slosh and control system modes
May require stiffness requirements (in addition to strength requirement) for Stage I/Stage II interface hardware
8/31/2006 30

Ascent Flight Control System (Continued)

Success Story SRB rate gyros were incorporated into the Mated Vertical Ground Vibration Test (MVGVT) test articles Large rotations were measured at the locations of the gyros in low frequency modes
Modal gains were large enough to cause potential loss of vehicle due to FCS instability Corrective action was simple
Stiffening the shelf on which gyros were installed

Lesson Instrument every FCS sensor location preferably with flightlike sensors in future GVTs

31 8/31/2006

Ascent Flight Control System (Continued)

Success Story Conservative approach used in slosh baffle implementation
STS-1 STS-17 SLWT 8 LO2 baffles 4 LO2 baffles 3 LO2 baffles

Slosh baffles are easily removed, but difficult to add as the program 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 by flight data

32 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
33 8/31/2006

Day-of-Launch I-Loads Update (DOLILU) Evolution

Problem The launch probability predictions for early Shuttle flights was less than 50%
More than half of the measured winds aloft violated the vehicles certified boundaries

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
8/31/2006 34

Figure 3: Ascent Design Operations Evolution

100 High

Lesson Learned:
Percent of Winds Violating Certification (%)

Reliance on Operations Process to Maintain Margin is Expensive

Ascent Operations Overhead 50 Med

Certification Violations 0 1975 Seasonal Annual

8/31/2006

Low 1985 Monthly 1995 Alternate Day-of-Launch 2005

35

Operations Overhead

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

Early Flights Single I-Loads
Qa
Over 50% of winds violated certified envelope

Present Flights DOLILU

Qa

Qb

Qb

Expanded Certified Envelope

3-Hour Wind Variation Certified Envelope Annual Wind Variation

DOLILU drives toward center of Qa Qb envelope and reduces winds violation to < 5%
36

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

8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
37 8/31/2006

Avionics Architecture
Problem Prevention of loss of vehicle/crew or mission due to avionics failures considering mission duration up to approximately 12 days Dissimilar solutions (primary, backup and two fault tolerance in avionics hardware/software) Establishment of SAIL Simulation of hardware/software interaction Four LRU Mid Value Select (MVS) implemented with appropriate cross 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 Orbiter The Orbiter system provided a reliable avionics system. For a short duration, missions such as Ares I ascent suggested a tradeoff to be performed between one and two fault tolerance. Overall system reliability could be used in the evaluation.

Actions

Lesson

38

8/31/2006

Avionics Architecture (Continued)

Establishing the Fault Tolerance Requirements is a Primary Avionics Cost Driver
Orion SM 2nd Stage 1st Stage (SRB)

High Time Exposure

Low Time Exposure Trade off study suggested: One vs. two fault tolerance on Booster A tailored level of fault tolerance could emerge as the best solution

The Shuttle approach of two fault tolerance* was robust, but may be excessive for a boost only vehicle. The overall system reliability (for example 0.999) should drive redundancy requirements.
* With some compromises
39 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
40 8/31/2006

Main Propulsion
Problem Pressure oscillations upstream of the SSME first stage pumps were not fully appreciated and not included in the design environments
This caused inadequate design resulting in fatigue of the H2 temperature probe located 18 upstream of pump Combined environments (vibroacoustics and pressure oscillations) also created fatigue cracks in the flow liners Neither were protected by screens

Corrective Actions Eliminated temperature probe and switched LCC to upstream manifold measurement impact 2 months Program stand down A massive analytical and test effort, resulting in polishing flow liner slots, welding existing cracks and implementing inspection after each mission impact 4 months Program stand down Based on Shuttle analytical and test experience, develop and incorporate pressure oscillations in the Main Propulsion System (MPS) hardware design environments
8/31/2006

Lesson

41

Main Propulsion (continued)

Problem Fill & drain valve shaft roller bearings failure in Main Propulsion Test Article (MPTA) spread debris throughout the main propulsion system. System did not contain debris screens due to pressure drop concerns. Several other cases of debris were found in MPS during early development phase Corrective Actions Pre-valve screens were implemented. However, locations of the screens were not optimal due to the existing hardware configuration constraints Lesson Decision to protect engine inlet from debris using screens should be made early in the MPS development
42 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
43 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 in the 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 Shuttle Development timeframe Lesson For Ares I, Backup software is not recommended for ascent flight. However, for Orion, it should be considered for crew escape.
44 8/31/2006

Flight Software (Continued)

Problem Significant duplication of development and verification facilities on Shuttle
Examples include:
FSL, FCHL, SAIL (STS & GTS), SES, SMS, JAEL, KATS plus dozens of non-real-time performance verification tools These facilities played an important role but, once established, their existence perpetuated This created unnecessary cost drag on the Program

Lesson Manage Ground and Flight Software and avionics facilities on the Ares I Program to preclude unnecessary proliferation and duplication
Force labs to terminate when their role is finished
8/31/2006 45

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
46 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 operational restrictions

Field Mills & catenaries on ground Cloud cover restrictions before launch

Years of unnecessary cost and effort prior to decision Starting with a fair weather vehicle may be a cost effective approach
Some avionics hardening could be worthwhile Crew escape should be considered for hardening
47

Lesson

8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
48 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 an invasive 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
49 8/31/2006

Flight Vehicle Instrumentation (continued)

Lesson Mandate design organizations to define requirements for flight instrumentation concurrently with system design Emphasis of verification and addressing uncertainties may result in easier implementation

50 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
51 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 adjustment and maintenance

Only applicable lessons learned from the Primary thrusters will be discussed
Approximate thrust range of potential roll control Ares I thrusters

52 8/31/2006

RCS Thrusters (Continued)

Problem The fuel valve seat extrusion caused leakage, leading to failoff 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 contamination with the Oxidizer
53 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 shut down the thruster at the onset of burn through Lesson Avoid pressurant gas in the propellant if possible (eg. Use bladders) Address combustion stability during the development and test program
8/31/2006 54

RCS Thrusters (Continued)

Problem
Thruster Columbium injector intergranular cracking Caused by residual stresses and inadequate rinsing of pre-weld etchant, coupled with high temperature (~600 Degrees F) insulation bake-out

Corrective Actions
Eliminated pre-weld etch for new build Developed NDE to inspect for cracks at White Sands Depot and on vehicle

Lesson
Avoid processes or chemicals that would result with Fluorine coming into contact with Columbium at temperatures above 500 Degrees F

55 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
56 8/31/2006

Materials and Processes

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 created leaks over the Programs life

57 8/31/2006

Materials and Processes (continued)

Corrective Actions Educated workers on the vulnerability of flex hoses Implemented inspection and replacement with spares and also substituted with rigid lines whenever practicable
Could have caused Program stand down; was covered by the Return to Flight schedule

Lesson Try to avoid using metal flexible hoses, especially in high traffic areas and incorporate hard protection whenever possible Educate workers and visitors on the vulnerability of flex hoses from the Programs onset

58 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
59 8/31/2006

Risk Management
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 measure effectiveness of a corrective action on the overall system reliability or 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

60 8/31/2006

Risk Management (continued)

Lesson Formal risk management, including PRA, early in development could produce many cost savings features 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

61 8/31/2006

Figure 5: Risk Rating Developed Since the Columbia Accident (Program View)
15 Redesign of FRCS Paper Covers Using Tyvek (Completed design/drawings) 18 Orbiter Processing Issues Hardware (Numerous processing issues at KSC) 22 Water Spray Boiler Freezing (Mitigation design in work, on-orbit testing planned) 23 MPS Surface Mounted GO2 Temp Sensor Mod (Complete design drawings/ MASR II database update) 28 Cold Plate Manufacturing Issues
8/31/2006

23

4 Likelihood

28

15

18

22

1
1 2 3 4 5

Consequence
62

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
63 8/31/2006

Initial Naive Concept of Operations

64 8/31/2006

Operational Reality

NASA, KSC Photo, dated September 25, 1979, index number KSC-79PC-500
8/31/2006

65

Operational Cost Drivers

Problem Insufficient definition of operational requirements during development phase
Concentration on performance requirements but not on operational considerations 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 developed and put into operations Lesson Must have the Concept of Operations defined Levy the requirements on contractors to support the Concept of Operations Must have continuity and integration between designers, ground operations, and flight operations requirements during the developmental phase
8/31/2006

66

Operational Cost Drivers (Continued)

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 organizations governs 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

67 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
68 8/31/2006

Structural and Ascent Performance Margin 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 ascent capability precluded the possibility of holding back some structural margin to avoid costly redesign changes as Program development matured Prior to performance enhancement program the Shuttle had an ascent performance shortfall of ~10K lbs Actions Taken All priorities were subordinated to the quest for ascent performance
Very few features supported effective operations Costly structural modifications to maintain the required factor of safety were made
8/31/2006 69

Structural and Ascent Performance Margin 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 to protect against costly design modifications as Program knowledge matures Transition to operations should be made consistent with vehicle operational capabilities imbedded in the design

70 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
71 8/31/2006

Significance of Shuttle Lessons Learned

Greater
2-Fault Tolerant Avionics Margin Mgmt. Instrumentation Risk Management RGAs in GVT S/W Verification Facilities Lightening Slosh Baffles Flex Modes Effects on FCS Ops Cost Drivers Engine Inlet Screens STA as Flight Article Ascent Aero Anomaly MPS Pressure Oscillations SRB IOP

5
Applicability to Ares I

Liftoff Loads GVT DOLILU Buffet Software Reliability

3
RCS Seat Extrusion

RCS Combustion Instability RCS Inter-granular Cracking Flex Hoses

2 1 1
Less

Less

Risk of Crew/Vehicle Loss Risk to Cost/Schedule

8/31/2006

4
Greater

5
72

Significance to Shuttle

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
73 8/31/2006

Launch Platform

Courtesy of the Sea Launch Company

8/31/2006

74

Assembly and Command Ship

Courtesy of the Sea Launch Company

75 8/31/2006

Launch

76 8/31/2006

Courtesy of the Sea Launch Company

Sea Launch Zenit Derived Launch System

Major integration of existing and new elements
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 rocket assembly ship
Courtesy of the Sea Launch Company

System was built and brought to operational state in less than 3.5 years
22 flights to date, 21 successful
77

8/31/2006

Sea Launch Operations

Integration of rocket stages and payload at home port in Long Beach, CA Launches performed from the Equator, 154 degrees west (south of Hawaii)
Courtesy of the Sea Launch Company

Small Team performs ground checkout and launch Ground Processing Team Americans Russians Ukrainians Norwegians Totals 80 200 50 75 405 Launch Team* 40 140 50 70 300

* Launch Team is a subset of the Ground Processing Team; Ground Processing team members that are not required to participate in launch at sea are sent back to their companies and are off the Sea Launch payroll
8/31/2006

78

Lessons Learned from Sea Launch

Zenit extremely automated launch vehicle
Very little interaction with crew during checkout, pre-launch, and flight

Single string accountability, no duplications of effort (to some extent driven by export compliance restrictions) Low operational cost benefited from original design criteria of 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

79 8/31/2006

OUTLINE
Introduction System Integration Approach Liftoff and Ascent Aerodynamics Structures Ascent Flight Control System Lessons learned from Day-of-Launch I-Loads Evolution Shuttle development & Avionics Architecture operations can reduce Main Propulsion Constellation life-cycle cost Software and development schedule, Lightning and result in more reliable Flight Instrumentation and safer systems 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
80 8/31/2006

The Big Lesson

The Big Lesson

At least 2 critical design flaws existed in the flight system through design, testing and flight testing
Not detected or acknowledged as major problems

A gap existed between actual and perceived state of vehicle robustness and safety Although strong indications were present, neither the design nor the operations team identified the problem

81 8/31/2006

The Big Lesson (continued)

Big Lesson
WE WERE NOT AS SMART AS WE THOUGHT WE WERE! Develop and maintain a strong integration team throughout the program life cycle Empower integration to challenge the elements and program on issues of design flaws and interaction between the elements
Continuously monitor performance and safety throughout the transition to operations and the operations phase

Integration and element engineering should be staffed with the best in their fieldinquisitive by nature, respected by peers and management, and who have the courage to take on the Program regarding issues Transition to operations should be made consistent with vehicle operational capabilities imbedded in the design

82 8/31/2006

BACK-UP

83 8/31/2006

Seven Types of System Analyses will Define Interstage Stiffness Requirements

1.) Response to Ground Winds 2.) Liftoff Loads and Clearances 3.) Roll Control Authority 4.)Transonic Buffet
Interstage Hardware

5.) FCS Flex Stability 6.) High Q static Elastic Loads 7.) High Q Response to Gust

84 8/31/2006