Genesis Mishap Investigation and Stardust Entry

1. Genesis Mishap Investigation and Stardust Entry Dr. Mike “Riskyswitch” Ryschkewitsch Pete Spidaliere

2. 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

3. Trajectory Genesis Mission Trajectory: 2001 - 2004 Return Phase/L2 Loop 07/22/04 : E-48d L+1079d

4. What Was Supposed to Happen?

6. What Did Happen?

8. Why Did It Happen?

9. Entry, Descent and Mid-Air Capture SRC Entry E=0H (09:53 MDT, 15:53 UTC) V = 11 km/s FPA=-8.0° TCM-11 E-52H TCM-12 E-28H Contingency SRC Separation E-4H Earliest STRATCOM (Altair) ~E-4:14, ~60,000km Nom. STRATCOM (Altair) ~E-1:40, ~32,000km 125 km Atmosphere Nom. End STRATCOM (Beale) Earliest UTTR Radar Acquisition ~E+1.5m, ~60km Over UTTR Airspace ~E+1.6m, ~43km SYSTEM X Drogue DeployE+2.2m, 33km ALTITUDE Nominal UTTR Radar Acquisition ~E+3.5m ~22km Parafoil Deploy E+6.5m, 6.7km Helicopter Intercept SRCE+18m, 2.8km To MAAF Begin 1st Helicopter PassE+19m, 2.5km 5th Helicopter Pass (if required)E+23m, 1.4km DOWNRANGE Intermediate Landing

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

11. G-Switch Functional Block Diagram Avionics Unit 1 G Switch1 Low Pass Filter1 Timer2 A2 Online And A1 G Switch2 Timer1 Low Pass Filter2 Depass. Press xducer A Pyros 5 places SRC Batt 1 Enable Plug Avionics Unit 2 B Press xducer Low Pass Filter1 G Switch1 Timer1 B1 Online And Depass. B2 G Switch2 Timer2 Low Pass Filter2 SRC Batt 2

12. G-Switch X-ray

13. G-Switch Orientation Acceleration Vector Required for G-Switch to Function Heatshield Actual Aerodynamic Braking Force Direction Switches were Reversed! Mounting Base of AU

14. How Did It Happen?

15. 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 Breakdown Heritage Design Review Weakness Systems Engineering Breakdown; Heritage Systems Engineering Breakdown Systems Engineering Breakdown; Heritage Design Review Weakness; Heritage Systems Engineering Breakdown The String of Events

16. What Can We Do to Avoid This?

17. Fix Agency-wide Systemic Problems • Strengthen the execution of Systems Engineering • Improve the Design Review Process • Treat Heritage Hardware Like a New Design

18. 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 PowerPoint 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

19. 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.4F - 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.6A - Engineering Peer Reviews • Process and requirements for how to do review • Milestone oriented reviews

20. 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

21. 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.

22. 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. 

23. The Ground Incident

25. 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.

26. Stardust Recovery

27. Stardust – Utah Landing

28. Stardust G-SwitchesSuccess 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.