GSFC ELV Safety Challenges - NASA
Transcript of 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]
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
G O D D A R D S P A C E F L I G H T C E N T E R 3
GSFC Center Org Chart
G O D D A R D S P A C E F L I G H T C E N T E R 4
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
G O D D A R D S P A C E F L I G H T C E N T E R 5
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)
G O D D A R D S P A C E F L I G H T C E N T E R 6
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
G O D D A R D S P A C E F L I G H T C E N T E R 7
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
G O D D A R D S P A C E F L I G H T C E N T E R 8
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
G O D D A R D S P A C E F L I G H T C E N T E R 9
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.
G O D D A R D S P A C E F L I G H T C E N T E R 10
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.
G O D D A R D S P A C E F L I G H T C E N T E R 11
“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.
G O D D A R D S P A C E F L I G H T C E N T E R 12
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
G O D D A R D S P A C E F L I G H T C E N T E R 13
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
G O D D A R D S P A C E F L I G H T C E N T E R 14
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
G O D D A R D S P A C E F L I G H T C E N T E R 15
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.