GSFC ELV Safety Challenges - NASA

G O D D A R D S P A C E F L I G H T C E N T E R

GSFC ELV Safety Challenges

ELV Safety Workshop 2014

Name: Bo Lewis

Title: Branch Head

Office: Systems Safety Branch

Tel: 301-286-7123

Email: [email protected]

mailto:[email protected]

G O D D A R D S P A C E F L I G H T C E N T E R 2

A Diverse Portfolio


GSFC Center Org Chart


Judith Bruner(Director)

Richard Barney(Deputy Director)

Eric Isaac(Associate Director)

Jesse Leitner(SMA Chief Engineer)

Joe Wonsever(Chief Technical Assessments Engineer)

Robert Savage(Assistant Director for SMA @ Wallops)

Rob Sticka(Assistant to the Director)

Jeanine Doherty(Program Analyst)

EEE Parts/Workmanship GroupMichael Sampson

(NASA EEE Parts Assurance Group Program Manager)Jeannette Plante

(Workmanship Program Manager)

Information and Assurance Technology Services Sanjeev Sharma

(IT Manager)

Directorate Resources Management Office

(300.1)Curtis Johnson

(Directorate Resources Manager)

Mission Support Division (320)

Mike Kelly(Chief)

VACANT(Deputy Chief)

System ReviewOffice (301)

Carolyn Dent(Chief)

Neil Martin(Deputy Chief - Detail)

Institutional SupportOffice (302)Cindy Mead

(Chief)Dave Campbell (Deputy Chief)

Occupational Safety & Health Division (350)

Patrick Hancock(Chief)

Daniel Simpson(Deputy Chief)

Systems Safety Branch (321)

Bo Lewis(Branch Chief)

Reliability & Risk Analysis Branch

(322)

Anthony Diventi(Branch Chief)

Mission Assurance Branch (323)

Gaspare Maggio(Branch Chief) Roman Kilgore

(Associate Branch Chief)

Software Assurance Office

(320.1)Sue Sekira

(Office Chief)

CURRENT GSFC S&MA ORGANIZATION


GSFC SAFETY ORGANIZATIONS

Lift Devices &Pressure VesselsRecertification

(Code 540)

System Safety & Occ Safety & Health

(Wallops)(Code 803)

Greenbelt I&T Facility Safety

Lab Safety(Code 500)

DirectorSafety & Mission

Assurance(Code 300)

Greenbelt Flight Systems

Safety(Code 321)

Institutional Safety(Code 350)


Safety & Mission Assurance Directorate

Occupational Safety and

Health Group

Systems Safety Group

Quality and Reliability Division

Reliability & Risk Assessment

Branch

371

Mission Software & Ground Systems Assurance Branch

372

Systems Review Branch

381

Management Systems Branch

382

Assurance SystemsDivision

Safety Division

Quality Engineering

Branch373

Mission Assurance

Branch383

Proposed Safety & Mission Assurance Directorate Code 300 Organization

300

360 380370

Directorate Resources Management Office

300.1


Goddard Safety and

Mission Assurance

Quality &

Reliability

Chief Safety and Mission

Assurance Management

Mission Ops Assurance

Management Systems

Systems

Assurance

Reliability and Maintainability

Software Assurance

Workmanship Standards and Processes

Materials and Processes Assurance

EEE Parts and Radiation Assurance

Mission Ground Systems

Commodity Risk Assessment

Quality Engineering

Ground Support Equipment

Safety

Systems Safety

Occupational Safety and Health

Lifting Devices and Equipment

Pressure Vessels/Systems

GSE SafetySupply Chain Program

SMA Functional Alignment

Red Text=New Code 300 Functions

Metrology and Calibration

Systems Reviews

Directives Management

7


Safety Data Packages Due (MSPSPs)

Project Safety Activities

-Proposal Support-MAR inputs

-Reqts Definition-Finalize MAR inputs-Safety Plan-Negotiate funding

- Design Assessment- Hazard Identification- Recommend Hazard Controls-Initial Risk Assessment-Range Safety reqts tailoring

- Verification of Hazard Controls- Updated Risk Assessment- PSWG meeting support

- I&T Safety Support -Track Closure of Verification Items-Final Risk Assessment-- Safety Certification- Prelaunch Safety Support


PI (Principle Investigator) Mode Missions

• PI Mode was instituted at the behest of the science community as part of the ‘FASTER!-BETTER!-CHEAPER! experiment.

• The mission PI is funded by HQ and is ‘responsible’ for meeting mission requirements.– The PI may contract with other organizations to perform project

management, provide a spacecraft bus, perform I&T functions and provide SMA and support functions.

• Although the PI is spending NASA funds, these contracts are not directly with NASA.

• In PI mode, GSFC is tasked by HQ to provide the PI organization with advice, and to facilitate their efforts in delivering verified flight hardware on time. – GSFC is also tasked to periodically report to HQ on the PI’s progress.

• PI’s often see little need for assistance from GSFC, other than acting as a conduit for funds.


PI Mode

• GSFC is responsible for certifying to HQ that the project and flight hardware

– Is on schedule

– Is on budget

– Will meet performance requirements

– Is safe

• PI’s often see SMA as unnecessary expense, and view safety as a program consideration that is outside of their responsibility.


“Heritage”

• Some project managers (& others) may view spacecraft bus designs and/or subsystems that have launched from somewhere and/or been accepted by some range safety organization in the past, as ‘heritage’ designs.

– Sometimes heritage claims are based on designs that haven’t even flown before but may be ahead in the development lifecycle

• As heritage designs, they are assumed to be ‘grandfathered’, i.e. requiring no further hazard analysis or review by the PSWG.

• GSFC views heritage hardware differently, as documented in GSFC-STD-1000, GSFC “Gold Rules”, Rule 1.11:

“All heritage flight hardware shall be fully qualified and verified for use in its new application. This qualification shall take into consideration necessary design modifications, changes to expected environments, and differences in operational use.”

• This issue often creates problems, especially with PI mode missions or other missions with HQ mandated compressed schedules.


Non-LSP Launches

• GSFC flight projects are sometimes directed by HQ to use non-LSP provided launch vehicles and/or non-US launch sites.

• Naturally, this can result in a different safety review process and perhaps, additional safety requirements.

• Examples:– JWST- Ariane 5 launch vehicle launched from French Guiana– GPM- JAXA HII-A launch vehicle launched from Japan– DSCOVR- Space-X Falcon 9 launch vehicle launched from Cape

Canaveral

• Standard GSFC practice is to negotiate with the responsible range safety organization as early as possible in order to gain agreement to use NASA Std8719.24 requirements and NPR 8715.7 deliverables and submittal template.

• Challenges include– Identifying Safety POC early to define safety expectations & requirements– Convincing project to allow us to talk directly with Foreign Safety POC


S/C Designs with Inadequate Fault Tolerance (From Launch Thru Separation From LV)

• NASA requires 2-fault tolerance for catastrophic hazards up to payload separation from the launch vehicle.

– NASA-STD-8719.24, Vol. 3 Para. 3.2.1. “ If a system failure may lead to a catastrophic hazard, the system shall have no less than three inhibits.”

• catastrophic hazard - a hazard, condition or event that could result in a mishap causing fatal injury to personnel and/or loss of spacecraft, launch vehicle or ground facility.

– NPR 8715.7, P1 Note:: “this program provides payload safety requirements related to payload design, production, processing and testing, vehicle integration, launch through payload separation from the launch vehicle …”

• Typical catastrophic hazards include inadvertent thruster firing, RF radiation and Solar Array deployment.

– Any of these events are normally assumed to result in loss of payload mission due to subsequent payload damage, and possible propagation to the launch vehicle or its FTS.

• Some payloads rely on “bounce analysis” performed by LV to avoid fault tolerance requirements on inadvertent RF radiation in the fairing

– However, LV is looking at impacts to their LV– Payload Developer needs to look at potential impact to their payload as well

• Some spacecraft bus vendors do not recognize damage to flight hardware as a catastrophic event, and dispute the need for more than two (2) independent inhibits.

• Some Systems Engineering organizations feel that design inhibits intended to prevent loss of mission events during launch constitute unacceptable risk to mission success.

– This is seldom if ever quantified


Lithium-Ion Batteries

• Some spacecraft bus design teams assume that NASA-STD 8719.24 requirements for design and verification of li-ion cells, batteries and battery containers are beyond their responsibility and instead the responsibility of their cell/battery vendor.– Spacecraft bus developer needs to flow down safety requirements to

battery vendor

• Some design teams assume that if a particular vendor’s cell/battery design was used by an earlier mission, the hardware is ‘grandfathered’ and does not need safety related analysis or testing.

• Quite often these same design teams do not recognize Li-ion cells as a fire hazard.

• Typical battery issues have been

• Propagation of 1 cell failure to other cells

• Ability of battery box to vent ( how many cells venting simultaneously is credible?)

• Battery Charging is hazardous procedure


SW Safety vs H/W Inhibits

• When confronted with insufficient inhibits to meet safety fault tolerance requirements, Projects are often faced with trade study of adding additional hardware inhibit, or use software controls to “meet intent” leading to safety critical software

• Their thought process usually follows this logic:

– Hardware inhibits are costly and decrease mission reliability (never quantified)

– SW controls are easy and inexpensive

• However, cost to fully meet safety critical SW requirements to convince safety engineers that risk is acceptable is hard to quantify and certainly not easy or inexpensive.

GSFC ELV Safety Challenges - NASA

Documents

Transcript of GSFC ELV Safety Challenges - NASA