CLDP-REQ-3102 searchable.pdf

CLDP-REQ-3102

Basic (June 2024)

Commercial Low-Earth Orbit Development Program (CLDP) Hazard Analysis and Safety Process

Requirements Document

See Directive CLDP-D0028 Approval 10/22/2024

Angela T. Hart Date

Program Manager, Commercial Low-Earth Orbit Development Program

Record of Revision/Changes

Revision Description Date Baseline Initial Release (Reference Directive CLDP-D0028, EFF. 06-11-2024)

Program Release 10-22-2024

SECTION

TABLE OF CONTENTS

1.0 Introduction

1.1 Purpose

1.2 Scope

1.3 Verb Application

1.4 Change Authority/Responsibility

2.0 Documents

2.1 Applicable Documents

2.2 Reference Documents

3.0 Hazard Analysis Overview

3.1 Hazard Analysis Types

3.2 Hazard Severities/Likelihood

3.2.1 Marginal Hazards

3.2.2 Critical Hazards

3.2.3 Catastrophic Hazards

3.2.4 Hazard Control Strategy

3.2.5 Failure Tolerance (FT)

3.2.5.1 FT Foe Critical Hazards

3.2.5.2 FT Foe Catastrophic Haz.acds

3.2.5.3 FT and Emergency Systems

3.2.6 Design For Minimum Risk (DFMR)

3.2.7 Process Controls

3.2.8 Emergency Response

3.2.8.1 Crew Sucvival Methods (CSMs)

3.2.8.2 Destination Sucvival Methods (DSMs)

3.2.9 Computer-Based Control Systems (CBCS)

3.2.9.1 Software Common Cause Failuce

3.3 Hazard Control Order of Precedence

3.3.1 Eliminate the Hazard

3.3.1.1 Reduce Risk 1brough Design Alteration

3.3.1.2 Use of Operational Controls

3.4 Hazardous Effect Mitigation

4.0 Safety Hazard Analysis Development and Phased Safety Review Process

Page 3 of83

4.1 Safety Milestones

4.1.1 Phase 0 - Concept Development

4.1.1.1 Phase I - Preliminary Design

4.1.1.2 Phase II- Final Design

4.1.13 Phase III - Final Acceptance

4.2 Safety Documentation

4.2.1 SDP Requirements

4.2.2 HRs

4.2.3 Flight Safety Certificate

4.2.4 Additional Safety Hazard Analysis

4.2.4.1 Integrated Hazard Assessments

4.2.4.1.1 Roles and Responsibilities

4.2.5 Maintenance Hazard Assessment (MHA)

4.2.6 Verification Closeout

4.2. 7 Safety Verification Tracking Log (SVTL)

4.2.8 Post-Phase III Activities

4.2.8.l Post-Phase III (Prior to Flight) Safety Approval

4.2.8.2 Post-Flight Safety Approval .... ..... ····· ·· ····· ··· ··· ·· ···· ·· ·· ····· •·······•· ··· ········· ·· ••······· ·· ·· ······ ···· ··•········ ···· ···•······•····· ··•······ ·•······ ·•······ ···· ·····••· ····•·········· 35

4.2.83 On-Orbit Reconfiguration

4.2.8.1 fncrem.ent Hazards

4.2.9 Safety Non-ComplianceN ar iance

4.2.9.1 Equivalent Safety (ES) Non-ComplianceNariance

4.2.9 .2 Program Level Non-Compliance/Variance

4.3 Series, Reflown and Modified Hardware

5.0 Joint Safety Review Scope

5.1 Integrated Destination Safety Reviews

5.2 Crew Transportation System Safety Reviews

5.3 Cargo Transportation System Safety Reviews

5.4 Payload and Cargo Safety Reviews

5.5 Joint Safety Review Completion

5.5.1 HR Disposition

6.0 Commercial Provider Accreditation

6.1 Trusted Vendor

6.2 Trusted Vendor Safety Process Requirements

6.3 Commercial Provider Safety Panel Process Requirements

Appendices

A: Acronyms

B: Glossary .................................................................................................................... 4 7

C: Hazard Analysis Types

D: on-ComplianceN ariance

E: Phase Safecy Review Requirements

F: Comments Documentation ..................................................................................... 7 4

TABLE

Table 3.1-1 Hazard Analysis Types (4 Pages) Table 3.2-1 Hazard Likelihood Definitions Table 3.2-3 Hazard Scoring Matrix Table 4.1.1-1 PHL Worksheet Sample Instructions Table 4.1-1 Safety Milestones and Development Schedule Table 4.2.1.1-1 Levels of Maturity Table 4.2.3.1.1-1 Responsibility Matrix Table 5.0-1 Joint Safety Review Summary Level Table C.2.2.1-1 PHL For SRR Table C.2.2.6-1 O&SHA Format and Data Elements (2 Pages) Table H-1 To Be Determined Items Table H-2 To Be Resolved Issues

FIGURE

Figure 5.0-1 Program Responsibilities Schematic Figure F.1.2-1 Phase O Review Provider Plan Figure E 1.3.2-1 Phase I Review Provider Plan Figure G.1.1-1 Examples Of Comment Form Figure G.1.2-1 Comments Example

Page 5 of83 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602428 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602429 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602430 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602431 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602432 https://gbc-word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=en-US&rs=en-US&wopisrc=https%3A%2F%2Fnasa.sharepoint.com%2Fteams%2FCLDP-REQ-3102%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F3b5b9cdeb02b42f881e61935543d22d4&wdenableroaming=1&mscc=1&hid=78FA2FA1-00A7-5000-95B4-82B31BBAD461.0&uih=sharepointcom&wdlcid=en-US&jsapi=1&jsapiver=v2&corrid=071c226e-2c0f-9f5c-da88-ef875b7789fc&usid=071c226e-2c0f-9f5c-da88-ef875b7789fc&newsession=1&sftc=1&uihit=docaspx&muv=1&cac=1&sams=1&mtf=1&sfp=1&sdp=1&hch=1&hwfh=1&dchat=1&sc=%7B%22pmo%22%3A%22https%3A%2F%2Fnasa.sharepoint.com%22%2C%22pmshare%22%3Atrue%7D&ctp=LeastProtected&rct=Normal&wdorigin=ItemsView&wdhostclicktime=1717676192279&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush#_Toc157602433

1.0 Introduction

1.1 Purpose

The purpose of this document is to establish haza1·d analysis requirements, methodologies, and processes for the Commercial Low Earth Orbit (LEO) Development Program (CLDP). The SOMD-CSD-10:XXX Commercial Low-Eruih Orbit Destination System Crew Cetiification Requirements for NASA Missions and CLDP-REQ-1130, Requirements and Standards for Commercial Low Ea1ih Orbit Development Program Document established for the CLDP Program dictate that comprehensive and accurate safety analytical practices be developed and implemented to identify and document all hazards, hazru·d controls and Emergency Response Methods.

1.2 Scope

The requirements of this document apply to the CLDP, Commercial Providers, Commercial Provider end-to-end Commercial LEO Destination (CLD), Crew Transpo1iation System (CTS), Cru·go Transp01tation System (Ca TS), utilization, payloads and cargo, and associated in-space activities relative to the involvement of U.S. Government (USG) crew. This includes ground and on-orbit, free flying or integrated operations.

Commercial Provider end-to-end CLD services includes (1) prepru·ation of USG crew, cargo, and payloads (pressurized and unpressurized) for transp01t to CLD; (2) operation of a ground missions center to communicate, coordinate and support tni.ssion operations (launch, transp01t, docking/undocking, delive1y, transfer, on-orbit, return to Eruth, landing, and post-landing recove1y and ground transport operations); (3) transp01tation of USG crew cargo, and utilization and payloads to and from the CLD or in-space LEO platf01m; (4) USG crew occupation and usage of CLD or in-space LEO platfo1m that provides for utilization facilities and supports internal and external payload installation and operation to meet reseru·ch and development mission objectives; (5) USG crew, cargo, and payloads post-landing recove1y and ground transp01tation of crew, cru·go, and payloads to a designated location. The Integrated Destination will be comprised of Cargo Visiting Vehicle (CaVV), Crew Visiting Vehicle (CVV), CLD, cargo, utilization, payloads and other systems that ru·e associated with USG crew habitation and operations.

The CLDP Hazru·d Analyses (HAs) will address design and operational hazards associated with CLD and CTS grotmd and flight hru·dwru·e, softwru·e, ground and on-orbit operations, human operator pe1f01mance, maintenance, and environments (including facilities). Hazards external to CLD and CTS (e.g. , CaTS, utilization, payloads and cargo) ru·e considered if they may present a hazai·d to the CLD or USG crew/ground personnel.

HA tracking and controls of critical /catastrophic severity is only required to address failures that impact flight assets and government personnel.

Note: This document supersedes use of SSP 30599 for CCP STRB.

Page 6 of83

1.3 Verb Application

CLOP defines in CLDP-REQ-1130, Requirements and Standards for Commercial Low Eaith Orbit Development Program, its implementation of requirement verbs as follows:

a) "Shall" - Used to indicate a requirement that is binding, which must be implemented, and its implementation verified in the design or in program documents.

b) "Should" - Used to indicate good practice or a goal which is desirable but not mandat01y.

c) "May" - Used to indicate permission.

d) "Will" - Used to indicate a statement of fact or declaration of purpose on the paii of the government that is reflective of decisions or realities that exist and are to be taken as a given and not open to debate or discussion.

e) "Is" or "Are" - Used to indicate descriptive material.

Rationales, included for many of the requirements, ai·e intended to provide clarification, justification, purpose, and/or the source of a requirement. If there is an inconsistency between a requirement and its rationale, the requirement always takes precedence.

1.4 Change Authority/Responsibility

Proposed changes to this document will be submitted by a CLOP Change Request (CR) for consideration and disposition. All changes to this document require the approval of the CLOP Program Control Board (PCB).

All such requests will adhere to the CLOP Change Review Process documented in CLDP-PLN-4000, Commercial Low Eaiih Orbit Development Program Infonnation and Configuration Management Plan.

The appropriate NASA Office of Primaiy Responsibility (OPR) identified for this document is CLOP Safety and Mission Assurance (SMA).

Nothing in this document supersedes applicable laws and regulations unless a specific exemption has been obtained.

Page 7 of83

2.0 Documents

2.1 Applicable Documents

The following documents include specifications, models, standards, guidelines, handbooks, and other special publications. The documents listed in this paragraph are applicable to the extent specified herein.

Document Number Title

CLDP-PLN-4000 Commercial Low Eaith Orbit Development Program fufo1mation and Conforu.ration Management Plan

CLDP-REQ-1130 Requirements and Standai·ds for Co1mnercial Low Eaith Orbit Development Program Document

2.2 Reference Documents

The following documents contain supplemental information to guide the user in the application of this document.

Document Number Title

ANSIZ136.1 American National Standard for Safe Use of Lasers CSD-10000 Human-Rating Requirements for Space Systems

JSC 20793 Crewed Space Vehicle Battery Safety Requirements

NASA-STD-6016 Standard Materials and Processes Requirements for Vehicle

NASA-STD-8739 .8 NASA Software Assurance and Software Safety Standard

NASA-HD BK NASA Complex Electronics Handbook for Assurance Professionals 8739.23 SOMD-CSD-1 OOOX Cormnercial Low Earth Orbit Destination System Crew Ce1tification

Requirements for NASA Missions

Page 8 of83

3.0 Hazard Analysis Overview

This section, along with its subsequent subsections, establishes core methodologies for perfonning Hazard Analyses (HAs ), stipulates the requirements for documenting those analyses, and outlines the process for accepting the hazard risk for all lifecycle phases and aspects of the CLDP.

A HA of the design and operation (including software) concepts is used to anticipate and prevent hazardous circumstances that may potentially result in mishaps. A HA is perfo1med to identify and document all safety hazards, including integrated hazards, applicable technical safety requirements, hazard causes (identify likelihood and severity), controls ( evaluate all hazards for means of eliminating, reducing, or controlling the associated risk), verification methods (test, analysis, inspection, demonstration, etc.), hazard risk assessment (severity and likelihood), crew survival capabilities, and emergency response procedures. It is a systematic process for gaining and evaluating specific infonnation pe11aining to the safety of a system and addressing failures that affect government personnel and flight assets.

In providing a method to analyze hazards, the hazard analysis accomplishes the following:

• Identifies hazardous conditions and hazardous elements in end item designs,

• Assesses the significance of the identified hazardous condition's effects,

• Provides a basis for establishing system safety preventive measures,

• Provides verification of end item design compliance to specified safety requirements and controls,

• Examines the safety impact of failures,

• Examines the hazard interface (integrated hazaTd assessment).

The CommeTcial Provider should initiate the HA in the early design concept phase and revise and maintain the HA thrnughout the development and operational phases. The Commercial Provider shall assure that all hazards and risks identified in the HAs are either eliminated or controlled to acceptable levels . The Commercial Provider shall revise and maintain hazards, their associated causes, controls, and verifications and use the HA results to develop, design, and operate the Commercial Provider end to-end CLDs throughout its lifecycle.

The result of this analysis is typically documented in the f01m of a Safety Data Package (SDP) and should include hazard identification, classification, and resolution, and a record of all safety-related failures. Hazard Reports (HRs) document hazard control(s), and verifications identified in the HAs. The HR info1ms program management of risks, how the risks are managed and controlled, whether the residual risk is acceptable, and whether actions need to be taken to address the residual risk prior to proceeding to the next program milestone. For more infmmation on SDP development, see Section 4.2, Safety Documentation. The evaluation/classification process is approached in te1ms of ratings of hazard characteristics and consequences. The classifications of hazards are applied in accordance with requirements provided in Section 3 .2, Hazard Severities/Likelihood. Detailed instmctions for conducting a HA are provided in Section 3.1 , Hazard Analysis Guidelines, and Section 4.0, Hazard Analysis Development. Appendix C, Haz~ud Analysis Types, additionally provides methodologies and examples to document traditional safety analysis techniques.

3.1 Hazard Analysis Types

Commercial Providers shall perf01m HAs as applicable in accordance with the appropriate section of Appendix C, Hazard Analysis Types (unless othe1wise specified in bilateral agreements or individual contracts). The Commercial Providers shall provide the HA encompassing all the hazards created by the end item and assess the design for compliance with Failure Tolerance (FT) requirements (reference Section 3.3.1). HA scope will include all Must Work and Must Not Work hazru·ds, including hazru·ds from hru·dwru·e and operational faults and failures, as well as loss of critical functions.

The following table of HAs describes vru·ious techniques that can be utilized so that all hazru·ds ru·e identified.

Type

Preliminary

Hazard Analysis

(PHA) .

Subsystem .

Hazard Analysis

(SSHA) .

TABLE 3.1-1 HAZARD ANALYSIS TYPES

(4 PAGES)

Purpose I Stage

Identify hazards and determine significance

Establish Safety Requirements

Identify basic hazard controls, evaluate alternate concepts, and document initial System Requirements Review safety risk of the concept or system (SRR)/Conceptual Phase to eliminate possibility of costly

Determine possible hardware, design changes later.

procedural, or system inte1face problems

Identify areas for testing, trade studies and further analysis

Identify hazardous conditions and elements in system/subsystem design and detennine significance

Preliminary Design Review Establish a basis for hazard controls (PDR)/Detailed Design

Development as hardware Provides verification of drawings become available.

system/subsystem design compliance to CLDP-REQ-1130 safety requirements and examines integrated hazards

Page 10 of83

Type

System Hazard Analysis (SHA)

Portable Equipment

Hazard Analysis

(PEHA)

Commercial Module Hazard

Analysis

(CMHA)

TABLE 3.1-1 HAZARD ANALYSIS TYPES

(4 PAGES)

Purpose I Stage

Examines safety impact of failures PDR/Detailed Design

Examines hazard interface Development as system and subsystem design and interfaces

Identifies areas and provides specific (including software) are defined.

detailed design information for SHA is updated because of any additional analyses system and/or inte1face changes.

Identify hazardous conditions and applicable destination modules for a p01table equipment item

Establish a basis for establishing hazard controls

Prnvides verification ofpmtable PDR/Detailed Design equipment design compliance to Development as hardware specified safety requirements drawings become available.

Examines safety impact of failures

Identify areas and provides specific detailed design information for additional analysis

Identify hazardous conditions in Destination modules PDR/Detailed Design

Development as system and Perform risk assessment on interfaces subsystem design and interfaces between the subsystems that compose (including software) are defined.

the module

Page 11 of83

Type

Operating and Support Hazard

Analysis

(O&SHA)

Software Hazard Analysis (SWHA)

TABLE 3.1-1 HAZARD ANALYSIS TYPES

(4 PAGES)

Purpose I Stage

Ensure the safety of system elements (persom1el, equipment, software, and hardware) during and from operations

Examines procedurally controlled activities

Identify hazards associated with operations including support

SRR/PDR: An optimal approach operations (assembly, maintenance, resupply, refiubishment) involves two phases: pe1fonn a generalized analysis dming the Identify hazard causes associated with conceptual phase; and mishap development associated wit11 subsequently perform a specific operations and support tasks and detailed analysis dming the

Identify preventative procedmes that procedme development phase.

can be used to avoid hazardous circmnstances OI mishaps

Define requirements and timeline for emergency response

Define requirements for handling and storage of hazardous materials.

Software is evaluated as a cause of hazards, as an active control to hazards, and as pa.it of the detection and wai11ing system

Integrated pa1t of the system safety analysis

Integrated pa.it of t11e system Evaluates program and interface safety analysis.

requirements, and identifies e1rnrs and deficiencies in the prograin requirements that could result in a hazard

Requirements analysis defined by

NASA-HDBK 8739.23

Page 12 of83

Type

Destination Commercial

TABLE 3.1-1 HAZARD ANALYSIS TYPES

(4 PAGES)

Purpose I Stage

Identify inte1faces between Destination modules/core systems/subsystems

Identifies inte1faces between Destination, trnnspmtation systems

Provider Integrated . Identify hazardous conditions to

As early in the development

Hazard personnel and the system from the process as possible.

Assessment interactions with Destination (IHA) modules/core systems/subsystems provided by other Commercial Providers/owners (integrated hazards)

Ground and . Ensures the safety of USG crew and Mission Systems NASA support personnel prior to SRR/PDR Hazard Analysis launch and after landing

3.2 Hazard Severities/Likelihood

Commercial Provider shall assess hazards using the hazard severity definition and hazard likelihood definition per Table 3.2-1. The Commercial Provider shall use the hazard scoring matrix, Table 3.2-3, to display the relative severity and likelihood ranking of each of the assessed hazards. Hazard severity level quantifies the worst-case accident or undesired event resulting from a cause without consideration of controls. Hazard likelihood is the probability that an identified hazardous effect will occur from the identified hazard cause based on control implementation. HRs are used to establish the risk baseline for the program, to help derive hazard controls and represent a flight constraint if not closed prior to the mission. If unacceptable risks are identified through the hazard analysis, it forces the program to take action, but are not typically used to prevent a milestone from occmring.

3.2.1 Marginal Hazards

Marginal hazards are defined as any condition which may cause damage to an end item (the loss of which then itself does not constitute a critical or catastrophic hazard) and/or an injmy that does not require medical intervention from a second crew member, nor consultation with a Flight Surgeon (including those injuries that might result in minor crew discomfmi).

Examples of minor crew injuries nominally associated with the marginal severity could include but are not limited to: crew discomfort, abrasions, bruises, or superficial burns. Marginal hazards am typically addressed via Commercial Provider internal processes and practices, and to document a comprehensive hazard analysis, the Commercial Provider should snmmarize/reference the results of their analysis

Page 13 of83 within the associated SDP. Marginal hazards do not require submission of Hazard Repo1ts (HRs) for formal approval.

3.2.2 Critical Hazards

Per CLDP-REQ-1130, Requirements and Standards for Commercial Low Earth Orbit Development Program, critical hazai·ds am defined as any condition which may cause a non-disabling personnel injmy or severe occupational illness· loss of Destination, mission or ability to supp01t a crewed mission over the planned mission duration. Critical hazards can also be from ha1·dwa1·e/software failures that result in the loss of a major end item, loss of redundancy (i .e. , with only a single hazard control remaining) for on-orbit life sustaining function or loss of an emergency system, or loss of use of systems needed for essential logistics or damage to a vehicle of a ground facility occms.

3.2.3 Catastrophic Hazards

Catastrophic hazards ai·e defined as any condition that when uncontrolled results in a catastrophic event.

This is an event resulting in loss of life or pe1manent disabling injmy, or an event resulting in the loss of a crew return vehicle.

TABLE 3.2-1 HAZARD LIKELIHOOD DEFINITIONS

Likelihood Criteria

Very High Will occur more than several times or highly to occur frequently in the life of the program. (Controls are missing or insufficient).

High Will occur once or likely to occur several times in the life of the program. (Controls have significant limitations or unce1tainty).

Moderate Likely to occur sometime in the line of the program.

(Controls exist, with some limitations OI unceltainty).

Low Unlikely, but possible to occm in the life of the program.

(Controls have minor limitations OI unce1t ainty).

Very Low So unlikely, it can be assumed occmTence may not be expe1ienced in the life of the program. (Strong controls in place) .

Page 14 of83

TABLE 3.2-3 HAZARD SCORING MA TRIX

Very High (5)

High (4)

Moderate (3)

Low (2)

Very Low (1)

3.2.4 Hazard Control Strategy

NIA

N/A

N/A

N/A

N/A

Marginal

(1-3)

C1itical

(4)

Severity

Catastrophic

(5)

A hazard control strategy is used to minimize risk of exposure to hazru·ds where hazru·d controls ru·e used to eliminate or control the hazru·d cause. This section will describe methods or approaches to eliminate or control the hazard cause.

3.2.5 Failure Tolerance (FT)

FT is the ability of the Commercial Provider design and its operation to continue to safely operate in the presence of a failure(s) and/or operator e1rnr(s). The Commercial Provider design capability to tolerate the number of failure events and/or operator etTors is based on the hazru·d severity level (critical or catastrophic). The HA and suppo1iing analysis are used to detennine the Commercial Provider design capability to tolerate a number of failure events and/or operator etTors based on the acceptability of the residual safety risk that is characterized and justified within the HA. For cases where the Commercial Provider design does not meet a FT requirement, a Safety Non-complianceNru·iance shall be briefed and reviewed by the CLDP Safety Review Board (CSRB) and, if necessa1y, elevated to the CLDP PCB. The Safety Non-complianceNariance shall include a description of the safety non-compliance/variance and technical basis for an exception to the FT requirement including why the hazru·d controls and residual risk is acceptable.

Common cause failures or events can affect multiple controls , inhibits or design features in the system. When redundancy is provided by identical components, locations, or channels, susceptibility to common cause failures may be increased, thereby defeating the intended level of redundancy. Susceptibility to these common cause failures shall be included in the dete1mination of the level of FT inherent in the system design. The use of dissimilru· redlmdancy can mitigate common failure causes.

Page 15 of83

3.2.5.1 FT For Critical Hazards

For FT considerations compliance with this requirement can be accomplished at the end item level or through a combination of hazard controls at the Module/System levels and end item level. Two verifiable controls must be provided such that a single failure does not result in a critical hazard for the end item to be considered single FT. The single FT requirements for critical hazards applies to end items in the Approach Ellipsoid (AE). For crew transp01tation system outside the AE, the crewed transpo11ation system requirements found in CLDP-REQ-1130, Requirements and Standards for Commercial Low Eaith Orbit Development Program requirements will be applied.

3.2.5.2 FT For Catastrophic Hazards

For FT considerations, end item hazards resulting in potential catastrophic impacts to transpo1iation systems ( exainple: interference resulting in Destination collision) ai·e also considered catastrophic.

Compliance with this requirement can be accomplished at the end item level or through a combination of hazard controls at the Module/System levels and end item level. Three verifiable controls must be provided such that the first and second failures do not result in a catastrophic hazard for the end item to be considered 2FT. After two failures have occurred, evacuation of the Destination is acceptable as a third control to hazards whose only catastrophic effect is loss of crew. The 2FT requirements for catastrophic hazai·ds apply to systems/end items in the AE. For crewed transpo1iation system/crewed VV outside the AE, the crewed transportation system/crewed VV requirements fmmd in CLDP-REQ- 1130, Requirements and Standards for Commercial Low Ea1th Orbit Development Program requirements will be applied.

3.2.5.3 FT and Emergency Systems

Per CLDP-REQ-1130, Requirements and Standards for Commercial Low Eaith Orbit Development Program, Emergency systems, EV A and emergency operations cannot be used as a pa1t of FT as these emergency systems and equipment cannot definitively prevent an initiating event. Therefore, a FT sb.-ategy without the use of EV A, emergency systems, or emergency operations will control catastrnphic and critical hazards. However, to prevent loss of crew and/or loss of Vehicle/Destination in the event all other approved hazard controls have failed, the use of EV A, emergency systems, and contingency or emergency operations will be considered an emergency response. For the EVA to be a valid emergency response, the Commercial Provider must include EVA capability as part of the design and there must be an EV A compatible interface to suppoli the EV A operations. Emergency operations are captured in the emergency response section of the HR. After two failures have occurred, evacuation of the Destination is acceptable as a third control to hazai·ds whose only catastrophic effect is loss of crew. Prohibition against an EVA as a leg of FT does not apply to operational controls used during the perf01mance of an EV A. Additional unplanned/contingency EV As do not contribute to the FT strategy.

HAs shall be perfo1med on each emergency system when the system is in the non-operational or non emergency operational state during a nominal mission. Full FT requirements apply to ensure that hazai·ds introduced by the presence of the emergency system are identified and controlled. The analyses shall include potentially hazardous conditions introduced by the presence of the emergency system, failures of the emergency system leading to hazards (including inadve1ient or accidental operation of the system, i.e. , "must not work"), and the effects the emergency system has on nominal operations of the vehicle. For all such scenaii.os, ( or the use of approved standai·ds and mai·gins, in worst-case conditions, Page 16 of83 and in line with the FT exemption process), the appropriate level of FT, as detennined by the integrated design and safety analysis, will be incorporated into the design.

FT requirements do not apply to emergency systems when the systems are activated to perfmm their intended functions for crew survival. However, design solutions must be in place to ensure the emergency system operates successfully and with high reliability. Emergency system reliability (including O FT design solutions) will be deemed adequate through an integrated design analysis that verifies compliance with the design specification for the specific emergency system. Where applicable, that integrated design analysis will meet any reliability allocation requirements for the emergency system.

3.2.6 Design For Minimum Risk (DFMR)

The Design For Minimum Risk (DFMR) approach is employed where a FT approach to design cannot be achieved or is impractical to apply and where specific design features can be fully implemented and verified. DFMR is based on a defined process in which approved standards and margins ru.-e implemented to minimize the likelihood of occunence of a hazai·dous effect by increasing design ma1·gin in the system based on the capability of the material, the operating environment, and their known vaii.ability. Application of margin may be implemented through increased dispersion of the environment or system prope1ties that respond to the environment. An example of this includes additional mate1i.al added beyond the mioimnm factor of safety. This allows for the design to provide a comparable control to FT.

DFMR approach may be applied to prima1y and secondaiy stiuctures, pressure vessels, pressurized lines and fittings, material compatibility, and flainmability where failure modes are 1mderstood and controlled using approved standards and mai·g:ins for designs with known material prope1ties, capability, vai·iability within a well-defined operating environment.

Candidates for DFMR shall be identified early in the Concept Development phase through the P:relimina1y Design phase and documented in the PHA and/or HR. New DFMR candidates will be coordinated, reviewed, and approved by CLDP p1i.or to being used as pai1 of the conti·ol strategy or Commercial Providers may use from a CLDP approved list of DFMR control approach.

Other potentially catastrophic hazai·ds that cannot be fully controlled using FT and/or DFMR can be proposed for acceptance to the CSRB per the Safety Non-ComplianceNaii.ance process outlined in Section 4.2.8.

3.2. 7 Process Controls

Process confrols used in manufacturing, assembly, test, handling, or hansp011ation processes ai·e crncial in assuring reliable design conti·ols (i.e., FT or DFMR) ai·e used to control and manage risk of exposure to hazai·ds. Control and mitigation of such hazai·d causes will be based on process controls ( e.g. , c1i.tical manufacturing, cleanliness standards, procurement standai·ds and processes, pa1ts contrnl programs quality management systems, etc.), which ai·e typically the only method of controlling and preventing

Page 17 of83 the hazard cause. Examples of hazard controls that require process controls include improper design, improper material selection, contamination of item causes failure, etc.

Commercial Provider shall identify process-based hazard controls in the HR including, identification of the controlling standai·ds or requirements that govern the process, the methods by which the process is controlled and verified to conform to those governing standards, and the rationale why the residual risk of defects is acceptable.

3.2.8 Emergency Response

Emergency response methods cover activities to save the crew (Crew Survivability) and efforts to save the destination (Destination Sm-vivability).

Emergency response and associated planning, including procedures, Personal Protective Equipment (PPE), and emergency response hardware/systems (Patch kits, defibrillator, smoke remediator, clean up kits, etc.) add robustness to the Destination design and provide the ability to intenupt the progress of a hazard sequence preventing a loss of crew event and/or allowing the recove1y of the Destination/VY from a catastrophic event.

The Commercial Provider shall perf01m HA of emergency equipment (PPE, fire extinguishers smoke remediator, leak detectors, etc.) used in emergency operations, using identified emergency scenarios and procedures as boundaries for the analysis, for the purpose of ensuring all necessa1y design requirements for the equipment are identified and safety risks to the flight crew and vehicle(s) when using the equipment are communicated. The emergency response HA shall be delivered to the appropriate safety review board as part of the HA package, including the verification that the crew has been trained in the use of the emergency response actions/procedures. At a minimum, the Provider shall develop emergency response actions/procedm·es for hazardous substance release (gas, liquid, paiticulate), depress, fire, Loss of Attitude Contrnl (LOAC), and medical emergency (emergencies).

3.2.8.1 Crew Survival Methods (CSMs)

Crew Sm-vivability methods represent the total set of requirements, analyses, equipment, training, and procedures used to isolate, mitigate and/or control the exposme to a hazardous condition which presents an immediate threat to the crew.

For an imminent catastrophic event the HA shall identify CSMs for each catastrophic hazard cause that will increase the probability of crew srn-vival when all hazard controls have failed. Based on trade sh1dies/analyses, the crew srn-vival capabilities available and implementable dming each phase of the mission will be dete1mined. The Commercial Provider shall develop and document CSM scenarios and analysis including a description of chain of events that leads to an imminent threat to crew ( e.g., external events, system failures) , emergency events (i.e. fire, collision, toxic release, depressurization, and medical emergencies), designed and operational capabilities that protect the crew (such as aboit, safe haven, rescue, emergency egress, emergency systems, and emergency medical equipment or access to emergency medical care), and crew roles, responsibilities, and involvement.

Page 18 of83

3.2.8.2 Destination Survival Methods (DSMs)

Destination Smvivability represents the total set of requirements, analyses, equipment, trnining, and procedures intended to secure the safety of the crew after a potentially catastrophic event sequence has started. No requirements are levied on the Destination to provide for its rec.ove1y and/or smvivability after the occmTence of a hazardous event. Expectation is that the Commercial Providers will want the ability to prese1ve their destination in the event of a potentially catastrophic event (hazardous substance release, Micro Meteoroid Orbital Debris (MMOD) strike resulting in depress, fire, etc.). Destination smvivability mitigations shall be documented in the hazard analysis. If the risk to US Government crew is increased during the DSM-specific response, then the procedures will need to be concmTed with by

NASA.

3.2.9 Computer-Based Control Systems (CBCS)

As pait of the hazard control strategy, the Commercial Provider shall use CBCS requirements for computer-based or complex electronic-based control systems that control a safety-critical process or device that pose a critical or catastrophic hazard due to an inadve11ent operation or failure. To minimize risks associated with the use of computers, the hazard control is developed using engineering and management principles, criteria/standards, and techniques to tolerate hardware failm·es and software errors.

Specific detail and requirements for hazard areas utilizing CBCS are provided in CLDP-REQ-1130 Requirements and Standards for Commercial Low Ea11h Orbit Development Program.

The safety HA process ensures that all computer systems or any system that involves software used as a hazard control means has an acceptable level of risk. The software safety hazard analysis assesses for all safety-related hazards that are caused by malfunctioning, error coded, or non-functional software (i.e. , failure modes due to all variations of software common cause failures) throughout all mission phases and operational scenarios. The Commercial Provider is responsible for evaluating and documenting the necessa1y controls and verifications in a HR and provide a CBCS compliance matrix to be reviewed by the Computer Safety Panel prior to Phase I, II and III.

3.2.9.1 Software Common Cause Failure

Software common cause failure is due to a latent software defect that triggers more than one unexpected spacecraft system behavior(s) stemming from the simultaneous use of same software instance. A software common cause failure adversely impacts the software ' s proper operation and prevents redundancy management schemes from isolating the problem to a specific device. Where spacecraft systems use software to execute critical functions, the Commercial Provider shall document software common cause failures, assess avionics and software architecture sensitivity to software common cause failures with the operational scenarios and mission phases, and identify the time to effect of each applicable hazard to dete1mine if the software can be recovered or repaired before a catastrophic hazard is realized as part of the HA. Software common-cause failure impacts on a potential hazard shall be documented as paii of the corresponding HRs.

Page 19 of83

A primaiy mechanism for combatting common-cause failure is the use of stringent development and test processes, to minimize the introduction of individual softwai·e faults , which may eventually manifest as software common cause failures .

3.3 Hazard Control Order of Precedence

Most hazards will require the combination of these approaches to adequately conu-ol a potential hazard.

3.3.1 Eliminate the Hazard

The primruy method ( and preferred first choice) for reducing hazru·ds is through a design approach that will prevent the occurrence of the hazai·d. Hazai·d elimination is accomplished by eliminating the hazard source by deleting (e.g., selecting non-hazai·dous sources of materials) or the hazardous operation (e.g. , selecting a design that achieves its purpose using non-hazardous operations).

3.3.1.1 Reduce Risk Through Design Alteration

When elimination is not possible, control and isolation of potential hazards and FT considerations ru·e to be included in design approach.

1. Inc01porate design features or devices, that if they work c01Tectly would prevent the hazai·d (e.g. , FT inhibits, FT/redundancy of critical functions, etc.).

2. Design changes that reduce the severity and/or the likelihood of the hazard(s) (e.g., increased high mai·gin to design factors of safety to failure or substitution of less hazardous technologies/substances/ energy sources).

3.3.1.2 Use of Operational Controls

Where it is not possible to reduce the hazard by design, real-time activities of the on-orbit crew , issuance of a ground command, or implementation of a preplanned decision (e.g. , safety-critical flight mies) may be used to counter hazardous conditions. The primaiy method used for operational controls (e.g. , crew close a manual valve, to provide a second control/bru.Tier to a hazai·d, crew torque safety critical fasteners to a specified torque value, ground mode a vehicle to free-drift within time to effect, if automated system fails , etc.) ai·e procedures. The next method, flight mles, is n01mally for aspects that are not contained in a nominal procedure ( e.g., the1mal requirements, contingency situations, lighting).

The last method of operational control is crew training. It is difficult to reliably verify that the crew understands the intent of the control and it requires proficiency/currency training to maintain the crew member's ability to perf01m the operation within the time to effect for the hazai·d.

For Catastrophic or Critical hazards, the use of flight rnles, procedures and training as the only risk reduction method should be avoided. The use of ground commands as operational controls is only applicable for those failures whose time-to-effect is longer than a pre-determined maximum allowable planned outages or Mean-Time-To-Repair of the ground systems and communication links.

Page 20 of83

3.4 Hazardous Effect Mitigation

Where it is not possible to reduce the hazard risk of hazard occunence to an acceptable level through design and operational controls, the use of hazardous effect mitigations allows safing and/or recove1y after a hazardous event has occurred. Hazardous effect mitigations can include the use of automatic safing devices, PPE, recove1y equipment, detection capabilities warning devices, and/or real-time activities of the on-orbit crew utilized to counter hazardous conditions once they occm and provide enhancements to safety.

Clear and distinct warning signals/notices and their application will be designed to minimize the probability of wrong signals or of improper personnel reaction to the signal. If possible advance cautiona1y / warning notices should be utilized to prepare crew for a potential associated higher-level haza1·d and subsequent reactive controls that may be required or occur automatically.

4.0 Safety Hazard Analysis Development and Phased Safety Review Process

The safety hazard analysis and review process are a phased safety review process (Phases 0, I, II, and III) that conesponds to conceptual, preliminruy, critical design and final acceptance review phases (including verification/validation).

The safety hazard analysis begins at the Concept Development phase with the assistance from all appropriate stakeholders and continues throughout the life of the end item ( destination, payloads, cargo and/or VVs). Eve1y phased safety review requires an SDP. The SDP shall include a System Safety Assessment Report (SSAR), or a tailored version that encompasses the data requirements for the relevant phase safety review ( refer to Section 4 .2 .1.1, SD P Requirements), HRs and any other supp01iing data necessa1y to justify and explain the contents of the HRs. A Preliminruy SSAR (or a version of it) will be a part of the SDP for the SRR and updates to this repo1i will be prui of the SDP for the Systems Definition Review (SDR). Phase 0 will be conducted around this timeframe and the most updated SSAR/SDP will be submitted for review. The completion of the appropriate safety hazru·d analysis and the CLDP acceptance of the residual risk is a component of the success criteria for the Preliminruy Design Review (PDR)/Phase I Critical Design Review (CDR)/Phase II, and System Acceptance Review (SAR)/Phase ill milestones; see Section 4.2, Safety Documentation for fiuiher details on SDP and HR data requirements.

The safety milestone reviews represent deliveries expected for a Commercial Provider following a traditional gated program development schedule. A Commercial Provider should align their HA development schedule to ensure that all verifications and controls ( design features, applicable standru·d, necessa1y testing, required inspections, etc.) are in place to suppoli procurement, manufacturing, assembly, and testing. Failure to identify and implement the appropriate contrnls and verifications exposes the Commercial Provider to the risk of having to rework/redo activities. At times, major updates to design or development approach may merit reassessment/delta reviews of prior safety milestones to ensure continued completeness of safety hazard documentation.

It is imp01tant to negotiate the phased safety schedule with the CSRB as the phased safety review schedule may not always be feasible for ce1iain development milestones. Meetings outside of the f01mal phased safety reviews (i.e. , working groups, Technical Interchange Meetings (TIMs)/special topics) are encouraged to enhance efficiency and reduce the time required for safety data to be reviewed during the milestone review. Delta Phase reviews may be necessa1y if there ru·e significant changes to the safety documentation due to a milestone review.

For larger, more complex systems with extensive safety hazard analysis/HRs, phased safety reviews might need to be divided across multiple meetings. These meetings could commence well in advance of the milestone review to ensure the phased review is completed prior to the conclusion of the milestone review. A summa1y of the development schedule and phased safety review timing, expectations and review scope is shown in Table 4.0-1.

For a detailed explanation and description of the phased safety review process, please see Appendix E, Phased Safety Review Requirements.

Page 22 of83

4.1 Safety Milestones

4.1.1 Phase O - Concept Development

The safety hazard analysis process commences in the Concept Development phase, during which the PHA is perfmmed. The prima1y objective of this safety hazard analysis is to identify all potential hazards, hazardous events, hazard causes, concept of operations, and dete1mine the necessruy safety requirements for eliminating, reducing, or controlling the risk. This process encompasses the identification of the system's safety-critical functions and the derivation of softwru·e safety requirements.

The method for conducting the PHA and fo1mat for the resulting Prelimina1y Hazru·d List (PHL) is in Appendix C, Hazru·d Analysis Types. Results of the hazru·d analysis are used to ensure that proper safety requirements are identified in the appropriate safety documents. The results of the PHA are documented in the Preliminary SSAR and included in the PHL (refer to Table 4.1.1.-1 for an example -suggested fmmat only). This report will be included in the SRR data package, and updates included in the SDR data package, which will feed or become part of the Phase O SDP.

Page 23 of83

TABLE 4.1.1-1 PHL WORKSHEET SAl\llPLE INSTRUCTIONS

Hazard Analysis Revision: DRM:

Title:

Worksheet No.: Engineer:

FFBD Version: FFBD Block Date:

No.:

Module/Subsystem: Sheet:

Hazard Causes Sen1ity Likelihood Requirements Hazard Failw·e Eme1·gency Elimination/ Tolerance Response

Control Pro,isions

Identify &tterbrief Identify the Provide the Identify the Identify Identify the Provide existing or description of worst-ease probability of existing or proposed level of methods for potential how…