National Aeronautics and Space Administration Genesis Mishap Investigation

National Aeronautics and Space Administration Genesis Mishap Investigation and Stardust Entry Dr. Mike “Riskyswitch” Ryschkewitsch Pete Spidaliere www. nasa. gov

National Aeronautics and Space Administration Spacecraft Overview 636 kg wet 6. 8 m tip-to-tip 2. 0 m wide 225 kg 1. 5 m diameter 1. 0 m tall www. nasa. gov

National Aeronautics and Space Administration Trajectory Genesis Mission Trajectory: 2001 - 2004 Return Phase/L 2 Loop 07/22/04 : E-48 d L+1079 d www. nasa. gov

National Aeronautics and Space Administration What Was Supposed to Happen? www. nasa. gov

National Aeronautics and Space Administration What Did Happen? www. nasa. gov

National Aeronautics and Space Administration Why Did It Happen? www. nasa. gov

National Aeronautics and Space Administration Entry, Descent and Mid-Air Capture TCM-11 E-52 H TCM-12 E-28 H Contingency Earliest STRATCOM (Altair) ~E-4: 14, ~60, 000 km SRC Entry SRC Separation E-4 H E=0 H (09: 53 MDT, 15: 53 UTC) V = 11 km/s FPA=-8. 0° Nom. STRATCOM (Altair) ~E-1: 40, ~32, 000 km Nom. End STRATCOM (Beale) ALTITUDE Earliest UTTR Radar Acquisition ~E+1. 5 m, ~60 km Over UTTR Airspace ~E+1. 6 m, ~43 km SYSTEM X 125 km Atmospher e Drogue Deploy E+2. 2 m, 33 km Nominal UTTR Radar Acquisition ~E+3. 5 m ~22 km Parafoil Deploy E+6. 5 m, 6. 7 km Helicopter Intercept SRC E+18 m, 2. 8 km Begin 1 st Helicopter Pass E+19 m, 2. 5 km 5 th Helicopter Pass (if required) E+23 m, 1. 4 km www. nasa. gov DOWNRANGE To MAAF Intermediate Landing

National Aeronautics and Space Administration Entry Loads and Events Genesis EDL Using REF 08 Return, Time-Based 30 Deceleration (g's) 25 20 Peak Heating Cut Cable to Drogue at 87 sec 15 Timer Activated 10 Circuits Armed Main Deploy At 260 sec Drogue Deploy At 5. 6 sec Power UHF/GPS At 261 sec 5 3 0 -300 Sensible Atmos -100 300 500 700 Time from Entry Interface (sec) www. nasa. gov 900 1100

National Aeronautics and Space Administration G-Switch Functional Block Diagram Avionics Unit 1 Online G Switch 1 Low Pass Filter 1 Timer 2 And Depass. G Switch 2 Low Pass Filter 2 Timer 1 A 1 Press xducer SRC Batt 1 Pyros 5 places Enable Plug Avionics Unit 2 Online G Switch 1 Low Pass Filter 1 Timer 1 B 1 SRC Batt 2 www. nasa. gov Press xducer And Depass. G Switch 2 A Low Pass Filter 2 Timer 2 B

National Aeronautics and Space Administration G-Switch X-ray www. nasa. gov

National Aeronautics and Space Administration G-Switch Orientation Acceleration Vector Required for G-Switch to Function Mounting Base of AU www. nasa. gov Switches were Reversed! Heatshield Actual Aerodynamic Braking Force Direction

National Aeronautics and Space Administration How Did It Happen? www. nasa. gov

National Aeronautics and Space Administration The String of Events • Schematic copied from Stardust • Box CDR lacked technical content • Verification requirements not clear – Centrifuge test expected (in CDR package), but not required. Verification matrix had test, but no detail – Systems Engineering did not have to sign off on Subsystem plans • Designer verified function (open/close) of switches; Systems Engineering believed orientation of switches were verified • Electrical designer incorrectly performed orientation verification via Mechanical drawing inspection • Red Team review assumed design was correct because it was a “heritage” design • Systems Engineering did not close the loop with the designer – Systems Engineering not required to review test result www. nasa. gov Breakdown • Heritage • Design Review Weakness • Systems Engineering Breakdown; Heritage • Design Review Weakness; Heritage • Systems Engineering Breakdown

National Aeronautics and Space Administration What Can We Do to Avoid This? www. nasa. gov

National Aeronautics and Space Administration Fix Agency-wide Systemic Problems • Strengthen the execution of Systems Engineering • Improve the Design Review Process • Treat Heritage Hardware Like a New Design www. nasa. gov

National Aeronautics and Space Administration Systems Engineering Peer Review • A small group of systems engineers serve as a peer review panel that will follow a mission throughout its life • Peer Review Panel responsibilities: – Provide guidance and share lessons learned • Peer review panel becomes a resource for that project – Recommend improvements • Address potential problems early – Ensure the practice of sound systems engineering • Provides consistency across multiple missions • Systems Engineering products are reviewed • Focus on documentation and data, not Power. Point charts • When to conduct reviews? – At appropriate project milestones and maturity of SE products • Project management gains insight and confidence into the mission’s progress through the review panel’s reports • Outcome: – Consistent, high-quality systems engineering deliverables – Highly competent systems engineers – Significant positive contribution to mission success www. nasa. gov

National Aeronautics and Space Administration Improved Design Reviews • Overall, a strong integrated process – Independent, closed loop – Depends critically on the reviewers • Experience, penetration, ability to offer constructive criticism – GPR 8700. 4 F - Integrated Independent Reviews • Process and requirements for how to do review – GSFC-STD-1001 - Criteria for Flight Project Critical Milestone Reviews • Content and “checklists” for systems level review – GPR 8700. 6 A - Engineering Peer Reviews • Process and requirements for how to do review • Milestone oriented reviews www. nasa. gov

National Aeronautics and Space Administration Improved Design Reviews • Efficacy of all reviews critically dependent on the reviewers – Experience, penetration, willingness to work, ability to offer constructive criticism • Engineering Milestone Peer Review are not a replacement for event driven tabletops • We don’t always get the same level of penetration when dealing with out-of-house, non-cost plus contracts • Flowdown to vendors is still an issue www. nasa. gov

National Aeronautics and Space Administration Heritage Hardware – Treat It Like a New Design Gold Rule (1. 11): All use of heritage flight hardware shall be fully qualified and verified for use in its new application. This qualification shall take into consideration necessary design modifications, changes to expected environments, and differences in operational use. Here is a New Gold Rule currently in review: Do not qualify by similarity - use the traditional verification methods of test, analysis, inspection, and demonstration instead of similarity. www. nasa. gov

National Aeronautics and Space Administration Heritage Hardware – Treat It Like a New Design For completeness sake, here is what GEVS says, 2. 2. 3 Qualification of Hardware by Similarity There are cases in which hardware qualified for one flight program is to be built and used on another program. Hardware that has been previously qualified may be considered qualified for use on a new program by showing that the hardware is sufficiently similar to the original hardware and that the previous qualification program has adequately enveloped the new mission environments. The details for performing this comparison should be defined by the project but as a minimum the following areas should be reviewed and documented: (1) Design and test requirements must be shown to envelope the original requirements. This should include a review of the test configuration and of all waivers and deviations that may have occurred during testing of the original hardware. (2) Manufacturing information shall be reviewed to determine if changes have been made that would invalidate the previous hardware qualification. This review should cover parts, materials, packaging techniques as well as changes to the assembly process or procedures. (3) Test experience with the previous flight build shall be reviewed to verify that no significant modifications were made to the hardware during testing to successfully complete the test program. Any significant change shall be identified and shown to be implemented on the current flight hardware. If the review of the above criteria shows that the hardware is of sufficiently similar design as the first build and that the previous test requirements envelope any new environmental requirements, then the hardware can be treated as qualified and need only to be subjected to acceptance level test requirements. The review of the hardware for similarity must be documented and included as part of the verification package. www. nasa. gov

National Aeronautics and Space Administration The Ground Incident www. nasa. gov

National Aeronautics and Space Administration Avoiding This in The Future Incident Command System • Incident Command System (ICS) defines a management process that provides for effective advance planning and training as well as effective command, control, and coordination of emergency response operations. – Designed initially in the 1970’s for emergency response operations, with modification the ICS may form an attractive model for Flight Operations. – As a result of the Genesis ground incident, the ICS was used by the Stardust mission, for both flight and ground recovery operations. • Centralized Command Authority • Planning, Nominal, and Contingency • Training, Nominal, and Contingency • Execution • As part of our continuous improvement process, GSFC Flight Operations should investigate the ICS model for applicability to our missions, particularly how it was implemented on Stardust. www. nasa. gov

National Aeronautics and Space Administration Stardust Recovery www. nasa. gov

National Aeronautics and Space Administration Stardust – Utah Landing www. nasa. gov

National Aeronautics and Space Administration Stardust G-Switches Success was not Guaranteed Specification: 3 G ± 0. 3 G Switches designed and installed properly, but spin test of spares showed a problem – none worked as expected each time. www. nasa. gov