# Presentation: 264321

## Genesis Mishap Investigation and Stardust Entry

- Dr. Mike “Riskyswitch” Ryschkewitsch
- Pete Spidaliere

## 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**

## Trajectory

**Return Phase/L2 Loop**
**07/22/04 : E-48d**
**L+1079d**

- Genesis Mission Trajectory:  2001 - 2004

## What Was Supposed to Happen?

## Slide 5

## What Did Happen?

## Slide 7

## Why Did It Happen?

## Entry, Descent and Mid-Air Capture

**TCM-11**
**E-52H**

**SRC Separation**
**E-4H**

**TCM-12**
**E-28H**
**Contingency**

_**5th Helicopter Pass (if required)**_** ****E+23m, 1.4km**

**ALTITUDE**

**DOWNRANGE**

**125 km**
** ****Atmosphere**

_**Earliest UTTR Radar Acquisition**_** ~****E+1.5m, ~60km**

_**Drogue Deploy**_** ****E+2.2m, 33km**

_**Begin 1st Helicopter Pass**_** ****E+19m, 2.5km**

_**Parafoil Deploy**_** E+6.5m, 6.7km**

_**Nominal UTTR Radar Acquisition**_** ~****E+3.5m ~22km**

_**Helicopter Intercept SRC**_** ****E+18m, 2.8km**

_**Over UTTR Airspace **_**~E+1.6m, ~43km**

_**Earliest STRATCOM (Altair)**_** **
**~E-4:14, ~60,000km**

_**Nom. STRATCOM (Altair)**_** **
**~E-1:40, ~32,000km**

_**Nom. End STRATCOM (Beale)**_

_**Intermediate Landing**_

_**To MAAF**_

_**SYSTEM X**_

_**SRC Entry**_** **
**E=0H (09:53 MDT, 15:53 UTC)**
**V = 11 km/s **
**FPA=-8.0°**

## Entry Loads and Events

**Genesis EDL Using REF08 Return, Time-Based**

**  ****Sensible**
**Atmos**

**Circuits Armed      **

**Peak Heating  **

**  ****Main Deploy**
**At 260 sec **

- 0

- 5

- 10

- 15

- 20

- 25

- 30

- -300

- -100

- 100

- 300

- 500

- 700

- 900

- 1100

**Time from Entry Interface (sec)**

**Deceleration  (g's)**

- 3

**Drogue Deploy**
**At 5.6 sec      **

**Timer Activated      **

**  ****Cut Cable to Drogue at 87 sec **

**  ****Power UHF/GPS**
**At 261 sec **

## G-Switch Functional Block Diagram

**Avionics Unit 1**

- G
- Switch1

- G
- Switch2

- Timer2

- And

- G
- Switch1

- G
- Switch2

- Timer1

- And

**SRC Batt 1**

**SRC Batt 2**

**Avionics Unit 2**

**A2**

**A1**

**B1**

**B2**

**Online**

**Depass.**

**Online**

**Depass.**

- Low Pass
- Filter1

- Low Pass
- Filter2

- Low Pass
- Filter1

- Low Pass
- Filter2

- Press
- xducer

**Enable Plug**

- Pyros
- 5 places

- Timer1

- Timer2

**A**

**B**

- Press
- xducer

## G-Switch X-ray

## G-Switch Orientation

**Acceleration Vector **
**Required for **
**G-Switch to**
**Function**

**Actual **
**Aerodynamic**
**Braking **
**Force **
**Direction**

**Mounting Base of AU**

- Heatshield

**Switches**
**were **
**Reversed!**

## How Did It Happen?

## 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

- _Breakdown_
- Heritage
- Design Review Weakness
- Systems Engineering Breakdown; Heritage
- Systems Engineering Breakdown
- Systems Engineering Breakdown; Heritage
- Design Review Weakness; Heritage
- Systems Engineering Breakdown

## What Can We Do to Avoid This?

## Fix Agency-wide Systemic Problems

- Strengthen the execution of Systems Engineering
- Improve the Design Review Process
- Treat Heritage Hardware Like a New Design

## 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

## 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

## 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

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

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

## The Ground Incident

## Slide 24

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

## Stardust Recovery

## Stardust – Utah Landing

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