National Aeronautics and Space Administration

G E N E S I S

Mishap Investigation Board Repo

Volum
Trade names or manufacturers’ names are used in this report for identification only. 

This usage does not constitute an official endorsement, either expressed or implied, 

by the National Aeronautics and Space Administration.
Pa g e  Gen e s i s Mi s h

GENESIS Mi

Volume
GGe n e s e n e ii s Mii h a pp Re ppot Pa g ii ii 
Pa g e ii iii GGe ne s e 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa ge iviv 
Pa g e Ge n e s en e s 
Ge n e si s Mi s h ap Re por t P g e ii
Pa g e ii Ge n e s i s M

VolumeI Conten

Signature Page (Board Members)........................................................................v

Advisors, Consultants, and JPL Failure Review Board Members.................... vii

Acknowledgements.............................................................................................ix

Executive Summary.............................................................................................1

1. Summary of Genesis Project.........................................................................5

2. Mishap Description -- Sequence of Events and Timeline...........................16

3. Method of Investigation ..............................................................................18

4. Proximate Cause..........................................................................................23

5. Root Causes and Contributing Factors........................................................28

6. Recommendations.......................................................................................41

7. Other Observations and Recommendations................................................52

8. Stardust Mission Recommendations...........................................................59

9. Nomenclature and Dictionary .....................................................................65

10. References...................................................................................................81

Appendices:

Appendix A:Letter Establishing the

Genesis Mishap Investigation Board ......................................... A-1

Appendix B:Genesis Project Description, narrative........................................B-5

Appendix C:Fault Tree: Process and Diagram .............................................C-21

Appendix D:Analyses and Studies ............................................................... D-29

Appendix E: Root Cause and Contributing Factor Narrative;

Event and Causal Factor Tree.................................................E-209

Appendix F:JPL Failure Review Board Report........................................... F-259

Appendix G:Contractors Supporting the Genesis MIB.............................. G-261

Appendix H:Meeting Minutes.................................................................... H-263

Appendix I:Press Releases............................................................................I-323

Appendix J:Bibliography..............................................................................J-333
Ge n e si s Mi s h ap Re por t P g e iv 
Pa g e e n e s i s Mi s

Signature Page (Board M

Dr. Michael Ryschkewitsch, Chairman

Director, Applied Engineering & Technology 

Directorate

NASA Goddard Space Flight Center, 

Greenbelt, MD

Peter Spidaliere

Executive Secretary

NASA Johnson Space Flight Center, Houston, TX

Patrick Martin

Ex-Officio

Office of Safety and Mission Assurance

NASA Headquarters, Washington, DC

Frank Bauer

Systems Engineering

NASA Goddard Space Flight Center, 

Greenbelt, MD

Col. Michael Coolidge

Air Force Space Command

Department of Defense

Marlon Enciso

Head, Electrical Systems Branch

NASA Goddard Space Flight Center, 

Greenbelt, MD

Thomas Gates

Materials/Structures

NASA Langley Research Center, Hampton, VA

Patricia Jones

Human Factors

NASA Ames Research Center, Moffett Field, CA

Steven Labbe

Aerodynamics

NASA Johnson Space Center, Houston, TX

Melvin Lucy

Senior Engineer, Systems Engineering Directorate

NASA Langley Research Center, Hampton, VA

Stacey Nakamura

Chief, Safety & Test Operations Division

NASA Johnson Space Center, Houston, TX

John Ormsby

Avionics

NASA Marshall Space Flight Center, 

Huntsville, AL

Jenny Stein

Parachute Systems

Exploration Systems Engineering Division

NASA Johnson Space Center, Houston, TX

James VanLaak

Systems Engineering

NASA Langley Research Center, Hampton, VA

Maj., (USAF Retired) Melba Weatherford

Headquarters Air Force Safety Center

Department of Defense
Ge n e si s Mi s h ap Re por t P g e vi
Pa g e vi Ge n e s i s M

Advisors and Consult

Mishap Investigation Board Advisors:

Clint Crookshanks National Transportation Safety Board

Robert Kichak Goddard Space Flight Center, Greenbelt, MD

Karen McNamara Johnson Space Center, Houston, TX

Catherine White Marshall Space Flight Center, Huntsville, AL

Mishap Investigation Board Consultants:

Lt. Gen. Edward Berry USAF, Retired

Dennis Deel Lockheed Martin Space Systems, Denver, CO

Charles Holloway Dynacs MDI

Yvonne Kellogg Dryden Flight Research Center, Edwards, CA 

John Kline Jet Propulsion Laboratory, Pasadena, CA

Patrick O’Rear Johnson Space Center, Houston, TX

Nicholas Smith Lockheed Martin Space Systems, Denver, CO

Donald Sweetnam Jet Propulsion Laboratory, Pasadena, CA

Joseph Vellinga Lockheed Martin Space Systems, Denver, CO

Ronald Zellar Goddard Space Flight Center, Greenbelt, MD 

NASA Headquarters, Washington, DC:

Debbie Hollebeke Legislative Affairs

Don Savage Public Affairs

Daniel Thomas Legal Advisor

Robert Tucker External Relations
GGe n e s e n e ii s Mii h a pp Re ppot Pa g viii viii 

JPL Failure Review Board

Dr. John Klein Management /Power Systems JPL/Chair

Rob Manning Systems JPL/Deputy Chair

Arden Acord “System Test, V&V” JPL

Kirk Barrow Mission Assurance JPL

Ed Barry Project Management USAF Ret.

Steven Battel Space Engineering Private Consultant

Jerry Dalton Electronics Reliability /Circuit Analysis JPL

Jim Donaldson Avionics Systems JPL

Wayne Lee Entry Systems JPL

Dave Perkins Systems LMSS

Tom Rivellini Mechanical Systems JPL

Joe Savino Avionics and Power Systems JPL

Rao Surampudi Batteries JPL

Mark Underwood Battery/Power Systems JPL

JPL Failure Review Boad Support Team

George Carlisle Navigation JPL Genesis Navigation

Prasun Desai Entry Systems LaRC Genesis

Ed Hirst Systems Engineering JPL Genesis Mission Manager

Bob Kerr Process Engineering JPL

George Lewis Navigation JPL Genesis Navigation

Nora Mainland Ops/Data Control JPL Genesis MOS

Bob Mitcheltree Entry/Descent Systems JPL

Tom Spilker Physics JPL Genesis

Don Sweetnum JPL Genesis Project Manager

Christine Szalai Entry/Descent Systems JPL

Tom Wahl Systems Engineering JPL Genesis

Bill Wilcockson Entry Systems LMSS

Other JPL and LMSS Contacts

Robert Berry LMSS Management LMSS

Jim Crocker LMSS Management LMSS

Gentry Lee Guru JPL

David Perkins Genesis Engineering LMSS

Mark Underwood Batteries JPL

Joe Vellinga Genesis Project LMSS
Pa g e ii x GGe ne s e 

Acknowledgeme

The Mishap Investigation Board would like to acknowledge the support of a number of groups and individuals who contributed to completing the investigation in an 

effective and timely manner. 

A special commendation goes to the Genesis Project Team who functioned as an 

Interim Response Team in performing the initial recovery and securing of the 

crashed sample return capsule. Their timely and quality response not only preserved the critical hardware for MIB examination but more importantly, provided 

the opportunity for the Mission Curation and Science Teams to preserve and process the scientific samples. Recent reports indicate that most or all of the science 

goals of the mission will be achieved. In addition, early collection of detailed 

notes from each member present at the crash site were invaluable in reconstructing 

the post-recovery timelines. 

The MIB received exemplary support from many members of the Genesis Project 

Team from Lockheed Martin Space Systems and from the Jet Propulsion Lab. The 

personnel from both organizations and their respective line management cooperated fully and proactively supported the MIB in doing its work. It was clear 

that everyone on both teams had been strongly personally committed to achieving 

Genesis mission success and that the crash was a strong personal blow to each one. 

Each and every team member contacted by the MIB was completely open and tried 

in every way to help reconstruct events over the life of the Genesis mission. It was 

clear that people involved felt personally responsible for the failures but, despite 

significant emotional stress, participated with a high degree of professionalism. Of 

special mention are Joe Villenga, Nick Smith, Dave Perkins and Al McKinney of 

LMSS and Don Sweetnam, Tom Wahl and Ed Hirst of JPL. Each of these people 

did everything possible to help the Board and in every way worked to make sure 

that the best possible knowledge was gained from the investigation. 

The Jet Propulsion Laboratory convened an internal Failure Review Board which 

operated in parallel with the NASA MIB. This team cooperated fully with and 

provided additional support for the MIB in many ways. Mark Underwood and 

Jerry Dalton made particularly strong contributions in the battery and avionics 

investigations respectively and the Board is indebted for their expertise and their 

dedication. Of special mention are John Klein, the FRB Chairman and Gen. Ed 

Barry for their overall insights and work in investigating the team and developmental history of the Genesis Project and Rob Manning for his systems engineering 

and design insights and for his strong leadership in building a free flow of information between the project and the JPL FRB. 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa e 

Mr. Pat Martin and Ms Faith Chandler of the NASA Headquaters Office of Safety 

and Mission Assurance provided invaluable help and guidance in keeping the investigation focused and in helping to organize the results in the clearest possible way. 

Mr. Don Savage was of great help in preparing and supporting the public release 

of information. The NASA Engineering and Safety Center provided invaluable 

assistance to the investigation, both in supplying key personnel and in supporting 

the transfer of funding to allow a quick start-up of the investigation. The US Air 

Force provided excellent support to the investigation both in providing two members to the Board as well as through the staff at the Utah Training and Test Range. 

The National Transportation Safety Board provided irreplaceable expertise and 

support to the Board in the person of Clint Crookshanks. His advice allowed early 

and timely action to be taken by the Board at the crash site, greatly expediting the 

investigation and minimizing the impact of the investigation on the preservation of 

the science payload. 

Ms. Yvonne Kellogg of the NASA Headquarters Office of the Chief Engineer had the challenging job of translating engineering language into clear 

English. The readability of the final report is due to her efforts. Any remaining 

issues are areas in which she was not able to convince the engineers to mend their 

ways. Mr. Ron Zellar and Mr. Pat O’Rear served as advisors to the MIB. They 

provided excellent technical support as well as handling a great deal of the coordination of activities and the organization of information to allow the Board to do 

its work. Without them, the work of the Board would have been a great deal more 

difficult to bring to completion. Chuck Holloway served as our quality assurance 

lead for all of the hardware investigations at the LMSS in Denver. He did an admirable job of keeping everyone on the straight and narrow in dealing with the Genesis hardware and in documenting our results. Last but certainly not least, Peter 

Spidaliere and Stacey Nakamura stand out as the chief stewards for Volumes I and 

II of this report respectively. They also led the interview and analysis processes 

necessary for understanding “how” the mishap occurred. The rest of the Board 

members are indebted to them.
Pa g e   GGe e s e n es ii s

Executive

Genesis was one of NASA’s Discovery missions, and its purpose was to collect 

samples of solar wind and return them to Earth. The Jet Propulsion Laboratory 

was the managing Center; the California Institute of Technology was designated 

the principal investigator and project team leader. Los Alamos National Laboratory provided the science instruments, and Lockheed Martin Corporation (acting 

through its Lockheed Martin Space Systems company) was the industrial partner 

and provided the spacecraft and sample return capsule. The Jet Propulsion Laboratory and Lockheed Martin Astronautics conducted mission operations. 

Launched on August 8, 2001, Genesis was to provide fundamental data to help 

scientists understand the formation of our solar system. Analysis of solar materials 

collected and returned to Earth will give precise data on the chemical and isotopic 

composition of the solar wind. 

On September 8, 2004 the Genesis sample return capsule drogue parachute did not 

deploy during entry, descent, and landing operations over the Utah Test and Training Range. The drogue parachute was intended to slow the capsule and provide 

stability during transonic flight. After the point of expected drogue deployment, 

the sample return capsule began to tumble and impacted the Test Range at 9:58:52 

MDT, at which point vehicle safing and recovery operations began. Section 2.0 

provides a description of the mishap.

On September 10, 2004, the Associate Administrator for the Science Mission 

Directorate established a Type A Mishap Investigation Board as defined by NASA 

Procedural Requirements 8621.1A, NASA Procedural Requirements for Mishap 

Reporting, Investigating, and Recordkeeping, to determine the cause and potential 

lessons from the incident. The Board was chartered to determine the proximate 

cause of the failure, identify the root causes, and develop recommendations to 

strengthen processes within NASA’s Science Mission Directorate to avoid similar 

incidents in the future. Section 3.0 describes the method of investigation used by 

the Board.

Additionally, the Board was to determine the adequacy of contingency response 

planning and the appropriateness of the actual contingency response, to include the 

safing and securing of the spacecraft and the science payload, and the protection of 

response personnel. The results of this second inquiry are documented in Volume 

II of this report. 

The Board determined the proximate (or direct) cause of the mishap to be that the 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g   

G-switch sensors were in an inverted orientation, per an erroneous design, and 

were unable to sense sample return capsule deceleration during atmospheric entry 

and initiate parachute deployments. Section 4.0 describes the proximate cause and 

lists other candidates that the Board investigated.

The Board found that deficiencies in the following four pre-launch processes 

resulted in the mishap: 

• the design process inverted the G-switch sensor design;

• the design review process did not detect the design error;

• the verification process did not detect the design error; and

• the Red Team review process did not uncover the failure in the 

verification process.

The Board identified several root causes and major contributing factors that resulted 

in the design inversion of the G-switch sensors and the failures to detect it. The root 

causes and contributing factors fall into six categories, some of which contributed 

to more than one of the above process errors. Each category is briefly explained 

below and in more detail in Section 5.0. Recommendations to avoid future reoccurrences are provided in Section 6.0. 

• Inadequate Project and Systems Engineering Management. 

A lack of involvement by JPL Project Management and Systems Engineering in Lockheed Martin Space Systems spacecraft activities led to insufficient critical oversight that might have identified the key process errors 

that occurred at Lockheed Martin Space Systems during the design, review, 

and test of the spacecraft. This process was consistent with the Faster, Better, Cheaper philosophy of the time and approved of by the Discovery 

Program. 

• Inadequate Systems Engineering Processes. 

Multiple weaknesses within the Genesis Systems Engineering organization 

resulted in requirements and verification process issues that led to the failure. The 

Board recommends adding a thorough review of all project Systems Engineering 

progress, plans, and processes as part of existing major milestone reviews. This 

recommendation was written to enforce discipline and critical assessment in the 

Systems Engineering organizations of future projects. Recommendations regarding Systems Engineering also address the issues raised by the Inadequate Project 

and Systems Engineering Management root causes by compelling a commitment 

by Project Management to support an adequate Systems Engineering function.
Pa g e   GGe e s e n es ii s

• Inadequate Review Process. 

All levels of review, including the Genesis Red Team review, failed to detect the 

design or verification errors. It is the Board’s position that technical reviews have 

become too superficial and perfunctory to serve the needs of the Science Mission Directorate. The technical review recommendations in this mishap report 

are targeted at significantly strengthening the Science Mission Directorate review 

process beyond its current state. 

• Unfounded Confidence in Heritage Designs. 

Genesis Management and Systems Engineering and the Genesis Red Team made 

a number of errors because of their belief that the G-switch sensor circuitry was 

a heritage design. Further, the prevalent view that heritage designs required less 

scrutiny and were inherently more reliable than new designs led to the mishap. The 

Board addresses the systemic problem of inappropriate faith in heritage designs 

in the Science Mission Directorate by recommending review and verification of 

heritage designs to the same level expected of new hardware/software.

• Failure to ‘Test as You Fly.’ 

Several issues led to the lack of proper testing of the G-switch sensors, including 

a failure to treat the G-switches as sensors, which ultimately led to the mishap. 

The Board’s recommendations to strengthen the review process within the Science 

Mission Directorate will partially address this issue, as well as a recommendation 

to require a “test as you fly” plan and a “phasing test plan” for all Science Mission 

Directorate projects.

• Faster, Better, Cheaper Philosophy. 

As demonstrated by several failures, NASA’s use of the Faster, Better, Cheaper 

philosophy encouraged increased risk taking by the Projects to reduce costs. 

Although NASA Headquarters had solicited and selected Genesis under the Faster, 

Better, Cheaper paradigm, the way JPL chose to implement the Genesis Mission 

substantially reduced their insight of the technical progress of the project. This 

precluded them from ensuring that the Project was executed within the range of 

previously successful mission implementation practices, thereby adding additional 

risk. The Discovery Program Office accepted these arrangements implicitly by 

way of the selection and subsequent management review processes. 

The potential pitfalls of this approach became clear when the Mars Climate Orbiter 

and Mars Polar Lander missions failed. Although much has been done within 

Science Mission Directorate to correct Faster, Better, Cheaper issues, the Board 

recommends that when establishing appropriate levels of budgetary and schedule reserve that the Science Mission Directorate gives greater consideration to the 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g   

overall maturity; launch constraints (e.g., short window planetary vs. others), and 

complexity. 

Board members based several of the recommendations on their experience with 

on-going Science Mission Directorate Systems Engineering and technical review 

issues. The Board also considered previous failure investigations when generating 

several of the recommendations. Most of the recommendations center on improving the technical review process of new designs, heritage designs, and Systems 

Engineering. Instead of creating more reviews, the Board recommends establishing more effective reviews that identify requirements, design, verification, and 

process issues early to avoid costly overruns or tragic failures. 

It appears highly likely to the Board that due to the dedicated efforts of the Genesis 

Recovery and Curation Teams and the nature of the sample collection materials 

most of the Genesis science goals will be met. However, the Board believes that 

this fortunate outcome should not reduce the importance of the lessons learned 

from the Genesis mishap to future missions.

Other significant observations and recommendations not directly related to root 

causes or contributing factors are provided in Section 7.0. Recommendations of 

the Board regarding actions the Stardust Project should consider are provided in 

Section 8.0. 
Pa g e   GGe e s e n es ii s

1.0 Summ

the Genesis Pro

a. Mission Description

Genesis was the fifth in NASA’s series of Discovery missions, and the first U.S. 

mission since Apollo to return extraterrestrial material to Earth for study. The purpose of the mission was to collect samples of solar wind and return them to Earth. 

The California Institute of Technology (CIT) provided the principal investigator 

and project team leader. The Jet Propulsion Laboratory (JPL) was the managing agency and provided the science canister. Los Alamos National Laboratory 

(LANL) provided the electrostatic concentrator for the science canister and the 

electron and ion monitors. Lockheed Martin Corporation (LMC), acting through 

its Lockheed Martin Space Systems (LMSS) company, was the industrial partner 

and provided the spacecraft and sample return capsule (SRC). JPL and LMSS 

conducted mission operations. 

Genesis was to provide fundamental data to help scientists understand the formation of our solar system, reinterpret data from past space missions, and provide 

focus to many future missions. Analysis of the collector materials will give precise 

data on the chemical and isotopic composition of the solar wind. Once analysis is 

complete, the Genesis mission will provide:

1. a major improvement in our knowledge of the average chemical composition of 

the solar system;

2. isotopic abundances of sufficient precision to address planetary science problems;

3. a reservoir of solar material to be used in conjunction with advanced analytical 

techniques available to 21st century scientists; and

4. independent compositional data on the three solar wind regimes.

Launched August 8, 2001, Genesis was positioned approximately one million miles 

from the Earth orbiting the Earth-Sun libration point L1 which is outside Earth’s 

magnetosphere. It remained in a libration point orbit for 28 months. The mission 

trajectory is shown in Figure 1.1. The capsule lid was closed on April 1, 2004 and 

the spacecraft returned for a daytime Earth entry.
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g   

b. Project Management Structure and Responsibilities

Under the Discovery Program Announcement of Opportunity (AO), the Discovery 

Program policy was to solicit missions that maximized the partnership between 

implementing NASA organizations, academia, and industry. The objective was to 

develop high-content missions at lower costs and with shorter schedules than the 

norm, i.e., ‘Faster Better Cheaper’ (FBC). The solicitation and selection required 

a principal investigator (PI)-mode mission in which all decision making authority was granted to the PI, who was responsible for mission scientific, technical, 

and programmatic success. For Genesis, programmatic and technical management 

authority was delegated by the PI to a JPL Project Manager with the lead JPL Mission Engineer (Systems Engineer) as his key technical staff and the LMSS Flight 

System (spacecraft and SRC) Program Manager as the deputy to the JPL Project 

Manager. The project organization is shown in Figure 1.2. It was also proposed 

that LMSS use its own technical and programmatic processes with JPL review 

and approval limited to systems-level requirements and verification. The Discovery 

Program Office accepted these arrangements implicitly by way of the selection and 

subsequent review process.

Figure 1.1.

Genesis Mission in 

Earth coordinates.
Pa g e   GGe e s e n es ii s

The Lockheed Martin organization in 1998 is shown in Figure 1.3. The LMSS 

Flight System Program Manager (also the Genesis Deputy Project Manager), had a 

Chief System Engineer who managed the technical aspects of the program and the 

supporting System Engineering, System Integration, Spacecraft and SRC Mechanical Integration, and Assembly, Test, and Launch Operations (ATLO) teams. The 

System Integration and Mechanical Integration Managers were members of the 

program team. Subsystem leads reported to the Integration Manager and were 

dedicated to Genesis but were members of the Product Development Organization 

(PDO). This “home shop”–type organization within LMSS’s Flight System Organization provided hardware products for multiple LMSS Programs. 

The PDO provided standardized products to the extent possible while still meeting program requirements. The PDO developed requirements for their products 

from the Flight System specification with Integration Manager approval, developed their products, verified them in accordance with the verification requirements 

documented in their product spec, and delivered their products to the Integration 

Managers and the Genesis ATLO Team for integration into the spacecraft or SRC. 

The lead PDO members were Cost Account Managers for their products and were 

responsible for meeting the agreed cost and delivering on the agreed schedule. 

PDO lead personnel supported the ATLO Team throughout the system-level testing and launch preparations and some of these personnel moved into the Mission 

Operations Team at launch.

Manager

System Integration

FS Chief Scientist

GENESIS

FLIGHT SYSTEM

PROGRAM  MANAGER

GENESIS

FLIGHT SYSTEM

PROGRAM  MANAGER

BUSINESS OPERATIONS

• PROGRAM CONTROL

• CONTRACTS

• COST MGMT

• ESTIMATING

• SUBCONTRACT MGMT

• PROCUREMENT -

Chief System Engineer

SEIT/Technical Lead

Flight Syst Struct/Mech Design

Spacecraft Struct/Mech Design

SRC Struct/Mech Design

Thermal System Integration

Propulsion System Integration

Loads/Dynamics Analysis Integ

Stress Analysis Integration

Filter,Vents,Seals,Purge Design

P/L Mech Integration

LV Integration, P/L Integration

SS Integration (Sys Schematics)

Avionics Integration

  - ACS, C&DH

  - EGSE/STL, Flight S/W

  - EPS/SRC Avionics

  - Harness, Telecom (S/C & SRC)

Outreach

System Fault Protection

Reliability/Compatibility

Contamination

EMC/PMP/EEE Parts

Mngr Flight System

ATLO

Mission Assurance

Manager

Systems Engineering

Mngr S/C & SRC Mech

Design Integration

System Design

  (Chair  System Design Mtg)

Systems Rqmts & Verification

System Analyses

  -  Mission

  -  Mass Properties

Configuration Documentation

SRC Recovery

Mission Ops

Product Development

Flt Syst Assy & Test

LV Integration

Flt Syst Shipping

Launch Operations

FLIGHT SYSTEM

VICE PRESIDENT

FLIGHT SYSTEM

51100 VICE PRESIDENT

51200

52100 52400 52400 52400 52400 52400 54100 55100 57300

51100

53000

Risk Management

52300  52300

51100

Program Secretary

Figure 1.2.

Genesis Project 

organization in 1998.
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g   

c. Space Segment

The spin-stabilized spacecraft was composed of a main spacecraft with an attached 

SRC. As part of the sample return sequence the SRC was separated from the main 

spacecraft, which was diverted to a disposal orbit. The main spacecraft and SRC 

are shown in the science collection configuration in Figure 1.4. The flight configuration is shown in Figure 1.5.

Payload Team

Leader

(JPL & LANL)

Principle Investigator 

(CIT)

Principle Investigator 

(CIT)

Project Manager

(JPL)

Planning, Control,

Analysis & Recovery

Leader (JPL)

Mission Engineer

(JPL)

Science Team

Leader

(CIT)

Deputy Project Mngr

&

Flight System Team

Lead

(LMA Program Mngr)

Outreach Coordinator

(JPL)

EPO Lead

(McRel)

PCM (JPL)

FRA (JPL)

MAM (JPL)

Safety (JPL)

Figure 1.3. 

Lockheed Martin Genesis 

organization in 1998.

Solar Panels

Science 

Canister

Cover Concentrator Collector 

Arrays

Sample

Return

Capsule 

Backshell

LGA-fwd 

(1 of 2)

Star

Trackers

Genesis 

Electron 

Monitor 

(GEM)

Propulsion Tank

(1 of 2)

* Genesis Ion Monitor (GIM) is caddy corner GEM, on +Xsv deck (fwd) 

* MGA and thrusters on -Xsv deck, towards -Xsv-axis (aft)

Digital Sun 

Sensor (1 of 2)

LGA-aft 

(1 of 2)

Command & 

Data Handling

Nutation

Damper (1 of 2) Figure 1.4. 

Spacecraft in science collection 

configuration, sun view.
Pa g e   GGe e s e n es ii s

d. Sample Return Capsule Detail

A cross section of the SRC design is shown in Figure 1.6. The science canister is 

in the center with the SRC avionics units (AU) and the SRC primary LiSO2 battery 

mounted in the annulus around the science canister. The canister and the avionics 

decks are mounted to the heatshield structure. The backshell contains the drogue 

parachute on the centerline and the parafoil main parachute is packed around the 

drogue canister. A mortar is fired inside the drogue canister to propel the drogue 

parachute out through the mortar cover. The deployable aft conical section (DACS) 

is released by firing three frangible pyrotechnic bolts (DACS Retention and Release 

Mechanism) and the drag load on the drogue parachute pulls the parafoil out, taking the DACS with it. Before releasing the DACS, the cable to the drogue mortar is 

cut with a pyrotechnic cable cutter. 

Figure 1.5. 

Flight configuration with 

thermal blankets installed.

Deployed solar array

Star trackers

N2H4 tank (1 of 2)

Electron monitor

Spacecraft

SRC

SRC heatshield

Deployable aft conic SRC backshell

section (DACS)

p y

Drogue parachute SRC vent (1 of 2)

cover (mortar

blows it off during

de lo ment
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 110 

Figure 1.7 shows the avionics unit A and the flight battery prior to installing the 

thermal close outs. The collectors are partially deployed. Also visible in the upper 

left is the cable management system that restrained the cable between the heatshield and backshell during backshell opening and closing.

DACS

Drogue Chute Main Parachute

Backshell TPS

Carbon-Carbon

Heatshield

DACS R&R Mechanism

Canister Support Strut

SRC Hinge (separated

prior to release)

Parachute Deck

Heatshield

Structure

Science 

Canister

Avionics Deck

Backshell 

Structure

206 kg

1.5 m diameter

1.0 m tall

Avionics Unit(B)

Unit A and Battery

Not shown

Not visible –

UHF, GPS

DACS

Drogue Chute Main Parachute

Backshell TPS

Carbon-Carbon

Heatshield

DACS R&R Mechanism

Canister Support Strut

SRC Hinge (separated

prior to release)

Parachute Deck

Heatshield

Structure

Science 

Canister

Avionics Deck

Backshell 

Structure

Backshell 

Structure

206 kg

1.5 m diameter

1.0 m tall

Avionics Unit(B)

Unit A and Battery

Not shown

Avionics Unit(B)

Unit A and Battery

Not shown

Not visible –

UHF, GPS

Figure 1.6. 

SRC cross section 

(SRC hinge is separated from 

SRC prior to release).

Figure 1.7. 

SRC prior to installing thermal 

closures – avionics box A and 

the LiSO2 battery in foreground.

Sample collector

deployable arrays

Science canister

Battery

Backshell

Avionics

unit A

Latch (1 of 4)

Seals – heatshield to

backshell (two)

Cable & guide

Science canister hinge
Pa g e 111 GGe n e se n e 

e. Drogue and Parafoil Parachute Deployment System Description

A parachute system is deployed in a sequence of timed pyrotechnic events. The 

Genesis parachute deployment sequence is illustrated in Figure 1.8, and includes 

the activation of post-landing location aides, namely, a GPS transceiver and a UHF 

beacon transmitter.

The timing for each pyrotechnic event in the sequence is shown in Table 1. Redundancy of the critical pyrotechnic devices was achieved by incorporating a firing 

circuit in each of the two AU’s. The critical devices are the first three listed in Table 

1. A simplified block diagram of the SRC pyrotechnic firing circuit is shown in 

Figure 1.9.

Mortar fire 

and 

ejection of

drogue

Drogue inflated Mortar harness cut and DACS

Separation;

GPS transceiver & UHF location

beacon activated

Parafoil Bag Strip

Parafoil Inflated

DACS

DACS

Parafoil 

Deployment

Bag

Deployment

Line

Mortar fire 

and 

ejection of

drogue

Drogue inflated Mortar harness cut and DACS

Separation;

GPS transceiver & UHF location

beacon activated

Parafoil Bag Strip

Parafoil Inflated

DACS

DACS

Parafoil 

Deployment

Bag

Deployment

Line

Figure 1.8. 

Parafoil deployment 

sequence.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 1212 

Table 1. SRC Sequence Timing.

Pyrotechnic 

Device

Time of Fire Command after Start of 

Event Sequencer, 

sec

Redundancy

Drogue mortar 5.7 Two firing circuits in each of 

the two avionics boxes

Drogue harness 

cable cutter

80.6 Two firing circuits in each of 

the two avionics boxes

DACS bolts, 

3 fired 

simultaneously

259.6 Two firing circuits in each of 

the two avionics boxes

GPS transceiver 261.4 One firing circuit in each of 

the two avionics boxes

UHF beacon transmitter261.4 One firing circuit in each of 

the two avionics boxes

The firing circuit is activated by the G-switch sensors, which are ANDed together 

to preclude a single switch failure from prematurely issuing a fire signal. A lowpass filter was added to prevent inadvertent G-switch sensor activation due to atmospheric transients (buffeting) during re-entry. The pressure transducer is not a 

backup to the G-switch sensor and is only used once the event sequence timer 

(EST) is running to ensure that parafoil deployment occurs at the desired altitude. 

A positive firing signal from the firing circuit in either AU was sufficient to fire the 

respective pyrotechnic device. 

Figure 1.9. 

SRC pyrotechnic firing 

circuit layout.

Avionics Unit 1

G

Switch1

G

Switch2

Timer2

Timer1

And

NSIs

5 places

A

B

G

Switch1

G

Switch2

Timer1

Timer2

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

Press

xducer

Enable Plug

Test Point

Test Point

Avionics Unit 1

G

Switch1

G

Switch2

Timer2

Timer1

And

NSIs

5 places

A

B

G

Switch1

G

Switch2

Timer1

Timer2

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

Press

xducer

Enable Plug

Test Point

Test Point
Pa g e 113 GGe n es e n 

The AU block diagram is shown is Figure 1.10. The primary functions performed 

by the motor drive electronics (MDE) board were completed when the science canister and the SRC were closed on April 1, 2004. During the SRC release sequence, 

the relay card and the field programmable gate array (FPGA) on the MDE board 

are used only to connect the SRC LiSO2 batteries to first the depassivation resistors 

and then to the EST board to power it through entry and post-entry operations. Gswitch sensors, used to sense atmospheric entry and initiate a pyrotechnic events 

timer, were mounted on the relay card although voltage was applied for the pyrotechnic events from the EST card.

The G-switch sensor is an acceleration-sensitive sensor, which is somewhat smaller 

than the metal ferrule of a common wooden pencil (Fig. 1.11).

Figure 1.10. 

SRC avionics unit.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 1414 

The acceleration direction required to close the switch is shown in Figure 1.11. An 

X-ray of the G-switch sensor shows how the spring mass and contact are oriented 

inside the cylinder (Fig. 1.11). The closure lip provides a good orientation reference between the photograph of the exterior and the X-ray of the interior of the 

G-switch sensor. When the G-switch sensor is mounted in the correct orientation, 

the internal plunger compresses against its spring as the g’s are increased, making 

electrical contact. The g profile for the Genesis entry, shown in Figure 1.12, was 

close to the pre-launch prediction. 

Figure 1.11. 

Aerodyne 7200-6-000 

acceleration switch 

(G-switch sensor) drawing 

and X-ray.
Pa g e 115 GGe n es e n 

As seen in Figure 1.12, the g’s build up due to the increased drag in the atmosphere. 

Upon reaching 3 g’s, the plunger touches an electrical contact in the end of the Gswitch sensor, closing the circuit and arming the sequencer. When the SRC slows 

down and the g’s drop below 3 g’s, the plunger in the G-switch sensor pushes away 

from the contact, which breaks the circuit and starts the sequencer. 

Figure 1.12. 

Genesis entry g profile. 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 1616 

2.0 Genesis Mishap De

Sequence of Events and 

This section describes the events leading up to the impact of the Genesis SRC 

vehicle at the Utah Test and Training Range (UTTR). Figure 2.1 illustrates the 

nominal timeline from the SRC release enable/no-go decision through landing. A 

detailed description of the post-impact ground recovery operations and timeline is 

in Volume II of this report.

During the science portion of the mission, which had no significant anomalies, the 

SRC functioned as an integrated element of the Genesis spacecraft. The SRC was 

oriented to face the sun and was configured to expose the collector surfaces to the 

solar wind. At the completion of the planned science mission, the SRC was closed 

to avoid contamination of the collector surfaces during the return flight to Earth 

and the spacecraft flew a trajectory designed to permit a daytime landing at the 

target site. 

Approximately 8 hours prior to landing, the SRC was prepared for separation and 

entry by activating (depassivating) its dedicated batteries, severing umbilicals, and 

increasing the spacecraft rate of rotation. A 4-hour period had been designed into 

the timeline to permit response to any observed contingency, but none occurred 

and the SRC separated from the parent Genesis spacecraft as planned. The Genesis spacecraft was subsequently diverted to a disposal orbit.

Figure 2.1. 

Entry timeline. 
Pa g e 117 GGe n es e n 

Following separation, the SRC continued on a ballistic trajectory to its entry interface with the Earth’s atmosphere. Entry occurred on time and at the nominal 

location to support a landing as designed in the UTTR. Operation of the spacecraft appeared nominal until the expected deployment of the drogue parachute at 

approximately 108,000 ft (33 km) altitude. No drogue or parachute was observed, 

and the SRC impacted the desert floor at 9:58:52 MDT.

The navigation team reconstructed the trajectory of the entering spacecraft and 

verified that the spacecraft was on the desired reference trajectory. Entry-phase 

tracking systems acquired the SRC over Oregon at an altitude of about 300,000 ft 

(90 km), only about 32 sec after encountering sensible atmosphere. Hypersonic 

entry deceleration was nominal until well after the drogue parachute should have 

deployed. 

Following impact, the recovery helicopters located and surveyed the impact site, 

and landed to permit recovery personnel to approach the SRC. The activities of 

the recovery personnel involved potential exposure to toxic gasses that could be 

released from a shorted battery and potential danger from the drogue mortar if it 

were unfired. This is described in detail in Volume II.

Following safing activities, the SRC hardware was transported to a holding facility 

at the Michael Army Airfield complex, where it was secured pending the arrival of 

the Genesis Mishap Investigation Board (MIB). 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 1818 

3.0 Genesis Mishap Method of Inv

On September 10, 2004, the Associate Administrator for the Science Mission Directorate established the NASA Genesis MIB and designated Dr. Michael Ryschkewitsch, Goddard Space Flight Center (GSFC) Director of Applied Engineering and 

Technology, as chairman. The Board was directed to: 

• obtain and analyze whatever evidence, facts, and opinions it considered relevant; 

• conduct tests, and other actions it deemed appropriate; 

• take testimony and receive statements from witnesses;

• impound property, equipment, and records as considered necessary;

• determine the proximate cause(s), root cause(s), and contributing factors relating to the Genesis Mishap;

• generate and prioritize findings;

• determine the adequacy of contingency response planning and the appropriateness of the actual contingency response, to include the safeing and securing of 

the spacecraft and the science payload, and the protection of response personnel; 

• develop recommendations to prevent recurrence of similar mishaps; and

• provide a final written report with contents as specified in NPR 8621.1A.

The letter establishing the Genesis MIB is provided in Appendix A.

LMSS investigation of the close out documentation provided to the Board gave 

strong indication of the likely cause of the failure. However, due to potential implications for other flight systems the Board elected to continue with a more thorough 

investigation (Appendix B). 

The Genesis MIB Chair and Executive Secretary received initial briefings from 

the Genesis Project (JPL and LMSS) and took responsibility for the recovered hardware at the UTTR crash site, beginning Sept. 10, 2004. The Genesis MIB held initial team organizational meetings on Sept. 14-15, 2004. 

The Genesis Project held overview briefings for the complete MIB team at 

UTTR on Sept.14-15 and at LMC on Sept. 22-23 and Sept. 29, 2004. The 

briefing included material on the Genesis spacecraft, subsystems, development, 

test, operations, navigation, and spacecraft health status up to the incident. On 
Pa g e 119 GGe n es e n 

Oct. 27, 2004, the Discovery Program provided an overview briefing of the FBC 

environment, including the Discovery Program culture at that time. 

During these initial meetings, the Board established seven sub-teams to investigate 

specific focus areas. The seven sub-teams and their summary charters are listed 

in the following. 

• Systems, Operations, and Environments 

- Lead development of the failure timeline and fault tree for the 

Genesis deployment failure. 

- Coordinate the development, review, approval, and disposition of the 

fault tree closure plans and records. 

• ‘Test as you Fly’

- Determine the adequacy of the Genesis verification program as it 

relates to the Genesis failure. 

- Determine if the verification process for each relevant event 

on the Fault Tree is adequate to absolve it as the cause of the 

failure (through coordination with the Systems, Operations, and 

Environments sub-team).

- Identify any inadequate verification of downstream event (as part 

of the investigation of possible failures subsequent to the failure to 

initiate the deployment sequence). 

• Entry Dynamics and Descent

- Determine if the Genesis SRC entry and descent performance, prior 

to the failure, were abnormal and may have caused the failure. 

- Determine if the descent environment, after the pyro initiation 

failure, might have been sufficient to trigger the pyro initiation 

sequence. 

• Battery

- Determine if the batteries caused or contributed to the Genesis pyro 

initiation failure. 

- Determine the cause and associated timeline for the low state-ofcharge exhibited by the batteries after the accident. 

- Identify, plan, and execute, with the MIB chair’s concurrence, any 

testing, data, and/or analyses required to answer these questions. 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 220 

• Avionics/Pyrotechnics/EEE Parts

- Determine if a failure in the design, implementation, or flight of the 

Genesis avionics and pyrotechnic subsystems may have caused the 

failure. 

- Identify, plan, and execute, with the MIB chair’s concurrence, any 

testing, data, and/or analyses required to answer these questions. 

• Recovery and Ground Safety – (Volume II)

- Determine the adequacy of contingency response planning and the 

appropriateness of the actual contingency response, to include the 

safing and securing of the spacecraft and the science payload, and the 

protection of response personnel.

• Project Environment and Decision Making Processes

- Identify any shortfalls in the project implementation/decision making 

process that may have led to the Genesis failure. 

After discussions with the MIB and FRB, in lieu of conducting a formal internal 

investigation LMSS management elected to make available their extensive resources 

to the MIB and FRB and to use the findings and recommendations to shape their 

internal actions and responses. LMSS provided a consultant to the Board; a senior 

manager with whom to consult and to help expedite LMSS actions.

In addition to root cause determination of the mishap, the MIB charter also included 

an assessment of the adequacy of contingency response planning and the appropriateness of the actual contingency response. The Recovery and Ground Safety SubTeam focused on safety, contingency planning, and ground communication issues. 

This team was led by Mr. Stacey Nakamura, Chief of the NASA JSC Safety and 

Test Operations Division, and focused on these issues at the request of the NASA 

Chief Medical Officer. Volume II of this report contains the assessment, findings, 

and recommendations for the Recovery and Ground Safety aspects of the Genesis 

mishap.

Under the guidance of the Systems, Operations, and Environments Sub-Team, the 

MIB used fault tree analysis to identify and analyze a comprehensive range of possible failure scenarios to provide a systematic process to track possible causes to 

closure. The Systems, Operations, and Environments Sub-Team assigned the other 

sub-teams various fault tree branches/items based on areas of expertise. The subteams documented and tracked the analysis and information gathering necessary 

to disposition each identified fault tree event. The Genesis MIB fault tree process 

is provided in Appendix C-1, the fault tree diagram is in Appendix C-2, and Fault 

Tree Closeout Plans and Records are in Appendices C-3 and C-4 (on DVD).

To provide the information required to disposition the fault tree failure scenarios, 
Pa g e 212 GGe n e se n e 

the Board requested specific inspections, tests and analyses to be conducted. The 

analyses, which included SRC tumble analysis and aerodynamic stability analysis, were performed by experts selected by the Board. The inspections and tests 

were performed by MIB and FRB members and monitored by an MIB Quality 

Engineer or LMSS technicians under the guidance of MIB and FRB members, 

using procedures built by LMSS experts and approved by the MIB. Inspections 

performed on the recovered hardware included inspections of the TPS, pyrotechnics, batteries, avionics boxes, and harnesses. Tests were conducted on the 

SRC avionics Engineering Development Unit (EDU) and recovered avionics units, including functional tests of cards from one of the recovered avionics units. The results of the inspection, tests, and analyses are 

summarized in the fault tree discussions in Appendix C and associated reports in 

Appendix D.

The Systems, Operations, and Environments Sub-Team held fault tree closure 

meetings and telecons during October and November 2004 where the sub-teams 

reviewed and reached consensus on each fault tree closure. Following completion 

of the Board fault tree reviews, the Board concurred on the likely credible cause 

for the loss of Genesis; they also agreed upon the explanation of potential causes 

considered, but determined to be unlikely or non-credible. Appendix E contains 

the root cause and contributing factor narrative and the event and casual factor tree. 

JPL formed its own Failure Review Board (FRB), which worked closely with the 

MIB. FRB members worked with MIB sub-teams to maximize efficiency. The 

JPL FRB final report is included in Appendix F. 

The Project Environment and Decision Making Processes Sub-Team conducted 

extensive interviews with current and former JPL and LMSS employees, as well 

as other members of the Genesis Red Team. Privileged interviews were offered; 

however, all interviewees requested non-privileged status. Because the interviews 

were non-privileged, FRB members participated in all interviews.

The Board typically held teleconferences twice a week to track the status of subteam activities and discuss special areas of interest. Throughout the investigation 

there were regular requests made of JPL and LMSS for information and data in 

support of the Board. JPL and LMSS provided full and open communication in 

response to all Board requests and provided specialized technical expertise when 

requested. The list of contractors supporting the MIB is in Appendix G. During 

the investigation, several meetings were dedicated to special topics. These meetings ensured that all Board members had similar understanding or exposure to key 

data. Minutes are provided in Appendix H.

The Board assembled observations concerning the Genesis design, verification, 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 2222 

and review processes; identified root causes and contributing factors; and then 

developed a set of recommendations. The MIB Chair provided a briefing of the 

report to JPL and LMC personnel prior to release of the final MIB report to confirm accuracy.
Pa g e 223 GGe n es e n 

4.0 Proximate C

NPR 8621.1A, NASA Procedural Requirements for Mishap Reporting, Investigating, and Recordkeeping, defines a proximate cause as “The event(s) that occurred, 

including any condition(s) that existed immediately before the undesired outcome, 

directly resulted in its occurrence and, if eliminated or modified, would have prevented the undesired outcome.” It is also known as the direct cause.

The Board determined the Genesis mishap proximate cause to be that the G-switch 

sensors did not activate the EST due to the improper orientation on the relay cards 

of SRC-AU boxes. In the wrong orientation, it was impossible for the sensors to 

detect atmospheric entry and initiate the EST, which was required to fire the pyrotechnics. 

The MIB researched the proximate cause of the failure of drogue parachute to 

deploy during entry through a fault tree analysis. During this analysis, the Board 

reviewed all aspects of the mission to identify potential contributors to the entry 

failure. The fault tree analysis focused on four main failure scenarios (or fault tree 

branches). These include: 

• avionics systems failures

• electrical power system failures

• electrical harness/connectors failures; and 

• drogue system failures. 

These four fault tree branches were then extended to a total of 103 fault tree elements, or specific failure scenarios, as part of the MIB’s fault tree development 

effort. Details of the fault tree are shown in Appendix C. The MIB thoroughly 

investigated each element of the fault tree by examining design documents, preflight test data, closeout photos, in-flight data, computer commands, telemetry, and 

by physical examination and testing of the recovered SRC, and through assorted 

special analyses. The data collected either supported or refuted each specific fault 

tree element’s contribution to the mishap. Conclusions were then formulated and 

the MIB as a whole concurred on the credibility of each possible failure mode. 

Each of the four fault tree branches are described in more detail in the 

following, along with its requisite impact to the proximate cause. 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 2424 

4.1. SRC Avionics Unit Failure

During entry, the SRC-AU was responsible for detecting entry and invoking specific commands in the proper sequence to deploy the drogue chute, cut the drogue 

chute harness, deploy the main chute, and activate the UHF and GPS systems. 

During the Genesis entry, none of these occurred. The Avionics System fault tree 

branch consisted of 13 sub-branches. These included: 

1. The G-switch sensors did not activate the EST. 

2. The low-pass filter in the EST was not designed properly for the 

anticipated aerodynamic braking profile.

3. After the EST started, an inadvertent reset would stop the EST. 

4. Incorrect timing of the EST oscillator prevented the release of the 

drogue. 

5. Latent electronic fault resulting from a potential high-voltage 

discharge from the scientific concentrator grid circuit.

6. Mortar initiator circuit’s current limiting ballast resistor damaged in 

pre-fight testing which prevented drogue pyro firing. 

7. Logic circuits out of phase.

8. EST jumpers set incorrectly, resulting in wrong event sequence. 

9. Electromagnetic interference (EMI) disrupted avionics circuit 

operation. 

10. Space or entry environment adversely impacted avionics. 

11. Pressure transducers, if improperly wired, interfered with the fire 

command. 

12. The Avionics System internal short during flight or entry. 

13. An open fuse prevented the Avionics Systems from operating 

properly. 

As noted earlier, it was determined that the G-switch sensors were improperly oriented on the SRC-AU relay card, making it impossible to initiate the EST circuitry 

and fire the pyrotechnics (item number 1 above).

MIB review of the board assembly drawings, flight board closeout photographs, 

and the flight A and B side AU’s indicates that the switches were installed in accordance with the design drawings. However, the relay cards, which contained the Gswitch sensors, were designed with the G-switch sensors in an inverted orientation 

as compared to how they were planned for Stardust (the heritage design). 
Pa g e 225 GGe n es e n 

Figures 4.1 and 4.2 show an assembly drawing and close out photograph of a flight 

relay card with G-switch sensors, respectively.

G-Switches

Mounting Base of AU

Figure 4.1. 

Relay card 

assembly drawing.

Figure 4.2. 

Relay card 

close-out photograph.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 2626 

The inversion of the G-switch sensors made it impossible for the masses in each 

sensor to compress their restraining springs, and activate the switch. As a result, 

the circuit to the EST could not be closed, preventing the timer that controlled the 

pyrotechnic firings from being initiated. Since the drogue pyrotechnic firing did 

not occur, the SRC continued its descent at a high rate of speed, lost stability, and 

struck the desert floor at 193 mph (311 kph).

4.2. Electrical Power System (including the Battery) Failure

The electrical power system fault tree is comprised of the batteries as well as the 

heaters and electrical loads that affect the power available to the avionics and 

drogue systems during entry. The batteries powering this entry system are dedicated to entry alone and were activated only hours before entry. 

There were six fault-tree sub-branches associated with the electrical power system. 

1. Sequence that activated and conditioned the batteries was incorrect. 

2. Power relays incorrectly configured. 

3. Power system design flaw resulted in premature draining of battery. 

4. The batteries or battery connectors jarred loose in-flight or during 

entry.

5. The entry conditions caused the batteries or cables to overheat, or 

short/open circuits to develop. 

6. Insufficient battery capacity prevented deployment of the drogue 

parachute (included assessment of battery over temperature event 

during the mission). 

The MIB investigated these possible failure modes and found each to be unlikely 

or not credible. Appendix C documents the fault tree closeouts for each. Further, 

Appendix D-1 contains a copy of the Battery Post-Flight Investigation Report, 

which addressed item 6 above in detail. 

4.3. Electrical Harness/Connector Failure

The wiring harness within the SRC must connect all the electrical elements of the 

SRC. In addition, this harness crosses a hinge and must be correctly routed and 

secured to ensure hinge operation and keep all electrical connections intact. 

There were three primary failure scenarios for the electrical harness/connector 

system. 
Pa g e 227 GGe n es e n 

1. Pyro circuits not connected. 

2. One or more harness wires open during flight. 

3. Harness wires shorted to each other or to ground.

The MIB dispositioned each failure mechanism as unlikely or not credible. Documentation for each is provided in Appendix C.

4.4. Drogue System Failure

The Genesis parachute system is deployed in a sequence of timed pyrotechnic 

events. The first event is to fire redundant NASA standard initiators (NSI’s). The 

initiators then ignite the mortar propellant. The mortar ejects the drogue parachute out of the mortar into the air stream where it inflates, slows, and stabilizes 

the vehicle. At the appropriate time, the mortar harness is cut and separation bolts 

are fired to release the DACS and drogue from the vehicle and ultimately deploy 

the parafoil.

For Genesis, the G-switch sensors were used to start the EST, which would fire 

the NSI’s to start the parachute system deployment. If the sequencer had started 

and the NSI’s fired, the drogue should have been deployed. Because the drogue 

was not deployed, the remaining events in the parachute sequence could not be 

accomplished. 

Therefore, the sub-branches of fault tree for the Parachute System were limited to 

the events associated with:

1. pyro firing

2. drogue deployment

The MIB dispositioned these failure mechanisms as not credible; they are documented in Appendices C and D.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 2828 

5.0 Genesis Mishap Root 

and Contributing 

NPR 8621.1A, NASA Procedural Requirements for Mishap Reporting, Investigating, and Recordkeeping, defines a root cause as “one of multiple factors (events, 

conditions, or organizational factors) that contributed to or created the proximate 

cause and subsequent undesired outcome and, if eliminated or modified, would 

have prevented the undesired outcome. Typically, multiple root causes contribute 

to an undesired outcome.”

Further, NPR 8621.1A defines a contributing factor as “an event or condition that 

may have contributed to the occurrence of an undesired outcome but, if eliminated 

or modified, would not by itself have prevented the occurrence.”

Using a bulleted format, Section 5.1 describes the four process-level failures that 

led to the mishap and their associated root causes and contributing factors. Section 

5.2 provides a brief presentation of the major findings associated with each root 

cause and contributing factor. Appendix E describes in narrative form each root 

cause and contributing factor in greater detail. Section 6.0 provides recommendations to avoid the reoccurrence of the issues identified by the Board, and Table 6.1 

provides a cross reference of root causes and contributing factors to recommendations.

Distinctions between JPL and LMSS Project Management and Systems Engineering are not generally made in this section. The Genesis Deputy Project Manager 

was the LMSS Program Manager; as a result errors made by the LMSS Program 

Manager cannot be – and the Board believes should not be -- separated from JPL 

Genesis Project Management. Further, the lead JPL Systems Engineer agreed, 

with Project Management concurrence, not to monitor or cross-check LMSS Systems Engineering activities or processes. This intentional omission leaves JPL 

Systems Engineering equally responsible for errors committed by LMSS Systems 

Engineering and for that reason distinctions between the two are made only when 

necessary to explain the events. 
Pa g e 229 GGe n es e n 

5.1 Process-Level Errors: Root Causes and Contributing Factors

The Genesis Project had a number of interrelated issues that led to the inversion of 

the G-switch sensors -- the proximate cause that resulted in the drogue parachute 

deployment mishap. After extensive review of the data and numerous interviews, 

the MIB determined that deficiencies in the following four pre-launch, top-level 

processes resulted in the incident, each involving multiple root causes and contributing factors:

1. the design process inverted the G-switch sensor design;

2. the design review process did not detect the design error;

3. the verification process did not detect the design error; and

4. the Red Team review process did not uncover the failure in 

the verification process.

Under each process failure were multiple root causes and contributing factors. 

Appendix E provides the Event and Causal Factor Tree depicting the hierarchy of 

events from the root causes through to the proximate cause. The Board used root 

cause analysis to develop six major categories of root causes and contributing factors; many of these were common to two or more of the above mentioned process 

failures. The six categories and their associated root causes and contributing factors are listed below.

1. Inadequate Project and Systems Engineering Management

• Contributing Factor 1.1: Insufficient JPL Project Management and 

Systems Engineering insight into LMSS activities.

• Contributing Factor 1.2: SRC not treated as a separate spacecraft. 

• Root Cause 1.1: Genesis Project Management and Systems 

Engineering did not perform due diligence with regard to reviewing 

briefing materials.

2. Inadequate Systems Engineering Process 

• Root Cause 2.1: Inadequate requirements generation.

• Root Cause 2.2: Systems Engineering did not define detailed 

verification requirements for subsystems.

• Root Cause 2.3: Lack of documentation of changes made to 

verification methods.

• Root Cause 2.4: Systems Engineering verification process did not 

require consideration of a verifier’s qualifications nor incorporate 

multiple verifiers.

• Root Cause 2.5: Systems Engineering was not required to review 

subsystem test procedures or verification results. 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 330 

• Root Cause 2.6: Inadequate execution of System-level verification. 

• Contributing Factor 2.1: Lack of a Systems Engineer assigned to the 

end-to-end entry, descent, and landing (EDL) function. 

• Contributing Factor 2.2: Inadequate Systems Engineering staffing 

level.

3. Inadequate Technical Review Process 

• Root Cause 3.1: Key individuals’ attendance was not required at 

project technical and drawing reviews.

• Root Cause 3.2: SRC-AU Critical Design Review (CDR) was too 

high-level to adequately assess the design. 

• Root Cause 3.3: JPL SMO gave the Red Team too little time to 

perform an adequate assessment. 

• Root Cause 3.4: Inadequate Red Team management of focus groups. 

4. Unfounded Confidence in Heritage 

• Root Cause 4.1: Inappropriate confidence in heritage designs. 

5. Failure to ‘test as you fly’

• Root Cause 5.1: G-switch sensor was not identified as having a 

critical alignment in the Pointing and Alignment Document (Phasing 

Plan). 

6. FBC Issues

• Root Cause 6.1: The Faster, Better, Cheaper (FBC) philosophy: 

‘cost-capped’ mission with threat of cancellation, if overrun.

5.2 Root Causes/Contributing Factors: Facts and Findings

The following section describes in a bulleted list format the individual root causes 

and contributing factors identified in Section 5.1. More detail is provided for each 

root cause and contributing factor in Appendix E-2.

In several cases the top-level process errors mentioned in Section 5.1 shared common root causes. To simplify the discussion, the root causes and contributing 

factors are discussed in terms of the six categories of root causes and contributing 

factors. 

Root Cause Category No. 1: Inadequate Project and Systems Engineering Management
Pa g e 313 GGe n e se n e 

Contributing Factor 1.1: Inadequate JPL Project Management and Systems Engineering insight into LMSS activities.

Facts:

• Insufficient JPL Project Management and Systems Engineering participation resulted from the FBC philosophy of pushing responsibility to the lowest level and not interfering with the contractor’s processes.

• JPL Project Management assumed that LMSS management was performing all necessary spacecraft Systems Engineering functions and required no 

JPL support.

• Discipline-specific engineering interaction did not occur on a regular basis 

between the JPL and LMSS teams.

• JPL Project Management and Systems Engineering limited its active support primarily to science instrument activities on the SRC.

• JPL Project Management and Systems Engineering did not actively support 

or thoroughly review the spacecraft or SRC, including the SRC-AU functions.

• The JPL Systems Engineering lead was not experienced in this type of project.

Findings:

• Inadequate JPL Project Management and Systems Engineering insight into 

LMSS spacecraft activities played a significant role in the Genesis mishap.

• Insufficient involvement by JPL Project Management and Systems Engineering in spacecraft activities resulted in total dependence on LMSS for its 

mission success. 

• The lack of involvement by JPL Project Management and Systems Engineering at the lower levels did not directly cause the failure, but made it 

difficult or impossible for them to identify the process failures that led to it.

Contributing Factor 1.2: SRC was not treated as a separate spacecraft.

Facts:

• Project Management addressed the SRC as an integral part of the Genesis 

spacecraft, not as a separate spacecraft.

• This reduced costs by avoiding the additional management structure needed 

if the SRC had been treated as a separate element. 

Finding:

• While not unsound or uncommon, this approach diminished focus on the 

critical mission success elements unique to the entry phase and may have 

contributed to the failure.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 3232 

Root Cause 1.1: Genesis Project Management and Systems Engineering did not perform due diligence with regard to reviewing briefing 

materials.

Facts:

• A centrifuge test to verify the directionality of the G-switch sensors had 

been planned, but was deleted in favor of drawing inspections. 

• The only documentation indicating that Genesis Project Management or 

Systems Engineering had been informed of a centrifuge test deletion was a 

single bullet presented at two management reviews that read, “SRC AU 3-g 

test approach validated; moved to unit test; separate test not required.”

• The “unit test” did not verify orientation, only continuity.

• No one recalled any discussion occurring regarding the bullet.

• Project Management and Systems Engineering assumed that a functional 

replacement for a centrifuge test was to occur that would determine Gswitch sensor orientation.

Finding:

• Had Project Management or Systems Engineering questioned the meaning 

of the cryptic bullet, the inadequacies of the approach would most likely 

have been discovered.

Root Cause Category No. 2: Inadequate Systems Engineering Process

Root Cause 2.1: Inadequate requirements generation. 

Facts:

• There was a requirement at the SRC avionics subsystem-level to deploy a 

drogue. This requirement included the phrase “descending X axial deceleration,” without a System- or AU-level coordinate system or figure to indicate 

the direction of the deceleration (acceleration) vector. 

• LMSS Systems Engineering assumed the wording of the requirement would 

be understood, based upon Stardust experience where the requirement was 

implemented properly and verified with a centrifuge test.

• The process of importing the Stardust design implementation did not include 

orientation information or sensitivities.

• The critical step of interpreting the AU design and layout in an integrated 

operational environment was not performed adequately due to the lack of 

systems engineering support.

Finding:

• The inversion might not have occurred if the direction of the acceleration 
Pa g e 333 GGe n es e n 

vector had been written in SRC avionics coordinates, or if a coordinate system figure had been included with the acceleration vector noted. 

Root Cause 2.2: Systems Engineering did not define detailed verification requirements for subsystems. 

Facts:

• Consistent with the FBC philosophy, the component verification function 

was delegated to the subsystem organizations with limited oversight from 

System Engineering. 

• Systems Engineering assigned a type of verification (test, analysis, etc.) and 

a verification event (performance test, functional test, etc.) to each subsystem 

requirement, reviewed spacecraft-level verification results, and performed 

verification bookkeeping.

• System Engineering did not establish detailed expectations for the verification of requirements.

Findings:

• The SRC-AU design and verification approach never demonstrated an integrated understanding of how the SRC system was intended to function.

• Absent this understanding, the design was incorrect and the verification testing was ineffective in detecting the design error.

• The G-switch sensor inversion might have been avoided had either the design 

engineer understood the integrated functionality of the system or the verification approach ensured an effective performance test of the AU.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 3434 

Root Cause 2.3: Lack of documentation of changes made to verification methods. 

and

Root Cause 2.4: Systems Engineering Verification Process did not require consideration of verifier’s qualifications or incorporate multiple verifiers.

These two root causes are closely related and are presented together in the following discussion.

Facts:

• The verification matrix for the Genesis spacecraft specified a performance 

test be used to verify the integrated performance of the SRC-AU.

• The actual method used to verify the G-switch sensor orientation was to 

inspect the Stardust SRC-AU G-switch sensor drawings for similarity to the 

Genesis drawings. 

• The inspection was performed incorrectly due to the SRC-AU PIE’s lack of 

experience inspecting mechanical drawings. 

• The SRC-AU Specification was under LMSS Level 3 Change Control; 

therefore, the SRC-AU PIE should have processed a Change Request before 

changing verification methods.

• The PIE did not process this Change Request or generate a Technical Memorandum documenting his approach and findings.

Findings:

• The PIE, an electrical engineer, performed the verification without the necessary mechanical engineering background to review complex mechanical 

drawings.

• Either a Change Request or Technical Memorandum would likely have 

resulted in a critical assessment of the inspection approach and possibly 

detected the error. 

Root Cause 2.5: Systems Engineering was not required to review subsystem test 

procedures or verification results. 

Facts:

• Systems Engineering was not viewed as responsible for subsystem verification activities and as a result, did not review test procedures or test/analysis 

results performed at the Subsystem level. 
Pa g e 335 GGe n es e n 

• Systems Engineering did not review the ‘unit test’ procedure or results that 

Project Management and Systems Engineering erroneously believed would 

verify G-switch sensor orientation.

Finding:

• No effective Systems Engineering review of the SRC entry system 

verification occurred. Had Systems Engineering critically reviewed 

verification activities, it is likely the incorrect orientation of the 

G-switch sensors would have been detected.

Root Cause 2.6: Inadequate execution of System-level verification. 

Facts:

• The lower-level SRC-AU requirement was derived from the System-level 

drogue chute deployment requirement, which had two requirements in one 

statement. The first requirement was to deploy a drogue between Mach 1.6 

to 2.0 and the second was to provide transonic/subsonic stability.

• Review of the verification analysis for this requirement indicated that no 

actual verification was performed, only a discussion of the intent of the 

design. 

• Two engineers reviewed the verification analysis as a cross-check; however, 

the lack of any actual verification was not recognized.

• Based on an interview with the LMSS Chief Systems Engineer, although the 

title of the requirement was “drogue Chute deploy,” the focus of the verification analysis review was on the drogue stability issue alone, not the drogue 

deployment. 

Finding:

• No verification of the relevant System-level drogue deployment requirement 

was performed. Absent such verification and associated unit tests, the verification process did not identify the design error.

Contributing Factor 2.1: Lack of a Systems Engineer assigned to the end-to-end 

Entry, Descent, and Landing (EDL) function.

Facts:

• No one on the Systems Engineering Team had been assigned individual 

Responsibility, Accountability, and Authority (RAA) for the entire EDL 

sequence and for oversight of the system design and operations plans to 

execute that phase. 

• A number of Systems Engineers had responsibilities that might have logically included the G-switch sensor function, but did not.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 3636 

• These Systems Engineers thought that another person had responsibility for 

the G-switch function.

Findings:

• Verification of the SRC AU G-switch sensor function should have been a 

responsibility of Systems Engineering, shared with the SRC-AU PIE, since 

it crossed subsystem boundaries.

• The lack of a Systems Engineering Team member responsibility for this 

critical integrated function did not directly cause the mishap, but did contribute to its occurrence.

Contributing Factor 2.2: Inadequate Systems Engineering staffing level. 

Facts:

• Based on MIB interviews, JPL and LMSS Project Management and Systems Engineering thought that the LMSS Systems Engineering Team had 

an adequate staff. 

• The LMSS Chief Systems Engineer was required to hold three positions 

(Chief Systems Engineer, Systems Engineering Manager, and Contamination engineer).

• Interviews indicated that the Systems Engineering Team had difficulty 

meeting their stated responsibilities, which were already reduced from traditional Systems Engineering responsibilities in accordance with Genesis’ 

implementation of the FBC philosophy.

Finding:

• The MIB found that LMSS Systems Engineering staffing levels were inadequate, and numerous traditional Systems Engineering responsibilities were 

not performed, (e.g., detailed subsystem verification requirements not established, subsystem test procedures not reviewed, and subsystem verification 

results not reviewed).

Root Cause Category No. 3: Inadequate Technical Review Process 

Root Cause 3.1: Key individuals’ attendance was not required at project technical 

and drawing reviews.

Fact:

• It appears that no one with a System-level perspective of the drogue chute 

deployment participated in the lower-level peer review of the SRC-AU. 

• No one from Systems Engineering participated or was required to participate in the drawing signoffs. 

Finding:
Pa g e 337 GGe n es e n 

• Had someone with a System-level perspective participated in these reviews, 

the G-switch sensor design inversion might have been detected. 

Root Cause 3.2: Design Reviews were too high level to assess the design adequately.

Facts:

• The AU CDR consisted of a 4 hour, 148-page chart review with little technical content and was insufficient to support a box-level CDR. 

• There were no noteworthy discussions of the G-switch sensor. No action 

items regarding the G-switch sensors were assigned. 

Finding:

• The design error might have been discovered had the design reviews been 

conducted in significantly more detail.

Root Cause 3.3: JPL Systems Management Office (SMO) gave the Red Team too 

little time to perform an adequate assessment.

Facts:

• For the June 2000 Red Team review, the JPL SMO gave the Red Team only 

3 days to review data products and meet with the project teams. 

• This abbreviated review period was intended to avoid impacting the project’s 

schedule. 

Findings:

• An inadequate review period resulted in a review of insufficient depth to 

meet its chartered goals, which were in part to evaluate the spacecraft and 

SRC design, implementation, and test.

• Had the JPL SMO allocated adequate time to the Red Team for a thorough 

review, the error (either the specific verification error or the overall verification process failures) might have been discovered.

Root Cause 3.4: Inadequate Red Team management of focus groups. 

Facts:

• The EPS Focus Group was a power system discipline-oriented team, not a 

cross-cutting, multidiscipline-oriented team. This group reviewed the SRCAU at the June 2000 review.

• Red Team management formed an EDL Focus Group for the October 2000 

Red Team cycle. This group was to take responsibility for AU parachute 

deployment functions from the EPS Focus Group.

• The EDL Focus Group did not address the SRC-AU, except to recommend 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 3838 

an action to coordinate with the Avionics Focus Group to review issues relative to the parachute deployment initiation system.

• The action was never completed because the Red Team system did not 

require actions to be closed.

Findings:

• EDL and EPS Focus Group failures were ultimately failures of the Red 

Team chairman to manage the Red Team properly.

• If the EDL Focus Group had pursued the EDL sequence completely, it is 

likely this group would have questioned the G-switch sensor implementation or verification. Instead, this group focused almost exclusively on entry 

aerodynamics.

• Had the EDL Focus Group followed up, or the Red Team action item process 

forced a follow up with the Avionics Focus Group, the design and verification errors might have been found. 

Root Cause Category No. 4: Unfounded Confidence in Heritage Design

Root Cause 4.1: Inappropriate confidence in heritage designs. 

Facts:

• The Genesis Project was based on an assumption of considerable reuse of 

heritage designs from Stardust.

• The view was extensive throughout the Genesis Project, although not universal, that heritage hardware should be considered inherently more reliable 

than non-heritage hardware.

• An erroneous belief that the SRC-AU was a heritage, or partially a heritage 

design, and unfounded confidence in heritage designs in general led to five 

errors that contributed to the mishap: 

(1) Systems Engineering recycled the key drogue deployment 

requirement in the SRC-AU specification from Stardust without 

reconsideration; 

(2) the SRC-AU PIE used Stardust schematics without reconsideration; 

(3) the design reviews focused less attention to the details of the pyro 

firing circuitry design because the presenters and reviewers placed 

greater confidence in it than was justified; 

(4) the SRC-AU PIE used the similarity of the Stardust heritage design 

to perform verification of the G-switch sensor orientation, which was 

performed incorrectly; and 

(5) the EPS Red Team Focus Groups that reviewed the SRC-AU did 

not review the design or the verification methodology because they 

considered the likelihood of a design or verification problem with a 

heritage design to be unlikely. 
Pa g e 339 GGe n es e n 

Findings:

• A major misconception existed within much of the Genesis leadership and 

within the Red Team that heritage hardware meant a lower standard of 

review and verification was acceptable.

• It is likely that the design error would not have occurred or would have been 

discovered during verification had the same standards as those applied to 

new hardware been applied to the SRC-AU. 

Root Cause Category No. 5: Failure to “Test as You Fly”

Root Cause 5.1: G-switch sensor not identified as having a critical alignment in the 

Pointing and Alignment Document (Phasing Test Plan).

Facts:

• The Pointing Budget and Alignment Criteria Document (Phasing Test Plan) 

did not identify the G-switch sensor as having a critical alignment.

• The G-switch sensors may not have been included because such plans are 

typically produced by engineers concerned with hardware that has precise 

alignment requirements, such as star trackers or science instruments.

• Members of the Genesis Systems Engineering team approved the document.

Finding:

• Had the G-switch sensors been identified as alignment-critical and been 

included in the Pointing and Alignment Document, the verification of the 

sensors would have been performed properly. 
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 440 

Root Cause Category No. 6: Faster, Better, Cheaper (FBC) Issues

Root Cause 6.1: Faster, Better, Cheaper (FBC) philosophy: Cost-capped mission 

with threat of cancellation if overrun.

Facts:

• As proposed, selected, and confirmed on Genesis, the FBC philosophy had the 

following effects:

(1) Maximal science scope and focus on payload issues at the expense of 

the spacecraft, SRC, and ground systems.

(2) Low schedule and dollar reserves leading to significant adverse 

pressure on decision making.

(3) Focus on a low-risk implementation led to a reliance on heritage 

hardware which gave a false sense that mission risk was controlled 

and allowed the risks associated with the lower standards for heritage 

to go unrecognized.

(4) Very lean Systems Engineering team with heavy un-checked reliance 

on the subsystems teams for requirements and verification functions.

(5) Near total reliance by JPL on the LMSS team and processes with 

little cross-checking outside of payload and payload interface 

activities.

• Genesis was selected with only 11-percent budget reserve at confirmation 

and had only 7.2 percent at CDR. All involved (NASA, JPL, and LMSS) 

were convinced that because of the assumed heritage design, this was an 

acceptable position. 

• JPL asked LMSS to give up fee to cover other non-LMSS risk issues and 

avoid a project overrun of the cost cap. 

Findings:

• The project maintained the cost-cap, in part at the expense of adequate technical insight by JPL into the LMSS Flight System and at the expense of a 

complete and robust Systems Engineering function.

• The Agency was at fault for encouraging and accepting the FBC 

philosophy as described above.
Pa g e 414 GGe n e se n e 

6.0 Recommenda

The following 12 recommendations address the root causes and contributing factors identified in Section 5.0. 

The Board did not make recommendations at the direct root cause or contributing factor level since they were generally at too low a level to provide meaningful 

solutions. For example, the Root Cause 2.1 regarding inadequate requirements 

generation could be addressed directly by recommending requirements training 

for all Systems Engineers. However, although such training is widely available, 

poor requirements are still common. The same can be said for almost any of the 

other identified Project Management, Systems Engineering, or technical review 

root causes and contributing factors. The Board chose to address issues at a higher 

level. For example, in the case of inadequate requirements generation, the Board 

recommends addressing this problem at the Systems Engineering level, not the 

requirements level alone. When the causes of inadequate Systems Engineering 

are corrected, the various Systems Engineering failures uncovered in this mishap 

investigation will be addressed simultaneously. 

The primary recommendations have to do with correcting systemic failures within 

the technical review process that have led to inadequate technical reviews of SMD 

Projects. In addition to correcting the constituents of the traditional review process, Systems Engineering products and processes must be reviewed in significantly 

greater detail than is common today. The Board did not intend the recommendations to add additional reviews; they propose to execute the correct reviews and 

make them effective in probing a design and its processes. 

Although there will be increased project-level costs associated with implementing 

these recommendations, it is the Board’s view that any project-level cost increase 

should be offset by Agency-level savings resulting from fewer mission failures. 

Table 6.1 provides a mapping of root causes and contributing factors to the proposed recommendations.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 4242 

6.1 Recommendations to Address Project Management and Systems 

Engineering Failures:

The following recommendations address the System Engineering process failures 

and the Management issues raised in Section 5.2. The first recommendation proposes a review process to force discipline and completeness into the Systems Engineering process for all future Science Mission Directorate projects. The second 

recommendation is directed at those projects that are later in their project lifecycle 

and where the first recommendation may no longer be feasible. The third recommendation addresses overall strengthening of Systems Engineering within NASA’s 

contractors. The fourth recommendation addresses the issue of failure to clearly 

define responsibility through a complex spacecraft system. The fifth recommendation identifies the need to assign adequate Systems and Subsystems Engineers 

to projects. The final recommendation addresses the question of considering organizational structures that segregate separable elements of spacecraft, such as the 

SRC. 

Recommendation 1: Institute a Systems Engineering Plans, Progress, and Processes Review for all Science Missions Directorate projects as part of the normal 

Project Design Review process.

Discussion of Recommendation 1:

The Genesis mishap occurred mainly because of failures in NASA’s Systems Engineering process. This issue is recognized within the Science Mission Directorate community and is known to be a cause of several of the Directorate’s recent 

failures (MCO, MPL, TIMED, and CONTOUR). Given this, the Board believes 

it is necessary for NASA to develop a strategy to significantly strengthen that process. Although not a complete strategy, this recommendation should significantly 

increase the rigor of project Systems Engineering. 

Future projects should hold the proposed review as part of a project’s normal control gates. The project would be required to focus on the detailed Systems Engineering processes employed, review the detailed Systems Engineering results that 

led up to the control gate, and review the detailed Systems Engineering plans for 

reaching the next control gate. This review should be a multi-day event -- similar to a standard Subsystem review. Focus should not be solely on process and 

plans, such as the Systems Engineering and Management plan and the Configuration Management plan, but also on review of the technical products (reports, trade 

studies, requirements, verification results, etc.) that the Systems Engineering team 

has produced. Having to explain to a group of experienced peers one’s plans and 

progress in significant detail is the best method of ensuring an improved Systems 

Engineering function within the Science Mission Directorate.
Pa g e 443 GGe n es e n 

Successful implementation of this recommendation requires Project management 

buy-in, which will be evidenced by requiring that the forward plan at each control gate include a resource-loaded, detailed implementation schedule for Systems 

Engineering activities.

The Systems Engineering lead for the Mission Design Review should chair the recommended review and it should be staffed by experienced Systems Engineers and 

Project Managers. A set of standards for the review team and project team should 

be developed, as well as training to assure compliance with these standards. 

Recommendation 2: Hold a tailored version of the review for current Science 

Mission Directorate projects that are late in their lifecycle and for which a complete 

Systems Engineering Plans, Progress, and Processes Review may not be feasible.

Discussion of Recommendation 2:

Projects that are late in their lifecycle may not be able to support a detailed review 

of all of their preceding Systems Engineering activities; however, a review of the 

adequacy of the Systems Engineering processes and selected products leading to 

the recommended review could identify significant weaknesses. If a significant 

Systems Engineering failure were identified as part of the tailored review, a more 

detailed review of any issues uncovered should be performed. 

Recommendation 3: The Science Mission Directorate should place increased 

emphasis on a contractor’s Systems Engineering processes and teams when making contract and award fee decisions.

Discussion of Recommendation 3:

The size and scope of the Genesis Systems Engineering Team was reduced largely 

to minimize costs. By increasing the emphasis on Systems Engineering in the 

award of contracts and award fee, the Agency should be able to raise the level of 

Systems Engineering staffing contractors apply to NASA projects.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 4444 

Recommendation 4: The Science Mission Directorate should require projects 

to consider having Mission Mode Engineers from the Systems Engineering organization assigned to each mission mode (ascent, coast, entry, etc.) as a means of 

guaranteeing complete coverage of all system functions. 

Discussion of Recommendation 4:

Mission Mode Engineers would be responsible for all functions associated with 

their assigned mode of operation; including requirements and verification, insight 

into hardware and software designs, and operations. For example, the Genesis 

system operated in several ways, each exercising distinct subsets of the hardware 

and requirements in different ways and carrying distinct risks. For Genesis these 

included launch and commissioning in orbit; science operations; return to Earth; 

and entry, descent, and landing. 

It is not atypical for NASA or its contractors to assign Systems Engineers responsibility for particular subsystems -- tracking requirements, design, test, and operations 

of those subsystems. Typically, modes of operations are addressed by Operations 

Engineers. Although it is still appropriate to maintain Operations Engineers who 

are responsible for modes of operations, there may be advantages to assigning 

responsibility for a mode of operation to a member of the Systems Engineering 

team, on a part or full-time basis. Since most modes of operation involve multiple 

subsystems performing a system-level function, defining responsibilities by mode 

will better allow Systems Engineers to view the subsystems/boxes from a Systemlevel perspective, instead of a stove-piped subsystem perspective. Also, by assigning responsibilities for each mode of operation, coverage of each function within 

the spacecraft will, by definition, be covered by a Systems Engineer. 

Implementation of this approach should be left to individual projects; however, the 

MIB recommends that the Science Mission Directorate require its consideration. 

Regardless of the methodology chosen for implementation, it is essential that Systems Engineering functions be applied to each of the major modes.
Pa g e 445 GGe n es e n 

Recommendation 5: NASA and JPL should assign System and Subsystem/Discipline Engineers to projects to maintain insight into the contractor’s activities. 

Discussion of Recommendation 5:

In the Genesis case, JPL assigned too small a staff of System and Subsystem/Discipline Engineers to this contractor-managed project. The advantages that a NASA 

or JPL team bring to contractor-run projects are that they:

• allow for viewing problems from different perspectives/cross-checking,

• allow for identifying problems that the contractor alone may not recognize,

• force the contractor to defend its technical decisions more thoroughly, with the 

result that decisions are more thoroughly considered,

• provide a continuous review process to the project, identifying and correcting 

problems earlier and at a lower cost, and

• allow for insight into processes to ensure their adequacy or allow identification 

of needed changes.

In determining the proper NASA/JPL staffing, consideration must be given to the 

team’s skill sets and training.

Recommendation 6: Future Science Mission Directorate projects that contain separable spacecraft elements within a single system should consider organizing the 

elements as a separate spacecraft. All projects should ensure that separable spacecraft elements are analyzed and evaluated fully for their free-flight functions and 

mission success, whether or not this is implemented organizationally.

Discussion of Recommendation 6:

Although there may be sound reasons to organizationally treat a separable spacecraft elements as part of a single spacecraft, these reasons should be justified. 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 4646 

6.2 Recommendations to Address Inadequate Reviews:

Recommendation 7: The Science Mission Directorate should institute a significantly more rigorous and more probing Design Review process than currently 

exists. 

Discussion of Recommendation 7:

That improved design review process should include the following items.

• A greater involvement in the planning and managing of reviews at all levels of 

the system by the Systems Review Team.

• A process that includes System Review Team ownership of all reviews of Subsystems and instruments, the above-mentioned Systems Engineering Review, 

and of all box-level and software reviews.

• Mandatory membership at each review that accounts for all disciplines appropriate to the system, subsystem/instrument, box, or software under review.

• Significantly greater level of detail than has become typical at all levels of review 

– less concentration on chartsmanship and more review of design details, analyses, and other products over a multi-day period.

• Continuity and coordination of membership at the different levels of review 

throughout the project lifecycle to maximize review team effectiveness.

• Notification of review chair of all substantive changes after each review.

An ineffective technical review process in the Science Mission Directorate also 

contributed to the Genesis mishap. This issue, like the weakness of Systems Engineering, is commonly recognized within the Science Mission Directorate community and has been a cause of several recent failures (MCO, MPL, TIMED, and 

CONTOUR). The Board recommends significantly strengthening the technical 

review process by raising the quality of technical reviews. Efforts to strengthen 

the review process are underway at GSFC and JPL, and must be completed and 

extended to all Centers and contractors executing Science Mission Directorate 

projects.

Recommendation 8: Separate Red Teams, or other comparable review teams, 

should not be routinely depended upon to conduct design and verification reviews 

of projects. As part of instituting a more rigorous review process, standing independent review teams should be given the charter across the lifecycle of the project 

and the membership necessary to avoid having to appoint additional Red Teams 

late in the project lifecycle.

Discussion of Recommendation 8:
Pa g e 447 GGe n es e n 

If a project’s independent System Review Team cannot be staffed properly or 

trusted to perform the functions asked of Red Teams, then what purpose do the 

System Review Teams serve and why do they exist? The charter of technical Red 

Teams, such as the Genesis Red Team, is not generally outside the scope of a project’s System Review Team. With advanced consideration of any special staffing 

required, and a sufficient charter, there should be no reason to assign Red Teams 

to review the design and verification of a project. A System Review Team does not 

generally contain business support, but if this is required an augmentation to the 

team could be made to fill that need.

Red Teams require a significant amount of time to become technically conversant 

with a project, more time than they are generally given, and as a result, they are 

unable to productively contribute and their impact is typically small or negative. 

This can be avoided by relying on the Systems Review Team to perform that function. 

6.3 Recommendations to Address Heritage Design Issues:

Recommendation 9: Give the heritage hardware and software used in Science 

Mission Directorate projects the same level of review as new designs, to include 

requirements, design, manufacturing, and test reviews.

Discussion of Recommendation 9:

Generally throughout the Agency, heritage hardware (and software) are given 

less scrutiny than new hardware because of an often unfounded faith that heritage 

designs are qualified and will perform properly in a new application. There are two 

weaknesses with this approach. First, few heritage designs meet all requirements 

associated with a new application and almost invariably require some level of modification or reverification to meet their new requirements. Second, the designer of 

the heritage hardware is typically not available to support a new application, so the 

level of understanding of the heritage design is generally lower than it is for a new 

hardware designs – a risky position in which to place a project. 

Although cost, schedule, and technical risks for heritage hardware and software 

may be lower than for new hardware, that can only be the case if there is a full engineering understanding of the heritage design and the configuration maintained. 

To reach that level of understanding, for a new set of requirements and without 

the original designer, the heritage design must be reviewed as thoroughly as new 

hardware. Since the design, analysis, production, and verification products already 

exist for heritage designs, there should be no additional costs associated with pro-
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 4848 

ducing these products. An incremental cost to develop a full understanding of the 

products and to present them at a detailed box-level review should be more than 

offset by a reduced likelihood of failure.

In general, heritage elements may reduce detail design costs, but project managers 

should not expect the use of heritage elements to reduce the work in requirements 

management, verification planning, and review. It should not be expected that a 

high heritage system will require significantly less Systems Engineering resources 

and contradictory statements should be carefully evaluated.

Recommendation 10: Reverification of all requirements should be required until 

existing heritage verification can be certified as adequate by the responsible engineer and demonstrated to be adequate at the appropriate box-level review. Likewise, testing requirements should specifically target all configuration changes from 

the heritage design unless adequate detailed rationale can be developed.

Discussion of Recommendation 10:

Inadequate verification of heritage hardware is common on many projects due to 

the assumption that since it has been previously been qualified that it requires less 

scrutiny than new hardware designs. This is often not the case, since the applications are almost always somewhat different and/or the design has been modified 

to operate in a new application. This recommendation is intended to enforce a 

rigorous treatment of heritage hardware verification by requiring the same level of 

verification as is applied to new hardware.

6.4 Recommendation to Address “Test As You Fly” Issues:

Recommendation 11: Include a requirement to review ‘test as you fly’ and ‘phasing test’ plans and deviations specifically as part of the improved design review 

process. This should occur at every level of assembly as part of the verification 

discussion. 
Pa g e 449 GGe n es e n 

Discussion of Recommendation 11:

Test as you fly exceptions and phasing test plans are commonly presented at design 

reviews, but not always. The Science Directorate should apply this practice universally and the System Review Team should review it thoroughly.

6.5 Recommendations to Address Faster, Better, Cheaper Issues:

Recommendation 12: The process leading to project confirmation should identify 

the appropriate level of reserves for a project based upon its overall maturity, launch 

constraints (e.g., short window planetary mission vs. low-Earth orbit), complexity, 

and all identifiable cost, schedule, and technical risks.

Discussion of Recommendation 12:

The Discovery Program (and other competitively selected science missions programs) has evolved significantly since the time of the Genesis selection and confirmation. In particular, the AO’s now require significantly larger reserves and 

emphasize the identification and management of risk. However, it is not clear that 

the current selection and confirmation process adequately assess the unique risk 

levels for each mission to ensure that reserve levels are adequate for that mission. 
Table 6.1 Cross Reference of Root Causes and Contributing Factors to Recommendations.

Mapping of Genesis MIB Recommendations 

to Root Causes and Contributing Factors (P = 

Primary mapping; S = Secondary mapping)

Project Management and Systems Engineering RecommendationsR1) Institute a Systems Engineering Plans, Progress, and Processes Review for all Science Missions Directorate projects as part of the normal Project Design Review process.R2) Hold a tailored version of the review for current Science Mission Directorate projects that are late in their lifecycle and for which a complete Systems Engineering Plans, Progress, and Processes Review may not be feasible.R3) The Science Mission Directorate should place increased emphasis on a contractors Systems Engineering processes and teams when making contract and award fee decisions.R4) The Science Mission Directorate should require projects to consider having Mission Mode Engineers from the Systems Engineering organization assigned to each mission mode (ascent, coast, entry, etc.) as a means of guaranteeing complete coverage of all system functions. R5) NASA and JPL should assign System and Subsystem/Discipline Engineers to projects to maintain insight into the contractor’s activities. R6) Future Science Mission Directorate projects that contain separable spacecraft elements within a single system, should consider organizing the elements as a separate spacecraft. All projects should ensure that separable spacecraft elements are analyzed and evaluated fully for their freeflight functions and mission success, whether or not this is implemented organizationally.

1. Inadequate Project and Systems Engineering Management

Contributing Factor 1.1: Insufficient JPL 

Project Management and Systems Engineering 

insight into LMSS activities. P P P P 

Root Cause 1.1: Genesis Project Management 

and Systems Engineering did not perform due 

diligence with regard to reviewing briefing 

materials.

P P P

Contributing Factor 1.2: SRC not treated as a 

separate spacecraft. S S S P

2. Inadequate Systems Engineering Process 

Contributing Factor 2.1: Lack of a Systems 

Engineer assigned to the end-to-end Entry, 

Descent, and Landing function. S S S P

Root Cause 2.1: Inadequate requirements 

generation. P P P

Root Cause 2.2: Systems Engineering did not 

define detailed verification requirements for 

subsystems. P P P

Root Cause 2.3: Lack of documentation of 

changes made to verification methods. P P P

Root Cause 2.4: Systems Engineering verification process did not require consideration 

of a verifier’s qualifications nor incorporate 

multiple verifiers.

P P P

Root Cause 2.5: Systems Engineering was not 

required to review subsystem test procedures 

or verification results. P P P

Root Cause 2.6: Inadequate execution of 

System-level verification. P P P

Contributing Factor 2.2: Inadequate Systems 

Engineering staffing level. P P P P

3. The Review Process at All Levels Failed to 

Identify the G-Switch Inversion

Root Cause 3.1: Key individuals’ attendance 

was not required at project technical and 

drawing reviews. S S S 

Root Cause 3.2: SRC-AU Critical Design 

Review was too high-level to adequately 

assess the design. S S S 

Root Cause 3.3: JPL SMO gave the Red 

Team too little time to perform an adequate 

assessment. 

Root Cause 3.4: Inadequate Red Team management of focus groups. 

4. Unfounded Confidence in Heritage 

Root Cause 4.1: Inappropriate confidence in 

heritage designs. 

5. Failure to ‘test as you fly’

Root Cause 5.1: G-switch sensor was not 

identified as having a critical alignment in the 

Pointing and Alignment Document (Phasing 

Plan).

6. FBC Issues

Root Cause 6.1: The Faster, Better, Cheaper 

(FBC) philosophy: ‘cost-capped’ mission with 

threat of cancellation, if overrun. 
Technical Review Recommendations R7) The Science Mission Directorate should institute a significantly more rigorous and more probing Design Review process than currently existsR8) Separate Red Teams, or other comparable review teams, should not be routinely depended upon to conduct design and verification reviews of projects. As part of instituting a more rigorous review process, standing independent review teams should be given the charter across the lifecycle of the project and the membership necessary to avoid having to appoint additional Red Teams late in the project lifecycle.Heritage Hardware RecommendationsR9) Give the heritage hardware and software used in Science Mission Directorate projects the same level of review as new designs, to include requirements, design, manufacturing, and test reviews.R10) Reverification of all requirements should be required until existing heritage verification can be certified as adequate by the responsible engineer and demonstrated to be adequate at the appropriate box-level review. Likewise, testing requirements should specifically target all configuration changes from the heritage design unless adequate detailed rationale can be developed.Test as you Fly RecommendationsR11) Include a requirement to review ‘test as you fly’ and ‘phasing test’ plans and deviations specifically as part of the improved design review process. This should occur at every level of assembly as part of the verification discussion. FBC RecommendationsR12) The process leading to project confirmation should identify the appropriate level of reserves for a project based upon its overall maturity, launch constraints (e.g., short window planetary mission vs. low-Earth orbit), complexity, and all identifiable cost, schedule, and technical risks.

S

P

P

S P

S P

S P P

S P

P
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 5252 

7.0 Other Observa

Recommendat

The following observations were made during the course of the MIB activities. 

They do not relate directly to the incident; however, the Board believed they were 

significant enough to document and to make recommendations to the Science Mission Directorate.

7.1. Recording Key Engineering Telemetry

Observation: The Genesis SRC collected temperature strip data that indicated 

the effectiveness of the heat shield. These data could be useful for future applications or return capsules and were used to eliminate certain heat shield breach faults 

that might have led to the incident. The temperature strip data, which did not 

require any data recording devices, were the only entry data gathered on board the 

SRC. 

The Board believes that it might have been useful to the community at large to have 

gathered more information during the entry -- information that could be applied to 

other return capsule concepts -- including Exploration System vehicles.

Project Managers who are not required to gather data for other future missions 

make logical, pragmatic decisions based on their science requirements and funding limitations. As a result, the need to maximize science yield and minimize 

cost drive Project Managers to collect no more than is required for their specific 

mission. 

Recommendation: The Board recommends that the Agency determine for each 

mission what, if any, ancillary engineering data should be gathered that might 

have applicability to other NASA applications. The results should be provided to a 

Project Manager as a requirement with the understanding that there will be a cost, 

and probably a science return, impact of such a requirement. 

7.2. Missing Resistor

Observation: One of the Genesis fault tree items was number 2.8, Timer Jumpers 

Wrong, Causing Excess Delay. The following observations were made during the 

inspections and test performed to close out this fault tree item.

To implement each timing circuit, a constant clock signal of a 10-Hz frequency is 
Pa g e 553 GGe n es e n 

input to one 12-bit (12 output lines) binary counter integrated circuit for each of 

the different timing circuits (drogue chute deploy; drogue harness cut; main chute 

deploy; etc). Each circuit is independent of each other with the exception of the 

10-Hz oscillator.

The required timing is then selected by connecting some or all (depending on the 

desired time) of the counter outputs to a series of logic AND gates. 

The AND gate inputs are either connected to the counter outputs or to 5 V through 

installation of one (but not both) of a pair of resistors/jumpers (one pair for each 

AND input/counter output pair). One resistor of the pair, if installed, would connect the AND gate input to 5 V making that particular AND gate input a logic ‘1’ 

all of the time and thus not affected by, or connected to, its paired counter output 

(see resistors 1B and 2B in Fig. 7.1). However, if the other resistor of the pair were 

installed instead, it would connect the counter output to the AND input causing 

that AND gate input to follow the logic state of the counter output (see resistors 1A 

and 2A in Fig. 7.1). Only one of the pair should be installed (i.e., 1A or 1B but not 

both). By systematically choosing which of the resistors are installed, the 10-Hz 

input clock can be divided down to achieve the desired timing.

The Avionics/Pyrotechnics/EEE Parts Subteam reviewed the base-lined drawings 

and subsequent changes, made with respect to the placement of the timing resistors 

and the respective signal timing expected from those resistor positions.

Figure 7.1. 

Example of EST timing 

circuit and timing jumper/

resistor placements.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 5454 

During the inspection of the EST board from avionics box B, all the resistors were 

determined to be installed in the proper configuration to achieve the stated signal 

timing.

During the inspection of the EST board from avionics box A, one pair of resistors, 

R185 and R186, was found to be missing (i.e., one of the two (R186) should have 

been installed but neither one was). This particular pair of resistors is in the timing circuit for the drogue chute harness cable cutter. Figure 7.2 shows some of the 

resistor pairs and the missing resistors intended location.

With neither resistor installed, the input to one of the AND gates is left ‘floating’ 

in an indeterminate state. When a CMOS logic input, such as the AND gate is left 

floating, the chip can sometimes read that input as a logic ‘1’ and at other times as 

a logic ‘0’. Which logic level this input floats to (1 or 0) can be affected by several 

factors including humidity and surrounding electrical fields and cannot be predetermined.

For example, this particular board went through its testing program and never 

showed a failure of this timer.

What this floating input means for the timing circuit is that if the input happened to 

‘float’ to a logic ‘1’ during the timing sequence, the circuit would have worked as 

expected. However, if the input ‘floated’ to a logic ‘0’, that particular timing circuit 

would have failed to send a ‘fire’ signal to its pyro. Since there was a redundant 

Figure 7.2

Example of resistor pairs and the 

intended location of the missing 

resistors.
Pa g e 555 GGe n es e n 

circuit in the other AU, this missing resistor could have resulted in a loss of redundancy but not a loss of pyro function.

An inspection was then made to determine if there had been a resistor installed but 

knocked loose upon impact. Inspection inside the box showed no loose pieces and 

a review of the close-out photos for the EST board confirmed that the resistor was 

missing prior to flight.

LMSS designers and Quality Assurance then reviewed paperwork to determine if 

the component had been installed and then removed under direction.

A review of the ‘pick list’, which is the list of components input into an automated 

part insertion machine, showed that R186 was programmed into the machine for 

insertion. There was no indication that a post-assembly inspection noticed a missing resistor. 

Later in the project cycle, LMSS changed some of the jumper resistors to modify 

some of the pyro firing timings. Changes were made on three separate occasions 

under three different Redline Record Sheets (RRS). There were also two resistors 

replaced as a precautionary measure due to visual damage (scratches).

A review of change papers indicates that neither R186 or R185 were to be moved; 

however, resistors R187 and R188 had been moved -- the most recent move had 

been during the last set of changes. Resistor 187 is within approximately 0.1 inches 

of the R185/R186 pair. In addition, only R188 has a reference designator on the circuit board, which makes if difficult to locate the correct components on the board. 

There is a possibility that R186 was inadvertently removed during the modifications of R187/R188.

A microscopic view of the solder pads showed evidence of re-solidification of the 

solder on the R186 pads, which indicates that the solder had been melted, most 

likely when R186 was removed.

Whatever the reason for the missing resistor, the fact that it was not noticed indicates a breakdown in the quality inspection process.

While MIB members were inspecting the flight hardware, three issues became 

evident that made the inspections of the timing resistors difficult.

1. The assembly drawings did not show the placement for all of the timing resistors 

(i.e., a graphical representation that would help locate particular components).

2. The assembly drawings were not updated to reflect the changes to the resistor 
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 5656 

placement called out in the Redline Record Sheets (RRS); nor did the RRS 

paperwork have any graphical representation of the new resistor locations that 

could be used in a visual inspection.

3. Only a portion of the resistors actually had a reference designator (i.e., R123, 

R43, R11, etc.) printed on the printed wiring board (PWB). Therefore, it was 

very difficult to verify which resistor was which without using an Ohm meter 

and probing the board (something that would have been frowned upon during 

the assembly and testing of new ‘flight’ quality boards).

The visual inspection could have been made easier if the assembly drawings (or 

at least the RRS paperwork) had shown graphically, the new resistor locations and 

these drawings had been kept up to date.
Pa g e 557 GGe n es e n 

Recommendation 1. - Documentation

Assembly drawings should show, graphically, the location of all components. Any 

subsequent changes should be reflected in the graphical representation, preferably 

on the actual assembly drawings, but at the very least in the change paperwork. 

Text instructions are not sufficient for a proper inspection by themselves. The one 

exception would be for changes that are simply part number or value exchanges 

that do not require moving, removing, adding, orientation changes, or change in 

physical size.

Recommendation 2. – Documentation and Design

While it is not always practical to silk screen the reference designator for every 

component on to a PWB due to part density, a concerted effort must be made to 

use as many designators as possible and to provide references for all Select-AtTest components or jumpers that are subject to change. For those designators not 

printed on the PWB, the assembly drawing should be annotated in such a manner 

that the missing designators on the PWB can be easily identified on the drawings 

(bold or italicize those designators on the drawing).

Recommendation 3. – Requirements Maturity and Flight 

Electronics Hardware Build-up

By building the flight electronics and then making repeated changes, as the requirements matured, an environment was established that increased the likelihood of 

a mistake being made, especially given the verification and systems engineering 

problems identified in the Genesis program. When a design must be made more 

complex to provide flexibility to meet changing requirements, re-verification of the 

hardware after incorporating changes must be rigorous. Building up the final flight 

hardware should be avoided until the requirements have been finalized and verified 

on an Engineering (or development) unit. 

7.3. LMSS Mission Success

Observation: The LMSS Mission Success Organization in Space Exploration Systems was separated from LMSS Product Assurance in December 1999, but did not 

become active on Genesis until approximately March 2000, due to the Mars Polar 

Lander (MPL) loss investigation. LMSS Mission Success was formed too late and 

was too understaffed to have contributed to the Genesis mishap, either positively 

or negatively. However, it was the Board’s view that this organization could be 

strengthened to help avoid future mission failures.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 5858 

Recommendation: Strengthen the LMSS Mission Success organization to provide 

a strong, independent technical review capability for future LMSS missions. 
Pa g e 559 GGe n es e n 

8.0 Stardust Mission Recom

The Board suggests that the Stardust Mission implement the following recommendations. During the Genesis mishap investigation, the Board identified areas of 

investigation beyond the scope of their inquiry that will improve the understanding of Stardust components and mission risks. These items are listed below and 

organized into three broad categories: Hardware Test and Analysis, Contingency 

Planning, and Engineering Reviews.

The Board suggests that these recommendations, especially the six Hardware Test 

and Analysis recommendations, are carefully coordinated to ensure optimum use 

of the Genesis flight hardware.

Hardware Test and Analysis

1. Perform Destructive Physical Analysis (DPA) of Flight G-Switch Sensor

The G-switch sensor performs a critical function by sensing the conditions that 

start the recovery sequence. Post-flight spin tests indicated that the switch should 

have functioned given the actual entry conditions for Genesis. However, the Gswitch sensor specification is not detailed enough to be able to validate the function of the switch for space application. The Board recommends that a DPA be 

performed on the Genesis flight switches to evaluate the condition of the switch, 

to determine the space and flight environment effects on the switch’s function, 

and to determine if the switches will function properly during the Stardust entry 

conditions. The DPA should encompass the standard suite of EEE part evaluation, 

including a test of hermeticity. 

2. Evaluate Effects of G-Switch Sensor Side Load

During spin table tests of the Genesis flight G-switch sensors, an anomaly with one 

of the switches was detected during the 30° off-axis test. (Note: The 30° off-axis 

test represented a severe side load condition not indicative of the actual Genesis 

entry conditions.) During this test one of the G-switch sensors stayed in the closed 

position after the test was completed and the spin table had stopped. The switch 

released only after a very slight vibration was applied to it. The Board recommends 

that the Stardust reentry environment be evaluated to determine the G-switch sensor side load. Further, G-switch sensor performance should be characterized over 

a range of acceleration conditions and combined with the side load data to ensure 

proper G-switch sensor behavior in the anticipated environment.

3. Determine Effects of Space Exposure on Parachutes and Pyrotechnics
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 660 

The Genesis SRC was exposed to the space environment for 3 years, providing an 

excellent opportunity to evaluate the effects of long-duration space exposure on 

parachute materials and pyrotechnics. The results of such an evaluation program 

would directly benefit the Stardust Mission because Stardust used similar hardware. Furthermore, future space programs that use parachute systems, such as 

the Crew Exploration Vehicle Program, would also benefit from these data. The 

Board recommends that the Genesis parachute and pyrotechnic systems undergo 

a thorough test and evaluation program to determine the effects of long-duration 

space exposure on these systems. The results of this program should be used to 

assess the condition of the Stardust hardware. The evaluation program should 

include materials used in construction of the parachutes and spare parachutes to 

provide a baseline for comparison with the Genesis flight hardware. A detailed 

plan should be developed to guide the test and evaluation of the Genesis materials 

and pyrotechnics to ensure maximum effectiveness of the test program. Deliberations regarding the test of the pyros should include knowledgeable JSC personnel.

4. Investigate SRC Latch Operability

The Genesis SRC latches are a scaled-up copy of the Stardust latch mechanisms. 

Although Genesis telemetry indicated that the SRC latches were closed, post-flight 

inspections revealed that one latch was open. The Board recommends that Stardust investigate whether the latch opened on impact or if it failed to operate in 

flight. Results of the investigation should be used to assess the risk to Stardust. In 

addition, the investigation should attempt to determine the source of the deposit on 

the exposed bare metal of the latches.

5. Determine Ablation Margin For Heatshield and Backshell

The Genesis and Stardust heatshield and backshell use similar material and design 

characteristics. The Genesis ablation performance can be used to evaluate the predicted Stardust reentry performance margin. The Board recommends that Stardust 

update ablation models of the heatshield and backshell using Genesis core samples 

if necessary. The updated ablation models should then be used to assess Stardust 

performance margins.

6. Determine Effects of Space Exposure on Seals, Vents, and Science Canister 

Filter

The Stardust seals between the heatshield and backshell and the backshell vents are 

critical components of the reentry capsule that help prevent high-temperature gas 

penetration. The science canister filter prevents contamination of the science samples after recovery. Since the Genesis seals and filter are very similar to the Stardust design, Stardust performance can be predicted from analysis of the Genesis 

flight hardware. The Board recommends that the Genesis heatshield to backshell 
Pa g e 616 GGe n e se n e 

seals, the Genesis backshell vents, and the Genesis science canister filter be evaluated to assess degradation due to the space environment. Results of this evaluation 

should be applied to the Stardust seals, vents, and filter to predict their condition 

and performance characteristics.

Contingency Planning

7. Adopt an Incident Command System Process for Recovery 

Contingency Planning

The Board recommends that Stardust adopt an Incident Command System (ICS) 

process into its planning and execution of recovery ground contingency operations 

- this includes specifically those recovery ground contingency operations managed 

by JPL/LMSS. If a Stardust mishap were to result in the activation of a recovery 

ground contingency, the ICS process provides for effective command, control, and 

coordination of emergency response operations. ICS would have helped the Genesis Project with (1) identification, containment, and barrier control of “hot zones”, 

(2) hazardous material awareness training and personnel protective equipment 

provisioning, (3) clear contingency operations command structure, and (4) effective internal and external communications management. The ICS process is well 

established in the United States and is used by municipal, state, civilian federal, 

and military federal agencies:

http://www.fema.gov/nims/

http://www.fs.fed.us/fire/operations/niims.shtml

http://www.osha.gov/SLTC/etools/ics/what_is_ics.html

http://www.911dispatch.com/ics/ics_describe.html

Stardust recovery ground contingency plans should incorporate UTTR Safety protocols as well as clearly articulate the roles and responsibilities of the UTTR organization during contingency response operations.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 6262 

8. Review Recovery Contingency Scenarios

For the Genesis Project, recovery contingency planning and training were not 

sufficient to ensure an adequate response to the incident that occurred (i.e., more 

detailed planning and training for the “hard landing” scenario should have been 

performed). The Board recommends that the Stardust Project review all possible 

recovery contingency scenarios in coordination with the UTTR organization, prioritize the scenarios for planning and resource allocation and training, and subject 

them to an independent review. 

9. Provide Sufficient Schedule for Recovery Contingency Review and Personnel 

Training

The Genesis Project experienced schedule compression in the 3-month period prior 

to SRC return. The Board recommends that the Stardust Project create a recovery 

contingency planning schedule in coordination with the UTTR organization that 

allows sufficient time for (1) development of detailed procedures, (2) independent 

reviews (and associated follow up actions), and (3) contingency training.

10. Review Consistency and Adequacy of Recovery Contingency Requirements

Genesis utilized multiple documents at various organizational levels to identify 

and plan for recovery contingency scenarios. These documents led to requirement inconsistencies and operational missteps. The Board recommends that the 

Stardust Project perform internal reviews to assure consistency and adequacy of 

requirements (including UTTR requirements) throughout the documentation tree.

11. Assemble One Binder for Recovery Contingency Plans

The Genesis Project did not maintain one main binder containing all recovery contingency plans. Also, written recovery contingency procedures were not available 

to all elements of the recovery team. The Board recommends that Stardust assemble and maintain all recovery contingency documentation in a single binder with 

configuration-controlled copies deployed to appropriate elements of the recovery 

team. This recovery contingency documentation should include detailed procedures for field recovery personnel.
Pa g e 663 GGe n es e n 

Engineering Reviews

12. Evaluate Stardust System Phasing

During the Board’s investigation, LMSS personnel described a Stardust 

G-switch sensor spin table test. The description of the G-switch sensor test helped 

the Board to understand and mitigate concerns regarding Stardust G-switch sensor phasing. However, definitive test plans, procedures, and results were not presented to the MIB since this was outside the scope of the MIB investigation. To 

ensure that Stardust G-switch sensor phasing is correct, the Board recommends 

that an independent evaluation be performed of the Stardust G-switch spin table 

test. This evaluation should include a review of the Avionics schematics and closeout photos, as well as spin table test plans, test procedures, and test results. This 

independent team should also review any other system phasing aspects of Stardust 

that are deemed mission critical and are not already validated during flight. This 

will provide additional assurance to NASA that all aspects of system phasing are 

addressed for the Stardust Mission lifecycle.

13. Review Stardust Requirements and Verification Procedures

The Board’s investigation uncovered important gaps in Genesis requirement verification plans and practices. To ensure similar gaps do not exist in the Stardust 

requirement verification program, the Board recommends an in-depth review of 

the Stardust requirements decomposition and verification program. The scope of 

this review should include actual verification test procedures, data, and analyses. 

In addition, traceability of requirements to verification tests and evaluation of test 

program coverage should also be reviewed to show that all requirements are properly verified.

14. Review Recovery Parachute System 

The MIB identified a weakness in the verification and review process during the 

investigation of Genesis. Review teams, such as the Red Team, failed to examine 

the pyro and parachute hardware requirements and verification/qualification plans. 

Also, very little data on the Genesis pyros were provided in the packages presented 

to the review teams. The MIB focused limited resources on issues surrounding the 

G-switch sensors and did not perform a detailed investigation on the pyros or parachute system. Because the Genesis mishap prevented a flight demonstration of the 

pyro and parachute hardware and because little data exist to validate the Genesis 

design, the Board recommends that the Stardust pyro and parachute requirements 

verification and hardware qualification program be reviewed.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 6464 
Pa g e 665 GGe n es e n 

9.0 Nomenclature and

ACS Attitude Control Subsystem

AFT allowable flight temperature

AO Announcement of Opportunity

ATLO Assembly, Test, and Launch Operations

ATP Acceptance Test Procedure

AU avionics unit

BOL beginning of life

C&DH command and data handling

CCA circuit card assembly

CDR Critical Design Review

CEB concentrator electronics box

CFD Computational Fluid Dynamics

CIT California Institute of Technology, Pasadena, CA

CMIC command module interface card

DACS deployable aft conical segment

DCNS Digital Communications Network System

DGB disk gap band

DPA Destructive Physical Analysis

DSI/O dual slave input/output

DSMC Direct Simulation Monte Carlo

DSN Deep Space Network

DSS digital sun sensor

EDAC error detection and correction

EDL Entry, Descent, and Landing

EDU Engineering Development Unit
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 6666 

EEPROM electrically erasable programmable read-only memory

EGSE Electrical Ground Support System

EI entry interface

EMC electromagnetic compatibility

EMF electromagnetic force

EMI/EMC electromagnetic interference/electromagnetic compatibility

EMIC EPS module I/F card

EOL end of life

EPI EaglePicher, Inc., Phoenix, AZ

EPS Electrical Power Subsystem

EPS/PCA Power Control Assembly in EPS

EPS/PIU Power Initiation Unit in EPS

EST event sequence timer

ET Ephemeris Time

FAT (or AFT) flight allowable temperature 

(or allowable flight temperature)

FBC faster, better, cheaper

FET field effect transistor

FFRDC Federally Funded Research Development Center

FPGA field programmable gate array

FRB Failure Review Board

FSRD Flight System Requirements Document

FSW flight software

FTA Fault Tree Analysis

GEM/GIM Genesis Electron Motor/Genesis Ion Monitor

GPS global positioning system

GSE ground support equipment

ICD Interface Control Document
Pa g e 667 GGe n es e n 

ICS Incident Command System

I/F interface

I/O input/output

IR infrared

ISA incident, surprise, anomaly

IX interface connector

JPL Jet Propulsion Laboratory, Pasadena, CA

KSC Kennedy Space Center, FL

LANL Los Alamos National Laboratory, NM

LGA low-gain antenna

LMC Lockheed Martin Corporation

LMSS Lockheed Martin Space Systems, Denver, CO

LOI Lissajous Orbit Insertion

LSC load switch card

MAAF Michael Army Air Field, Dugway Proving Ground, UT

MAD motor articulation drive

MAR mid-air recovery

MDE motor drive electronics

MCSPF mission critical single point failures

MGA medium-gain antenna

MGO Mars Global Orbiter

MIB Mishap Investigation Board

MOS Mission Operations (team)

MPL Mars Polar Lander

MSRD Mission System Requirements Document

MSVDD Mission System Verification Description Document

MTF Multi-Function Test Facility

MVM master verification matrix
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 6868 

NAV Navigation (team)

NSI NASA standard (pyro) initiator

PARL precess to attitude on rhumb line 

PCA Planning, Control, and Analysis Team

PDR Preliminary Design Review

PDO Product Development Organization

PFR Problem Failure Report

PIE Product Integrity Engineer

PIM pyro initiation module

PIRS Product Integrity Reporting System

PIU pyrotechnical initiator unit

PMP Project Management Plan

PPIC payload & pointing I/F card

PRS Problem Reporting System (LMSS)

PTH plate through hole

PWB printed wiring board

R&R retention & release

RF radio frequency

S/C spacecraft

SCID spacecraft ID

SCLK spacecraft clock

SE Systems Engineer

SEE single event effects

SEU single event upset

SKM station keeping maneuver

SMO Systems Management Office

SMT surface mount technology

SNL Sandia National Laboratory, Albuquerque, NM
Pa g e 669 GGe n es e n 

SOC state of change

SPG single point ground

SRC sample return capsule

SSF Space Systems Factory

SSS spinning sun sensors

STRATCOM Strategic Command

STR system test requirement

STU special test unit

TCM trajectory correction maneuver

TLM telemetry

TPS Thermal Protection Subsystem

TVAC thermal vacuum

UHF ultra high frequency

UTC Universal Coordinated Time

UTTR Utah Test and Training Range, 

Dugway Proving Grounds, UT

VIS Verification Information Sheet

WCA worst-case analysis
GGe n e s e n e ii s Mii h a pp Re ppor t Pa g 770 

Genesis Dic

ACS Attitude Control Subsystem (on S/C bus). The ACS is 

primarily responsible for the pointing of a spacecraft 

during on-orbit operations.

AFT Allowable flight temperature (max allowable in flight 

operations, usually derated from the design qualification 

flight temp.

ATLO Assembly Test and Launch Operations. LMSS term 

for all pre-launch flight hardware (FSW) operations at 

the flight system level. Starts after box-level, subsystem, and assembly-level delivery to initial S/C assembly 

process and completes at launch. Usually only covers 

flight equipment operations and does not typically cover 

assembly and system-level engineering-model (qual) 

hardware testing.

AU Avionics unit. There are two AU’s in the Genesis SRC 

(redundant – AU1 and AU2). They contain the science 

motor controllers (array and canister hinge control used 

during the science mission) as well as a relay card and 

the entry event sequencer timers. The dual (logically 

AND’ed) G-triggers (roughly 3-g threshold) are on the 

relay card in the SRC and trigger the event sequence 

timer.

Backshell The back (aft body) of the SRC aeroshell. Used SLA561V (Viking Mars Entry) ablative TPS.

C&DH Command and Data Handling Subsystem (on S/C bus). 

This is the main (and only) general-purpose computer 

on board the S/C bus and it is a standard dual redundant design (fail-stop and resume) that is used on several 

operational LMSS spacecraft. It includes a RAD6000 

single board computer with 256 MB of EDAC memory 

and VME I/O. It also includes FLASH memory, I/O 

cards (including interfaces to the S-band RF command 

and telemetry), and local power supplies.
Pa g e 717 GGe n e se n e 

CDR Critical Design Review. A review of a design (at any 

level of assembly) typically held at the completion of the 

detailed design phase and prior to hardware build (or 

software coding). A standard NASA control gate. 

CMIC Command module interface card. Provided cross-string 

prime selection and cross-strapped memory inside the 

C&DH. This is the key internally dual-redundant crossstrap interface between the two C&DH strings. This 

card selects the prime string and holds the data that 

is “handed off” to the string that takes control after a 

swap.

Concentrator The portion of the science payload that electro-statically 

focused solar ions onto the concentrator’s four small targets.

Contributing Factor NPR 8621.1A defines a contributing factor as “an event 

or condition that may have contributed to the occurrence 

of an undesired outcome but, if eliminated or modified, 

would not by itself have prevented the occurrence.”

DACS Deployable aft conical segment. The aft-most part of the 

SRC backshell that is separated via three frangible bolts 

and is pulled off by the drogue chute. The DACS pulls 

out the main parafoil parachute as it separates.

Depassivation The process used on board the vehicle to remove (burn 

off) the passivation (oxide) layer that chemically accumulates in primary battery cells over days and months. 

This layer is useful for long missions when the battery 

must be stored as it prevents self-discharge but if not 

removed or reduced, it excessively limits the current that 

is provided from the battery. The SRC battery (LiSO2) 

must be (and was) depassivated prior to use by discharging through a high-wattage/low-impedance resistance 

for several minutes starting a few hours before entry (see 

official timeline).
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 7272 

DGB Disk gap band drogue parachute configuration. Top of 

chute is the disk (with a vent hole in the center), an air 

gap and a band of fabric on the outer-most perimeter. 

This configuration is directly derived from the Mars 

Viking DGB parachute design and qualification program 

(in particular the full-scale supersonic high-altitude Balloon-launched Deployment Test program in the 1970’s 

and the PEPP and SHAPE parachute test programs).

Discovery A NASA program that funds a series of principal investigator-lead, cost-capped, low-cost small missions. Genesis is the 5th Discovery Mission (after NEAR, Mars 

Pathfinder, Stardust, etc).

Divert The TCM that the S/C bus executes after SRC release so 

that the bus does not impact Earth.

Drogue A 6-ft DGB supersonically deployed parachute used 

for dynamic stability in the transonic phase and used to 

assist DACS pull-out and parafoil deploy.

DSN Deep Space Network. The ground system run by JPL 

for NASA that communicates with JPL deep space missions (X, S, and Ka-band stations at Canberra Australia, 

Goldstone CA, and Madrid Spain)

DSS Digital sun sensor – has a modest field of view of the 

sun, but is more accurate.

Dual initiator Pyro initiators that contain dual bridge wires. Used by 

the cutters and other R&R interfaces. Although similar, 

they are not NSIs.

E-4 hrs Entry minus 4 hours. 

EDL Entry, descent, and landing phase of the mission.

EEPROM electrically erasable programmable read-only memory 

(on S/C Bus).
Pa g e 773 GGe n es e n 

Entry ellipse The ellipse-shaped area at the entry radius that 

covers all a priori dispersions (navigation errors, 

S/C execution errors, estimated atmosphere density variations, estimated winds, etc), in a 99-percent sense. The 

a priori size of this ellipse was estimated to be 40x28 

km and centered on our agreed-to target based on endto-end Monte Carlo simulations.

EST Event sequence timer. The card in (each of) the AUs in 

the SRC that takes the G-trigger signals and times the 

various pre-programmed descent events (drogue deploy, 

DACS cutter, DACS and parafoil separation and power 

up of the GPS and beacon).

ET Ephemeris Time. A UTC-like time standard used by 

navigators.

FBC Faster, Better, Cheaper. A philosophy espoused during 

the 1990’s within NASA to develop spacecraft (typically 

small spacecraft) faster than was typical prior to that 

time. These missions were to be better in terms of technical performance and less expensive.

FFRDC Federally Funded Research Development Center. The 

Jet Propulsion Laboratory (JPL) is NASA’s only FFRDC. 

NASA provides funding for JPL, which is operated by 

the California Institute of Technology.

FSW Flight software (only on the Spacecraft in the case of 

Genesis)

GEM/GIM Genesis Electron Monitor/Genesis Ion Monitor. Los 

Alamos experiment. Used in flight to determine which 

solar wind regime the vehicle was in to control collection arrays. FSW autonomously used that knowledge to 

select which collector array was to be exposed (the algorithm was resident in the C&DH FSW on the S/C bus).
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 7474 

Global SeqVariables Software variables used by on-board sequences (such as 

the SRC release sequences) to test the status of autonomously controlled states such as ACS event completion 

or fault protection as well as to “mark” its place in the 

sequence (“mark and roll-back” function). These allowed 

the sequence to make key decisions to cancel or proceed 

with the critical actions. These variables are stored in 

the CMIC so that in the event of a C&DH side swap, 

the backup string can resume where the prime string left 

off.

GPS/DCNS Global Positioning System-based commercially procured locator used by the SRC.

Heatshield The front (fore body) of the SRC aeroshell. Used carboncarbon composite TPS.

Heritage A design with significant reuse of previously qualified 

hardware and/or software.

Inheritance Review Used by LMSS to indicate a review of a heritage design 

for applicability to a new mission for which the hardware/software had not been originally intended. 

I/O Input/output (e.g., electronic hardware between sensors 

and actuators and the computer).

ISA Incident, surprise, and anomaly. The closed-loop problem reporting system used by JPL and LMSS during the 

post-launch operational phase.

L-1 First Lagrangian Point. A point between the Earth and 

the sun where the gravity of each is equal. Genesis’ location for approximately 2 years during science operations.
Pa g e 775 GGe n es e n 

Landed ellipse The ellipse-shaped area on the ground at UTTR that 

covers all a priori dispersions (navigation errors, S/C 

execution errors, estimated atmosphere density variations, estimated winds, etc), in a 99-percent sense. The a 

priori size of this ellipse was estimated to be 40x28 km 

and centered on our agreed-to target based on end-toend Monte Carlo simulations. 

LGA Low-gain antenna for S-band 2-way communication at 

low data rate or when near Earth (there is one pointed aft 

and another pointed forward)

LOI Lissejous Orbit Insertion. The TCM that placed the S/

C (and SRC) into a looping “halo orbit” about the first 

Lagrangian point (also called L-1).

MAR Mid-air recovery. The Genesis SRC was intended to be 

captured during its descent on a parafoil by a waiting 

helicopter.

MGA Medium-gain antenna for S-band 2-way communication 

used during science mission.

Mortar The pyrotechnically activated pressurized drogue chute 

launcher. Had dual redundant NSI inputs each driven by 

one of the dual AU’s. 

NAV Navigation (team). Primarily performed at JPL.

NSI NASA standard (pyro) initiator (used to ignite the mortar). 

Parafoil The subsonic rectangular lifting SRC parachute that 

facilitates helicopter mid-air capture.

PARL Precess to attitude on rhumb line. An ACS turn mode 

for large off-sun turns that closes the loop using the sun 

sensor’s sun cone angle only. The Star Tracker is not 

used. Sun clock angle is not explicitly controlled during the turn due to the limited field of view of the Star 

Tracker.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 7676 

Patch Commands that contain FSW overlays that correct or 

augment the loaded FSW code. These are very rarely 

used and are usually added to correct design flaws in the 

loaded FSW.

PCA Planning, Control and Analysis Team (JPL & LMSS). 

Essentially the Genesis Mission Operations Team.

PDR Preliminary Design Review. A review of a design (at 

any level of assembly) typically held after design requirements have been flowed down to the lowest level and 

preliminary design solutions have been generated. A 

standard NASA control gate. 

PFR Problem Failure Report. The closed-loop problem reporting system used by JPL during the development phase.

PIE Product Integrity Engineer – An LMSS term for the 

engineer with responsibility (cost, schedule, and technical) for a specific item of hardware.

PIM card Payload interface module card. Controlled hinge separation and SRC separation on S/C side.

Proximate cause NASA NPR 8621.1A, NASA Procedural Requirements 

for Mishap Reporting, Investigating, and Recordkeeping, defines a proximate cause as “The event(s) that 

occurred, including any condition(s) that existed immediately before the undesired outcome, directly resulted 

in its occurrence and, if eliminated or modified, would 

have prevented the undesired outcome.” It is also known 

as the direct cause.

PRS LMSS Problem Reporting System used during development. Significant problems were copied into the JPL 

PFR system during development.

Qual The process (test and analyses) that prove that the design 

is qualified for the mission (typically environmental, but 

also functional and system-level interactions).
Pa g e 777 GGe n es e n 

R&R Retention and release devices (e.g., pyro cutting of frangible bolts, cable cutters, pyro separation nuts, etc.)

RAA Responsibility, Accountability, and Authority.

Root cause NPR 8621.1A defines a root cause as “one of multiple 

factors (events, conditions, or organizational factors) that 

contributed to or created the proximate cause and subsequent undesired outcome and, if eliminated or modified, 

would have prevented the undesired outcome. Typically, 

multiple root causes contribute to an undesired outcome.”

S/C Spacecraft – The space vehicle on which the SRC was 

the payload. 

Sabot The piston inside the drogue mortar that pushes the 

drogue out of the mortar canister. Once free of the vehicle, the sabot has its own square 14-inch wide parachute 

that is intended to keep it separate from the drogue.

SCLK Spacecraft clock (time). A monotonic time count maintained on board the spacecraft (bus) that corresponds to 

a UTC value that is interpreted on the ground and used 

to drive command execution times.

SE Systems Engineer. An engineer responsible for system 

design, requirements, and verification. SE’s may have all 

or part of these responsibilities, depending on the organization of the SE team.

Semaphore (FSW) A mechanism typically implemented via the real-time 

operating system that is used to serialize multi-task 

access to shared resources (like I/O). 

Semaphore (telecom) A discrete signal that, when issued, indicates that a particular state has been achieved. 

Sequence block A list of commands that are stored on board (as a file) 

that may be “called” by other sequences. Typically 

sequence blocks implement commonly used functions.
GGe n e s e n e ii s Mii h a pp Re ppo t Pa g 7878 

Sequence (seq) A list of timed commands that are stored on board (as 

a file) that can be initiated by a real-time command and 

will execute serially based on the time tag of that command or based on time relative to the previous command.

SKM Station-Keeping Maneuver. Small maneuvers that maintained the vehicle’s position and attitude during the science collection phase of the mission.

SOC State of charge (of a battery). Typically represented as a 

percent of a rechargeable (secondary) battery capacity or 

as an absolute amp-hr value. The S/C bus Ni-H battery 

can be charged above 100 percent. The SRC’s LiSO2 is 

not rechargeable (and is therefore called a primary battery).

SMO Systems Management Office

SRC Sample return capsule. The portion of the spacecraft that 

held the science collection materials and was returned to 

Earth.

SSS Spinning sun sensors. Off-sun angle estimate and spin 

rate. Has wide field of view (to allow large off-sun attitude excursions) but is not as accurate as the DSS.

Star Trackers Dual redundant star scanning imagers. Centroiding and 

star identification are done in the C&DH by ACS FSW.

TCM Trajectory Correction Maneuver. Used to invoke significant changes in the trajectory of the bus. While there 

were only 11 TCMs needed in the Genesis mission, there 

were many different modes of TCM operation that were 

possible depending on what direction and magnitude of 

TCM was needed relative to the sun and Earth.
Pa g e 779 GGe n es e n 

Thrusters The Genesis thrusters on the S/C bus are used to perform turns (e.g., to precess the S/C to a new spin attitude) and burns (e.g. for major maneuvers) as well as 

to control the spin rate. Since there is an asymmetry in 

the thruster arrangement, whenever the S/C performs a 

spin change or an attitude turn, a change in the vehicle’s 

velocity occurs as a side effect. 

TLM Telemetry.

TPS Thermal Protection Subsystem.

UTC Universal Coordinated Time. The time standard used 

for controlling and defining MOS and S/C events.

UTTR Utah Test and Training Range (Genesis landing site), 

near US Army Dugway Proving Ground.

x/D (entry) Ratio of center-of-mass distance from nose to entry body 

diameter. Should be small for dynamic stability during 

entry.

x/D (Parachute) Ratio of DGB drogue trailing distance to entry body 

(blunt body) diameter. Viking tests of DGB chutes mandates x/D = 8.5 or more. This is to ensure that parachute 

deployment occurs sufficiently far away from the wake 

of the entry body to inflate safely.
Ge n e si s Mi s h ap Re por t Pa g e 80 
a g e 81Ge n e s i s Mi 

10.0 Referen

Crookshanks, Clinton, Materials Laboratory Factual Report No. 04-133, National 

Transportation Safety Board, Nov. 2004.

Dekker, S., A Field Guide to Human Error Analysis. London: Ashgate, 2003.

Harrison, M., Diagnosing Organizations. New York: Sage.

Lockheed Martin Technical Memorandum, “Consolidation of Spacecraft to SRC 

Cable Deadfacing Analyses,” GN-TM-276, May 2001.

Loftus, E., Eyewitness Testimony, Harvard University Press, 1979.

Loftus, E., Memory, Reading MA: Addison-Wesley, 1980.

Marshal, Lee and Corey Kroll, “Genesis Spacecraft-SRC Cable Deadfacing 

Analysis Update,” June 2004.

NASA OSMA, Definitions of Root Cause Analysis and Related Terms, 2003.

NPR 8621.1A NASA Procedural Requirements for Mishap Reporting, Investigating, 

and Recordkeeping

Reason, J., Human Error, Cambridge: Cambridge University Press, 1990.

Reason, J., Managing the Risks of Organizational Accidents, London: Ashgate, 

1997.

Shappell, S. and D. Wiegmann, Analysis of Aviation Accidents: The Human 

Factors Analysis and Classification System, London: Ashgate, 2001.

Wasserman, S. and K. Faust, Social Network Analysis: Methods and Applications, 

Cambridge: Cambridge University Press, 1994.
Pa g e A-1 Ge n e s i s Mi s h ap Re 

Append

Letter Establishing the Genesis Mishap Investi

Boa
Ge n e s i s Mi s h ap Re por t Pa g e

September 10, 2004

Science Mission Directorate

TO: Distribution

FROM: Associate Administrator, Science Mission Directorate 

SUBJECT: Investigation Board for the Genesis Mishap

This memorandum is in reference to NPR 8621.1A “NASA Procedural 

Requirements for Mishap Reporting, Investigating, and Recordkeeping” 

and establishes the Genesis Mishap Investigation Board (MIB) and sets 

forth its responsibilities and membership. The Chairperson, Members of 

the Board, and supporting staff are listed in the enclosure.

I am establishing the Genesis MIB to gather information, analyze the facts, 

identify the proximate cause (s), root cause (s) and contributing factors 

relating to the Genesis, and to recommend appropriate actions to prevent a 

similar mishap from occurring again as specified in the referenced NPR.

The Chairperson of the Board will report to me.

The Board will 

• Obtain and analyze whatever evidence, facts, and opinions it considers 

relevant. 

• Conduct tests, and other actions it deems appropriate. 

• Take testimony and receive statements from witnesses.

• Impound property, equipment, and records as considered necessary.

• Determine the proximate cause (s), root cause (s) and contributing factors relating to the Genesis Mishap and document.

• Generate and prioritize findings.

• Determine the adequacy of contingency response planning and the 

appropriateness of the actual contingency response, to include the safing 
Pa g e A-3 Ge n e s i s Mi s h ap Re 

and securing of the spacecraft and the science payload, and the protection of response personnel. 

• Develop recommendations to prevent recurrence of similar mishaps.

• Provide a final written report to me with contents as specified in the referenced NPR.

The Chairperson will:

• Conduct Board activities in accordance with the requirements in NPR 

8621.1A and other pertinent NASA documents.

• Establish and document, as necessary, rules and procedures for organizing and operating the Board, including any subgroups, and for the 

format and content of oral or written reports to and by the Board.

• Designate any representatives and advisors, consultants, experts, liaison 

officers, or other individuals who may be required to support the activities of the Board and define the duties and responsibilities of those persons.

• Keep all concerned Genesis and support Center officials informed of the 

Board’s plans, progress, and findings.

• Designate another member of the Board to act as Chairperson in his or 

her absence.

• Document all meetings and retain records.

All Genesis program and support Center personnel must cooperate fully 

with the Board and provide any records, data, and other administrative or 

technical support and services that the Board may request.

The Board will begin its investigation during the week of September 13, 

2004, and will provide a final report within 75 calendar days of this letter. 

I will dismiss the Board when it has fulfilled its requirements.

A.V. Diaz

Enclosure
Ge n e s i s Mi s h ap Re por t Pa g e

Distribution:

Deputy Administrator/Mr.Gregory

Executive Officer, Integrated Financial Management Program/Mr. Ciganer

Associate Deputy Administrator for Systems Integration/Ms. Kicza

Chief of Staff/Mr. Schumacher

White House Liaison/Mr. Jezierski

Chief Scientist/Dr. Grunsfeld

Chief Health and Medical Officer/Dr. Williams

Director of Advanced Planning/Dr. Elachi

Chief of Safety and Mission Assurance/Mr. O’Connor

Chief Education Officer/Dr. Loston

Inspector General/Mr. Cobb

Associate Administrator for Exploration Systems Mission Directorate/Adm. Steidle

Associate Administrator for Space Operations Mission Directorate/Mr. Readdy

Associate Administrator for Science Mission Directorate/Mr. Diaz

Associate Administrator for Aeronautics Research Mission Directorate/Dr. Lebacqz

Chief Financial Officer/Ms. Sykes

Office of Procurement/Mr. Luedtke

Office of Small and Disadvantaged Business Utilization/Mr. Thomas

Chief Information Officer/Ms. Dunnington

Chief Engineer/Mr. Bradley

Associate Administrator for Institutions and Management/Mr. Jennings

Office of Human Capital Management/Ms. Novak

Office of Infrastructure, Management, and Headquarters Operations/Mr. Sutton

Office of Diversity and Equal Opportunity/Dr. Hayden-Watkins

Office of Security and Program Protection/Mr. Saleeba

General Counsel/Mr. Wholley

Chief of Strategic Communications/Dr. Burns

Office of Public Affairs/Mr. Mahone

Office of Legislative Affairs/Mr. Forsgren

Office of External Relations/Mr. O’Brien

Ames Research Center/Mr. Hubbard

Dryden Flight Research Center/Mr. Petersen

Glenn Research Center/Dr. Earls

Goddard Space Flight Center/Dr. Weiler

Jet Propulsion Laboratory/Dr. Elachi

Johnson Space Center/Gen. Howell

Kennedy Space Center/Mr. Kennedy

Langley Research Center/Gen. Bridges

Marshall Space Flight Center/Mr. King

Stennis Space Center/Adm. Donaldson

Air Force Safety Center/Major Gen. McFann

Air Force Safety Center/SES Alston
Pa g e B-5 Ge n e s i s Mi s h ap Re 

Append

Genesis Project Description, N

a.	 Mission Description

Genesis was the fifth in NASA’s series of Discovery missions, and the first 

US mission since Apollo to return extraterrestrial material to Earth for 

study. The purpose of the mission was to collect samples of solar wind and 

return them to Earth. Professor Don Burnett of the California Institute of 

Technology was the principal investigator and project team leader. The Jet 

Propulsion Laboratory (JPL) was the managing agency and provided the 

science canister. Los Alamos National Laboratory (LANL) provided the 

electrostatic concentrator for the science canister and the Electron and Ion 

Monitors. Lockheed Martin Corporation (LMC), acting through its Lockheed Martin Space Systems (LMSS) company, was the industrial partner 

and provided the spacecraft and sample return capsule (SRC). JPL and 

LMSS conducted mission operations. 

Genesis was to provide fundamental data to help scientists understand the 

formation of our solar system, reinterpret data from past space missions, 

and provide focus to many future missions. Analysis of the collector materials will give precise data on the chemical and isotopic composition of the 

solar wind. Once analysis is complete, the Genesis mission will provide:

(1) a major improvement in our knowledge of the average chemical composition of the solar system;

(2) isotopic abundances of sufficient precision to address planetary science 

problems;

(3) a reservoir of solar material to be used in conjunction with advanced 

analytical techniques available to 21st century scientists; and

(4) independent compositional data on the 3 solar wind regimes.

Launched on August 8, 2001, Genesis was positioned approximately one 

million miles from the Earth orbiting the Earth-Sun libration point L1 

which is outside Earth’s magnetosphere. It remained in a libration point 

orbit for 28 months. The mission trajectory is shown in Figure B-1. The 

capsule lid was closed on April 1, 2004 and the spacecraft returned for a 

day-time Earth entry.
Ge n e s i s Mi s h ap Re por t Pa g e

b. Space Segment

The spacecraft was spin stabilized, nominally spinning at 1.6 rpm. The 

spacecraft was a honeycomb disc with the sample return capsule (SRC) 

mounted toward the sun and the launch vehicle adapter below. Electronics were on the sun side of the disc outside the SRC. Star trackers were 

mounted on the perimeter viewing near radially but away from the sun. 

Two bladder propellant tanks were mounted at the perimeter with nutation 

dampers just outboard. Thrusters, 5 lbf for major maneuvers and 0.2 lbf for 

precessions and minor maneuvers, were mounted on the anti-sun side of 

the spacecraft to minimize potential for contamination of the collectors. 

The rechargeable nickel hydrogen spacecraft battery was mounted inside 

the launch vehicle adapter. The science collection configuration is shown in 

Figures B-2a and B-2b. Thermal control was provided by multi-layer insulation blankets that covered all of the components, as shown in the flight 

configuration picture, Figure B-3.

Figure B-1.

Genesis Mission in 

Earth coordinates.

Solar Panels

Science 

Canister

Cover Concentrator Collector 

Arrays

Sample

Return

Capsule 

Backshell

LGA-fwd 

(1 of 2)

Star

Trackers

Genesis 

Electron 

Monitor 

(GEM)

Propulsion Tank

(1 of 2)

* Genesis Ion Monitor (GIM) is caddy corner GEM, on +Xsv deck (fwd) 

* MGA and thrusters on -Xsv deck, towards -Xsv-axis (aft)

Digital Sun 

Sensor (1 of 2)

LGA-aft 

(1 of 2)

Command & 

Data Handling

Nutation

Damper (1 of 2) Figure B-2a. 

Spacecraft in science collection 

configuration, sun view.
Pa g e B-7 Ge n e s i s Mi s h ap Re 

Solar Panels

Battery Box

Nutation

Damper

(1 of 2)

Propulsion

Tank

(1 of 2)

Medium

Gain

Antenna

Thrusters 

0.2, 5.0 lbf 

(0.89, 22-N)

Launch

Adapter

* open canister cover and 

 SRC backshell not shown

GEM

Star

Trackers

Spinning

Sun Sensors 

(top deck) 

GIM 

(top

deck) Figure B-2b. Spacecraft in 

science collection configuration, 

anti-sun view.

Figure B-3. 

Flight configuration with 

thermal blankets installed.

Deployed solar array

Star trackers

N2H4 tank (1 of 2)

Electron monitor

Spacecraft

SRC

SRC heatshield

Deployable aft conic SRC backshell

section (DACS)

p y

Drogue parachute SRC vent (1 of 2)

cover (mortar

blows it off during

de lo ment
Ge n e s i s Mi s h ap Re por t Pa g e

c. Sample Return Capsule Detail

A cross section of the SRC design is shown in Figure B-4. The science canister is in the center with the SRC Avionics Units (AUs) and the SRC primary LiSO2

 battery mounted in the annulus around the science canister. 

The canister and the avionics decks are mounted to the heatshield structure. The SRC hinge opens the backshell off of the heatshield. The hinge is 

bolted to the heatshield and backshell with pyrotechnic bolts to separate 

the hinge from the SRC after pyrotechnic cable cutters sever the connection to the spacecraft power and control electronics. The backshell contains 

the drogue parachute on the centerline and the parafoil main parachute 

is packed around the drogue canister. A mortar is fired inside the drogue 

canister to propel the drogue parachute out through the mortar cover. The 

Deployable Aft Conical Section (DACS) is released by firing three frangible 

pyrotechnic bolts (DACS Retention & Release Mechanism) and the drag 

load on the drogue parachute pulls the parafoil out, taking the DACS with 

it. Prior to releasing the DACS, the cable to the drogue mortar is cut with a 

pyrotechnic cable cutter. The SRC is protected from entry heat loads by a 

carbon-carbon heatshield insulated from the structure by carbon foam and 

on the backshell by Super Light Ablator material.

DACS

Drogue Chute Main Parachute

Backshell TPS

Carbon-Carbon

Heatshield

DACS R&R Mechanism

Canister Support Strut

SRC Hinge (separated

prior to release)

Parachute Deck

Heatshield

Structure

Science 

Canister

Avionics Deck

Backshell 

Structure

206 kg

1.5 m diameter

1.0 m tall

Avionics Unit(B)

Unit A and Battery

Not shown

Not visible –

UHF, GPS

DACS

Drogue Chute Main Parachute

Backshell TPS

Carbon-Carbon

Heatshield

DACS R&R Mechanism

Canister Support Strut

SRC Hinge (separated

prior to release)

Parachute Deck

Heatshield

Structure

Science 

Canister

Avionics Deck

Backshell 

Structure

Backshell 

Structure

206 kg

1.5 m diameter

1.0 m tall

Avionics Unit(B)

Unit A and Battery

Not shown

Avionics Unit(B)

Unit A and Battery

Not shown

Not visible –

UHF, GPS

Figure B-4. 

SRC cross section 

(SRC hinge is separated from 

SRC prior to release).
Pa g e B-9 Ge n e s i s Mi s h ap Re 

The canister is shown in the science collection configuration with the SRC 

backshell open and the science canister open with the arrays deployed in 

Figure B-5. Thermal closure panels cover the avionics and battery.

Figure B-6 shows the AU A and the flight battery prior to installing the 

thermal closures. The collectors are partially deployed. Also visible in the 

upper left is the cable management system that restrained the cable between 

the heatshield and backshell during backshell opening and closing.

Deployable Collector Arrays

? Fixed?  Collector Array within Canister Cover

- Another ? Bulk Solar Wind?  Collector Array

SRC Lid Foils

- Metallic Foils within SRC Backshell

Metallic Glass Collector

Concentrator

Figure B-5. 

SRC open in science collection 

configuration.

Figure B-6. 

SRC prior to installing thermal 

closures – avionics box A and 

the LiSO2 battery in foreground.

Sample collector

deployable arrays

Science canister

Battery

Backshell

Avionics

unit A

Latch (1 of 4)

Seals – heatshield to

backshell (two)

Cable & guide

Science canister hinge
Ge n e s i s Mi s h ap Re por t Pa g e 

Temperature strips were attached to the inside honeycomb structure of the 

heatshield and backshell to record the maximum temperature reached during entry and heat soak back.

d. Entry, Descent, and Landing Nominal Timeline

Figure B-7 shows the entry and descent timeline for the mission. Trajectory 

correction maneuver (TCM) 10 was the first to move the targeting of the 

flight system from off-Earth to the Utah Test and Training Range (UTTR). 

TCM 11 was performed at Entry (E) –52 hours to establish a target, or 

instantaneous impact point, in NE Nevada so that the velocity increments 

added by the spin up and precession maneuvers and the push off of the 

SRC would put the target mid-air capture spot at the desired target point 

on UTTR. TCM 11 accurately established the target point so that TCM 12, 

a contingency maneuver that could have been performed at E --28 hours, 

was not needed.

Figure B-7 also summarizes the decisions that had to be made to verify that 

safe return was highly probable. The Green button decision was based on 

targeting, spacecraft, and ground systems all being “go” for entry at E --8 

hours. Spacecraft fault protection was constantly checking performance of 

all subsystems and would have autonomously proceeded through component fixes, rebooting, and even side swap to restore the spacecraft to operation if any fault had occurred. The ground control team could have signaled 

termination just before the release (the Red button) if a problem occurred 

* Red or dashed = contingency or

single failure anomaly

PACIFIC OCEAN

29 Aug

E-10.3d 07 Sep

E-28h

E-4h E-3.5h

Trajectory

Correction

Maneuver

#10 Sample

Return

Capsule

ENTRY

Spacecraft Bus Divert (w/o &

w/ SRC to 6mo backup)

125 KM

06 Sep

E-52h

Utah

Test &

Training

Range

02 Sep

E-6.3d

08 Sep

E-8h

Backup

TCM-10

Entry Maneuvers

SRC Release Enable/NoGo

Uplink (1)

TCM-12

TCM-11

Sample Return Capsule Release/

Release Disable (3)

Divert Disable (4)

Earth Entry Decision Mechanisms:

1. SRC Release Enable (ground command)

2. SRC Release Fault Protection (spacecraft flight software)

3. SRC Release Disable (ground command)

4. Divert Maneuver Disable (ground command)

FP Release Disable (2)

* Red or dashed = contingency or E=0 @ 8 SEP 2004 09:53 MDT

single failure anomaly

PACIFIC OCEAN

29 Aug

E-10.3d 07 Sep

E-28h

E-4h E-3.5h

Trajectory

Correction

Maneuver

#10 Sample

Return

Capsule

ENTRY

Spacecraft Bus Divert (w/o &

w/ SRC to 6mo backup)

125 KM

06 Sep

E-52h

Utah

Test &

Training

Range

02 Sep

E-6.3d

08 Sep

E-8h

Backup

TCM-10

Entry Maneuvers

SRC Release Enable/NoGo

Uplink (1)

TCM-12

TCM-11

Sample Return Capsule Release/

Release Disable (3)

Divert Disable (4)

Earth Entry Decision Mechanisms:

1. SRC Release Enable (ground command)

2. SRC Release Fault Protection (spacecraft flight software)

3. SRC Release Disable (ground command)

4. Divert Maneuver Disable (ground command)

FP Release Disable (2)

E=0 @ 8 SEP 2004 09:53 MDT

Figure B-7. 

Entry timeline. 
Pa g e B-11 Ge n e s i s Mi s h ap Re 

that would jeopardize safe entry into UTTR airspace. If termination had 

occurred after cable cut the SRC would have been on internal battery power 

and would have been dead in hours. Prior to cable cut the divert maneuver 

already on board and ready for execution would have placed the spacecraft 

with SRC into a backup orbit that would return to Earth for a second entry 

attempt in about 6 months. 

The final decision (Purple button) was the command to enable the spacecraft to execute the same divert maneuver to put the spacecraft en route 

to a safe disposal orbit. If the SRC did not separate from the spacecraft 

(i.e., if the cable had not fully cut and the two bodies were dangling with a 

soft connection), this final decision would cover the contingency. The final 

decision timeline is shown in Figure B-8.

Table B-1 is the summary timeline from the start of SRC battery preheat 

through post-divert tracking. It shows Deep Space Network (DSN) coverage at Canberra, Goldstone, and Madrid; SRC Release; Spacecraft Divert 

Timeline; spacecraft event descriptions; what was running in the Spacecraft 

Test Laboratory (STL); the interfaces in work at the time; and the ground 

team activities, e.g., polls, that were taking place to make the decisions for 

entry to proceed.

10:00

10:10

10:20

10:30

10:40

10:50

11:00

AU1 AU2

UnconditionalRestart

CC

1 2 3

11:5012:0012:1012:20

12:30

12:40

001020

3040

5000

10:50

11:00

11:1011:20

11:3011:4011:50

12:00

R

6

AU2done

10RPM

AU1done CC&hingeseparationdone

PARL

SC10done SC10done,usefixedPARLfile

7

SC15done

15RPM

PARLdone

4 5

12:40

12:00

12:1012:20

12:3012:40

10:5011:00

PURL

11

INS PARL DELTA-V

8 9 10

REDBUTTON

PURPLEBUTTON

0. LastprecessionoffinaltargetingTCMplacesS/Cpointingat28 degoff-sun,inSun-SRCReleasePlane.

UTC TIME EVENT RELATIVE COMMENTS OFF-SUN DELTA-V

1. 09/08/04 10:00 SRC AU Battery 1 Depass. -01:53 28 deg

2. 09/08/04 10:15 SRC AU Battery 2 Depass. -01:38 28 deg

3. 09/08/0410:31 CableCut&HingeSep. -01:22 SRConinternalbattery 28deg

4. 09/08/04 10:48 Spin Up to 10 RPM -01:05 Star Tracker OFF, above 2 rpm 28 deg 0.63 m/s

5. 09/08/0411:05 Precess toReleaseAtt. -00:48 UseS/Cbat.,FWDtoAFTLGA 145deg 1.55m/s

6. 09/08/04 11:32 Spin Up to 15 RPM -00:21 145 deg 0.37 m/s

==>REDBUTTONOPPORTUNIT Y<==

7. 09/08/04 11:53 S R C R E L E A S E 00:00 145 deg 0.31 m/s

==>PURPLEBUTTONOPPORTUN ITY<==

8. 09/08/04 12:09 Start Divert Sequence +00:16 Delay needed to allow sep. 145 deg

9. 09/08/04 12:14 Precess PARL to Divert Att. +00:21 105 deg 0.67 m/s

10. 09/08/04 12:21 Divert DELTA-V +00:28 One design w/ or w/o SRC 105 deg 25.12 m/s

11. 09/08/04 12:26 Precess PURL close to Sun +00:33 Start S/C bat. recharge <22 deg 3.02 m/s

12. 09/08/04 12:58 Data Playbacks +01:05 <22 deg

09/08/04 15:53 SRC Entry +04:00

Figure B-8. 

SRC release sequence timeline in 

Universal Time.

0. Last precession of final targeting TCM places S/C pointing at 28 deg off-sun, in Sun-SRC Release Plane.

UTC TIME EVENT RELATIVE COMMENTS OFF-SUN DELTA-V

1. 09/08/04 10:00 SRC AU Battery 1 Depass. -01:53 28 deg

2. 09/08/04 10:15 SRC AU Battery 2 Depass. -01:38 28 deg

3. 09/08/04 10:31 Cable Cut & Hinge Sep. -01:22 SRC on internal battery 28 deg

4. 09/08/04 10:48 Spin Up to 10 RPM -01:05 Star Tracker OFF, above 2 rpm 28 deg 0.63 m/s

5. 09/08/04 11:05 Precess to Release Att. -00:48 Use S/C bat., FWD to AFT LGA 145 deg 1.55 m/s

6. 09/08/04 11:32 Spin Up to 15 RPM -00:21 145 deg 0.37 m/s

==>  R  E  D    B  U  T  T  O  N    O  P  P  O  R  T  U  N  I  T Y  <==

7. 09/08/04 11:53 S R C   R E L E A S E 00:00 145 deg 0.31 m/s

==>  P U R P L E    B  U  T  T  O  N    O  P  P  O  R  T  U  N  I  T  Y  <==

8. 09/08/04 12:09 Start Divert Sequence +00:16 Delay needed to allow sep. 145 deg

9. 09/08/04 12:14 Precess PARL to Divert Att. +00:21 105 deg 0.67 m/s

10. 09/08/04 12:21 Divert DELTA-V +00:28 One design w/ or w/o SRC 105 deg 25.12 m/s

11. 09/08/04 12:26 Precess PURL close to Sun +00:33 Start S/C bat. recharge <22 deg 3.02 m/s

12. 09/08/04 12:58 Data Playbacks +01:05 <22 deg

09/08/04 15:53 SRC Entry +04:00
Ge n e s i s Mi s h ap Re por t Pa g e 

Table B-1. Summary Timeline, SRC Battery Prehe

Through Post-Divert Tracking.

SPACECRAFT/DSN

DOW DOY UTC PDT MDT E-hrs G C M EVENTDESCRIPTION STL INTERFACE EVENTDESCRIPTION

Tue 251 09/0716:00 09/0709:00 09/0710:00 23:55 D Start Preheat Sequence

Tue 251 09/0717:00 09/0710:00 09/0711:00 22:55 D SRCRLS

Tue 251 09/0718:15 09/0711:15 09/0712:15 21:40 D DSS-34 EOT

Tue 251 09/0718:15 09/0711:15 09/0712:15 21:40 DSS-66 BOT

Tue 251 09/0718:30 09/0711:30 09/0712:30 21:25 DSS-46 EOT

Tue 251 09/0718:30 09/0711:30 09/0712:30 21:25 D DSS-54 BOT

Tue 251 09/0720:00 09/0713:00 09/0714:00 19:55 D noop

Tue 251 09/0723:00 09/0716:00 09/0717:00 16:55 D OD ODCUTOFF-Eval#2

Tue 252 09/0800:00 09/0717:00 09/0718:00 15:55 D NAV->SRC DeliverEntryDispersions-Eval#2

Tue 252 09/0800:30 09/0717:30 09/0718:30 15:25 D noop

Tue 252 09/0801:00 09/0718:00 09/0719:00 14:55 D All Go/No-GoEvaluation#2Meeting

Tue 252 09/0801:45 09/0718:45 09/0719:45 14:10 D DSS-24 BOT

Tue 252 09/0801:45 09/0718:45 09/0719:45 14:10 D D DSS-16 BOT

Tue 252 09/0802:05 09/0719:05 09/0720:05 13:50 D D DSS-66 EOT

Tue 252 09/0802:05 09/0719:05 09/0720:05 13:50 D DSS-54 EOT

Tue 252 09/0803:00 09/0720:00 09/0721:00 12:55 D

Tue 252 09/0805:00 09/0722:00 09/0723:00 10:55 D OD ODCUTOFF-Eval#3(FINAL)

Wed 252 09/0806:00 09/0723:00 09/0800:00 09:55 D NAV->SRC DeliverEntryDispersions-Eval#3

Wed 252 09/0806:40 09/0723:40 09/0800:40 09:15 D DSS-34 BOT

Wed 252 09/0806:40 09/0723:40 09/0800:40 09:15 D D DSS-46 BOT

Wed 252 09/0807:00 09/0800:00 09/0801:00 08:55 D D All SRCReleaseGo/No-GoBriefing

Wed 252 09/0808:00 09/0801:00 09/0802:00 07:55 D D All SRCReleaseGo/No-GoPoll

Wed 252 09/0808:05 09/0801:05 09/0802:05 07:50 D D Uplink Divert/SRC Release Start

Wed 252 09/08  10:00 09/08  03:00 09/08  04:00 05:55 D D SRC Release Sequence Start

Wed 252 09/0810:00 09/0803:00 09/0804:00 05:55 D D SRCRLS:AU1Depassivation

Wed 252 09/0810:15 09/0803:15 09/0804:15 05:40 D D SRCRLS:AU2Depassivation

Wed 252 09/0810:20 09/0803:20 09/0804:20 05:35 D D DSS-24 EOT

Wed 252 09/0810:31 09/0803:31 09/0804:31 05:24 D SRCRLS:CableCut&HingeSep

Wed 252 09/0810:48 09/0803:48 09/0804:48 05:07 D SRCRLS:10RPMSpinControlStart

Wed 252 09/0810:50 09/0803:50 09/0804:50 05:05 D DSS-16 EOT

Wed 252 09/0811:03 09/0804:03 09/0805:03 04:52 D SRCRLS:PARLStart

Wed 252 09/0811:08 09/0804:08 09/0805:08 04:47 D SRCRLS:POLL#1

Wed 252 09/0811:32 09/0804:32 09/0805:32 04:23 D SRCRLS:15RPMSpinControlStart

Wed 252 09/0811:37 09/0804:37 09/0805:37 04:18 D SRCRLS:POLL#2

Wed 252 09/0811:45 09/0804:45 09/0805:45 04:10 D SRCRLS:POLL#3

Wed 252 09/08  11:53 09/08  04:53 09/08  05:53 04:01 D S R C   R E L E A S E 

Wed 252 09/0812:00 09/0805:00 09/0806:00 03:55 D SRCRLS:POLL#4

Wed 252 09/0812:08 09/0805:08 09/0806:08 03:47 D Divert Start Divert

Wed 252 09/0812:08 09/0805:08 09/0806:08 03:47 D DIV:15RPMSpinControlStart

Wed 252 09/0812:15 09/0805:15 09/0806:15 03:40 D DIV:PARLStart

Wed 252 09/0812:21 09/0805:21 09/0806:21 03:34 D DIV:DELTA-VStart

Wed 252 09/0812:26 09/0805:26 09/0806:26 03:29 D DIV:PURLStart

Wed 252 09/0812:33 09/0805:33 09/0806:33 03:22 D DIV:DivertComplete

Wed 252 09/0815:10 09/0808:10 09/0809:10 00:45 D DSS-34 EOT

Wed 252 09/0815:15 09/0808:15 09/0809:15 00:40 DSS-46 EOT

Wed 252 09/0815:20 09/0808:20 09/0809:20 00:35 HelicoptersTakeOff

Wed 252 09/08  15:55 09/08  08:55 09/08  09:55 ENTRY - 125km EIP

Wed 252 09/0816:01 09/0809:01 09/0810:01 +00:06 SRCMainChuteDeploy(22,000ft)

Wed 252 09/0816:10 09/0809:10 09/0810:10 +00:15 HelicopterstoFurtherstIntercept

Wed 252 09/0816:17 09/0809:17 09/0810:17 +00:22 SRC Capture (approximate)

Wed 252 09/0816:30 09/0809:30 09/0810:30 +00:35 IntermediateLanding

Wed 252 09/0817:00 09/0810:00 09/0811:00 +01:05 ReturntoMAAF

Wed 253 09/0900:00 09/0817:00 09/0818:00 +08:05

Wed 253 09/0900:40 09/0817:40 09/0818:40 +08:45 DSS-34 BOT

Wed 253 09/0901:00 09/0818:00 09/0819:00 +09:05 Divert Epilogue

Wed 253 09/0902:00 09/0819:00 09/0820:00 +10:05 Spacecraft Reconfiguration

Thu 253 09/0917:20 09/0910:20 09/0911:20 +25:25 DSS-34 EOT

DSN GROUND(FLIGHT)
Pa g e B-13 Ge n e s i s Mi s h ap Re 

The green bar in Figure B-9 shows the fault protection options that became 

more restricted as release was approached and time to execute complete 

recovery was no longer available. Also shown in the right column are the 

velocity increments imparted during the final maneuvering of the spacecraft to set up the proper attitude for SRC release and the spacecraft maneuvers for divert. 

The entry interface is defined as occurring at 125 km shortly before the 

sensible atmosphere is encountered. The entry, descent, and post-capture

timeline is shown in Table B-2. Specific heating, acceleration, range, and 

location plots are shown in Figure B-10. 

SRC Entry E=0H (09:53 MDT, 15:53 UTC) 

V = 11 km/s 

FPA=-8.0°

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

ALTITUDE 

DOWNRANGE

SRC Release Enable/No Go

E-8H SRC Separation

E-4H

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)

SYSTEM X

Figure B-9. 

Entry profile and timeline.. 

Genesis EDL Using REF08 Return, Site Relative

  Entry Interface

  Sensible Atmos

Drogue

Peak Heating 

Main

0

20

40

60

80

100

120

140

-1000 -800 -600 -400 -200 0

Surface Range To Go (km)

Altitude (km)

Genesis EDL Using REF08 Return, Time Based

Entry Interface

Sensible Atmos

Drogue      

Peak Heating 

Main

0

5

10

15

20

25

30

-300 -100 100 300 500 700 900 1100

Time from Entry Interface  (sec)

Deceleration (g's)

Genesis EDL Using REF08 Return, Time Based

  Entry Interface

  Sensible Atmos

Drogue

Peak Heating 

0  Main

50

100

150

200

250

300

350

400

450

500

-300 -100 100 300 500 700 900 1100

Time from Entry Interface  (sec)

Convective Heating (W/cm2)

Genesis EDL Using REF08 Return, Groundtrack

  Entry Interface

  Peak Heat

Drogue Deploy

37

39

41

43

45

47

49

-129 -124 -119 -114 -109

Longitude  (deg)

Latitude (deg)

Genesis EDL Using REF08 Return, Site Relative

  Entry Interface

  Sensible Atmos

Drogue

Peak Heating 

Main

0

20

40

60

80

100

120

140

-1000 -800 -600 -400 -200 0

Surface Range To Go (km)

Altitude (km)

Genesis EDL Using REF08 Return, Time Based

Entry Interface

Sensible Atmos

Drogue      

Peak Heating 

Main

0

5

10

15

20

25

30

-300 -100 100 300 500 700 900 1100

Time from Entry Interface  (sec)

Deceleration (g's)

Genesis EDL Using REF08 Return, Time Based

  Entry Interface

  Sensible Atmos

Drogue

Peak Heating 

0  Main

50

100

150

200

250

300

350

400

450

500

-300 -100 100 300 500 700 900 1100

Time from Entry Interface  (sec)

Convective Heating (W/cm2)

Genesis EDL Using REF08 Return, Groundtrack

  Entry Interface

  Peak Heat

Drogue Deploy

37

39

41

43

45

47

49

-129 -124 -119 -114 -109

Longitude  (deg)

Latitude (deg)

Figure B-10. 

Atmospheric entry profile. 
Ge n e s i s Mi s h ap Re por t Pa g e 

Table B-2. Entry, Descent, and Post-Capture Timeline.

Time Event Description_____________

E – 4 hrs USAF Strategic Command begin tracking

E - 2 hrs Collect weather data on wind velocity and 

azimuth, temperature, pressure, and density vs. 

altitude

Entry Defined at 125 km above 6378 km spherical radius 

(848 km uprange)

E + 40 sec Begin UTTR infrared and cine tracking [if clear 

skies] (80 km MSL altitude, 430 km uprange, 7o 

elevation)

E + 59 sec Peak heating (60.4 km MSL altitude, 266 km 

uprange)

E + 71 sec Peak g’s (51 km MSL altitude, 137 km uprange,

20o elevation)

E + 121 sec 3 g’s timer trigger (34.4 km MSL altitude, 12 km 

uprange, 71o elevation)

E + 127 sec Drogue chute mortar deploy at Mach 1.8 (33 km 

MSL altitude, 9 km uprange, 75o elevation)

E + 140 sec SRC decelerated to Mach 1 (30 km altitude, 4 km 

uprange, 82o elevation)

E + 220 sec Enter UTTR airspace from above (17.7 km MSL 

altitude, 0 km uprange, 90o elevation)

E + 381 sec Deploy main chute by releasing DACS/drogue 

(6.7 km MSL altitude), begin DCNS and UHF 

tracking

E + 20 min Mid-Air Retrieval (first pass) (2.4 km MSL 

altitude)

E + 24 min Latest MAR opportunity (1.3 km MSL altitude)

MAR+12 min Intermediate landing touchdown

MAR+20 min min Lift-off and fly to MAAF

MAR+44 min min Nominal landing at MAAF

MAR+2 hrs hrs Purge established on canister

MAR+5 days Canister and other hardware delivered to JSC

Science assessment begins
Pa g e B-15 Ge n e s i s Mi s h ap Re 

The post-mid-air capture timeline was driven by getting a nitrogen purge 

on the science canister within 2 hours. The timeline was dependent on 

where in the range the capture was made which could significantly change 

the time to reach Michael Army Air Field (MAAF). Intermediate landing 

was expected to take 10 to 12 minutes to reach the ground and about 5 

to 8 minutes on the ground but the low-speed transit to the landing site 

could vary depending on the On-Site Range Commander’s assessment of 

the safety of prospective landing sites. 

Once the SRC had touched down at MAAF on the apron north of Building 

1012, the SRC was to be rolled into the entry area, the vent covers installed 

during intermediate landing lifted, and safety experts from LMSS and NASA 

Johnson Space Center (JSC) would check the SRC interior gas for HCN, CO, 

and SO2. Before lifting the backshell, the safety team would sample the interior gases again. If toxic gases were present, LMSS and JSC personnel wearing 

Self Contained Breathing Apparatus (SCBA) would open the backshell and 

establish the nitrogen purge while other personnel maintained a safe distance 

from the SRC. The safety team was to saw the latches attaching the backshell 

to the heatshield. The SRC could then be opened by lifting the backshell.

After the safety team purged the nitrogen from the science canister, the timeline was more relaxed. The recovery team would remove the thermal closeout panels to gain access to disconnect and remove the battery, which was the 

next time-sensitive item to be accomplished before completing operations on 

September 8.

e. Drogue and Parafoil Parachute Deployment System Description

As shown in Figure B-10, the deceleration of atmospheric entry first builds 

with increased drag on the capsule as the ambient atmosphere becomes 

more dense, reaches a peak deceleration of 22 g’s, and then decreases as the 

capsule slows. It was intended that the SRC avionics G-switch sense when 

the increasing deceleration reached 3 g’s to arm the pyrotechnic initiation 

circuitry. After reaching the peak deceleration, the avionics were to sense 

the decreasing transition to initiate the timers leading successively to the 

firing of the drogue mortar, drogue harness cable cutter, drogue aft conical 

section retention bolt cutters leading to the release of the parafoil, and turn 

on of the GPS transceiver and UHF beacon transmitter. The timing of these 

events is shown in Table B-3. Redundancy was designed into the AU by 

incorporating firing circuits in each unit for the critical pyrotechnic events. 
Ge n e s i s Mi s h ap Re por t Pa g e 

A positive firing signal from the timing chain in either AU was sufficient to 

fire the respective pyrotechnic device. 

Table B-3. SRC Pyrotechnic Device Firing Time

Pyrotechnic Device Time of Fire Command

after G-switch

opening, sec

Remarks

Drogue mortar 5.7 Two circuits each in 

AU A and B

Drogue harness cable 

cutter 80.6 Two circuits each in AU A and B

DACS bolts, 3 fired 

simultaneously 259.6 Two circuits each in AU A and B

GPS transceiver 261.4 One circuit each in 

AU A and B

UHF beacon 

transmitter 261.4 One circuit each in AU A and B

Note: Each of the “ANDed” timer signal outputs is replicated four times to produce the 

distinct timing events.

Figure B-11 is a simplified block diagram of the SRC avionics system pyrotechnic firing system. The low-pass filter is designed to prevent inadvertent G-switch circuit atmospheric transients (buffeting) as the increasing 

deceleration passes through 3 g’s . The G-switch sensors are ‘ANDed’ to 

preclude a single switch failure from prematurely issuing a deploy signal. 

The AUs are referred to in development phase documentation as 1 and 2 or 

A and B alternatively with 1 = A and 2 = B.

Figure B.11.

SRC avionics 

pyrotechnic firing 

system.

Avionics Unit 1

G

Switch1

G

Switch2

Timer2

Timer1

And

NSIs

5 places

A

B

G

Switch1

G

Switch2

Timer1

Timer2

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

Press

xducer

Enable Plug

Test Point

Test Point

Avionics Unit 1

G

Switch1

G

Switch2

Timer2

Timer1

And

NSIs

5 places

A

B

G

Switch1

G

Switch2

Timer1

Timer2

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

Press

xducer

Enable Plug

Test Point

Test Point
Pa g e B-17 Ge n e s i s Mi s h ap Re 

The AU block diagram is shown is Figure B-12. The primary functions 

performed by the Motor Drive Electronics (MDE) board were completed 

when the science canister and the SRC were closed on April 1, 2004. During the SRC Release Sequence, the relay card and the FPGA on the MDE 

board are used only to connect the SRC LiSO2 batteries to the depassivation resistors attached to the interior of the heatshield first and then to 

the Event Sequence Timer (EST) board to power it through entry and post 

entry operation of the GPS transceiver and the UHF beacon. The G-switch 

sensors were mounted on this relay card for entry, although voltage was 

applied from the EST card.

Figure B.12. 

SRC avionics unit.
Ge n e s i s Mi s h ap Re por t Pa g e 

The EST block diagram is shown in Figure B-13. The G-switch sensor initiates all the R-C timer circuits set to fit the entry profile (see Table B-3 event 

times). The drogue parachute stabilizes the capsule during the passage 

through transonic velocities, nominally being deployed at Mach 1.8. The 

drogue cable cut could be done anytime between drogue deploy and DACS 

firing. The DACS firing is timed to correspond to about 22,000 ft (72 km) 

above MSL. The pressure transducer is a back-up to timed parafoil deployment but is switched on by a timer sequence initiated by the G-switch sen

sor. It is intended for back-up initiation for parafoil deployment in case the 

estimated timing of the descent sequence was incorrect. It is not intended 

as a back-up to the G-switch sensor. The redundant AU circuits are cross 

strapped and the boxes are cross strapped, as shown in Figure B-13. The 

UHF beacon and the GPS transceiver provide location information in case 

of a failed Mid-Air Retrieval.

The component of interest is the Aerodyne 7200-6-000 3-g acceleration 

switch, referred to herein as the G-switch sensor. The G-switch sensor 

drawing is shown in Figure B-14. The acceleration direction required to 

close the switch is marked on the drawing. An X-ray of the G-switch sensor is included in Figure B-14 showing how the spring mass and contact 

are oriented inside the cylinder. The closure lip provides a good orientation reference between the photograph of the exterior and the X-ray of the 

interior of the G-switch sensor. When mounted in the correct orientation, 

the internal plunger would be compressed against its spring during SRC 

deceleration upon entering the atmosphere. When the deceleration reached 

approximately 3 g’s , the plunger would have touched an electrical contact 

in the end of the switch, closing the circuit and arming the EST. When the 

Figure B-13.

Event sequence timer.
Pa g e B-19 Ge n e s i s Mi s h ap Re 

deceleration dropped below 3 g’s as the capsule slowed, the plunger would 

have been pushed away from the contact, breaking the circuit and causing 

the EST to start, leading to the successive deployments of the drogue and 

parafoil. 

Figure B-14. 

Aerodyne 7200-6-000 

acceleration switch 

(G-switch sensor) drawing 

and X-ray.

Pa g e C-21 Ge n e s i s Mi s h ap Re 

Appendix

Fault Tree: Process and 

Proprietary and/or Export Control Se

remove
Ge n e s i s Mi s h ap Re por t Pa g e 

1.1

Spacecraft Bus Sequence Wrong

1.2

Power State of Circuits Incorrect (Relays)

1.3

Power Electronics Design Flaw

1.4

Power Disconnected on Entry

1.5

Entry Thermal Environment Effects

1.6

Inadequate Battery Voltage and Power

1.0

Electrical Power Failure in SRC

2.1

G Switch did not active sequencer

2.2

Low Pass Filter wrong time constant

2.3

Reset on Timer Triger

2.4

Oscillator Frequency Incorrect

2.5

Latent Fault due to high voltage discharge

2.6

Pyro Ballast Resistors damaged in test

2.7

Timing of AND circuits out of phase

2.8

Timer Jumpers wrong causing excess delay

2.9

EMI Disrupted circuit operations

2.10

Environment effects on Avionics

2.11

Cross-strapped pressure transducer interfers with fire command

2.12

Avionics shorted

2.13

Fuses open

2.0

SRC Avionics Failure

3.1

Circuits not connected to Pyro

3.2

Harness Open

3.3

Harness Shorted

3.0

Harness/Connector Failure

4.1

Pyro Failed

4.2

Drogue parachute did not deploy

4.0

Drogue System Failure

Drogue Not Deployed

1.1.1

Battery online command incorrect

1.1

Spacecraft Bus Sequence Wrong

1.2.1

Cable cut effects

1.2.2

Spin Up effects

1.2.3

Separation Shock Effects

1.2.4

Entry Load effects

1.2.5

Power off Transient in MDE toggles power relays

1.2.6

Relay did not connect to EST position

1.2

Power State of Circuits Incorrect (Relays)

1.3

Power Electronics Design Flaw

1.4.1

Battery Enable plug came loose

1.4.2

Entry loads disconnecteed Power Connectors

1.4

Power Disconnected on Entry

1.5.1

Entry Plasma effect on cut cables

1.5.2

Overheating and shorting of cables

Overheating and damage of battery

1.5

Entry Thermal Environment Effects

1.6.1.1

Extrernal Shorts Drained Battery

1.6.1.2

Battery Drained before Entry - Excess Avionics Load

1.6.1.3

Deadface drained battery

1.6.1

Excessive Electrical loads

1.6.2.1

Battery Drained before Entry - bad power model

1.6.2.2

Battery Temp too low in flight

1.6.2.3

Battery stored at too high a temp in flight

1.6.2

Inadequate battery

1.6.3

Mechannically damaged battery

1.6.4

Battery thermostat open on EDL

1.6.5

Depassivation not complete

1.6

Inadequate Battery Voltage and Power

1.0

Electrical Power Failure in SRC

Appendix C

Fault Tree D
Pa g e C-23 Ge n e s i s Mi s h ap Re 

2.1.1

Improper Orientation of the G Switch

2.1.2.1

G switch cannot handle design spin load

2.1.2.2

Spin rate exceeded g swithc capability

2.1.2.3

G switch cannot handle design Angle of Attack loads

2.1.2.4

Angle of Attack exceeded g switch capability

2.1.2

Loads prevented G Switch Activiation

2.1.3

High Freq Chatter Activation Interference

2.1.4

Space Effects rendered G Switch unusable

2.1.5

G Switch shorted at test connector

2.1.6.1

Loads never reached trigger level

2.1.6.2

Loads never dropped below trigger prior to impact

2.1.6

G load profile off-nominal

2.1.7

Incorrect G Switch installed

2.1.8

Mechanical failure of G Switch

2.1

G Switch did not active sequencer

2.2.1

Improper Filter Design

2.2.2

Entry dynamics exceeded filter capability

2.2

Low Pass Filter wrong time constant

2.3

Reset on Timer Triger

2.4

Oscillator Frequency Incorrect

2.5

Latent Fault due to high voltage discharge

2.6

Pyro Ballast Resistors damaged in test

2.7

Timing of AND circuits out of phase

2.8

Timer Jumpers wrong causing excess delay

2.9.1

Internal EMI

2.9.2

External EMI

2.9

EMI Disrupted circuit operations

2.10.1

Space (Micrometeoriod, Debris, Radiation, Vacuum)

2.10.2

Entry Effects - Thermal

2.10.3

Entry Effects - Plasma

2.10.4

Entry Effects - Mechanical

2.10

Environment effects on Avionics

2.11

Cross-strapped pressure transducer interfers with fire command

2.12

Avionics shorted

2.13

Fuses open

2.0

SRC Avionics Failure
Ge n e s i s Mi s h ap Re por t Pa g e 

4.1.1.1

NSI is a dud/degraded/contaminated

4.1.1.2

Inadequate current for required duration

4.1.1.3

Broken bridge wire

4.1.1.4

Shelf life exceeded

4.1.1

NSI Failed to Fire

4.1.2.1

No propellant in booster charge

4.1.2.2

Wrong amount/propellant in booster charge

4.1.2.3

Booster charge is a dud/degraded

4.1.2.4

Foreign Object

4.1.2.5

Propellant contamination

4.1.2.6

Incomplete combustion of propellant

4.1.2

Mortar booster charge failed to fire

4.1.3

TPS Failure (Breach or excess temps)

4.1

Pyro Failed

4.2.1.1

Insufficient Gas pressure generated by booster charge

4.2.1.2

Manifold failed to contain/transfer energy

4.2.1

Mortar lid not expelled

4.2.2

Sabot Jammed

4.2.3

TPS Failure (Breach or excessive temp)

4.2

Drogue parachute did not deploy

4.0

Drogue System Failure

3.1.1

Connected wrong

3.1.2.1

Separation Shock

3.1.2.2

Entry Loads

3.1.2.3

Improper Installation

3.1.2

Connectors loose or demated

3.1.3

Bent pin/Contamination/Open in connectors

3.1

Circuits not connected to Pyro

3.2.1

TPS Failure (Breach or excessive Temp)

3.2.2

Micrometeroid Damage/Debris

3.2.3

Harness flexing e.g., Hinge movement

3.2

Harness Open

3.3.1

TPS Failure (Breach or excessive temp)

3.3.2

Micrometeroid Damage/Debris

3.3.3

Harness flexing e.g., Hinge movement

3.3.4

Test Port plug shorted out

3.3

Harness Shorted

3.0

Harness/Connector Failure

Ge n e s i s Mi s h ap Re por t Pa g e 

Appendix C

Fault Tree Sprea
Pa g e D-27 Ge n e s i s Mi s h ap Re 

Appendx D Con

Proprietary and/or Export Control Se

remove

D-9 Human Factors and Organizational Analysis..........................

Pa g e D-29 Ge n e s i s Mi s h ap Re 

Appendix

 Human Factors and Organizational

Patricia M. Jones

Executive Summary

This report is a detailed analysis of human and organizational factors that 

contributed to the Genesis mishap. It focuses on decision making, management, and communication issues. Through detailed analysis of interview 

transcripts and an organizational communication survey, four layers of 

contributions have been identified: individual human error in engineering and design; preconditions relating to team coordination and individual 

readiness; flaws in project management and systems engineering practices; 

and organizational factors related to the pervasive influence of the FasterBetter-Cheaper corporate culture at the time of the Genesis design.

1. Introduction

This report provides a detailed account of the human factors and organizational analysis that provided data and results for the Genesis MIB. Because 

of the nature of the Genesis mishap as a “design error”, attention was not 

focused on many “classic” human factors issues such as display design, 

usability of controls, and the like, but more focused on decision making, 

management processes, and organizational climate issues. 

The goal of the analysis was not to blame individuals but to systematically 

examine a range of issues, beginning with various types of “design error” 

and working backwards in time to preconditions, management operations, 

and organizational influences (Reason, 1990; see Shappell and Wiegmann 

(2001) for an alternative characterization). Figure D-9.1 illustrates the conceptual idea.

A more detailed characterization of “designer acts” is that designers may 

make errors or perform violations. Errors are related to perception, cog-
Ge n e s i s Mi s h ap Re por t Pa g e 

nition, and motor performance. A perceptual error is that the designer 

“didn’t see it”. A cognitive error takes several forms such as “forgot it”, 

“didn’t attend to it”, “didn’t use the rule”, “made the wrong decision”. A 

motor error is that the designer did not actually perform the skill or technique appropriately. A violation refers to carrying out a known procedure 

– the person may violate a procedure routinely (e.g., as in often driving 

over the speed limit), may violate a procedure ‘somewhat’ (infraction), or 

may knowingly perform a blatant violation (exception).

If we then ask why a designer may perform an error or violation, then the 

next layer of analysis is “precondition” related to that designer as an individual or as part of a team. There are three major types of preconditions: 

medical, team coordination, or readiness. A person may err because he or 

she is in an adverse state either mentally (e.g., mental fatigue) or physically 

(e.g., physical fatigue, drunk) or may be limited in some other way (e.g., is 

not strong enough to perform a physical task). A second type of precondition related to team coordination issues. Three specific types of coordination issues are those related to communication processes, to assertiveness, 

and to flexibility/adaptability. Inadequate communication can take many 

forms (e.g., communication gaps, lack of shared vocabulary). Assertiveness refers to the likelihood or ability of people to speak up to make their 

views and issues known. Flexibility/adaptability in a team context refers 

to the willingness of the team to adapt to new demands. For example, a 

team that insists on using a design process that no longer fits the current 

situation could be diagnosed as having a flexibility/adaptability problem. 

Finally, readiness of an individual or team refers to training and certificaFigure D-9.1. 

Conceptual framework for 

analysis.
Pa g e D-31 Ge n e s i s Mi s h ap Re 

tion issues. Readiness also refers to ‘workload’ in the sense of the number 

of concurrent task demands placed on the person or team.

Again, if we ask why such preconditions exist, we turn next to issues 

related to management operations. In the case of a design mishap such as 

Genesis, our focus is specifically on systems engineering and project management issues. Systems engineering as defined within NASA includes 

major activities related to requirements, verification, risk management, and 

documentation. Project management issues include oversight, decisions 

about local resources such as staff assignments, schedule and costs, and 

problem reporting systems and practices. For completeness, the category 

of supervisory misconduct is also included.

Finally, if we ask why those management operations problems might exist, 

we turn to the broader category of organizational influences. Two major 

classes of organizational influence are resource management (staffing, 

funding, equipment) and organizational climate (organizational structure, 

organizational culture, and organizational processes). Examples of organizational risk factors include lack of staff, staff turnover, lack of funding, 

poor equipment, ineffective organizational structures, poor organizational 

culture, and unclear or cumbersome organizational processes.

This set of categories was used to analyze organizational data from Genesis. These categories are summarized in Table D-9.1.
Ge n e s i s Mi s h ap Re por t Pa g e 

Table D-9.1. Detailed Set of Analytical Categori

Category Sub-Category Detailed Category

Designer Acts Error Attention/Memory

Knowledge/Rule

Skill/Technique

Judgment/Decision

Perception

Violation Routine

Infraction

Exception

Preconditions Medical Mental State

Physical State

Limitation

Team Coordination Communication

Assertiveness

Adaptability/Flexibility

Readiness Training/Preparation

Certification/Qualification

Concurrent task demands

Management Operations Systems Engineering Requirements

Verification

Risk Management

Configuration Control / 

Documentation

Project Management Supervision/Oversight

Local Resources

Problem Reporting

Supervisory Misconduct

Organizational Influences Resource Management Staffing

Funding

Equipment/facilities

Organizational Climate Culture

Structure

Policies
Pa g e D-33 Ge n e s i s Mi s h ap Re 

Within the context of this framework, several specific issues related to Genesis emerged as special topics of study. These were:

1. Requirements, design, and test issues. In particular, how the requirements were written, interpreted and used in design, and how verification activities were planned and carried out.

2. Communication and role issues. In particular, how information was 

communicated and how roles were perceived.

3. Heritage issues. In particular, the extent to which it was perceived that 

Genesis inherited hardware from Stardust, which therefore might influence decisions about requirements, testing, and communication.

4. Organizational climate issues related to the “Faster-Better-Cheaper” 

emphasis within NASA’s Discovery Program at that time. In particular, 

emphasis on cost and schedule, the use of cost caps, and how those factors influenced decision making.

In addition, several categories were quickly dismissed as irrelevant (e.g., 

medical issues, supervisory misconduct). Therefore, the resulting analysis 

focused on the subset of categories shown in Table D-9.2.
Ge n e s i s Mi s h ap Re por t Pa g e 

Table D-9.2. Focus of Genesis Analysis.

Category Sub-Category Detailed Category Examined for

Genesis

Designer Acts Error Attention/Memory

Knowledge/Rule How knowledge was 

applied and used

Skill/Technique

Judgment/Decision Who made what 

decisions

Perception

Violation Routine

Infraction

Exception

Preconditions Medical Mental State

Physical State

Limitation

Team 

Coordination

Communication Informal 

communication 

network

Assertiveness

Adaptability /Flexibility

Readiness Training /Preparation Years of experience; 

educational 

background

Certification /

Qualification

Concurrent task 

demands

Number of 

simultaneous roles 

held by individuals

Management 

Operations

Systems 

Engineering

Requirements Clarity vs. ambiguity; 

common view vs. 

different views

Verification Clarity vs. ambiguity; 

common view vs. 

different views

Risk Management Central or peripheral

Configuration Control / 

Documentation

Project 

Management

Supervision /Oversight Degree of oversight

Local Resources

Problem Reporting

Supervisory Misconduct

Organizational 

Influences

Resource 

Management

Staffing As related to FBC 

climate

Funding As related to FBC 

climate

Equipment/facilities

Organizational 

Climate

Culture FBC climate

Structure Formal roles and 

responsibilities; 

informal 

communication 

network

Policies
Pa g e D-35 Ge n e s i s Mi s h ap Re 

2. Methods

Data were collected through two major activities: interviews and an organizational communication survey. In addition, some archival documents 

from the Genesis mission were used as data sources, such as rosters, organizational charts, and documents from design reviews.

2.1. Organizational Communication Survey

The purpose of the organizational communication survey was twofold: to 

clarify roles and tenure on the Genesis project that were not clear from the 

interviews, and to gather systematic data about communication patterns 

among the 23 people selected as relevant to the Genesis mishap investigation. These 23 included all those who were interviewed plus those from 

other functions who were selected as relevant by the Board. Two names 

were added from an original roster of 21 from the JPL and LMSS assistants 

to the investigation. The final roster of 23 participants is shown in Table 

D-9.3 below.

Table D-9.3. Roster of the Survey Participant

ID Label General Role Institutional

Affiliation

Technical Specialty for

Engineering Roles

MGL1 Manager LMSS N/A

MGL2 Manager LMSS N/A

MGJ1 Manager JPL N/A

PML1 Project manager LMSS N/A

PMJ1 Project manager JPL N/A

SEJ1 Systems engineer JPL N/A

SEJ2 Systems engineer JPL N/A

SEJ3 Systems engineer JPL N/A

SEL1 Systems engineer LMSS N/A

SEL2 Systems engineer LMSS N/A

SEL3 Systems engineer LMSS N/A

MAL1 Mission assurance LMSS N/A

MAJ1 Mission assurance JPL N/A

LEL1 Lead engineer LMSS SRC Recovery

LEL2 Lead engineer LMSS Mechanical

LEL3 Lead engineer LMSS ATLO

LEL4 Lead engineer LMSS Operations

LEL5 Lead engineer LMSS Payload Integration

LEL6 Lead engineer LMSS EPS and SRC avionics

LEL7 Lead engineer LMSS Entry systems

LEJ1 Lead engineer JPL Payload

ENL1 Engineer LMSS SRC electronics

ENL2 Engineer LMSS SRC electronics and C&DH
Ge n e s i s Mi s h ap Re por t Pa g e 

A standard communication network-style survey was used in which each 

person provided a subjective rating (from a fixed set of choices) of how 

often he or she communicated with each other person in the network. The 

six rating categories are shown in Table 4 below, along with the numeric 

scores later used to analyze the data. This rating was intended to capture the memory of “average” communication during Phases B, C, and D 

of the Genesis project, where communication includes all modes such as 

face-to-face individual or group meetings, email, telecons, etc. Contractor 

(2004, personal communication) confirmed that in social network analysis 

research, it is acceptable to ask people about networks they belonged to 

some years ago, provided that “average” behavior is requested rather than 

behavior in a specific time period. A copy of the organizational communication survey, with actual names of the 23 people omitted, is shown in 

Section 6 of this report. 

Table D-9.4. Rating Categories for Communication Frequenc

Category Numeric Score Later Used in Analysis

None 0

Once a year or less 1

Several times a year 2

Several times a month 3

Several times a week 4

Once a day 5

Several times a day 6

The communication network survey was disseminated by email, along with 

an offer by the analyst to gather data via telephone interview or fax. All 

participants used email. In a few cases, participants left part of the communication network survey blank. In most cases, this was resolved through 

emails to discuss if the participant had actually intended to rate “none” on 

communication or if the participant had simply forgotten to check an item. 

In four cases, one or two items remained unchecked, the situation was not 

resolved, and these missing data were left blank and taken to be “zero” for 

analytical purposes.

The analysis of the ratings of communication frequency is an example of 

social network analysis (Wasserman and Faust, 1994). Social network analysis is a specialized field that uses graph theory and multivariate statistics 

to examine social network data – ranging from communication networks, 

as in this study, to studies of friendship and advice between individuals, 

information sharing between organizational groups, and trade relations 

among nations. Whatever the context, the basic idea of social network anal-
Pa g e D-37 Ge n e s i s Mi s h ap Re 

ysis is that you have data that can be represented as a graph: that is, a set 

of nodes and arcs that connect the nodes. In this study, a node represents 

a person and the arc represents the rating of communication frequency. In 

particular, because the survey participants are all rating each other on a 

scale of 0 – 6 for communication frequency, the graph in this investigation 

is an example of a directed and valued graph. It is directed because it has a 

direction: an arc between two nodes originates from one (the ‘source’) and 

goes to another (the ‘recipient’). This arc is an ‘outdegree’ of the source 

and an indegree of the recipient. It is valued because it has a value: a score 

of 0 to 6. All these data can be represented as a ‘sociomatrix’, which is a 

matrix where the rows represent the people who did the rating, the data in 

the matrix represent those ratings, and the columns represent the people 

who were rated. Thus, the rows show outdegrees from each person and the 

columns show indegrees into each person.

For example, consider a network of three individuals – Alpha, Bravo, and 

Charlie – who did ratings as follows: Alpha said “I talk with Bravo once 

a day” (5) and “I talk with Charlie several times a month” (3). Bravo said 

“I talk with Alpha several times a week” (4) and “I talk with Charlie not 

at all” (0). Charlie said “I talk with Alpha several time a day” (6) and “I 

talk with Bravo not at all” (0). The resulting sociomatrix is shown in Table 

D-9.5.

Table D-9.5. Example Sociomatrix of Alpha, Bravo, Charlie.

Alpha Bravo Charlie

Alpha ---- 5 3

Bravo 4 ---- 0

Charlie 6 0 ----

There are numerous types of analyses that can be done on social network 

data. In this investigation, we will restrict our attention to the following 

specific questions:

1. Basic descriptive statistics about the network: number and strength of 

indegrees and outdegrees, density.

2. Centrality and prestige of the people in the network:

3. Cohesion: Are there distinct subgroups or cliques? If so, how many and 

who are members?
Ge n e s i s Mi s h ap Re por t Pa g e 

2.1.1. Descriptive Statistics

A variety of simple descriptive measures can be used to characterize sociomatrix data. These include 

• Counting the number of indegrees and outdegrees for each node in a 

directed graph. In the usual sociomatrix format as shown in the AlphaBravo-Charlie example, this simply means counting up the number of 

non-zero entries in each column (for indegrees) and row (for outdegrees).

• Calculating the mean strength of the indegrees and outdegrees for each 

node in a directed valued graph.

• Calculating the density of a directed graph, which is the percentage of 

arcs that exist (i.e., are non-zero) out of the total possible number of arcs. 

Thus, the density measure varies between zero and one.

• Examining mutuality: in a directed graph, each pair of nodes may or 

may not have arcs of the same strength.

In the Alpha-Bravo-Charlie example, we obtain the results for indegrees 

and outdegrees shown in Table D-9.6.

Table D-9.6. Descriptive Statisti

from Alpha-Bravo-Charlie Example.

Node Indegrees Indegree

Strength

Outdegrees Outdegree

Strength

Alpha 2 5 2 4

Bravo 1 5 1 4

Charlie 1 3 1 6

The density of the Alpha-Bravo-Charlie graph is 4/6 = 0.67.

2.1.2. Centrality and Prestige

A basic question in social network analysis is how to identify the most 

“important nodes in the network”. Here, “importance” is taken to mean 

“most prestigious” and “most central”. The simplest measure of node prestige is the relative indegree: the number of indegrees divided by the total 

number of indegrees possible (g-1 where g is number of nodes). In this 

example, Alpha is the most prestigious (or ‘popular’) node with a relative 

indegree of 1, the maximum possible because both other nodes in the network have chosen Alpha. Bravo and Charlie both have a relative indegree 

of 0.5.
Pa g e D-39 Ge n e s i s Mi s h ap Re 

A more complicated measure of node prestige takes into account not just 

nodes that are directly connected to that node, but also to all the other 

nodes reachable by that node. In our small example, this is irrelevant – both 

Bravo and Charlie are directly connected to Alpha. See Wasserman and 

Faust (1994) for further discussion.

Centrality of a node in a network can be calculated in a variety of ways. 

The formula for closeness centrality given by Equation 5.22 in Wasserman 

and Faust (1994) is to calculate the reciprocal of the average ‘distance’ of 

each node from the node of interest. A variety of other measures of centrality exist; see Wasserman and Faust (1994) for more discussion. 

In our simple Alpha-Bravo-Charlie example, we can calculate closeness for 

each node as follows in Table D-9.7. However, note that in our example, big 

numbers mean “more frequent communication” and thus larger numbers 

are ‘closer’. Therefore, because the closeness centrality measure is a reciprocal, a smaller closeness centrality score would mean greater closeness. 

Alternatively, we could recode our original sociomatrix to be more intuitive with the notion of “distance”.

Table D-9.7. Closeness Centrality 

the Alpha-Bravo-Charlie Network.

Node Closeness Centrality = (g-1) / [Sum of distances from other nodes]

Where g = 3

Alpha 2 / [5+3] = 0.25 This is the most central node

Bravo 2 / [4+0] = 0.5 This is the least central node

Charlie 2 / [6+0] = 0.33 This is the second most central node

Mutuality is a concern with directed graphs. Mutuality refers to the idea 

that any dyad (group of two nodes) may or may not reciprocate the relationship between those nodes. In our Alpha-Bravo-Charlie example, both Bravo 

and Charlie report that they do not talk at all. Thus the Bravo-Charlie dyad 

is mutual. However, the other dyads are not mutual; they are asymmetric. 

In other words, the Alpha-Bravo-Charlie sociomatrix is asymmetric. For 

most real data sets, this is the case. An index of mutuality can be computed 

to show the degree to which the network contains mutual dyads.

2.1.3. Cohesion

Another common concern in social network analysis is to identify cohesive subgroups. A variety of mathematical definitions exist that distinguish 

cliques from groups and other similar concepts; these are based on the 
Ge n e s i s Mi s h ap Re por t Pa g e 

identification of paths, trails, geodesics, and so on in graph-theoretic terms. 

In the case of a directed graph, we can choose a threshold value above 

which to analyze what nodes are reachable from what other nodes. In our 

Alpha-Bravo-Charlie example, the group of three nodes is cohesive because 

all nodes are reachable from every other node.

2.1.4. Other Structural Phenomena

Identifying other interesting structural features of a social network relies 

on automated statistical packages and visualization. For example, one phenomena of interest is to identify “bridges” in the network – an arc that 

connects two subgroups that otherwise would not be connected. A node 

that connects two groups that otherwise would not be connected is called a 

cutpoint. In our example, Alpha is a cutpoint. If Alpha was removed from 

the network, Bravo and Charlie would remain as isolated nodes. 

Other larger-scale questions have to do with hypothesis testing. A number of techniques exist for comparing a hypothesized sociomatrix to an 

actual sociomatrix data set and performing statistical goodness-of-fit tests. 

For the purposes of this investigation, such detailed hypotheses were not 

explored.

2.2. Interviews

Interviews were conducted as part of the main Genesis investigation and are 

documented elsewhere in Volume 1. Four different analyses of interview 

data were performed. The general method for each analysis was the same: 

interview comments that were judged relevant to the issue at hand were 

selected and separated into “thought units” which usually corresponded 

to individual sentences, but in some cases a “thought unit” consisted of a 

sentence fragment and in some cases consisted of several sentences. After 

a comprehensive selection of “thought units” was derived, each unit was 

coded. This coding activity was the systematic interpretation of each unit 

into one of a mutually exclusive set of codes designed to capture relevant 

features of the question of interest.

Four different coding systems were developed related to four major areas 

of interest from the interview data. These four areas of interest were (1) 

Heritage, (2) Design and Test, and (3) FBC and Organizational Climate. An 

additional qualitative assessment was done of Roles and Communication 

to supplement the organizational network data.
Pa g e D-41 Ge n e s i s Mi s h ap Re 

2.2.1. Heritage Coding Systems

From the interview data, “thought units” were collected in which the word 

‘heritage’, ‘common’, ‘commonality’, or ‘reuse’ was used to refer to common 

features between Genesis and Stardust. 

Two different coding systems were developed. The first focused on the level 

of detail that ‘heritage’ was described and how it related to decision making or action. In particular, in this coding system, each unit was assigned a 

triple code <Object, Explicitness, Action>. The mutually exclusive options 

for each item in this triplet are shown in Table D-9.8 below.

Table D-9.8. Heritage Coding System for Object-Explicitness-Actio

Code Type Code Numeric

Code

Object Mission 1

System 2

Subsystem 3

Avionics (“box”) 4

SRC avionics box 5

G-switches 6

Other 7

Explicitness about 

design or test impact

N/A 1

Implicit 2

Explicit 3

Action/Impact N/A 1

Less scrutiny needed because assumed same as 

before

2

More scrutiny needed because change identified 3

For example, a statement such as “We knew the G-switch was heritage from 

Stardust so we didn’t have to test it” would be coded as <6, 3, 2>, while a 

statement such as “Genesis had Stardust heritage” was coded as <1, 1, 1>.

A second set of codes was developed to examine the extent to which different people in various roles did or did not perceive heritage. Selected 

thought units were coded as the tuple <ROLE, BELIEF> using the system 

shown in Table D-9.9 in the following. The coding of person to role was 

straightforward based on the person’s formal affiliation as given in the 

interview and/or survey data.
Ge n e s i s Mi s h ap Re por t Pa g e 

Table D-9.9. Heritage Coding System for <ROLE, BELIEF

Code Type Code Numeric Code

Role Project Management (PM) 1

Systems Engineering (SE) 2

Red Team 3

Engineering 4

Other 5

Belief Heritage 1

Not Heritage 2

For example, if a person in a project management role said, “We knew that 

the hardware design was different than Stardust”, that unit was coded as 

<1, 2>.

2.2.2. Design and Testing Coding System

The interview data varied widely in how design and verification issues were 

characterized. For example, “verifying the G-switch” referred to a variety 

of potential kinds of verification types (verification by test or similarity or 

by analysis) and various different kinds of tests (functional, performance, 

continuity, directionality) and test techniques (centrifuge, drop, lift). 

Interview data were collected into relevant “thought units” in which the 

words “design”, “verification”, “test”, “centrifuge”, and related items were 

identified.

Each of these units was coded into the tuple <ROLE, OBJECT, LEVEL, VERIFICATION-TYPE, TEST-TYPE, TEST-DETAIL> as shown below in Table 

D-9.10. Role was straightforward to identify from each person’s job title or 

function as described in the interviews. 
Pa g e D-43 Ge n e s i s Mi s h ap Re 

Table D-9.10. Design/Test Coding System for <ROLE, OBJECT, LEVE

VERIFICATION-TYPE, TEST-TYPE, TEST-DETAIL>.

Code Type Code Numeric Code

Role Project Management (PM) 1

Systems Engineering (SE) 2

Red Team 3

Engineering 4

Other 5

Object of discussion Philosophy 1

System 2

Avionics 3

SRC 4

SRC Avionics 5

G-switch 6

G-switch circuitry 7

FPGA 8

Packaging 9

Other 10

Level of design or verification 

discussed

None/NA 0

Science 1

Mission 2

Flight 3

Subsystem 4

Box 5

Component 6

Circuitry 7

Other 8

Verification Type None 0

Analysis 1

Similarity 2

Test 3

Test Type None 0

Functional 1

Performance 2

Continuity 3

Other 4

Test Detail None 0

Spin/centrifuge 1

Drop 2

Lift 3

Other 4

For example, if an engineer stated “We planned to do a centrifuge test on 

the G-switch”, that would be coded as <4, 6, 6, 3, 4, 1>. 
Ge n e s i s Mi s h ap Re por t Pa g e 

2.2.3.	 Roles and Communication Analysis

Interview notes were analyzed to examine the extent to which self-reported 

roles differed from others’ perception of that role.

2.2.4.	 FBC and Organizational Climate Coding System

The Board was interested in the extent to which the well-documented climate of Faster-Better-Cheaper would have affected decision making on the 

Genesis mission. In particular, this meant significant pressures to meet cost 

and schedule goals that could put technical goals at risk. A related question of organizational climate is the extent to which people perceived that 

the Genesis project climate was open and that teamwork was effective. 

Interview data were collected into relevant “thought units” in which the 

words “schedule”, “cost”, “faster-better-cheaper”, “teamwork”, and related 

items were identified (e.g., “people weren’t shy about speaking up”).

Each of these units was coded into the triplet <ROLE, BELIEF, STRENGTH> 

as shown below in Table D-9.11. Role was straightforward to identify from 

each person’s job title or function as described in the interviews. 

Table D-9.11. FBC Coding System f

<ROLE, BELIEF, STRENGTH>.

Code Type Code Numeric

Code

Role Project Management (PM) 1

Systems Engineering (SE) 2

Red Team 3

Engineering 4

Other 5

Belief No schedule pressure 10

Schedule pressure 11

No cost pressure 20

Cost pressure 21

Open communication/good teamwork 30

Lack of communication/poor teamwork 31

No resource issues 90

Resource issues 91

General statement about resources 99

Strength Mild 0

Moderate 1

Strong 2
Pa g e D-45 Ge n e s i s Mi s h ap Re 

For example, if a Systems Engineer said, “Well yeah we had some schedule 

pressure but it was no different than any other project”, that was coded as 

<2, 11, 0>. As another example, if an Engineer said, “I couldn’t run that test 

because it was too expensive”, that was coded as <4, 21, 1>.

3. Results

Two sets of results are presented: those for the organizational communication survey and those for the interview data.

There are several important caveats to keep in mind with all these results. 

First, these data are based on participants’ memory of events from approximately six years ago. It is well known that memory is reconstructive in 

various ways and may not always be reliable (e.g., Loftus, 1979; 1980). For 

example, people may reconstruct events as they “must” have happened but 

not necessarily as they did happen. Furthermore, there are well-known 

social effects to be noted, such as people’s general tendency to say socially 

acceptable answers. Finally, few conclusions can be drawn from the absolute frequency counts in the data. These counts are obviously related to the 

nature of the interview questions and follow-up probes asked; therefore, 

frequency of behavior alone is confounded with the nature of the interview. However, relative frequencies may be diagnostic.

Nevertheless, interviews and surveys contain valuable data that can be 

analyzed systematically.

3.1. Organizational Communication Survey Results

The demographic part of the organizational communication survey helped 

to clarify the roles, experience, and tenure of the 23 selected participants 

in the Genesis project. From these data, the following observations are 

noted:

Observation: The team was experienced. The mean number of years of 

experience at the home institution (JPL or LMSS) prior to Genesis was 

reported to be 15.5 years.

Observation: Turnover was not a significant issue. A detailed look at 12 

key participants (two project managers, six systems engineers, two lead 

engineers, and two engineers) showed that eight of them worked on Genesis before the System Requirements Review (March 1998) and worked continuously through to launch (August 2001). One worked before the SRR 

and continuously through May 2000, then transitioned to part-time status 
Ge n e s i s Mi s h ap Re por t Pa g e 

until August 2001 when Genesis launched. One participant joined after the 

Preliminary Design Review (July 1998) and worked through launch. The 

remaining two of these 12 represented the only significant turnover in the 

project that occurred October/November 1998. The first engineer for the 

SRC avionics left the organization after 5 months on Genesis, with a 1-2 

week turnover period with his successor.

Observation: Most people had multiple roles. This meant heavy concurrent task demands on most of the key people on the Genesis project. For 

example, systems engineers would typically have four or five roles such as 

System Design Lead, Requirements Lead, Verification Lead, Contamination Control Lead, Payload Integration Lead, or Launch Vehicle Integration 

Lead.

3.1.1. Descriptive Statistics of the Communication Network

The communication network contained 23 nodes. Thus, the maximum 

number of indegrees or outdegrees is 22. The rating scale was numerically 

coded as 0 to 6, where 6 represented the most frequent communication as 

show in Table 4 previously. Thus, the highest mean value of an indegree or 

outdegree would be 6 as well, if every rating received was a 6.

Figure D-9.2 shows a frequency histogram of indegrees. This shows that 

many people in the network were “popular”; in fact, 14 of them had either 

21 or 22 indegrees.

Indegree Frequency Counts

0

2

4

6

8

10

12

14

16

0 thru 5 6 thru 10 11 thru 15 16 thru 20 21 thru 22

Number of Indegrees per Node

Frequency

Figure D-9.2.

Frequency histogram for 

indegrees.
Pa g e D-47 Ge n e s i s Mi s h ap Re 

Figure D-9.3 shows a frequency histogram of outdegrees. This shows that 

most people were “expansive” in that they rated having at least some communication with most everybody else in the network. In fact, 22 of the 23 

people in the network rated themselves as communicating with 16 or more 

other people.

For the entire network, the mean number of indegrees, which equals the 

number of outdegrees by definition (i.e., we are simply counting all the arcs 

that exist in two different ways) is 19.91. The mean value or “strength” of the 

indegrees was 3.15 and the mean value of outdegrees was 3.19. Thus, we can 

say the “average communication” as reported in this network was slightly 

more than “several times a month”. The density of the network (which 

only examines the presence or absence of mutual dyads, not considering 

their strength) is 0.91, which is quite high (the maximum is 1). Therefore, 

even though many ratings of communication frequency were not identical 

between two people, it was almost always the case that people did reciprocate on the simpler question of “did we communicate at all or not”.

3.2.1.	 Centrality and Prestige

For each person in the network, prestige was calculated as relative indegree 

(number of indegrees divided by 22, the maximum number of indegrees). 

In this network of 23 people, 10 of them are “most prestigious” in that the 

prestige score is 1.0. The relatively low rating for ENL1, the first SRC avionics engineer on Genesis, is most likely due to his short tenure on the project. 

Outdegree Frequency Counts

0

2

4

6

8

10

12

0 thru 5 6 thru 10 11 thru 15 16 thru 20 21 thru 22

Number of Outdegrees per Node

Frequency

Figure D-9.3.

Frequency histogram for 

outdegrees.
Ge n e s i s Mi s h ap Re por t Pa g e 

MGL1 is in a job function that is not actually part of the Genesis project but 

in a related matrix organization. Otherwise the range of prestige scores is 

quite narrow and high – from 0.82 to 1.0.

A closeness centrality measure was calculated for each network node also. 

This used the same formulation as in the previous example: the reciprocal of the sums of distances of adjacent nodes. Again, in this formulation, 

smaller numbers are ‘closer’ because the inverse of larger numbers for communication frequency results in smaller scores. In addition, the closeness 

centrality measures were ranked smallest to largest to also help highlight 

the “top” scorers for closeness. Ties were represented using the standard 

midrank method. For example, a score of 0.34 occurred twice and those 

numbers would have been ranked 11 and 12 if they were distinct; therefore 

the mean rank of (11 + 12) / 2 = 11.5 was assigned to both those values.

The resulting scores for prestige and centrality are shown in Table D-9.12.
Pa g e D-49 Ge n e s i s Mi s h ap Re 

Table D-9.12. Prestige and Closeness Centrality of the Network.

ID Label General

Role

Institutional

Affiliation

Prestige

(relative

indegree)

Closeness

Centrality

Rank of

Closeness

Centrality

MGL1 Manager LMSS 0.68 0.54 22

MGL2 Manager LMSS 1.0 0.34 11.5

MGJ1 Manager JPL 0.86 0.39 16

PML1 Project 

manager

LMSS 1.0 0.28 3.5

PMJ1 Project 

manager JPL 0.95 0.39 16

SEJ1 Systems 

engineer JPL 1.0 0.33 9

SEJ2 Systems 

engineer JPL 0.86 0.42 21

SEJ3 Systems 

engineer JPL 0.86 0.32 7

SEL1 Systems 

engineer LMSS 1.0 0.22 1

SEL2 Systems 

engineer LMSS 1.0 0.27 2

SEL3 Systems 

engineer LMSS 1.0 0.31 6

MAL1 Mission 

assurance LMSS 0.82 0.39 16

MAJ1 Mission 

assurance JPL 0.82 0.41 18.5

LEL1 Lead 

engineer LMSS 0.95 0.28 3.5

LEL2 Lead 

engineer LMSS 1.0 0.3 5

LEL3 Lead 

engineer LMSS 1.0 0.41 18.5

LEL4 Lead 

engineer LMSS 1.0 0.34 11.5

LEL5 Lead 

engineer LMSS 0.95 0.33 9

LEL6 Lead 

engineer LMSS 0.95 0.38 14

LEL7 Lead 

engineer LMSS 1.0 0.33 9

LEJ1 Lead 

engineer JPL 0.86 0.42 20

ENL1 Engineer LMSS 0.36 0.59 23

ENL2 Engineer LMSS 0.86 0.36 13

From Table D-9.7 we can see that in addition to many prestigious nodes 

in the network, the most central nodes were two of the systems engineers 
Ge n e s i s Mi s h ap Re por t Pa g e 

from Lockheed Martin, the Lockheed Martin project manager, and two of 

the lead engineers from Lockheed Martin.

3.2.2.	 Cohesion

The next kind of analysis is to look at cohesion, and in particular the presence of subgroups in the network. This type of analysis can be very sophisticated, but for the purposes of this investigation, visual inspection of the 

sociomatrix was used as a simple way to gauge the presence of independent 

subgroups (cliques – those groups that are not connected). In this type of 

network (a valued directed graph), the value of 5 was used as a threshold 

and the analysis examined both the upper half and the lower half of the 

sociomatrix (which was not symmetric).

The choice of the value of 5 (representing communication of at least “once a 

day”) as a lower threshold for examining cohesion is because all the nodes 

in the network are connected at the value of 4 and lower. That is, in looking 

at communication of “several times a week” or less, every node was eventually reachable by every other node. In that sense, this entire network is 

very well-connected or “one big clique”.

Using a threshold value of 5, the lower half of the sociomatrix was examined to see what nodes were reachable by what other nodes. That analysis 

showed the following:

• two nodes were not connected to anybody: MAL1 and LEL7

• one cohesive subgroup was: MGL1, LEL6, ENL1, and ENL2.

• The other cohesive subgroup consisted of everybody else

Similarly, a visual inspection of the upper half of the sociomatrix was performed and found almost identical results, with the one difference that 

MGL1 became an isolate and was not part of the LEL6-ENL1-ENL2 group.

3.3.	 Interview Results

The results from coding the interview data are presented in this section.

3.3.1.	 Heritage Results

The issue of heritage was discussed at a variety of levels in the interviews. Fifty-three units were categorized as <OBJECT, EXPLICITNESS, 

ACTION>.
Pa g e D-51 Ge n e s i s Mi s h ap Re 

Figure D-9.4 shows the distribution of units related to the level of discussion. A discussion of heritage was usually explicitly related to design and 

test as shown in Figure D-9.5. The number of units of whether heritage 

meant less scrutiny or lack of heritage meant more scrutiny, or neither, was 

approximately equal with a slight advantage to “neither” as shown in Figure D-9.6.

Figure D-9.4. 

Distribution of units for 

OBJECT of heritage.

Figure D-9.5. 

Distribution of units 

about EXPLICITNESS 

of heritage.

Figure D-9.6. 

Distribution of units 

about ACTION related 

to heritage.
Ge n e s i s Mi s h ap Re por t Pa g e 

Examining the relation of role and belief, forty-eight units were categorized 

as <ROLE, BELIEF>. It was found that project managers and systems engineers had comments both about how Genesis was heritage and how Genesis was not heritage. Engineering staff focused most of their comments 

on how Genesis differed from Stardust heritage. Members of the Red Team 

did not recognize that Genesis differed in heritage from Stardust. These 

results are shown in Figure D-9.7.

3.3.2.	 Design and Test Results

A total of 154 ‘thought units’ were extracted from the interviews that related 

to design and test issues. 

Figure D-9.8 shows the distribution of units by role.

Figure D-9.9 shows the distribution of units by object, where rare categories 

were all collected into “Other”.

Figure D-9.10 shows the distribution of units about the level of the design 

or test activity. Rare items were all collected into the category “Other”.

Figure D-9.7. 

Belief in heritage by 

organizational role.

Figure D-9.8. 

Distribution of units by role.

PM

19%

SE

41%

RedTeam

21%

Engr

19%
Pa g e D-53 Ge n e s i s Mi s h ap Re 

The frequency counts for the categories of verification type, test type and 

test detail are show in Table D-9.13.

Table D-9.13. Percent Frequency for Units 

Verification Type, Test Type, and Test Detail.

Code Type Code Percentage of Units

Verification Type None 71

Analysis 1

Similarity 1

Test 27

Test Type None 81

Functional 4

Performance 1

Continuity 4

Other 10

Test Detail None 83

Spin/centrifuge 6

Drop 3

Lift 0

Other 8

Figure D-9.9. 

Distribution of units about 

“Object” of design or test.

Figure D-9.10. 

Distribution of units about 

the “Level” of design or test.

Philosophy

44%

System

10%

SRC 

Avionics

17%

G-switch

13%

Other

16%

Frequency of "Level" items

None

42%

Box

22%

Component

18%

Other

18%
Ge n e s i s Mi s h ap Re por t Pa g e 

These data in Table D-9.13 illustrate that most of the units from the interviews were very general remarks about verification and testing. Most of 

the time there was not a detailed articulation of what kind of test was under 

discussion.

The data in this section show that in general there was a lack of clarity 

about design and testing. There were no systematic patterns of specific 

tests being consistently discussed for specific components.

3.3.3.	 Roles and Communication Results

A qualitative analysis of the interview transcripts provided deeper insight 

into potential issues related to roles, responsibilities, and communication 

in the Genesis project.

In general, the project managers and systems engineers had a common 

view of a formal hierarchical process for defining design requirements and 

verification requirements. For example, the JPL Project Manager explained 

in some detail the different levels of organization – mission, system, subsystem etc. – and the related formal processes of requirements flow-down and 

roll-up. Similarly, the systems engineers discussed the process of verification flow-down and roll-up. The project managers and systems engineers 

emphasized that they would probably not know the details of particular 

test types – at their level, they would need to know that adequate testing 

was done, and they trusted the engineering staff to use its best judgment to 

accomplish design and verification goals. 

The interviews also highlighted some disconnects between people’s perceptions of their own roles versus others’ perceptions of their roles. For 

example, one of the systems engineers spoke of the Recovery Operations 

Team Chief as “the EDL lead” and therefore by implication a good checkand-balance for all matters related to entry, descent, and landing, including the G-switch. Another systems engineer stated that he thought the 

SRC avionics engineers would go to that Chief for matters related to the 

G-switch; but he did recognize that the Chief’s interest began with the SRC 

separation from the spacecraft. The Recovery Operations Team Chief himself defined his role as an end-user of “the box”, primarily concerned with 

trajectory analysis and modeling, safety, and operational planning for the 

actual capture of the SRC, and was not involved in any detailed testing of 

the G-switch or other mechanisms.
Pa g e D-55 Ge n e s i s Mi s h ap Re 

3.3.4.	 FBC and Organizational Climate Results

A total of 66 ‘thought units’ were extracted from the interviews that related 

to cost, schedule, teamwork and other resource and organizational climate 

issues. The distribution of the comments by role is shown in Figure D-9.11. 

It is easily seen that most statements were made by people in project management and systems engineering roles.

If we then take the 66 statements and categorize them by the topic – whether 

schedule was an issue or not, whether teamwork was an issue (i.e., categorize them by the coding scheme shown previously) – we find the results 

shown in Figure D-9.12. While there was a fair amount of variety, the two 

Statements by Role

PM 

40%

SE

38%

RedTeam

2%

Engr

9%

Other

11%

PM 

SE

RedTeam

Engr

Other

Statements about Resources

General

6%

No problem

3%

Problem

5%

Schedule - no

11%

Schedule - yes

18%

Cost - no

11%

Cost - yes

23%

Good comm/team

17%

Poor comm/team

6%

General

No problem

Problem

Schedule - no

Schedule - yes

Cost - no

Cost - yes

Good comm/team

Poor comm/team

Figure D-9.11.

Distribution of “FBC” 

statements by role.

Figure D-9.12. 

Distribution of statements 

by type.
Ge n e s i s Mi s h ap Re por t Pa g e 

most common kinds of statements were along the lines of “yes there was 

schedule pressure” and “yes there was cost pressure”.

A more detailed examination focused on those categories with relatively 

high frequency counts: statements by project managers, system engineers, 

and engineers about cost and schedule. It was found that the distinction 

between “strong” versus “moderate” or “none” was not very helpful, and 

so results are collapsed across those categories. The distribution of frequency counts of the resulting four kinds of statements (there was or was 

not schedule pressure, there was or was not cost pressure) by role (project 

manager, system engineer, engineer) is shown in Figure D-9.13.

On the face of it, some of these results are surprising. Did project managers really perceive no schedule problems and claim about half the time that 

cost was not an issue? To go back to the raw data, there are a variety of 

very different statements that were categorized in these ways. For example, 

the statements that the Star Tracker was a recognized risk, “and so schedule was added”, and that “after Mars 98...a month of schedule was added” 

were coded as a “no schedule problem/schedule did not impact quality”. Similarly, the statements of how cost was not an issue often involved 

detailed explanations of the fee structure of the Genesis contract to LMSS. 

The fee was not based on having an on-time launch but was based on science return. In that sense, cost did not overwhelm the scientific purpose of 

the mission.

4. Discussion and Conclusions

Returning to Table D-9.2, we may now shed some more light on the details 

that emerge from the analysis. “Designer error” includes both the ambiStatements by Role

0

2

4

6

8

10

12

14

Schedule

Problems

Schedule not

an issue

Cost

Problems

Cost not an

issue

Statement Type

Systems Engineer

Project Mgr

Engineer

Figure D-9.13. 

Distribution of statements 

about cost and schedule by 

role.
Pa g e D-57 Ge n e s i s Mi s h ap Re 

guity about the G-switch drawings and proper methods for verification 

of the G-switch function. Preconditions relate somewhat to team coordination issues (as evidenced by some role confusion and some rigidity in 

the systems engineering and project management processes seen in the 

interviews), although the organizational communication survey generally 

shows a strong social network among all the major parties. Another precondition discussed in Volume 1 is the issue of personal readiness, particularly 

that an electrical engineer alone is ill-equipped to cope with some of the 

mechanical issues that would arise with a G-switch implementation. Yet 

another layer deeper are the systems engineering and project management 

issues. The data here suggest, and detailed comments in the interview corroborate, that the formal requirements and verification processes tended to 

prevent appropriate ‘drill-down’ into issues that should have been examined in detail. In other words, the formal and hierarchical processes acted 

as a barrier to some extent, perhaps leading to a false sense of security that 

issues had been properly raised and resolved at some other level. This is 

not to say that formal hierarchical processes are bad, but that it still takes 

appropriate judgment and action to wield them effectively. The ambiguity 

about the notion of ‘test’ itself leads systematically to assumptions that can 

often go unexamined. Finally, the organizational climate of reliance on 

heritage and the values of “Faster” and “Cheaper” tending to trump “Better” are another set of latent factors behind the mishap. 

5. References

Dekker, S. (2003). A field guide to human error analysis. London: Ashgate.

Harrison, M. (19xx). Diagnosing organizations. New York: Sage.

Loftus, E. (1979). Eyewitness testimony. Harvard University Press.

Loftus, E. (1980). Memory. Reading MA: Addison-Wesley.

Reason, J. (1990). Human error. Cambridge: Cambridge University Press.

Reason, J. (1997). Managing the risks of organizational accidents. London: Ashgate.

Shappell, S. and Wiegmann, D. (2001). Analysis of aviation accidents: The 

human factors analysis and classification system. London: Ashgate.
Ge n e s i s Mi s h ap Re por t Pa g e 

Wasserman, S. and Faust, K. (1994). Social network analysis: Methods and 

applications. Cambridge: Cambridge University Press.

Organizational Communication Survey: As given to 23 members of the 

Genesis team except that actual names from the roster are omitted.

Genesis MIB

Organizational Communication Survey

Purpose: The purpose of this survey is to gather systematic data abo

organizational communication patterns. These data will be based

your own individual recall of “average” communication with different

people related to the Genesis project. The data will be used for aggregate analyses of communication patterns. Similar to non-privil

interview data, these “raw” data will not be used in the Board’s final 

report.

Instructions: This survey is in two parts. Part 1 asks you for demographic data about how long you worked on Genesis and what jobs

held during that time. “Job title” refers to an official title like “Systems 

Engineer”. “Major duties” refer to major activities you remember bei

responsible for, such as “avionics box design” or “Level 2 requirements

documentation”.

Part 2 of the survey asks you to recall the “average” frequency of communication with each other person in the given roster during your time

with the Genesis project. Frequency of communication includes face-toface conversations, any kinds of meetings (tabletop, weekly status, PD

etc.), telephone/telecons, and email. A rating scale is provided and y

just need to check the item on the rating scale that most closely matches

your recall.
Pa g e D-59 Ge n e s i s Mi s h ap Re 

31

Part 1: Demographics

Name: Date: 

Affiliation during your time on Genesis (Choose one): JPL LMA

How many years had you worked there before you worked on the Genesis project? 

What is your educational background? (Choose all that apply)

Electrical engineering Mechanical engineering Industrial or systems engineering

 Business Administration Aeronautical engineering Astronomy

 Other (please specify):

Please list your each of your positions on the Genesis project. For each position, list start

and end dates, your official supervisor, and your major duties. Use the back of this page to

continue if you had more than three positions with Genesis.

Position 1:

Start date (month/year): End Date (month/year): 

Official Supervisor (name):

Major duties:

Position 2:

Start date (month/year): End Date (month/year): 

Official Supervisor (name):

Major duties:

Position 3:

Start date (month/year): End Date (month/year): 

Official Supervisor (name):

Major duties:
Ge n e s i s Mi s h ap Re por t Pa g e 

32

Part 2: Communication Survey

For each person on the below roster (excepting yourself), please check the box that most

closely matches the average frequency of communication that you recall with that person

while you were working on the Genesis project. Communication includes face-to-face

conversations, any kinds of meetings (tabletop, weekly status, PDR, etc.),

telephone/telecons, and email. If any engineering or technical person you recall

communicating with at least several times a week is NOT on this roster, please write in

the names below and indicate your rating of communication frequency.

Name None Once a

year or

less

Several

times a

year

Several

times a

month

Several

times a

week

Once a

day

Several

times a

day
Pa g e E-61 Ge n e s i s Mi s h ap Re 

Append

Root Cause and Contribut

Factor Narrative; Event and Causal F

This appendix complements Section 5.0 of the report. Section E-1 is a timeline to place the events in a historical perspective; Section E-2 contains the 

details of each root cause or contributing factor.

Figure E-2 contains the Event and Causal Factor Tree for the Genesis mishap, a visual representation of the causes that led to the mishap. The MIB 

used a fault tree(see Appendix C-2.A.) to identify the possible causes leading to the mishap and the Event and Causal Factor Tree was then used to 

further decompose those events by asking why each event occurred. The 

MIB continued this “why” process until they identified the root causes and 

causal factors.

E-1. Process-Level Errors: Timeline of Root Causes a

Contributing Factors

The Discovery Program selected Genesis for implementation in early 

November 1997. It was selected as a PI-led Discovery Class mission under 

a cost cap, following the selections of Mars Pathfinder, NEAR, Lunar Prospector, and Stardust. To be competitive, a high heritage design was proposed, based upon the Stardust SRC and spacecraft bus subsystems. At 

the time of the proposal, the Project planned the Genesis SRC-AU to be a 

heritage implementation of the Stardust design. 

The project-level Preliminary Design Review (PDR) was held July 20 and 

21, 1998. The Project was confirmed on August 19, 1998 with tight schedule and fiscal margins (the Phase C/D schedule margin to launch was 4 

months; the Phase C/D/E cost reserve was 11 percent). 

Throughout the Project, JPL Project Management and Systems Engineering had little involvement in LMSS activities. JPL therefore had no effective insight into the lower-level activities or processes of the LMSS Flight 

Systems (spacecraft) Team, and no means of cross checking or detecting 

the LMSS process errors. This lack of involvement, consistent with NASA’s 

FBC philosophy, and approved by the Discovery Program, did not cause 
Ge n e s i s Mi s h ap Re por t Pa g e 

the failure directly, but did contribute significantly to its occurrence. Also 

throughout the Project, the inadequate Systems Engineering Staffing levels at JPL and LMSS contributed to the mishap. Staffing was inadequate for 

the responsibilities that the Systems Engineering organization recognized 

and for those, such as complete verification roll-up, that it did not recognize 

as its responsibility.

The Genesis Project had a number of interrelated issues that led to the 

inversion of the G-switch sensors -- the proximate cause that resulted in 

the drogue parachute deployment mishap. After extensive review of the 

data and numerous interviews, the MIB determined that deficiencies in the 

following four pre-launch, top-level processes resulted in the incident, each 

involving multiple root causes and contributing factors:

1. the design process inverted the G-switch sensor design;

2. the design review process did not detect the design error;

3. the verification process did not detect the design error; and

4. the Red Team review process did not uncover the failure in the verification process.

Process-Level Error No. 1: Design Process Generated Design Error

Around the time of PDR and Confirmation Review, the Genesis project 

recognized that the SRC-AU required more functionality than was available from the heritage Stardust SRC-AU, upon which its proposed design 

had been based. Additional relays and a new motor control board were 

required to drive the collection arrays and contamination lid used for gathering and isolating samples. To accommodate these requirements, the SRCAU design was upgraded to six cards, which was well beyond the volume 

of the original SRC-AU box. The six boards were installed on edge, an orientation 90° from that of the Stardust SRC-AU. To meet SRC center of gravity requirements, the SRC-AU was split into two redundant boxes of three 

cards each. The G-switch sensor was also moved from the timer card to the 

relay card, since it was mounted on shock isolators and would help avoid 

a “spoofing” issue (i.e., inadvertent triggering due to buffeting during the 

early entry or inadvertent shifting of the relay positions) with which the 

designers were concerned. 

When heritage hardware is used in a new application, LMSS engineers 
Pa g e E-63 Ge n e s i s Mi s h ap Re 

typically conduct an inheritance review of the hardware. With these and 

other changes to filters and timers, Stardust heritage had been violated, and 

the project recognized this by not holding an inheritance review. However, many engineers believed that the pyro initiation aspects of the design 

maintained their Stardust heritage. 

The requirement for the SRC-AU to deploy the drogue was flowed down to 

the SRC-AU Design Team, but the cryptic requirement levied by Systems 

Engineering on the SRC-AU may have led to confusion among the box-level 

designers. This requirement drove the deployment of the drogue chute on 

the “X axis descending deceleration,” but contained no coordinate system or 

indication of the direction of the acceleration vector for the Electrical Engineers who were leading the redesign to reference. The requirement was 

taken from Stardust requirements wording, which also contained no coordinate system or indication of the direction of the acceleration vector. The 

inadequate requirements statement was a result of inadequate requirements generation and an assumption that the Stardust requirement would 

be understood based on its Stardust heritage – inappropriate confidence 

in heritage design.

The LMSS Flight Systems Product Development Organization (PDO) handled the SRC-AU changes. These changes laid out the relevant portions of 

the relay card printed circuit boards based on a Stardust heritage schematic 

that contained no indication of any sensitivity of the G-switch sensors to 

orientation. It also appears that the G-switch sensor part-level drawing was 

not understood by the layout engineer, since it contained a clear indication 

of the required direction of acceleration to close the switch. As a result, the 

relay card drawing was laid out with the G-switch sensor in an inverted 

orientation from that necessary for it to function during entry.

During this design process, and throughout the life of the project, there 

was a lack of a Systems Engineer assigned end-to-end EDL responsibility. There were Systems Engineers and others with responsibilities for 

most functions of the SRC; however, there was a gap in coverage that left 

the G-switch sensor function unaddressed by Systems Engineering. Had 

Systems Engineering assigned that responsibility, the MIB believes it is 

likely that the AU PIE and the relay card designer would have received 

guidance regarding the orientation of the G-switch sensor, a mechanical 

sensing device. The SRC-AU designers had insufficient mechanical systems or guidance, navigation, and control systems experience to recognize 

the orientation issue with their design.
Ge n e s i s Mi s h ap Re por t Pa g e 

The failure to assign a Systems Engineer end-to-end EDL responsibility 

may have been due, in part, to a decision by the Project not to treat the SRC

as a separate spacecraft. Had it been treated as a separate spacecraft, th

SRC would have received additional and more dedicated focus. Although 

this did not cause the failure, it may have been a contributing factor.

Concurrent with the changes already mentioned, the PIE for the SRC-AU 

left the Project and a new PIE was assigned. During the 1- to 2-week handoff period, the new PIE faced several pressing issues:

• the SRC-AU motor drive electronics (MDE) card did not fit within its 

space allocation;

• the FPGA was 20-percent oversubscribed and it was unclear whether the 

relays could be laid out in the space available; and 

• the EST board was also pressing against its layout/volume constraints. 

The primary concern of the PIE at this time was the MDE board -- which 

placed science requirements for the Project in jeopardy – threatening the 

Project schedule, and therefore, the cost-cap established by the FBC philosophy. 

Process-Level Error No. 2: Technical Reviews Failed to Identify

Design Error

The SRC-AU PIE presented the new SRC-AU design at peer and drawing 

reviews, and it was subsequently presented at the SRC-AU Critical Design 

Review (CDR). 

Based on MIB interviews, it appears that not all of the key individuals necessary for an adequate peer review were present. An attendance list for the 

peer review could not be located. Review of the drawing signatures also 

indicates that no one from Systems Engineering signed the drawings, signifying that the design would meet system-level requirements. This may 

have been the case because procedure at that time did not require participation by key individuals at project technical and drawing reviews. 

However, as previously noted, there was no Systems Engineer assigned

end-to-end EDL responsibility, so even if attendance had been required at 

technical reviews or at drawing sign-offs, it is not clear that a person with 

the focus on EDL system requirements and performance would have been 

available. 
Pa g e E-65 Ge n e s i s Mi s h ap Re 

During the SRC-AU CDR, the SRC-AU PIE presented a short, top-level 

design review package; however, that CDR was too high level to adequately assess the design. This Science Mission Directorate-wide systemic 

problem of weak technical reviews led to this failure as it did not allow for 

in-depth probing of the design. 

At the SRC-AU CDR the CRD package stated that the SRC-AU would 

undergo a centrifuge test to verify the functionality of the SRC-AU. The 

MIB believes it is possible that attendees may have concluded that any error 

in the G-switch sensor orientation would be identified through testing, and 

as a result, less scrutiny of the design occurred. As will be discussed below 

the centrifuge test was deleted after the CDR, so reduced scrutiny could 

have resulted in failure to identify the design error.

Process-Level Error No. 3: Verification Process Failed to Detect 

Design Error

The centrifuge test was deleted for four reasons: 

1. schedule pressure; 

2. an erroneous belief by some in Project Management and Systems Engineering that a box-level continuity test had functionally replaced the centrifuge tests; 

3. a possible belief by some in Project Management that verification by 

inspection of drawings was completed properly; and 

4. the G-switch sensor was not identified as having a critical alignment in 

the Pointing and Alignment Document (i.e., a Phasing Plan).

The centrifuge test was deleted primarily because of schedule pressure. 

The philosophy of the time, Faster, Better, Cheaper, created an ever-present threat of cancellation if overruns occurred on cost-capped missions.

Delivery of the SRC-AU to spacecraft ATLO slipped by 4 months, due to 

the design issues with the MDE; the number of changes required to the 

SRC-AU boards; and increasing scope of the centrifuge test, which threatened the overall project schedule. Project Management and the SRC-AU PIE 

believed continued slips during ATLO would have consumed the minimal 

cost reserves available, placing the Project in jeopardy of cancellation. 
Ge n e s i s Mi s h ap Re por t Pa g e 

Two Systems Engineering process failures led to the increase in scope of 

the centrifuge test that caused the SRC-AU schedule to become untenable: 

1. Systems Engineering did not define the detailed verification requirements for the subsystems, so the AU Subsystem Team did not have 

higher-level guidance as to what was necessary to verify, and

2.	no Systems Engineer was assigned end-to-end EDL responsibility, 

which led to a lack of involvement by Systems Engineering during key 

testing discussions. 

From the interviews, the MIB also noted that the technical team was very 

concerned about the possibility of spoofing. It appears that the focus on 

spoofing issues may have reduced the attention being paid to the G-switch 

sensor orientation. 

Following the decision to delete the centrifuge test, the SRC-AU PIE decided 

a continuity test was needed for portions of the G-switch sensor circuit that 

had not yet been tested. The PIE and LMSS Mission Assurance developed 

a manual “quick-lift” test to verify that the G-switch sensors made contact 

and that all related circuit card and backplane signals were contiguous. 

This quick-lift test consisted of raising the box rapidly by hand and observing switch contact through a continuity check. This test was not meant by 

the PIE to serve as a phasing test (a test to verify orientation/alignment), 

and therefore it did not address switch orientation. Given the philosophy 

of pushing responsibility down to the subsystems, Systems Engineers did 

not participate in designing the test.

Project Management and Systems Engineering believed that the quick-lift 

test had functionally and adequately replaced the centrifuge test. Key to 

drawing this erroneous conclusion was a single cryptic bullet, “SRC-AU 

3-G test approach validated; moved to unit test; separate test not required,” presented to JPL and LMSS Project Management and Systems Engineering. 

However, Project Management and Systems Engineering did not question the meaning of the cryptic bullet regarding deletion of the centrifuge testing. Had it been questioned, the MIB believes it is likely that the 

weakness of the approach would have been identified. No documentation

of the change in verification methods was generated in the form of a 

Change Request or Technical Memorandum. Had this been done it would 

have resulted in a critical assessment of the change. It remains unclear if a 

Change Request was required by the Configuration Management process 

at that time, but a Technical Memorandum was clearly appropriate. 
Pa g e E-67 Ge n e s i s Mi s h ap Re 

No one above the SRC-AU Team reviewed the test plan or results, which 

contributed to the belief that the quick-lift test had functionally replaced the 

centrifuge test (in addition to above-mentioned communications issues). 

This was because Systems Engineering was not required to review

subsystem test procedures or verification results. As a result, Systems 

Engineering continued to believe that the quick lift test had functionally 

replaced the centrifuge test. It was not identified in the verification roll-up 

process that normally occurs on projects, but was effectively only a verification bookkeeping process on Genesis.

Because of the schedule pressure, it was decided to delete the centrifuge 

test in favor of verification by inspection against Stardust drawings. This 

approach could have been successful if it had been performed by an experienced Mechanical Engineer or guidance, navigation, and control; however, 

the drawing inspection was performed by the SRC-AU PIE, an Electrical 

Engineer who lacked the necessary mechanical experience, but apparently 

did not realize his limitation. While the PIE erroneously concluded that 

the orientation was correct, he perhaps should have realized that he needed 

assistance from Systems Engineering or the PDO. In addition, the error was 

also partially a Systems Engineering failure because the Systems Engineering verification process did not require consideration of a verifier’s 

qualifications nor incorporate multiple checkers to verify a requirement.

Had the background of the verifier been considered or multiple personnel 

been required to perform the inspection as a cross check, it is likely that the 

weakness of the inspection approach would have been detected.

The final issue leading to the deletion of the centrifuge test was that the 

G-switch sensor was not identified as having a critical alignment in the 

Pointing and Alignment Document (Phasing Test Plan). Had the Gswitch sensor been identified as having a critical alignment in the Phasing 

Plan, it is likely that it would have received the level of scrutiny that other 

critical sensors typically receive, and the alignment error would have been 

discovered.

Inadequate execution of System-level verification of the drogue deployment requirement was the final reason for the verification process failure. 

The requirement for drogue deployment was poorly written and contained 

requirements for both drogue deployment and aerodynamic stabilizations; 

however it was interpreted to address only aerodynamic stability – a result 

of inadequate Systems Engineering requirements generation. A Systemlevel verification analysis, the “Recovery Analysis,” was performed, but 
Ge n e s i s Mi s h ap Re por t Pa g e 

failed to verify actual deployment. The verification failure also occurred 

because there was no Systems Engineer assigned end-to-end EDL responsibility to review the Recovery Analysis results and because Subsystem 

verification was not considered as part of the System-level roll-up. Systems

Engineering was not required to review subsystem test procedures or

verification results, and as a result the verification roll-up function was 

performed ineffectively. 

Through this series of events, the SRC-AU was delivered for spacecraft 

assembly having never completed a phasing test and with incorrect, undocumented verification of G-switch sensor orientation. 

Process-Level Error No. 4: Red Team Reviews Failed to Identify

Verification Error

JPL’s Systems Management Office (SMO), under direction from NASA and 

JPL Senior Management, established a Red Team to review the readiness 

of Genesis for launch in June 2000, after the second Mars failure. The Red 

Team chair developed a detailed plan and objectives that JPL Senior Management reviewed and approved. The Red Team chairman then formed 

11 focus groups that spent 2 days reviewing material, 1 to 1 1/2 days with 

their JPL and LMSS counterparts on Genesis, and 1 day preparing a report. 

Inputs were then assimilated into one report that was briefed to the JPL 

and LMSS Genesis Project Management. 

The Electrical Power Subsystem (EPS) Focus Group reviewed the SRC-AU 

in June 2000, since an EDL Focus Group had not been formed for the June 

2000 review. The EPS Focus Group did not identify any issues regarding the inversion of the G-switch sensor. This oversight appears to have 

occurred for the following reasons. 

• First, the EPS Focus Group was disciplined oriented, not cross-cutting, being interested primarily in power issues, which included power 

switching (G-switch sensor electrical contact function), but not all EDL 

functions (G-switch sensor orientation). This resulted from inadequate

top-level Red Team management of the focus groups.
Pa g e E-69 Ge n e s i s Mi s h ap Re 

• Second, the JPL SMO gave the Red Team too little time to perform an

adequate assessment. Although the EPS Focus Group approached its 

review conscientiously, it had little chance of performing an adequate 

review in the time available. 

• Finally, given the limited time available and their focus on power issues, 

when the EPS Focus Group learned that the deployment circuitry was 

a heritage design, they became part of a longstanding Science Mission 

Directorate problem i.e., having inappropriate confidence in heritage 

designs.

In October 2000, the Red Team chairman formed an EDL Focus Group and 

assigned them responsibility for all EDL activities, including those that had 

been addressed by the EPS Focus Group. However, the EDL Focus Group 

concentrated on aerodynamic issues and provided no review of drogue or 

drogue deployment functions. As a result, no findings regarding the Gswitch sensor were uncovered during the reviews. The EDL Focus Group 

took an action to coordinate with the Avionics Focus Group to review pyro 

initiation circuitry; however, the action was never closed. These failures 

by the EDL Focus Group were a result of inadequate top-level Red Team

management of the focus groups.

Late in the Genesis schedule, the Project was responding to the Mars Failure Board recommendations, the Red Team findings that called for significant activities, and a slip in launch date caused by a launch scheduling and 

personnel resource conflict with the Mars Odyssey Project. As a result, 

Discovery Program gave the Genesis Project an additional $17M to respond 

to the Red Team findings and to pay for a 6-month slip caused by the Mars 

Odyssey conflict. The Project used this time to conduct additional Systemlevel testing. However, since these additional tests used a bypass of the 

G-switch sensors and focused on higher-level verification and validation, 

these tests did not identify the G-switch sensor inversion.

E-2. Root Causes and Contributing Factors, Narrative Discussion

The following discussion provides the details associated with each root 

cause and contributing factor and is intended as a companion document to 

Section 5.2 of this report.
Ge n e s i s Mi s h ap Re por t Pa g e 

Root Cause Category No. 1:

Inadequate Project and Systems Engineering Management

Root Cause 1.1: Project Management and Systems Engineering did no

question meaning of a cryptic bullet regarding deletion of centrifuge test.

There is some confusion regarding what Genesis Program Management 

and Systems Engineering knew about the deletion of the centrifuge test, 

due to the passage of time and a lack of documentation. The SRC-AU PIE’s 

recollection was that he had been directed by LMSS Project Management to 

delete the centrifuge test; however, the only known documentation indicating that JPL and LMSS Project Management or Systems Engineering had 

been informed of a centrifuge test plan change was a single bullet presented at the 9/9/99 Bluebook Meeting (LMSS management review) and 

the 9/14/99 Monthly Management Review (briefing to JPL). That bullet 

read, “SRC-AU 3-G test approach validated; moved to unit test; separate test not 

required.” The unit test that was referred to was a quick lift test that verified 

G-switch sensor continuity, not orientation.

Because there was no recollection of a conversation regarding the bullet 

statement mentioned above, the Board decided it was not possible to determine how the brief and cryptic mention of this change was interpreted, 

although no one recalled any discussion occurring regarding the statement. The Board believes it is reasonable to assume that had the meaning 

of the cryptic bullet been questioned by JPL or LMSS Project Management/

Systems Engineering then it is likely that the inadequacies of the approach 

would have been discovered.

Contributing Factor 1.1: Lack of JPL Project Management and Systems 

Engineering insight into LMSS activities.

The lack of adequate management and oversight by JPL contributed significantly to the Genesis mishap. Of particular importance was the lack 

of involvement by JPL Project Management and Systems Engineering in 

LMSS Flight System (spacecraft) activities – stove-piping of the two teams 

– leaving JPL with effectively no insight into the activities or process of the 

LMSS team, and therefore no means of detecting the LMSS process errors. 

The FBC culture of the time encouraged pushing responsibility to the lowest level and not interfering with the contractor’s processes. 

Although JPL held weekly Systems Engineering telecons with all Project 

participants, it is apparent to the Board from interviews and briefings that 
Pa g e E-71 Ge n e s i s Mi s h ap Re 

JPL Project Management and Systems Engineering were assuming LMSS 

was performing all necessary spacecraft Systems Engineering functions 

and required no JPL support, involvement, or approval of its processes. JPL 

provided discipline support but predominantly in response to issues identified via “bubble-up” reporting from LMSS to JPL, not JPL searching for 

issues within the LMSS effort. Little or no regular discipline engineering 

interaction occurred between the JPL and LMSS teams. JPL did support 

SRC payload integration activities, but these focused on the science instrument not the spacecraft or SRC, and did not include the SRC-AU functions. 

This stove-piped Systems Engineering approach left little opportunity for 

cross-discipline verification and significantly reduced the safety net that 

a comprehensive systems engineering process provides. In addition, the 

JPL Systems Engineering lead was not experienced in this type of project. 

These shortfalls led to a weak spacecraft systems engineering implementation, which is discussed more thoroughly in the Systems Engineering 

discussion below. 

Although the lack of involvement by JPL Project Management and Systems 

Engineering at the lower levels did not directly cause the failure, the lack 

of involvement in the spacecraft made it difficult or impossible for them to 

identify the process failures that led to it or to find the specific engineering 

error in question. 

Appendix D-7 contains a report by the Test as You Fly Sub-team with 

observations that provide further indication of the nature and extent of the 

systems engineering issues within the project.

Contributing Factor 1.2: SRC was not treated as a separate spacecraf

Although the SRC was managed as an integral part of the Genesis spacecraft, it was not treated as a separate spacecraft -- which it was during the 

key entry phase. This approach reduced costs by avoiding the overhead of 

the additional management structure. The approach taken by the Project 

was not unsound or uncommon, but it may have contributed the failure by 

producing less focus on the SRC than if it had been treated as a separate 

spacecraft.
Ge n e s i s Mi s h ap Re por t Pa g e 

Root Cause Category No. 2:

Inadequate Systems Engineering Process

The following discussion identifies the Systems Engineering process root 

causes and contributing factors that led to the failure. These root causes 

and contributing factors fall into three major categories.

1. The Systems Engineering Team did not consider several typical and necessary Systems Engineering functions to be their responsibility, such as 

defining for the subsystems teams expectations for verification of their 

requirements nor for reviewing the results of verification testing.

2. Some Systems Engineering functions were performed incorrectly, such 

as requirements that were not clearly documented.

3. A lack of a Systems Engineering team member whose clearly delineated 

responsibilities included the G-switch sensor function.

The Board believes the JPL and LMSS Systems Engineering Teams were 

too small to address their defined responsibilities adequately, and those 

defined responsibilities did not represent the full extent of a comprehensive Systems Engineering process necessary for the Genesis Mission. This 

contributed to the failure, but did not directly cause it. 

Root Cause 2.1: Inadequate requirements generation

There was a single requirement at the SRC Avionics subsystem level that 

addressed the issue of G-switch sensor orientation and that may have 

caused the confusion that contributed to the inversion. The requirement 

from “SRC Avionics Subsystem Requirements Document GN-55200-200, 

Rev A” reads, “3.2.1.4.2.2 Drogue Parachute Release Trigger - The SRC avionics 

event sequence timer shall initiate the parachute release trigger timer upon detection of a 3.0 g ± 10% descending X axial deceleration.” Of particular importance 

are the words, “descending X axial deceleration,” which were taken verbatim 

from requirement 3.2.3.1 of “Stardust SRC AU Requirements Document, 

905C5100016, Rev 0.”

LMSS Systems Engineering believed that the wording of the requirement 

would be understood based upon experience from the Stardust Project, 

where the requirement was implemented properly and verified with a centrifuge test. However, the Stardust and Genesis requirements were difficult to understand since no figures were provided showing the direction of 

the X-axis or the direction of the ‘deceleration’ (acceleration) vector. 
Pa g e E-73 Ge n e s i s Mi s h ap Re 

The SRC drogue deployment requirement was written in terms of a higherlevel requirement (e.g., spacecraft-level instead of SRC-AU level), which 

may have caused confusion at the subsystem level. The Board determined 

that the inversion might not have occurred had the requirement included 

a description of the direction of the acceleration vector, or had a coordinate 

system figure been included with the acceleration vector noted. 

Root Cause 2.2: Systems Engineering did not define detailed verificatio

requirements for subsystems.

The Systems Engineering Team was performing the requirements flowdown function, but was not performing the entire verification roll-up function that led to the incorrect verification of the G-switch sensor function. 

Genesis Project Management and Systems Engineering delegated the component verification function to the PDO with limited oversight from the 

Genesis Project System Engineering in accordance with LMSS/Flight Systems and Systems Engineering practices at the time (Flight Systems Faster/

Better/Cheaper (FBC) Program Plan, FS-98-0006, Rev E, Jan. 2000 and the 

Mission Integration and Test Plan Volume 1 – System Verification Plan, GN57300-100, Oct. 1999). Systems Engineering assigned a type of verification 

(test, analysis, etc.) and a verification event (performance test, functional 

test, etc.) to each subsystem requirement, reviewed spacecraft-level verification results, and performed verification bookkeeping. 

Genesis System Engineering responsibilities should have included establishing detailed expectations for the verification of requirements and 

reviewing the subsystem test plans and verification results, but did not. 

The G-switch sensor inversion might have been avoided had a detailed 

statement been provided regarding how the System or Subsystem requirements to deploy the drogue were to be verified. Such guidance to the SRC 

Avionics Subsystem engineers would have been helpful in establishing 

expectations for close-out of Subsystem verification requirements. The 

Board believes that would have led to adequate verification or a change 

request when another method was proposed. 

Systems Engineering assumed that the Subsystem engineers knew what 

needed to be done to verify their requirements and that no guidance was 

necessary. This was consistent with the pervasive FBC philosophy within 

NASA at the time to push responsibility to the lowest level possible. Meant 

to reduce costs, this approach pushed the responsibility too low, partic-
Ge n e s i s Mi s h ap Re por t Pa g e 

ularly given that the function the SRC-AU performed crossed subsystem 

boundaries, and was therefore a System-level issue. 

Root Cause 2.3: Lack of documentation of changes made to verificatio

methods.

Root Cause 2.4: The Systems Engineering Verification Process did not 

require consideration of verifier’s qualifications or incorporate multiple 

checks.

These two root causes are closely related and are presented together in the 

following discussion.

The method used to verify the G-switch sensor orientation was to inspect 

the Stardust SRC-AU G-switch sensor drawings for similarity to the Genesis drawings. As a result, verification of this one portion of the drogue 

deployment requirement was actually through inspection, not test, as specified by Systems Engineering for that requirement. The SRC-AU specification was under LMSS Level 3 Change Control; as a result, the PIE should 

have processed a Change Request for the change in verification methods, 

but he did not. A Technical Memo or Change Request would have resulted 

in a critical assessment of the inspection approach, namely that the PIE, an 

Electrical Engineer, was performing the verification without the necessary 

mechanical engineering background to review complex mechanical drawings. With a cross check of his work, the G-switch sensor inversion might 

have been identified. 

Since the Stardust AU had undergone a successful centrifuge test to verify 

its G-switch sensor orientation, inspection of the Stardust drawings and 

comparison against the Genesis drawings would have revealed the inversion of the Genesis G-switch sensors, if the comparison had been performed 

correctly. While a direct test is preferable, an inspection of drawings can 

be an acceptable verification method. Ideally, multiple engineers with the 

proper experience and knowledge would have performed the inspection 

independently and compared their results. This was not done. 

Root Cause 2.5: Systems Engineering was not required to review subsystem test procedures or verification results.

Systems Engineering did not assign itself responsibility for reviewing subsystem verification activities. As a result, Systems Engineering was not 
Pa g e E-75 Ge n e s i s Mi s h ap Re 

required to review test procedures or to review test/analysis results performed at the Subsystem-level. 

The quick-lift test that Project Management and Systems Engineering thought 

had replaced the centrifuge test as a means of verifying G-switch sensor orientation was intended to test only the continuity of the circuit. Had Systems 

Engineering reviewed the test procedures or assessed the results of the tests, 

it is possible that the Systems Engineering staff would have recognized that 

not all drogue deployment functions were being verified. 

Root Cause 2.6: Inadequate execution of System-level verificatio

The Flight System Requirements Document (spacecraft-level requirements 

document) included a requirement that read “3.2.1.2.8.3.2.2 Drogue Chute 

Deploy – The SRC shall deploy a drogue parachute capable of providing subsonic 

SRC stability at a velocity of 1.8 + 0.2 Mach.” This requirement, from which 

the SRC-AU requirement was derived, was two requirements in one statement; the first was to deploy a drogue and the second to provide stability 

between Mach 1.6 to 2.0. The Board determined that the weakness of the 

process to verify the requirement led to the G-switch sensor inversion, not 

the weak requirement itself. Analysis was the verification method identified for the requirement, which is generally considered appropriate for 

stability verification, but not for deployment of a parachute, where test is 

appropriate. 

The verification analysis, provided in Recovery Analysis Report – Document No. GN-000-A-88VR, was based on a top-level discussion of the intent 

of the design and mention of a stability analysis, without any technical 

content provided to indicate verification of the requirement. The following 

is an excerpt from the report. 

• “3.2.1.2.8.3.2.2 Drogue Chute Deploy – The SRC shall deploy a 

drogue parachute capable of providing subsonic SRC stability 

at a velocity of 1.8 ± 0.2 Mach.

• DISCUSSION The SRC has been designed to deploy a drogue 

parachute capable of providing transonic SRC stability. The 

sequence of events is that the g switch reads 3 g’s, after coming 

down from a peak of approximately 40 g’s, a period of time 

elapses (5.6 sec) and the drogue mortar is pyrotechnically 

actuated. The drogue parachute enters the supersonic 

slipstream, inflates, and quickly slows the SRC to subsonic 

speeds. The commanding of the drogue mortar actuation 
Ge n e s i s Mi s h ap Re por t Pa g e 

has been calculated to occur at a velocity of 1.8 Mach based 

on known atmospheric conditions tied to entry dynamics. 

Monte Carlo trajectory modeling performed by NASA Langley 

Research Center, which statistically varies trajectory and 

atmospheric parameters over 3000 test cases, verifies system 

performance falls within the required range, and maintains 

SRC stability as required.

• This discussion verifies compliance with paragraph 3.2.1.2.8.3.2.2 

of the Flight System Requirements Document, no further action is 

required.”

As a cross check, two engineers reviewed the recovery analysis; however, 

they did not recognize the lack of any verification in the verification discussion. Further, based on an MIB interview with the LMSS Chief Systems 

Engineer, the focus of the review was on the drogue stability issue alone, not 

the drogue deployment, although the title of the requirement was “Drogue 

Chute Deploy.” Regardless of the wording, the analysis author and reviewers interpreted the requirement to address only stability, not deployment. 

As a result, no one noticed that there was no statement regarding how the 

deployment sequence had (or had not) been tested. If there had been a 

statement regarding the deployment sequence and the System-level verification been performed adequately, the Board believes it is likely the weakness of the actual drogue deployment verification approach would have 

been identified.

The Board realized during an interview with a JPL Systems Engineering team member that the above verification statement was inadequate. 

Although the interviewee did not recall the specific verification analyses, 

he did recall that some of the verification analyses reports were similarly 

inadequate, but he was not aware of any action taken by JPL Systems Engineering to correct the problem.

Contributing Factor 2.1: Lack of a Systems Engineer assigned to the endto-end EDL functio

The PIE for the SRC-AU was responsible for his box and contributed to the 

failure, since the unit had functions that crossed subsystem boundaries. 

However, during the interviews it became clear to the MIB that no one 

on the Systems Engineering Team had been assigned individual Responsibility, Accountability, and Authority (RAA) for the entire EDL sequence 

and for oversight of the system design and operations plans to execute that 

phase. 
Pa g e E-77 Ge n e s i s Mi s h ap Re 

The RAA function was crucial to achieve complete integration and oversight and to ensure that all SRC functions were properly implemented in 

design and verified. The Aerodynamics Lead identified the pyro timing 

requirements used in the AU, but was not responsible for the avionics or 

G-switch sensor that fired the pyro; the Recovery Lead was concerned with 

the parachute functions, but not the components in the AU that deployed 

them; and the Systems Engineering Lead responsible for Avionics considered himself responsible for the electrical function of the AU, but not the 

system-level function the G-switch sensors performed. 

Further, each person thought that someone else had responsibility for the 

G-switch sensors. The LMSS Chief Systems Engineer, in his additional role 

as Chief Engineer, considered himself to be responsible for the G-switch 

sensors. However, this was not understood by the aforementioned engineers, and given that the Chief Engineer was responsible for the rest of 

the spacecraft and held multiple positions within the project, the Board 

does not believe it is reasonable to assume he could have maintained direct 

oversight of such a low-level circuit. In addition, based on MIB interviews, 

it was not clear to the Avionics PIE to whom he should turn for advice or 

interpretation of requirements, results, or changes in plan.

In the Systems Engineering organization, an RAA would be responsible for 

the full end-to-end EDL and thus the G-switch sensor function. Without an 

RAA, the lack of attention to the G-switch sensors by Systems Engineering 

manifested itself as a failure to detect the inversion of the G-switch sensor 

during the design, technical review, and verification processes. Although 

the SRC-AU PIE was also responsible for that function, had a Systems 

Engineer also been responsible for oversight of the all interfaces/functions 

associated with the unit, the Board believes it is likely that the design or 

verification errors would have been detected.

Contributing Factor 2.2: Inadequate Systems Engineering staffing level

Based on MIB interviews, JPL and LMSS Project Management and Systems 

Engineering thought that the LMSS Systems Engineering team had an adequate staff. However, it appeared to the MIB that the staffing levels were 

not adequate; first, when considering the limited responsibilities that the 

System Engineering Team had been assigned and particularly if one considers the Systems Engineering responsibilities that were not performed, 

(e.g., detailed subsystem verification requirements not established, subsystem test procedures not reviewed, and subsystem verification results not 

reviewed). 
Ge n e s i s Mi s h ap Re por t Pa g e 

The MIB drew its conclusion that the LMSS staff was inadequate by considering that the LMSS Chief Systems Engineer held three positions (Chief 

Systems Engineer, Systems Engineering Manager, and Contamination Engineer). It became clear from interviews that the Systems Engineering team 

was hard pressed to meet their stated (although incomplete) obligations, 

much less the additional obligations that should have been assigned. 

Comparison of the LMSS Stardust and Genesis Systems Engineering Teams 

also indicates that the Genesis Team was too small. The small Genesis 

Systems Engineering staff was the result of a belief on the part of JPL and 

LMSS Project Management that leveraging off of Stardust heritage would 

allow for a smaller, less expensive team. The Board did not believe this 

to be a sound position, particularly given that heritage assumptions did 

not hold as the design matured and given that the Genesis SRC was more 

complex than the Stardust SRC. It was also not sound because the Systems 

Engineering requirements and verification processes needed to be executed 

with undiminished rigor. 

By comparison, the Genesis actual labor charges show approximately a 26-

percent reduction over Stardust levels from inception to the start of ATLO. 

These were the critical periods when mistakes were made that eventually 

led to the mishap. Figure E-1 shows this mismatch in staffing between the 

two projects. 

0.0

2.0

4.0

6.0

8.0

10.0

12.0

14.0

16.0

18.0

20.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

STARDUSTACTUALS

GENESISACTUALS&BESTESTw ithFEB01LAUNCH

SYSTEMS ENG BACKGROUND - STARDUST ACTUALS

BARS GENESIS - ACTUALS, ETC & EST

ACTUALS THROUGH 10/00

NO MARS FLOWDOWN

GENESIS

LAUNCH

STARDUST ATLO MO.16

GENESIS ATLO MO. 16

STARDUST

LAUNCH

CDR

CDR Figure E-1.

Comparison of LM

Stardust and Gene

Systems Engineer

staffing profiles ov

project life. Genes

launch indicates p

launch; actual lau

delayed late in life 

to accommodate M

Odyssey needs.
Pa g e E-79 Ge n e s i s Mi s h ap Re 

MSS 

esis 

ing 

ver 

sis 

planned 

nch 

 cycle 

Mars 

As noted earlier, the JPL Systems Engineering involvement in the spacecraft 

was limited. Had they been more involved in LMSS activities, their staff of 

three Systems Engineers would not have been sufficient for the task. 

An understaffed Systems Engineering team caused the JPL and LMSS Systems Engineers to devote less time to 

• understanding or uncovering subsystem problems (sometimes called 

“unknown unknowns”), 

• melding the spacecraft and mission systems (JPL and LMSS) teams, and 

• ensuring a comprehensive verification and validation program was performed at all system levels. 

The small staff did not directly cause the failure, but it did significantly 

contribute to its occurrence.

Root Cause Category No. 3: Review Process Fail

The Review Process at every level of detail failed to identify the G-switch 

sensor inversion. The design reviews failed to identify the error in the 

design, due to a lack of detail in some reviews and a lack of participation 

in others. 

Later Red Team reviews, assigned in the wake of the Mars mission failures, 

should have identified the deletion of the centrifuge test as an issue and the 

inadequate method used to verify G-switch sensor orientation (inspection 

of Stardust heritage drawings). However, the Red Team did not identify 

these, due in large part to inadequate time to review the project, errors by 

the focus teams assigned responsibility to review the SRC-AU functions, 

and inadequate management of the Red Team Focus Groups. 

The issue of inappropriate faith in heritage designs by the Red Team is discussed later in this Heritage Section of this narrative.

1. Project Technical Reviews

Root Cause 3.1: Participation by key individuals not required at projec

technical and drawing reviews.

Based on MIB interviews, it appears that no one with a System-level perspective of the drogue chute deployment participated in the lower-level 

peer reviews of the SRC-AU. An attendees list could not be located. Addi-
Ge n e s i s Mi s h ap Re por t Pa g e 

tionally, no one from Systems Engineering participated or was required 

to participate in the drawing signoffs. The Board believes the G-switch 

sensor design inversion might have been identified had an engineer with a 

System-level perspective participated in these reviews. 

Root Cause 3.2: Design Reviews were too high level to adequately asses

the design.

An assessment of the CDR documentation for the AU indicates that it was 

held at too high a level to identify the G-switch sensor design error. The 

only references in the CDR presentation to the G-switch sensors were in 

a functional block diagram, timing description diagram, and a note that 

centrifuge testing was planned for the switch. The AU CDR, scheduled for 

only 4 hours, consisted of a 148-page chart package, which contained little 

technical content and was insufficient to support a box-level Critical Design 

Review. No action items regarding the G-switch sensors were taken.

Based on interviews, there were no noteworthy discussions of the G-switch 

sensor. A partial attendance list indicates that the JPL Systems Engineer 

participated along with other JPL Electrical Engineers and EaglePicher Inc. 

Battery Engineers. The LMSS attendance list could not be located. The 

LMSS Chief Systems Engineer chaired the review.

Had the design reviews been conducted in significantly more detail, it 

is likely the inversion would have been discovered (e.g., detailed walkthroughs of printed circuit board containing the G-switch sensor and discussion of its functions and how they had been or would be verified).

Red Team Reviews

Root Cause 3.3: JPL SMO gave the Red Team too little time to perform an 

adequate assessment.

A key failing of the Red Team review was that the JPL SMO allowed 

insufficient time to perform the review adequately. For the June 2000 Red 

Team review, the JPL SMO gave them only 3 days to review data products 

and meet with the project teams, which was done to avoid impacting the 

project’s schedule. However, the review was of insufficient depth to meet 

its chartered goal, which was in part to evaluate the spacecraft and SRC 

design, implementation, and test. Had JPL SMO allocated adequate time 

to the Red Team for a thorough review, it is possible that the error, particularly the verification error, would have been discovered.
Pa g e E-81 Ge n e s i s Mi s h ap Re 

Root Cause 3.4: Inadequate Red Team management of focus groups. 

The EPS Focus Group was a power-system-discipline-oriented team, not 

the ‘cross cutting’, multidiscipline-oriented team necessary to review the 

design adequately. This was not the fault of the EPS Focus Group, but rather 

the result of an error on the part of Red Team management to structure the 

teams with all of the necessary support. 

For the October 2000 Red Team cycle, an EDL Focus Group was formed. 

This Group was to take responsibility in part for AU parachute deployment 

functions from the EPS Focus Group. However, the EDL Focus Group did 

not address the SRC-AU, except to recommend an action to coordinate with 

the Avionics Focus Group to review issues relative to the parachute deployment initiation system. The action was never completed because the Red 

Team system did not require actions to be closed. If the EDL Focus Group 

had pursued the EDL sequence completely, and not focused almost exclusively on entry aerodynamics, the Board believes it is likely they would 

have questioned the G-switch sensor implementation or verification. Further, had the EDL Focus Group followed up, or the Red Team action item 

process forced a follow up with the Avionics Focus Group, the errors might 

have been found. These EDL Focus Group failures were also ultimately 

failures to manage the Red Team properly.

Root Cause Category No. 4:

Unfounded Confidence in Heritage Design

Root Cause 4.1: Inappropriate confidence in heritage designs. 

The Genesis Project was based on an assumption of heavy reuse of heritage 

designs from the Stardust Project. The unfounded confidence in heritage 

hardware as being inherently more reliable than new designs helped lead 

to this mishap. The view that heritage hardware should be considered 

inherently more reliable than non-heritage hardware was not universally 

held by Genesis Team members, but was extensive and was voiced as late 

as the February 2004 Genesis System Recovery Design Review. 

Although it was recognized that the final Genesis AU was not strictly a heritage design (since it was extensively modified from the Stardust design), 

many team members viewed it as maintaining much of its heritage and, 

hence, requiring less scrutiny in design and verification. An erroneous 

belief that the SRC-AU was a heritage, or partially a heritage design, and 
Ge n e s i s Mi s h ap Re por t Pa g e 

unfounded confidence in heritage designs in general led to five errors that 

contributed to the mishap.

1. The key drogue deployment requirement in the SRCAU specification was recycled from Stardust without 

reconsideration;

2. Stardust schematics were used without reconsideration;

3. the design reviews focused less attention to the details of the 

design of the pyro firing circuitry, because greater confidence 

than was justified was placed in it due to its heritage;

4. verification of the G-switch sensor orientation by similarity to 

the Stardust heritage design was performed (and performed 

incorrectly); and

5. one of the Red Team Focus Groups that reviewed the SRC-AU 

did not review the design or the verification methodology, 

because they considered the likelihood of a design or 

verification issue with a heritage design to be unlikely. 

The FBC philosophy was, in part, based on the assumption that the use of 

heritage hardware would reduce costs, schedule, and technical risks and 

reduce verification process requirements. The assumption that heritage 

hardware could reduce cost and schedule risks was perhaps well founded, 

but such an argument regarding technical risks could only be made after a 

thorough technical review of the design and its verification in the Genesisspecific application. In summary, there existed a major misconception within 

much of the JPL and LMSS leadership and within the Red Team that heritage 

hardware meant a lower standard of review and verification was acceptable. 

Had the same standards as those applied to new hardware been applied to 

the SRC-AU, it is likely that the design error would not have occurred or 

would have been discovered during verification.

Root Cause Category No. 5: Failure to “Test as You Fly”

The failure of Project Management and Systems Engineering to recognize 

the importance of the ‘test as you fly’ philosophy was evidenced by the deletion of the centrifuge test and the replacement of the test with the unsuccessful verification-by-drawing inspection. These issues have been previously 

presented; however, there was one additional error demonstrating a failure 

to recognize the importance of testing, which was that the G-switch sensor 

alignment was not identified as critical in the Pointing and Alignment Document. 
Pa g e E-83 Ge n e s i s Mi s h ap Re 

Appendix D-7 contains a more complete discussion of the Genesis “test as 

you fly” issues in report entitled, ‘Test as You Fly Observations.’

Root Cause 5.1: G-switch sensor not identified as having a critical alignmen

in the Pointing and Alignment Document (Phasing Plan).

In addition to deleting the test for schedule reasons, the Pointing Budget and 

Alignment Criteria Document (Phasing Test Plan) did not identify the Gswitch sensor as having a critical alignment and, hence was not included in 

that plan. The purpose section of the document read in part “The Genesis 

Pointing Budget and Alignment Criteria document establishes subsystem component 

and instrument control and knowledge alignment requirements.” The document 

did not include the G-switch sensors as having a critical alignment, so no 

alignment test was formally planned as part of the document. The possible 

reason the G-switch sensors were not included in the plan was that such 

plans are typically produced by engineers concerned with hardware that 

has precise alignment requirements, such as star trackers or science instruments. Although members of the Systems Engineering Team approved the 

document, the previously noted issue of a lack of a Systems Engineer with 

end-to-end EDL responsibility, inclusive of the G-switch sensors, may have 

contributed to the omission. 

Had the G-switch sensors been identified as alignment-critical and included 

in the Phasing Test Plan, the drogue deployment failure might have been 

avoided. Testing would have been required and additional attention would 

have been given to the G-switch sensor orientation.

Root Cause Category No. 6: Faster, Better, Cheaper Issues

Root Cause 6.1: Faster, Better, Cheaper Philosophy: cost-capped missio

with threat of cancellation if overrun.

FBC was a concept, under an annual fixed budget, to increase the number 

of experimental missions from one ‘big’ billion dollar experiment to a series 

of smaller cost missions, e.g., ~$200-250M each, with each implemented via 

streamlined processes. Characteristics of missions selected under the FBC 

mantle were shortened schedules; lower overall budget, as well as budget 

reserves; maximum value on heritage systems; and implementation of government-industry partnering rather than the traditional government oversight process. NASA recognized that the risk to mission success would 

increase, but it was hoped that using the contractors’ proven processes, hardware, and software would minimize the risks. Some NASA leaders believed 
Ge n e s i s Mi s h ap Re por t Pa g e 

that four out of five successes were better than one billion-dollar mission 

failure. 

However, FBC missions became synonymous with fixed-price, cost-capped 

missions. Competitive pressures were intended and did maximize the ratio 

of science to total dollars expended. With science scope determined early in 

the project, and with fixed launch windows (fixed schedule) for most deepspace missions, risk was the only variable a project team had to trade to 

maintain fixed cost and schedule. 

As proposed, selected, and confirmed on Genesis, the FBC mantra had the 

following effects.

• Maximum science scope and focus on payload issues at the expense of the 

spacecraft, SRC, and ground systems.

• Low schedule and dollar reserves leading to significant adverse pressure 

on decision making.

• Focus on a low-risk implementation led to a reliance on heritage hardware 

which gave a false sense that mission risk was controlled and allowed 

the risks associated with the lower standards for heritage to go unrecognized.

• A very lean Systems Engineering Team with heavy un-checked reliance 

on the subsystems teams for requirements and verification functions.

• Near total reliance by JPL Project Management and Systems Engineering 

on the LMSS Team and processes with little cross checking outside of payload and payload interface activities.

NASA was also at fault for encouraging and accepting this concept. They 

selected this mission with only 11-percent budget reserve at confirmation 

and had only 7.2 percent at CDR. All involved (NASA, JPL, and LMSS) were 

convinced that because of the assumed heritage design, this was an acceptable position. However, once heritage was broken and design issues arose, 

and the limited reserves expended, there was only one place for funds to be 

found -- the contractor’s profits. Eventually, JPL Project Management asked 

LMSS to give up fee to cover other non-LMSS risk issues and avoid a project 

overrun of the cost cap. Later, due to a launch slip and NASA-mandated 

changes the project obtained more money for the JPL Project Team; and was 

able to re-establish fee for LMSS through incentives to be efficient during 

flight operations. 
Pa g e

E-85Ge n e s i s Mi s h p eot

1

Drogue failed to deploy

G006

G-Switch Inverted

G001

Design Process Generated Design

Error

G002

Relay Card Drawing Was

Incorrect

G007

Page 2

Technical Reviews (peer,

drawing, AU CDR) Failed to

Identify Design Error

G003

Peer and drawing reviews failed

to identify design error

G029

Page 8

Insufficient detail at AU CDR

for adequate visibility into

design

G030

Page 9

AU CDR Attendees may have

believed any error would be

identified during testing and,

as a result, did not focus

adequately on possible design errors

G031

Page 10

Verification Process Failed to

Detect Design Error

G004

Page 11

Red Team Reviews Failed to

Identify Verification Error

G005

Page 22

Legend

Incident

Proximate 

Cause

Top – Level 

Process Failure 

Systems 

Engineering Root 

Causes

Review Process 

Root Causes

Heritage Root 

Causes

‘Test as you Fly’ 

Root Causes

Project Management 

Root Causes

Contributing 

Factors

Intermediate 

Events

FBC

Root Causes

Figure E-2. Event and Causal Factor Tree.
Ge n e s i s Mi s h 

p eot Pa g eE-86 

Relay Card Drawing Was

Incorrect

G007

Page 1

Inadequate SRC AU-Level Drogue

Deployment requirement leading

to possible confusion at

subsystem level.

G008

Coordinate system figure and

acceleration vector figure not

referenced in AU specification

or testing documentation

G011

Inadequate SE Requirements

Development Process

F

Page 3

Heritage Requirement Taken from

Stardust (which had no

Coordinate System) w/o

Reconsideration – Systems

Engineering Assumed It Would be 

understood 

G012

Page 4

Heritage Stardust Schematic

Used to Create Genesis

Schematic

G009

Heritage Stardust Schematic

contained no indication of

sensitivity to G-switch

Orientation

G018

No Guidance to Relay board

layout engineer or AU PIE from

Responsible Systems Engineer

Regarding sensitivity to 

orientation

G019

Page 4

Relay board layout engineer and

AU PIE (both Electrical

Engineers) not mechanically

oriented

G020

Page 6

G-switch piece part drawing

indicating acceleration vectordirection apparently not used

or not understood by Relay Board Layout Engineer

G010

Page 7
Pa g e

E-87Ge n e s i s Mi s h p eot

3

RC 2.1 - Inadequate SE 

Requirements Development 

Process

F

Page 2

Page 20

Page 4

CF1.1 - Insufficient JPL Project 

Management and Systems Engineering 

insight into LMA Activities

H

CF2.2 - Inadequate Systems 

Engineering staffing level

I
Ge n e s i s Mi s h ap Re por t Pa g e 

4

No Guidance to Relay board

layout engineer or AU PIE from

Responsible Systems Engineer

Regarding sensitivity to

G019

Page 2

Heritage Requirement Taken from

Stardust (which had no

Coordinate System) w/o

Reconsideration – Systems

Engineering Assumed It Would be understood

G012

Page 2

RC2.1- Inadequate 

Requirements Generation

F

Page 3

RC 4.1 Inappropriate 

confidence in heritage 

Designs

G

CF2.1 – Lack of a Systems 

Engineer Assigned End to End 

Entry, Descent and Landing 

Function

D

Page 5
Pa g e

E-89Ge n e s i s Mi s h p eot

5

D

Page 4

Page 13

Page 8

... see x-ref

CF1.2 - SRC not treated as a

separate spacecraft

G028

CF1.1 - Inadequate JPL Project Management

and Systems Engineering Insight

into LMA Activities

H

CF2.2 - Inadequate Systems Engineering

Staffing Level

I

CF2.1 – Lack of a Systems 

Engineer Assigned End to End 

Entry, Descent and Landing 

Function
Ge n e s i s Mi s h ap Re por t Pa g e 

6

Relay board layout engineer and

AU PIE (both Electrical

Engineers) not mechanically

oriented

G020

Page 2

Page 7

Relay board layout engineer and

AU PIE unaware of the need to

ask for assistance

G023

No Data

G024
Pa g e E-91 Ge n e s i s Mi s h ap Re 

7

G-switch piece part drawing

indicating acceleration vector

direction apparently not used

or not understood by Relay

G010

Page 2

Relay board layout engineer and

AU PIE (both Electrical

Engineers) not mechanically

oriented�

G020

Page 6
Ge n e s i s Mi s h ap Re por t Pa g e 

8

Peer and drawing reviews failed

to identify design error

G029

Page 1

Peer reviews not well attended

G032

RC3.1 – Key individuals’ 

attendance was not required at 

project technical and drawing 

reviews

G034

H

D

Page 5

CF2.1 – Lack of a Systems 

Engineer Assigned End to End 

Entry, Descent and Landing 

Function

CF1.1 - Insufficient JPL Project 

Management and Systems Engineering 

insight into LMA Activities
Pa g e E-93 Ge n e s i s Mi s h ap Re 

9

Insufficient detail at AU CDR

for adequate visibility into

design

G030

Page 1

RC3.2 - SRC AU Critical Design Review

was Too High Level to

Adequately Assess the Design

G036

H

CF1.1 - Insufficient JPL Project 

Management and Systems Engineering 

insight into LMA Activities
Ge n e s i s Mi s h ap Re por t Pa g e E-

AU CDR Attendees may have

believed any error would be

identified during testing and,

as a result, did not focus

adequately on possible design 

errors

G031

Page 1

Centrifuge test of G-switch in

plan at time of AU CDR

G038

RC 2.3 – Lack of Documentation 

of changes made to verification 

methods

E
Pa g e

E-95Ge n e s i s Mi s h p eot

11

Verification Process Failed to

Detect Design Error

G004

Page 1

Centrifuge Test Deleted

G040

RC5.1 - G-Switch sensor was not identified as 

having a critical alignment in the Pointing and 

Alignment Document (Phasing Test Plan)

G049

H I

Schedule Pressure

G044

Spacecraft-level Assembly and

Test (ATLO) behind schedule;

SRC AU contributing to delays

G050

Page 12

Scope of centrifuge test

increased beyond G-switch

testing to include test relays

under g-load conditions

G051

Page 13

Belief by LMA and JPL

Management and Systems

Engineering that "quick-lift"

test functionally replaced centrifuge 

test

G045

Incorrect and cryptic briefing

bullet regarding deletion of

centrifuge test

G056

Page 14

Systems Engineering did not

review test procedures or

verification results

G062

Page 15

LMA Project Management believed

orientation verified by

inspection of Stardust and

Genesis drawings

G046

Page 16

SRC AU PIE incorrectly verified

orientation by inspection

G041

Page 17

System-level verification

analysis (recovery analysis)

did not detect lack of

verification of drogue

B

Page 20

CF1.1 - Insufficient JPL Project 

Management and Systems Engineering 

insight into LMA Activities

CF2.2 - Inadequate Systems Engineering 

staffing level
Ge n e s i s Mi s h ap Re por t Pa g e E-

Spacecraft-level Assembly and

Test (ATLO) behind schedule;

SRC AU contributing to delays

G050

Page 11

RC6.1 - FBC Philosophy: ‘Cost 

Capped’ mission with threat of 

cancellation, if overrun

G052
Pa g e

E-97Ge n e s i s Mi s h p eot

13

Scope of centrifuge test

increased beyond G-switch

testing to include test relays

under g-load conditions

G051

Page 11

RC2.2 – Systems Engineering 

did not define detailed verification 

requirements for subsystems

G053

H I

D

Page 5

CF2.1 – Lack of a Systems 

Engineer Assigned End to End 

Entry, Descent and Landing 

Function

CF1.1 - Insufficient JPL Project 

Management and Systems Engineering 

insight into LMA Activities

CF2.2 - Inadequate Systems 

Engineering staffing level
Ge n e s i s Mi s h ap Re por t Pa g e E-

Incorrect and cryptic briefing

bullet regarding deletion of

centrifuge test

G056

Page 11

RC1.1.- Project Management and 

Systems Engineering did not 

perform due diligence with regards 

to reviewing briefing materials.

G058

RC2.3 – Lack of documentation of 

changes made to verification 

methods

E
Pa g e E-99 Ge n e s i s Mi s h ap Re 

15

Systems Engineering did not

review test procedures or

verification results

G062

Page 11

RC 2.5 - Systems Engineering was 

not required to review subsystem test 

procedures or verification results

C

Page 20

H I

CF2.2 - Inadequate Systems 

Engineering staffing level

CF1.1 – Insufficient JPL Project 

Management and Systems 

Engineering insight into LMA 

activities. 
Ge n e s i s Mi s h ap Re por t Pa g e E-1

LMA Project Management believed

orientation verified by

inspection of Stardust and

Genesis drawings

G046

Page 11

SRC AU PIE did not indicate

that G-switch orientation was

incorrect

G063

SRC AU PIE incorrectly verified

orientation by inspection

A

Page 17
Pa g e E-101 Ge n e s i s Mi s h ap Re 

17

SRC AU PIE incorrectly verified

orientation by inspection

G041

Page 11

SRC AU PIE incorrectly verified

orientation by inspection

A

Page 16

SRC AU PIE lacked sufficient

knowledge and experience to

verify complex mechanical

drawings

G065

Page 18

Verification by inspection was

not formally documented

G067

Page 19
Ge n e s i s Mi s h ap Re por t Pa g e E-1

SRC AU PIE lacked sufficient

knowledge and experience to

verify complex mechanical

drawings

G065

Page 17

RC2.5 – Systems Engineering was 

not required to review subsystem 

test procedures or verification 

results

G068

H I

CF2.2 - Inadequate Systems 

Engineering staffing level

CF1.1 – Insufficient JPL Project 

Management and Systems 

Engineering insight into LMA 

activities. 
Pa g e E-103 Ge n e s i s Mi s h ap Re 

19

Verification by inspection was

not formally documented

G067

Page 17

RC2.3 – Lack of Documentation of 

Changes made to verification methods

E
Ge n e s i s Mi s h 

p eot Pa g eE-104 2

System-level verification

analysis (recovery analysis)

did not detect lack of

verification of drogue

B

Page 11

Verification statements in the

System-Level “Recovery

Analysis” did not verify drogue

deployment requirement

G071

System-Level Drogue Deploy

Requirement Not Included in

Verification Requirement (only

Aerodynamic Stability)

G072

RC2.6 - Inadequate Execution of 

System-Level Verification

G075

Page 21

F

Page 3

Recovery Analysis reviewers did

not include an engineer

responsible for Entry, Descent,

and Landing Function

G073

RC2.6 - Inadequate Execution of 

System-Level Verification

G075

Page 21

D

Page 5

C

Page 15

RC 2.1 - Inadequate SE 

Requirements Development 

Process

CF2.1 – Lack of a Systems 

Engineer Assigned End to End 

Entry, Descent and Landing 

Function

RC2.5 – Systems Engineering was 

not required to review subsystem 

test procedures or verification 

results
Pa g e

E-105Ge n e s i s Mi s h p eot

21

G075

Page 20Page 20

H I

RC2.6 - Inadequate Execution of 

System-Level Verification

CF1.1 – Insufficient JPL Project 

Management and Systems 

Engineering insight into LMA 

activities. 

CF2.2 - Inadequate Systems 

Engineering staffing level
Ge n e s i s Mi s h 

p eot Pa g eE-106 2

Red Team Reviews Failed to

Identify Verification Error

G005

Page 1

Red Team EPS Focus Group did

not identify SRC AU

verification error

G081

EPS Focus Group believed

G-switch design was heritage;

no further investigation

required

G084

RC4.1 - Inappropriate confidence 

in Heritage Designs

G

Loss of design Heritage not

communicated to or understoodby Red Team EPS Focus Group

G092

Page 24

Red Team focused on problems

identified by project instead

of searching for unknown

problems

G091

Page 23

Red Team focused group was

discipline oriented (power),

not ‘cross cutting’ –

responsible for power to pyro,

G085G088

Red Team EDL Focus Group, which

had end-to-end responsibility

for EDL, did not reviewdeployment circuitry at

G082

RC3.4 - Inadequate Red Team 

Management of Focus Groups

G088

Red Team EDL action item to

coordinate w/ Avionics focus

group on pyro initiation

circuitry did not occur

G083

Page 25

RC3.4 - Inadequate Red Team 

Management of Focus Groups
Pa g e E-107 Ge n e s i s Mi s h ap Re 

23

Red Team focused on problems

identified by project instead

of searching for unknown

problems

G091

Page 22

RC3.3 - JPL SMO gave Red Team 

too little time to perform an adequate 

assessment

G095
Ge n e s i s Mi s h ap Re por t Pa g e E-1

Loss of design Heritage not

communicated to or understoodby Red Team EPS Focus Group

G092

Page 22

No Data

G093
Pa g e E-109 Ge n e s i s Mi s h ap Re 

25

Red Team EDL action item to

coordinate w/ Avionics focus

group on pyro initiation

circuitry did not occur

G083

Page 22

Not required to close Red Team

action items (only identified

issues)

G087

G088

RC3.4 - Inadequate Red 

Team Management of 

Focus Groups

Pa g e F-111 Ge n e s i s Mi s h ap Re p

Appendix F Cont

F-1 Genesis Project Enviro

The JPL Failure Review Board report was not complete at the time of 

publication. Please request this information from Dr. John Klein at:

John.W.Klein@jpl.nasa.gov

Pa g e G-113 Ge n e s i s Mi s h ap Re 

Append

Contractors Supporting the G

Lockheed Martin Personnel who provided significant support to the MIB:

Douglas W. Banning

Richard P. Bland

Gerald W. Byers

Edward K. Clint

Robert A. Corwin

Calvin L. Craig, Jr

Jack A. Dekker

Robin D. Diloreti

Randy R. Doggett

Peter G. Doukas

C. Thomas Edquist

Rick A. Emerie

Steven J. Glenn

Jeffery J. Greteman

Richard A. Kriegbaum

Kelli L. Kubala

Donald C. Larson

Shelby L. Logan

Charles R. Love

Gary D. Mahonchak

Alfred D. McKinney

Lloyd P. Oldham

Brian W. Overman

David E. Perkins

Charles E. Rasbach

Owen G. Short

Nicholas G. Smith

Jarvis T. Songer

Kenny R. Starnes

Patricia A. Stroh

Joseph M. Vellinga

William H. Willcockson

Randall S. Wilson

Alison E. Zehnle

Pa g e H-115 Ge n e s i s Mi s h ap Re 

Append

Meeting Minutes

Proprietary and/or Export Contr

text remove

Pa g e I-117 Ge n e s i s Mi s h ap Re 

Append

Press Releas

 Conten

9/10/04 NASA Appoints Genesis Mishap 

Investigation Board Leader (04-295)............................ 324

9/20/04 Genesis Mishap Investigation 

Board Status Report #1 (04-306)................................... 326

9/23/04 Genesis Mission Status Report (04-236)............ 327

9/30/04 Genesis Mission Status Report (04-245)............ 329

10/14/04 NASA’s Genesis Mishap Board 

& Researchers Both Report Progress (04-345) ............ 331
Ge n e s i s Mi s h ap Re por t Pa g e I

Donald Savage Sept. 10, 2004 

Headquarters, Washington 

(Phone: 202/358-1727) 

RELEASE : 04-295 

NASA Appoints Genesis Mishap Investigation Board Leader

NASA’s Associate Administrator for Science Al Diaz announced today, Dr. 

Michael Ryschkewitsch, Director of the Applied Engineering and Technology Directorate at NASA’s Goddard Space Flight Center (GSFC), Greenbelt, 

Md., would lead the Genesis Mishap Investigation Board (MIB). 

The MIB will gather information; analyze the facts; identify the proximate 

cause(s), root cause(s) and contributing factors relating to the Genesis mission; and recommend appropriate actions to prevent a future similar mishap. The Genesis sample return capsule failed to deploy its parachutes, as 

it descended through Earth’s atmosphere September 8. 

The MIB will include experts from NASA, other government agencies and 

external consultants. The Board’s investigation report is due to NASA Headquarters in mid-November. NASA will release the names of additional MIB 

members as soon as available. The Board’s initial meeting is next week. 

Prior to his current assignment, Ryschkewitsch was Deputy Director of the 

GSFC Applied Engineering and Technology Directorate. He also served 

as the center’s Deputy Director of the Systems, Technology and Advanced 

Concepts Directorate. 

He has a bachelor’s degree and Ph.D. in physics from Duke University, Durham, N.C. Prior to joining NASA, he served as a postdoctoral fellow and 

Visiting Assistant Professor of Physics at the University of Delaware. He 

joined GSFC in 1982 as a cryogenics engineer. He served as Head of the 

Cryogenic Systems Development Section and Assistant Branch Head for 

the Electromechanical Systems Branch. He was selected as Associate Chief 

of the Space Technology Division in 1990. 

He led the GSFC team that worked with Ball Aerospace to develop the 

concept for the Corrective Optics Space Telescope Axial Replacement 

(COSTAR), used in the repair of the Hubble Space Telescope. In 1992, he 

was selected to form, then became Chief, of the Engineering Directorate 

Systems Engineering Office. 
Pa g e I-119 Ge n e s i s Mi s h ap Re 

He is a past recipient of the Robert Baumann Award for Mission Success. 

In 2004 he received the NASA Engineering and Safety Center Leadership 

Award. 

NASA’s Jet Propulsion Laboratory (JPL) in Pasadena, Calif., manages the 

Genesis mission for NASA’s Science Mission Directorate, Washington. 

Lockheed Martin Space Systems, Denver, developed and operated the 

spacecraft. JPL is a division of the California Institute of Technology, Pasadena. News and information about Genesis is available on the Internet at: 

http://www.nasa.gov/genesis 

For background information about Genesis, visit: 

http://genesismission.jpl.nasa.gov 

For information about NASA on the Internet, visit: 

http://www.nasa.gov 

- end 
Ge n e s i s Mi s h ap Re por t Pa g e I

Donald Savage Sept. 20, 2004 

Headquarters, Washington 

(Phone: 202/358-1727) 

RELEASE : 04-306 

Genesis Mishap Investigation Board Status Report #1

The NASA Genesis Mishap Investigation Board (MIB) arrived at Dugway 

Proving Ground (DPG), Utah, September 10, to take charge of the investigation. The Genesis Sample Return Capsule (SRC) impacted the ground after 

its drogue and parafoil systems failed to deploy during re-entry September 

8. Dr. Michael Ryschkewitsch is the leader of the MIB. 

Thanks to excellent work by the Genesis Project Team, functioning as an 

initial response team, the wreckage of the SRC and its contents of scientific 

samples were recovered from the dry lakebed. The science team continues 

work securing and curating the recovered sample materials, working independently from the activities of the MIB. 

Since the initial recovery of the hardware, an inventory was made of the 

impact crater, both by visual examination and metal detector, to ensure 

no significant wreckage remains. The recovery team finished its work and 

turned the impact crater site back over to DPG. 

The team finalized plans for preparing and transporting the SRC wreckage 

to Lockheed Martin Space Systems’ facilities in Denver, where the spacecraft was built and tested. 

The MIB determined all the science-specific hardware is not relevant to the 

Board’s work in determining the causes of the mishap. That hardware was 

released to the Project’s Science and Curation Team for continued processing. At the request of the Board, NASA’s Jet Propulsion Laboratory, Pasadena, Calif., and Lockheed Martin have begun the process of sorting and 

assembling the Genesis records and data. 

News and information about Genesis is available on the Internet at: 

http://www.nasa.gov/genesis & http://genesismission.jpl.nasa.gov 

- end - 
Pa g e I-121 Ge n e s i s Mi s h ap Re 

DC Agle (818) 393-9011 

Jet Propulsion Laboratory, Pasadena, Calif.

Donald Savage (202) 358-1547

NASA Headquarters, Washington, D.C.

Bill Jeffs (281) 483-5035 

Johnson Space Center, Houston

NEWS RELEASE: 2004-236 September 23, 2004

GENESIS MISSION STATUS REPORT

The Genesis team has shipped its first scientific sample from the mission’s 

specially constructed cleanroom at the U.S. Army Proving Ground in 

Dugway, Utah. The sample, containing what are known as “lid foils,” was 

attached to the interior lid of the Genesis sample return capsule. 

“This is the first batch in what we are growing more confident will be many 

more scientifically valuable samples,” said Genesis Project Manager Don 

Sweetnam of NASA’s Jet Propulsion Laboratory, Pasadena, Calif. “It appears 

that we have recovered about 75 to 80 percent of these lid foils. A great deal 

of credit has to go to the dedicated men and women of Genesis who continue to do very precise, detailed work out there in the Utah desert.” 

After the sample was shipped from Utah, it was received by Genesis coinvestigator Nishizumi Kunihiko from the University of California, Berkeley, Space Sciences Laboratory. 

In addition to the lid foils, there was optimistic news about the collector 

array. Team members from JPL arrived in Utah on Monday with a special fixture to aid in handling the science canister’s stack of four collector 

arrays. The stack was successfully removed as one piece. With the stack on 

the fixture, the team has begun the process of disassembling the arrays. 

Several large pieces of individual collector materials, including one completely intact hexagon, were recovered from the top array. 

The Genesis cleanroom activities are focused on getting the materials ready 

for shipping. A date has not yet been selected for transporting the Genesis 

science canister and recovered collector materials from Dugway to NASA’s 

Johnson Space Center in Houston. The team continues its meticulous work 
Ge n e s i s Mi s h ap Re por t Pa g e I

and believes that a significant repository of solar wind materials has survived that will keep the science community busy working on their science 

objectives. 

News and information about Genesis is available online at 

http://www.nasa.gov/genesis . For background information about Genesis, visit http://genesismission.jpl.nasa.gov . For information about NASA 

visit http://www.nasa.gov . 

-end
Pa g e I-123 Ge n e s i s Mi s h ap Re 

DC Agle (818) 393-9011 

Jet Propulsion Laboratory, Pasadena, Calif.

Gretchen Cook-Anderson (202) 358-0836 

NASA Headquarters, Washington, D.C.

Bill Jeffs (281) 483-5035 

Johnson Space Center, Houston

NEWS RELEASE: 2004-245 September 30, 2004

GENESIS MISSION STATUS REPORT

The Genesis team is preparing to ship its samples of the Sun from the mission’s temporary cleanroom at the U.S. Army Proving Ground, Dugway, 

Utah, to NASA’s Johnson Space Center, Houston.

“We have essentially completed the recovery and documentation process 

and now are in the business of preparing everything for transport,” said 

Eileen Stansbery, Johnson Space Center assistant director of astromaterials 

research and exploration science. “We still have a way to go before we can 

quantify our recovery of the solar sample. I can tell you we have come a 

long way from September 8, and things are looking very, very good.” 

A major milestone in the process was the recovery of the Genesis mission’s 

four separate segments of the concentrator target. Designed to measure the 

isotopic ratios of oxygen and nitrogen, the segments contain within their 

structure the samples that are the mission’s most important science goal. 

“Retrieving the concentrator target was our number one priority,” Stansbery said. “When I first saw three of the four target segments were intact, 

and the fourth was mostly intact, my heart leapt. Inside those segments are 

three years of the solar samples, which to the scientific community, means 

eons worth of history of the birth of our solar system. I saw those, and I 

knew we had just overcome a major hurdle.” 

Other milestones in the recovery process included the discovery that the 

gold foil collector was undamaged and in excellent condition. The gold foil, 

which is expected to contain almost a million billion atoms of solar wind, 

was considered the number two priority for science recovery. The polished 

aluminum collector was misshapen by the impact. However, it is intact and 
Ge n e s i s Mi s h ap Re por t Pa g e I

expected to also yield secrets about the Sun. Another occurred when the 

cleanroom team disassembled the collector arrays. They revealed, among 

large amounts of useable array material, some almost whole sapphire and 

coated sapphire collectors and a metallic glass collector. 

Packing solar samples for transport is a little different than packing a 

house-worth of belongings for a cross-country move. After the meticulous 

process of inspection and documentation, each segment of collector gets its 

own ID number, photograph and carrying case. The samples and shipping 

containers fill the space of about two full size refrigerators. The Genesis 

material will probably move to the Johnson Space Center within the next 

week. 

“If you had told me September 8 that we would be ready to move Genesis 

samples to Houston within the month I would have replied, ‘no way,’” said 

Genesis Project Manager Don Sweetnam of NASA’s Jet Propulsion Laboratory, Pasadena, Calif. “But here we are, with an opportunity to fulfill our 

major science objectives. It is a great day for Genesis, and I expect many 

more to come.” 

For more information about the Genesis mission on the Internet, visit 

http://www.nasa.gov/genesis . For background information about Genesis 

on the Internet, visit http://genesismission.jpl.nasa.gov . 

-end
Pa g e I-125 Ge n e s i s Mi s h ap Re 

Donald Savage Oct. 14, 2004 

Headquarters, Washington

(Phone: 202/358-1727) 

RELEASE: 04-345 

NASA’s Genesis Mishap Board & Researchers Both Report Progress

As scientists begin to unpack more than 3,000 containers of samples of the 

sun brought to Earth by NASA’s Genesis mission, the Mishap Investigation 

Board (MIB) has identified a likely direct cause of the failure of Genesis’ 

parachute system to open. 

The parachute system failed to deploy when Genesis returned to Earth September 8, 2004. The MIB, analyzing the Genesis capsule at a facility near Denver, said the likely cause was a design error that involves the orientation of 

gravity-switch devices. The switches sense the braking caused by the highspeed entry into the atmosphere, and then initiate the timing sequence leading to deployment of the craft’s drogue parachute and parafoil. 

“This single cause has not yet been fully confirmed, nor has it been determined whether it is the only problem within the Genesis system,” said Dr. 

Michael G. Ryschkewitsch, the MIB chair. “The Board is working to confirm 

this proximate cause, to determine why this error happened, why it was not 

caught by the test program and an extensive set of in-process and after-thefact reviews of the Genesis system.” 

Meanwhile, scientists unpacking samples at NASA’s Johnson Space Center 

(JSC), Houston, curation facility remain upbeat in their assessment of the 

prospects for obtaining useful science from the recovered samples. 

The facility counted more than 3,000 tracking numbers for the containers 

that hold pieces of wafers from the five collector panels. The panels secured 

samples of atoms and ions from the solar wind that were collected during 

Genesis’ nearly three-year mission in deep space. Some of the containers 

hold as many as 96 pieces of the wafers. The team has been preparing the 

samples for study since the science payload and recovered samples arrived 

at JSC October 4. 

Planning is under way for preliminary examination of the samples to prepare for allocation to the science community. The samples eventually will be 

moved to the JSC Genesis clean room where they will be cleaned, examined 
Ge n e s i s Mi s h ap Re por t Pa g e I

and then distributed to scientists, promising researchers years of study into 

the origins and evolution of the solar system. 

“We cheered the news from the science team about the recovery of a significant amount of the precious 

samples of the sun,” said Dr. Ghassem Asrar, deputy associate administrator for the Science Mission Directorate at NASA Headquarters, Washington. 

“Despite the hard landing, Genesis was able to deliver. However, we await 

the final report of the Mishap Board to understand what caused the malfunction, and to hear the Board’s recommendations for how we can avoid 

such a problem in the future,” he added. 

The recovered remains of the Sample Return Capsule (SRC) are undergoing engineering inspections and tests at the Waterton, Colo., facility of Lockheed Martin Astronautics (LMA). The Genesis spacecraft and SRC were built 

at Waterton. Lockheed Martin is supporting the MIB both to examine the 

recovered hardware and in assembling documentation relevant to the development of the space system. 

“Both Lockheed Martin and JPL have been providing every possible support 

to our investigation. All of the people from both organizations who were 

involved in the Genesis project have been extremely professional and cooperative in helping the Board do its work,” said Dr. Ryschkewitsch. 

The safety critical pyrotechnic devices and the damaged lithium sulfur dioxide battery have been secured to allow safe operations. The battery has been 

transported to the Jet Propulsion Laboratory in Pasadena (JPL), Calif., to 

begin detailed evaluation. 

The MIB is evaluating the recovered hardware, pertinent documentation, 

impact site recovery activities and interviewing people from development 

teams. The MIB is using a fault tree as its guide. A fault tree is a formal 

method for determining, organizing and evaluating possible direct causes 

for a mishap and to trace them to root causes. 

The Board’s charter is to examine every possible cause and to determine 

whether it was related to the mishap. The Board expects to complete its work 

by late November. 

For information about NASA and agency programs on the Web, visit: 

http://www.nasa.gov 

- end 
Pa g e J-127 Ge n e s i s Mi s h ap Re 

Document # Title/Description Author Issue Date DS 

page #

ABL0001 Packing Slip for PO 245594C; to Hi-Shear Technology Corp. Ablestik Laboratories 4/4/96 45

ABL0002 Packing List; for PO 245594C; to Hi-Shear Technology Corp. Ablestik Laboratories 2/29/96 47

ABL0003 Certificate of Conformance for PO 245594C; to Hi-Shear 

Technology Corp. 

Ablestik Laboratories 2/29/96 48-49

AST0001 Packing Slip for PO 244942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/18/96 78

AST0002 Packing Slip for PO 244942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/18/96 85

AST0003 Certificate of Conformance for PO 244942C “Astro Seal, Inc.” 3/18/96 86

AST0004 Packing Slip for PO 244942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/12/96 100-101

AST0005 Packing Slip for PO 24942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/13/96 104

AST0006 Packing Slip for PO 244942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/12/96 105

AST0007 Packing Slip for PO 245594C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/4/96 106-107

AST0008 Packing Slip for PO 244942C; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 2/29/96 117-118

AST0009 Certificate of Conformance for PO 244942C “Astro Seal, Inc.” 3/5/96 119

AST0010 Packing Slip for 244948P1; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 3/4/96 136

AST0011 Packing Slip for 244948P1; to Hi-Shear Technology Corp. “Astro Seal, Inc.” 2/29/04 142

AST0012 Certificate of Conformance for PO 244948P “Astro Seal, Inc.” 2/29/96 143

AST0013 Certificate of Conformance (#11134); for glass or ceramic 

insulators

“Astro Seal, Inc.” 10/30/95 149

BMC0001 Certificate of Test Brown Metals Company 5/16/94 26

BMC0002 Certificate of Test; PO 235970 (WO 93352) Brown Metals Company 7/17/91 163

CAR0001 Certificate of Tests (No. 19816); for Fry Steel Company Carpenter Technology 

Corporation

3/8/95 87-90

CAR0002 Certificate of Tests (No. 19816); for Fry Steel Company Carpenter Technology 

Corporation

3/8/95 120-123

CAR0003 Certificate of Tests (No. 19855); for Fry Steel Company Carpenter Technology 

Corporation

9/22/95 145-147

CON0001 “Certification (No. 0211420) for PO 11030; Astro Seal, Inc.” “Continental Heat 

Treating, Inc.”

3/1/95 91

CON0002 “Certification (No. 0210880) for PO 11030; Astro Seal, Inc.” “Continental Heat 

Treating, Inc.”

2/23/96 124

COO0001 Manufacturing Order - Ordnance Group Coors Ceramics 3/14/96 56

COO0002 Packing Slip; PO 244818C; to Hi-Shear Technology Corp. Coors Ceramics 12/19/95 59

COO0003 Packing List; PO244818C; to Hi-Shear Technology Corp. Coors Ceramics 12/14/95 62

COO0004 Certificate of Compliance for PO 244818C Coors Ceramics 12/13/95 63

COO0005 Customer Deviation Request for PO 244818C Coors Ceramics 12/1/95 64-65

COO0006 Manufacturing Order - Ordnance Group Coors Ceramics 3//18/96 684

DUR0001 “Mechanical Properties Report for PO 11658; Astro Seal, Inc.” “Durkee Testing 

Laboratories, Inc.”

3/21/96 92-99

Append

 Bibliog
Ge n e s i s Mi s h ap Re por t Pa g e J

Document # Title/Description Author Issue Date DS 

page#

DUR0002 “Mechanical Properties Report for PO 11474; Astro Seal, Inc.” “Durkee Testing 

Laboratories, Inc.”

2/29/96 125-132

EBW0001 Packing Slip; PO 245132; Hi-Shear Technology Corp. E.B. Welding 4/23/96 178

EBW0002 “Invoice, PO 245132; to Hi-Shear Technology Corp.” E.B. Welding 4/18/96 179

EBW0003 Certificate of Conformance; PO 245132 E.B. Welding 4/18/96 180

EBW0004 Packing Slip; PO 245132; Hi-Shear Technology Corp. E.B. Welding 5/9/96 181

EBW0005 Memo Shipper for PO 245132; Hi-Shear Technology Corp. E.B. Welding 4/17/96 182

EBW0006 Certificate of Conformance (#700865) for PO 245132; HiShear Technology Corp.E.B. Welding 4/18/96 183

EBW0007 Packing Slip; PO 245132; Hi-Shear Technology Corp. E.B. Welding 5/3/96 184

EBW0008 Certificate of Conformance (#700865) for PO 245132; HiShear Technology Corp.E.B. Welding 4/17/96 185

EBW0009 Packing Slip; PO 245132; Hi-Shear Technology Corp. E.B. Welding 5/3/96 186

EBW0010 “Invoice, PO 245132; to Hi-Shear Technology Corp.” E.B. Welding 4/16/96 187

EBW0011 Certificate of Conformance; PO 2451321; Hi-Shear Tech E.B. Welding 4/19/96 188

EBW0012 Packing Slip; PO 245132; Hi-Shear Technology Corp. E.B. Welding 5/4/95 189

EBW0013 Packing Slip for PO 245132; Hi-Shear Technology Corp. E.B. Welding 5/3/96 190

EBW0014 “Invoice, PO 245132; to Hi-Shear Technology Corp.” E.B. Welding 4/16/96 191

EBW0015 Certificate of Conformance (#700865) for PO 245132; HiShear Technology Corp.E.B. Welding 4/16/96 192-193

E/MC “Invoice, PO 54645; to Western Gasket & Packing” E/M Corporation 2/23/91 164

EVR0001 Packing Slip; PO 2457270; Hi-Shear Technology Corp. EV Roberts & Associates 4/15/96 198

EVR0002 Packing Slip; PO 244138C; Hi-Shear Technology Corp. EV Roberts & Associates 5/26/95 203

EVR0003 “Invoice, PO 244138C; Hi-Shear Technology Corp.” EV Roberts & Associates 5/24/95 205-206

EVR0004 Packing Slip; PO 244138C; Hi-Shear Technology Corp. EV Roberts & Associates 6/2/95 207

EVR0005 “Invoice, PO 244138C; Hi-Shear Technology Corp.” EV Roberts & Associates 5/30/95 210-211

EVR0006 Packing Slip; PO 243951C; Hi-Shear Technology Corp. EV Roberts & Associates 8/29/95 214

EVR0007 Invoice; PO 243951C; Hi-Shear Technology Corp. EV Roberts & Associates 8/28/95 215-216

EVR0008 Packing Slip; PO 245727C; Hi-Shear Technology Corp. EV Roberts & Associates 4/15/96 219-220

GEN0001 Neutrography Service Certification; PO 245130; Hi-Shear 

Tech

General Electric Nuclear 

Energy

4/23/96 513-514

HTC0001 “Report, 13-40738 Table of Contents; Section 1” Hi-Shear Technology 

Corp.

5/10/96 15-19

HTC0002 Purchase Order 244597C Hi-Shear Technology 

Corp.

8/16/95 20-21

HTC0003 “Inspection Check Sheet; Cup, end closure (PO 244597C)” Hi-Shear Technology 

Corp.

12/21/93 23

HTC0004 “PO244706C, to M&C Remco Tape Products” Hi-Shear Technology 

Corp.

8/24/95 30-31

HTC0005 “Inspection Check Sheet; Disk, insulating (PO 244706C)” Hi-Shear Technology 

Corp.

2/24/92 33

HTC0006 “Material Review Report, PO 244706C” Hi-Shear Technology 

Corp.

8/30/95 35-36

HTC0007 Purchase Order 244706C; to M & C Remco Tape Products Hi-Shear Technology 

Corp.

8/24/95 37-38

HTC0008 “Inspection Check Sheet; Disk, insulating (PO 244706C)” Hi-Shear Technology 

Corp.

2/24/92 40
Pa g e J-129 Ge n e s i s Mi s h ap Re 

Document # Title/Description Author Issue Date DS 

page#

HTC0009 “Material Review Report, Disk, insulating (PO 244706C)” Hi-Shear Technology 

Corp.

8/30/95 42-43

HTC0010 “Purchase Order 245594C, to Ablestik Laboratories” Hi-Shear Technology 

Corp.

2/29/96 44

HTC0011 “Inspection Check Sheet, Washer, Charge cup, insulating 

(PO245594C)”

Hi-Shear Technology 

Corp.

1/7/91 46

HTC0012 Purchase Order 244818C; to Coors Ceramics Hi-Shear Technology 

Corp.

10/6/95 55

HTC0013 “Inspection Check Sheet, Charge cup (PO 244818C)” Hi-Shear Technology 

Corp.

3/14/96 57-58

HTC0014 “Inspection Check Sheet, Charge cup (PO 244818C)” Hi-Shear Technology 

Corp.

1/3/96 60-61

HTC0015 Purchase Order 245387C; to M & C Remco Tape Products Hi-Shear Technology 

Corp.

1/18/96 66-67

HTC0016 “Inspection Check Sheet, Disk, Sealing, Tape (PO 245387C)” Hi-Shear Technology 

Corp.

2/21/96 69

HTC0017 Purchase Order 244942C reprint; to Astro Seal Inc. Hi-Shear Technology 

Corp.

10/31/95 73-77

HTC0018 “Inspection Check Sheet, Initiator body, single piece (PO 

244942C)”

Hi-Shear Technology 

Corp.

3/19/96 79-84

HTC0019 “Material Review Report, initiator body, single piece (PO 

244942C)”

Hi-Shear Technology 

Corp.

3/5/96 103

HTC0020 Source Inspection Report PO 244942C; AstroSeal Hi-Shear Technology 

Corp.

2/23/96 108

HCT0021 “Material Review Report, initiator body, single piece (PO 

244942C)”

Hi-Shear Technology 

Corp.

3/5/96 109

HCT0022 “Inspection Check Sheet, Initiator body, single piece (PO 

244942C)”

Hi-Shear Technology 

Corp.

3/4/96 111-116

HTC0023 “Purchase Order 244948P; to Astro Seal, Inc.” Hi-Shear Technology 

Corp.

11/1/95 133-135

HCT0024 Routing; Work Order #6842-6335B Hi-Shear Technology 

Corp.

4/23/96 137

HCT0025 “Inspection Check Sheet 939635-003W (W/C); Pin header 

assy, glass seal (PO 244948P1)”

Hi-Shear Technology 

Corp.

3/5/96 138-141

HTC0026 Engineering Change Order; Drawing #939654 change 

revision from E to F

Hi-Shear Technology 

Corp.

9/27/91 157

HTC0027 Purchase Order 235990; to Western Gasket & Packing Hi-Shear Technology 

Corp.

6/21/91 158

HTC0028 “Inspection Check Sheet 93954-003; Washer, sealing” Hi-Shear Technology 

Corp.

9/12/91 160

HTC0029 “Rejection Sheet, #29291; washer, flat” Hi-Shear Technology 

Corp.

9/23/91 165-166

HTC0030 Purchase Order 244642C; to McCoy Sales Corp. Hi-Shear Technology 

Corp.

8/17/95 167

HTC0031 Purchase Order 244642C; to McCoy Sales Corp. Hi-Shear Technology 

Corp.

8/17/95 168

HTC0032 Receiving Inspection Record for PO 244642C; McCoy Sales Hi-Shear Technology 

Corp.

10/27/95 170

HTC0033 “Report, 13-40738; Section 2.0 Outside Processing” Hi-Shear Technology 

Corp.

5/10/96 176-177
Ge n e s i s Mi s h ap Re por t Pa g e J

Document # Title/Description Author Issue Date DS 

page#

HTC0034 “Report, 13-40738, Section 3.0 Adehsives and Epoxy” Hi-Shear Technology 

Corp.

5/10/96 194-195

HTC0035 Purchase Order 245727C; EV Roberts & Associates Hi-Shear Technology 

Corp.

3/14/96 196-197

HTC0036 Receiving Inspection Record for PO 245727C; EV Roberts Hi-Shear Technology 

Corp.

4/17/96 199-201

HTC0037 Purchase Order 244138C; EV Roberts & Associates Hi-Shear Technology 

Corp.

5/23/95 202

HTC0038 Receiving Inspection Record for PO 244138C; EV Roberts Hi-Shear Technology 

Corp.

5/31/95 204

HTC0039 Receiving Inspection Record for PO 244138C; EV Roberts Hi-Shear Technology 

Corp.

6/5/95 208-209

HTC0040 Purchase Order 243951C; EV Roberts & Associates Hi-Shear Technology 

Corp.

8/24/95 212-213

HTC0041 Purchase Order 245727C: EV Roberts & Associates Hi-Shear Technology 

Corp.

3/14/96 217-218

HTC0042 Receiving Inspection Record for PO 245727C; EV Roberts Hi-Shear Technology 

Corp.

4/17/96 221-222

HTC0043 “Report, 13-40738, Section 4.0 In-Process Data” Hi-Shear Technology 

Corp.

5/10/96 223

HTC0044 Test Data Sheet; WA #6842-200 Hi-Shear Technology 

Corp.

4/3/96 224-283

HTC0045 Addendum I to Test Data Sheet; WA# 6842-200 Hi-Shear Technology 

Corp.

4/4/96 284-286

HTC0046 In Process; 13-40738 Hi-Shear Technology 

Corp.

5/7/96 287-296

HTC0047 Powder Work Sheet; WA# 6842-200 Hi-Shear Technology 

Corp.

4/4/96 297

HTC0048 Data Sheet 1; Slurry Procedure 7001045; WA# 6842-200 Hi-Shear Technology 

Corp.

4/5/96 298

HTC0049 Slurry Procedure Results; AOS# 9392410-1; WA#6842-200 Hi-Shear Technology 

Corp.

4/12/96 299-328

HTC0050 Test Data Sheet (Rework); AOS#9392410-1; WA#6842-200 Hi-Shear Technology 

Corp.

4/12/96 329-332

HTC0051 Slurry Procedure Results; AOS# 9392410-1; WA#6842-200 Hi-Shear Technology 

Corp.

4/16/96 333-362

HTC0052 Test Data Sheet (Rework); AOS#9392410-1; WA#6842-200 Hi-Shear Technology 

Corp.

4/16/96 363

HTC0053 Test Data Sheet; WA #6842-200 Hi-Shear Technology 

Corp.

4/26/96 364-424

HTC0054 “Report, 13-40738, Section 5.0 Non-Destructive Data” Hi-Shear Technology 

Corp.

5/10/96 425-435

HTC0055 Test Data Sheet; WA #6842-200; Initiator P/N SEB 26100001 Hi-Shear Technology 

Corp.

4/18/96 436-510

HTC0056 Graph; Electrostatic Discharge unknown 511

HTC0057 X-Ray Test Report; to NASA JSC (NAS9-19426) Hi-Shear Technology 

Corp.

5/1/96 512

HTC0058 Test Data Sheet; WA #6842-200; NASA Lot No MSS Hi-Shear Technology 

Corp.

5/9/96 515-532

HTC0059 “Report, 13-40738, Section 6.0 Functional Data “ Hi-Shear Technology 

Corp.

5/10/96 533
Pa g e J-131 Ge n e s i s Mi s h ap Re 

Document # Title/Description Author Issue Date DS 

page#

HTC0060 DLAT Test; NSI Lot MSS Hi-Shear Technology 

Corp.

5/7/96 535-536

HTC0061 Results; Lot MSS DLATS Hi-Shear Technology 

Corp.

4/26/96 538-539

HTC0062 Test Data Sheet; Figure 9B; WA# 6842-200; Initiator P/N SEB 

26100001; Lot Sample Test- Destructive Tests

Hi-Shear Technology 

Corp.

4/26/96 551-564

HTC0063 Test Data Sheet; Figure 13; WA#6842-200; Initiator P/N 

26100001; Acceptance Range for 3.5 Amp Firing Test

Hi-Shear Technology 

Corp.

5/3/96 565

HTC0064 Test Data Sheet; Figure 11; WA#6842-200; Initiator P/N 

26100001; Firing Test

Hi-Shear Technology 

Corp.

5/3/96 566-568

HTC0065 Graphs; WA#6842-200; Temperature Tests Hi-Shear Technology 

Corp.

5/3/96 569-593

HTC0066 “Test Data Sheet, Figure 15B; WA#6842-200; Initiator P/

N SEB 26100001; Acceptance Criteria for 40V Capacitor 

Discharge”

Hi-Shear Technology 

Corp.

5/6/96 594

HTC0067 “Test Data Sheet, Figure 15A; WA#6842-200; Initiator P/N 

SEB 26100001; PIC Capacitor Discharge Firing Test”

Hi-Shear Technology 

Corp.

5/6/96 595-596

HTC0068 Graphs; WA#6842-200; Temperature Tests Hi-Shear Technology 

Corp.

5/6/96 597-616

HTC0069 “Test Data Sheet, Figure 14C; WA#6842-200; Initiator 

P/N SEB 26100001; Acceptance Range for 40V Capacitor 

Discharge”

Hi-Shear Technology 

Corp.

5/3/96 617

HTC0070 “Test Data Sheet, Figure 14A; WA#6842-200; Initiator P/N 

SEB 26100001; Capacitor Discharge Firing Test”

Hi-Shear Technology 

Corp.

5/3/96 618

HTC0071 Graphs; WA#6842-200; Temperature Tests Hi-Shear Technology 

Corp.

5/3/96 619-620

HTC0072 “Test Data Sheet, Figure 14B; WA#6842-200; Initiator 

P/N SEB 26100001; Acceptance Range for 20V Capacitor 

Discharge Firing Test”

Hi-Shear Technology 

Corp.

5/3/96 621

HTC0073 “Test Data Sheet, Figure 14A; WA#6842-200; Initiator P/N 

SEB 26100001; Capacitor Discharge Firing Test”

Hi-Shear Technology 

Corp.

5/3/96 622-624

HTC0074 Graphs; WA#6842-200; Temperature Tests Hi-Shear Technology 

Corp.

5/6/96 625-649

HTC0075 “Test Data Sheet, Figure 12; WA#6842-200; Initiator P/N SEB 

26100001; Acceptance Range for 22 amps”

Hi-Shear Technology 

Corp.

5/3/96 650

HTC0076 Test Data Sheet; Figure 10; WA#6842-200; Initiator P/N 

26100001; Firing Test

Hi-Shear Technology 

Corp.

5/6/96 651

HTC0077 Graphs; WA#6842-200; Temperature Tests Hi-Shear Technology 

Corp.

5/3/96 652-654

HTC0078 “Report, 13-40738; Section 7.0 AOS, Cure Logs, Rework 

Sheets”

Hi-Shear Technology 

Corp.

5/10/96 655

HTC0079 AOS Summary Sheet for WA#68420200 Hi-Shear Technology 

Corp.

unknown 656

HTC0080 Assembly Operation Sheets; Revision A; AOS# 9392410-1 Hi-Shear Technology 

Corp.

3/18/96 657

HTC0081 Engineering Design Release #9392410-1 Hi-Shear Technology 

Corp.

3/15/96 658-660

HTC0082 AOS Change Log; 9392410-1 Hi-Shear Technology 

Corp.

11/15/95 661-673

HTC0083 Test Data Sheet; AOS#9392410-1; Hi-Shear Technology 

Corp.

unknown 674-677
Ge n e s i s Mi s h ap Re por t Pa g e J

Document # Title/Description Author Issue Date DS 

page#

HTC0084 Cure/Dry Log Sheet; Template Hi-Shear Technology 

Corp.

N/A 678

HTC0085 In-Process Rework Log; Template Hi-Shear Technology 

Corp.

N/A 679

HTC0086 AOS Summary Sheet; AOS 9392410-1 Hi-Shear Technology 

Corp.

unknown 680

HTC0087 Addendum to AOS 93922410-1; Explosive Weights Hi-Shear Technology 

Corp.

unknown 681

HTC0088 Graphic; Figure A: Charge Cup Grinding Hi-Shear Technology 

Corp.

4//18/95 682

HTC0089 Cure/Dry Log Sheet; 13-40738; WA#6842-200; Trays 1-15 Hi-Shear Technology 

Corp.

3/30/96 684-713

HTC0090 In-Process Rework Log; Discrepancies per Tray Hi-Shear Technology 

Corp.

4/4/96 714-739

HTC0091 “Report, 13-40738, Section 8.0 Rejection Reports” Hi-Shear Technology 

Corp.

5/10/96 740

HTC0092 “Material Review Report, P/N 9392410-1” Hi-Shear Technology 

Corp.

4/3/96 741-745

LMC0001 Genesis Recovery Phase Risk Review EDL Lockheed Martin; B. 

Willcockson

7/10/04

LMC0002 Genesis Spacecraft System Description Lockheed Martin Space 

Systems; N. Smith

9/22/04

LMC0003 Genesis SRC System Description Lockheed Martin Space 

Systems; N. Smith

9/22/04

LMC0004 Genesis SRC Anomalies Lockheed Martin Space 

Systems; K. Starnes

9/22/04

LMC0005 Genesis SRC Entry Lockheed Martin; B. 

Willcockson

9/22/04

LMC0006 Deployment Timelines Lockheed Martin Space 

Systems; D. Perkins

9/22/04

LMC0007 “Lockheed Martin Space Systems Team Roster, Phase CD” Lockheed Martin Space 

Systems; D. Perkins

9/27/04

LMC0008 “JPL Genesis Team Roster, Phase CD” Lockheed Martin Space 

Systems; D. Perkins

9/27/04

LMC0009 1997-2001 Lockheed Martin Organization Lockheed Martin Space 

Systems; J. Vellinga

10/7/04

LMC0010 LMSS Manpower by WBS Lockheed Martin Space 

Systems; D. Perkins

9/30/04

MCC0001 Packing Slip for PO 244642C; to Hi-Shear Technology Corp. McCoy Sales Corp. 10/25/95 169

MCC0002 Packing List for PO 244642C; to Hi-Shear Technology Corp. McCoy Sales Corp. 10/23/95 171

MCR0001 Packing Slip for PO 244706C; to Hi-Shear Technology Corp. M & C Remco Tape 

Products

8/30/95 32

MCR0002 “Certificate of Specifications, PO 244706C” M & C Remco Tape 

Products

8/30/95 34

MCR0003 Packing Slip for PO 244706C; to Hi-Shear Technology Corp. M & C Remco Tape 

Products

8/29/95 39

MCR0004 “Certificate of Specifications, PO 244706C” M & C Remco Tape 

Products

8/30/95 41

MCR0005 Packing Slip for PO 245387C; to Hi-Shear Technology Corp. M & C Remco Tape 

Products

2/20/96 68
Pa g e J-133 Ge n e s i s Mi s h ap Re 

Document # Title/Description Author Issue Date DS 

page#

MCR0006 Certificate of Specifications; PO 245387C M & C Remco Tape 

Products

2/21/96 70

MCR0007 Packing List for PO 245387C; to Hi-Shear Technology Corp M & C Remco Tape 

Products

1/24/96 71-72

MSC0001 “Packing List for PO 244948P1; to Astro Seal, Inc.” MS Certified Metals 

Supply

2/2/95 148

NAS0001 Material Inspection and Receiving Report NASA JSC 5/20/96 1

NAS0002 NASA Standard Initiator Flight Certification Record NASA JSC 5/15/96 2-14

NAS0003 Hi Shear Propellant Blend Acceptance Test NASA JSC 8/16/95 50-52

NAS0004 Concurrence on Rejection reports #2485 and 2494 NASA JSC 3/22/96 102

NAS0005 Concurrence on Rejection reports #2485 and 2494 NASA JSC 3/22/96 110

NAS0006 Facsimile; Firing Data for NSI Lot MSS; NAS9-19426 NASA JSC 5/12/96 534

NAS0007 Facsimile; NAS9-19426; Lot MSS DLATS NASA JSC 4/26/96 537

NAS0008 Genesis Frequently Asked Questions NASA JPL; Whalen 9/2/04

NAS0009 Genesis Mission Description NASA JPL; Hirst 9/22/04

NAS0010 Recovery Personnel at UTTR NASA JPL; Hirst 9/28/04 N/A

NAS0011 1997-09-15 Proposal Orals version 1 NASA JPL; Hirst 10/12/04

NAS0012 1997-09-15 Proposal Orals version 2 NASA JPL; Hirst 10/12/04

NAS0013 1998-08-12 Post Preliminary Design Review NASA JPL; Hirst 10/12/04

NAS0014 1998-11 JPL Payload Organization NASA JPL; Wahl 10/4/04

NAS0015 1999-03-13 Science Team Meeting NASA JPL; Hirst 10/12/04

NAS0016 1999-04-09 Gns within JPL Organization NASA JPL; Hirst 10/12/04

NAS0017 1999-08-31 Post Critical Design Review NASA JPL; Hirst 10/12/04

NAS0018 2001-09-25 Post Launch Assessment Review NASA JPL; Hirst 10/12/04

NAS0019 2002-10-30 Don Sweetnam to Project Manager NASA JPL; Hirst 10/12/04

NAS0020 2003-03-14 Aimee Whalen to Education Public Outreach Lead NASA JPL; Hirst 10/12/04

NAS0021 2003-06-02 Nora Mainland to Mission Operations Team Lead NASA JPL; Hirst 10/12/04

NAS0022 2003-10-03 Don Sevilla to Payload Recovery Lead NASA JPL; Hirst 10/12/04

NAS0023 2003-12-12 Sharon Kyle to Project Resource Administrator NASA JPL; Hirst 10/12/04

NAS0024 2004-06-25 Tom Wahl to Project System Engineer NASA JPL; Hirst 10/12/04

NAS0025 2004-07-16 Ed Miranda to Project Scheduling NASA JPL; Hirst 10/12/04

NAS0026 2004-08-26 Curt Henry to System Engineering NASA JPL; Hirst 10/12/04

NAS0027 JPL Workforce Charts NASA JPL; Sweetnam 10/28/04

NAS0028

NTS0001 Test Report No. 673-2069; Thermal Cycling and Random 

Vibration

National Technical 

Systems

5/10/96 540-550

PHC0001 Packing List & Certification of Conformance; PO 840378 Parker Hannifin 

Corporation

9/15/95 172-175

RMF0001 “Invoice, PO 244597C” Reid Metal Finishing 6/22/94 24

SPI0001 Packing Slip for PO 244597C; to Hi-Shear Technology Corp. “Spiveco, Inc.” 8/26/95 22

SPI0002 Packing Slip for PO 244597C; to Hi-Shear Technology Corp. “Spiveco, Inc.” 8/21/95 27

SPI0003 Certificate of Compliance for PO 244597C “Spiveco, Inc.” 8/22/95 28-29

STS0001 “Certificate of Specification, Embrittlement Test” Somers Thin Strrip 10/10/88 25

TRI0001 “Certification of Process (PO 244948PY); for Astro Seal, Inc.” “Trident Plating, Inc.” 1/31/96 150

TRI0002 “Certification of Process (PO 244948P1); for Astro Seal, Inc.” “Trident Plating, Inc.” 1/25/96 151

TRI0003 “Certification of Process (PO 244948P1); for Astro Seal, Inc.” “Trident Plating, Inc.” 2/20/96 152
Ge n e s i s Mi s h ap Re por t Pa g e J

Document # Title/Description Author Issue Date DS 

page#

TRI0004 “Certification of Process (PO 244948P1); for Astro Seal, Inc.” “Trident Plating, Inc.” 2/6/96 153

TRI0005 “Certification of Process (PO 244948P1); for Astro Seal, Inc.” “Trident Plating, Inc.” 2/20/96 154

TRI0006 “Certification of Process (PO 244948P1); for Astro Seal, Inc.” “Trident Plating, Inc.” 1/12/96 155-156

WES0001 Packing Slip for PO 244990; to Hi-Shear Technology Corp. Western Gasket & 

Packing

9/3/91 159

WES0002 “Invoice, PO 235990; to Hi-Shear Technology Corp.” Western Gasket & 

Packing

6/21/91 161

WES0003 Certificate of Conformance for PO 235990; Hi-Shear Tech. Western Gasket & 

Packing

8/30/91 162

WIL0001 Certificate of Conformance; Chemical analysis Wilbur B. Driver 

Company

10/3/67 53-54