1. National Aeronautics and Space Administration www.nasa.gov/sls Space Launch System Phase I Safety Review Preparation for GT #2 Topic: Phase I Safety Review Preparation for GT #2 Date: 10/21/2015 Org: Scott Spearing / FP30 Cube Quest Town Hall Meeting #2

2. Agenda Safety Ground Rules Safety Review Process Overview Safety Data Package Development Safety Presentation Questions? 2

3. Safety Ground Rules 3 Definition for a Hazard: Any affect by or from the secondary payload which could cause harm or risk the successful operation or mission of the Space Launch System (SLS) vehicle, primary payload (Orion), or the ground crew. The Secondary Payload Deployment System’s prime directives (in order of importance): 1)Do no harm to the vehicle 2)Do not affect the process/schedule of the vehicle 3)Deploy payloads at the end of SLS operations 4)Aid in the success of the secondary payload missions We are guests on the initial flight of a new vehicle, which has the ability to leave LEO.

4. Safety Status/Process 4 Phase 0 - Introduce payload concepts to the PSRP - Preliminary identification of possible hazards - Gain insight from PSRP as to payload concept & hazards Process flow is from SLSP EM-1 Secondary Payload Safety Review Process (SLS-PLAN-217) Phase I - Present preliminary payload design to PSRP - Identify possible system design hazards & potential hazard mitigations - Receive PSRP comments/suggestions & direction to advance to Phase II Phase II - Present mature payload design to PSRP - Identify methods of verification to assure hazard is eliminated or controlled - Identify any modifications/alterations to previous design or Phase I agreement - Receive PSRP comments/suggestions & direction to advance to Phase III Phase III - Present verification results (i.e. analysis, test reports, inspections, etc.) to PSRP - Identify any modifications/alterations to previous design or Phase II agreement - Receive PSRP comments & recommendation for flight to SLS Presentation RequiredSafety Data Package w/Hazard Report Required

5. Safety Data Package 5 Safety Data Package is composed of: 1)Basic Introduction Fill in blue highlighted wording w/payload specific information 2)Mission Overview Fill in blue highlighted wording w/payload specific information Brief paragraph of mission details only 3)SLS Payload Accommodations Fill in blue highlighted wording w/payload specific information 4)Payload Hardware Overview This section w/#7 (see below) that the payload developer needs to put as much detailed information, concerning their hardware, into the document. Areas with in a cubesat design that could be a hazard (i.e. batteries, pressure vessels, liquid propellants, energy storage devices, etc.) need to have additional info added. 5)Ground Processing Fill in blue highlighted wording w/payload specific information 6)On-Orbit Operations Fill in blue highlighted wording w/payload specific information 7)Safety Assessment This section needs to be filled out w/any possible hazard you think you have, whether it is identified in the outline or something you may have a concern about. Also need to discuss how that hazard could be eliminated/mitigated/controlled.

6. Hazard Report 6 Current hazard report hazards fall into either a “short form” or a “long form”. Short Forms – Capture the more common type of hazards that most payloads could experience. For Phase I the following blocks need to be filled out: Block A – Leave blank, to be filled in by NASA safety Block B – enter “Phase I” Block C – enter date you plan to submit hazard report Block D – enter your cubesat name Block F – Indicate Mission Phase the hazard could occur Block H – Indicate which hazard control in Block G you plan to employ Block I – is used for Phase II & III to identify how you plan to verify you have the proper hazard control in place (i.e. inspection, analysis, testing, etc.) and where you will list the reports confirming you completed the verification. Any data you wish to add to support your filling out of the hazard report can be added as appendixes (i.e. materials lists, grounding schematic, etc.) For GT#2 the info in Block I is not needed. But if you decide to add info in that block for future use it will not be held against you.

7. Hazard Report cont. 7 Long Form – Capture the unique hazard which your payload might have that was not in the short form (i.e. batteries, liquid propellant, etc.). Header - fill out payload name and mark HR IDENTIFIER as “TBD” Line 1 – briefly describe the hazard & the condition it could occur Line 1a – identify “Phase I” Line 1b – enter date you plan to submit hazard report Line 1c – enter “Payload Name, Cube Quest” Line 1d – list payload safety engineer (person who filled out the form) Line 2 – describe the hazard and its effect to the vehicle or ground crew Line 3 – create a title for the cause and mark the *severity & **likelihood Line 4 – list what, if anything, you are using to control the hazard beyond the confines of your payload (i.e. dispenser for containment, etc.) Line 5 – mark the cause(s) as “new (Phase I)” Line 6 – add any other info for this hazard that you think would aid in clarification of the other lines. *Severity This index quantifies the worst case accident or undesired event resulting from this cause. Severity levels are I (Catastrophic), II (Critical), and III (Marginal). Hazard Reports with Severity Level of III (Marginal) shall not be brought forth to the Safety Review Panel. **Likelihood The likelihood (probability of occurrence) of this hazard cause manifesting itself after controls have been implemented. Likelihood levels are A, B, C (Remote), and D (Improbable), with A being the most probable.

8. Safety Presentation 8 Phase I presentation is a summation of the safety data package and review of the hazard report forms (short & long). Basic info needed is: Payload objectives – 1 page Concept of Operations (w/emphasis on hand over @ KSC thru 15 sec. after deployment) – 1 page Overall cubesat configuration description (i.e. top level description, block diagrams, etc.) – 1 to 3 pages Description of each system (diagrams, components identified, operations, etc.) – 6 to 10 pages Detailed hardware descriptions concerned w/possible hazards – x pages (as needed) Overall payload schedule – 1 page Summary of identified hazards (standard & unique) – 2 to 3 pages Review each hazard report page (short & long) – x pages Back-ups Approach to meet IDRD safety requirements tables – x pages Any additional info you might need to have for your presentation – x pages

9. Project Schedule 9

10. Town Hall - Safety 10 Questions ?

11. Back – Up Charts 11

12. Verification/CoFR Plan 12

13. Short Form Example 13 EXAMPLE

14. Long Form Example 14 UNIQUE HAZARD CONTROL REPORT FORMAT Payload Name SLS EM-1 Secondary Payload HR IDENTIFIER 1. HAZARD TITLE: Enter a brief description of the hazard in terms of hazard initiator, action or consequence. a.Review Level:Phase I, II, or III b.Revision Date:Date c.Scope:Payload, Payload Carrier d.Hazard Report Focal:Name, Phone Number _____________________________________________________________________________________________ 2. HAZARD CONDITION DESCRIPTION: The hazard description should define the risk situation including the unsafe act or conditions and its effect on SLS or personnel. _____________________________________________________________________________________________ 3. CAUSE SUMMARY: CAUSE 1:Cause Title 1 SEVERITY:LIKELIHOOD: CAUSE 2:Cause Title 2 SEVERITY:LIKELIHOOD: _____________________________________________________________________________________________ 4. INTERFACES: What does the Payload interface with? Does it rely on other hardware for controls? _____________________________________________________________________________________________ 5. STATUS OF OPEN WORK: CAUSE 1:Closed or Open (Phase II); Closed or Closed to SVTL (Phase III) CAUSE 2:Closed or Open (Phase II); Closed or Closed to SVTL (Phase III) _____________________________________________________________________________________________ 6. REMARKS: Entries here should include any information relating to the hazard but not fully covered in any other item field. EXAMPLE