![](media/image1.png){width="1.2993055555555555in"
height="1.1569444444444446in"} OSP-PLAN-022

National Aeronautics and BASELINE

Space Administration EFFECTIVE DATE: September 10, 2003

**George C. Marshall Space Flight Center**

Marshall Space Flight Center, Alabama 35812

UP40

Orbital Space Plane

PROGRAM

Human Rating Plan

Volume I

**ORBITAL SPACE PLANE\
HUMAN RATING PLAN**

**VOLUME I**

**SIGNATURE PAGE**

**Prepared by:**

*/s/ William A. Jacobs, P.E. 9/10/03*

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

William A. Jacobs, P.E. Date

Requirements Management Office

Orbital Space Plane Program

**Concurred by:**

*/s/ David C. Leestma 18 Sept '03*

David C. Leestma Date

Assistant Program Manager

Orbital Space Plane Program Office

*/s/ Shannon D. Bartell Sept 18, 2003*

Shannon D. Bartell Date

Assistant Program Manager

Orbital Space Plane Program Office

*/s/ D. E. Smith 18 Sept 03*

Dennis E. Smith Date

Manager

Orbital Space Plane Program Office

**ORBITAL SPACE PLANE\
HUMAN RATING PLAN**

**VOLUME I**

**SIGNATURE PAGE**

Approved by:

*/s/ J. Victor Lebacqz 9/12/03*

Dr. J. Victor Lebacqz, Acting Associate Administrator Date

Office of Aerospace Technology

*/s/ Richard Williams 9/12/03*

Dr. Richard Williams, MD, Date

Chief Health and Medical Officer

*/s/ Bryan O'Conner 9/12/03*

Bryan D. O'Connor, Associate Administrator Date

Safety and Mission Assurance

*/s/ William Readdy 9/12/03*

William F. Readdy, Associate Administrator Date

Office of Space Flight

DOCUMENT HISTORY LOG

+---------+-------+---------+-----------------------------------------+
| **S     | **    | **Effe  | **Description**                         |
| tatus** | Docum | ctive** |                                         |
|         | ent** |         |                                         |
| **(Base |       | *       |                                         |
| line/** | **    | *Date** |                                         |
|         | Revis |         |                                         |
| **Revi  | ion** |         |                                         |
| sion/** |       |         |                                         |
|         |       |         |                                         |
| **Canc  |       |         |                                         |
| eled)** |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
| B       |       | 0       | Baseline Release                        |
| aseline |       | 9-10-03 |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+
|         |       |         |                                         |
+---------+-------+---------+-----------------------------------------+

#######  {#section .unnumbered}

####### Table of Contents {#table-of-contents .unnumbered}

[1.0 Introduction: 6](#introduction)

[1.1 Program Philosophy on Human Rating
6](#program-philosophy-on-human-rating)

[2.0 Documents 7](#documents)

[2.1 Applicable Documents 7](#applicable-documents)

[2.2 Reference Documents 7](#reference-documents)

[3.0 Human Rating Process 8](#human-rating-process)

[3.1 Human Rating Plan Development Process
8](#human-rating-plan-development-process)

[3.2 Compliance of requirements in NPG 8705.2
10](#compliance-of-requirements-in-npg-8705.2)

[3.3 System Designs 10](#system-designs)

[3.4 Design Philosophy 10](#design-philosophy)

[3.5 Software Design 11](#software-design)

[3.6 Test and Verification Requirements and Plans
11](#test-and-verification-requirements-and-plans)

[3.7 Configuration Management Approach
12](#configuration-management-approach)

[3.8 Human Rating Certification Process
14](#human-rating-certification-process)

[4.0 Decomposed Human Rating Requirements for the OSP System
16](#decomposed-human-rating-requirements-for-the-osp-system)

[4.1 Aerospace Design Standards 16](#aerospace-design-standards)

[4.2 System Safety and Reliability 16](#system-safety-and-reliability)

[4.3 Abort and Crew Escape 18](#abort-and-crew-escape)

[4.4 Flight Termination 19](#flight-termination)

[4.5 Proximity Operations 19](#proximity-operations)

[4.6 Human-In-The-Loop Requirements:
19](#human-in-the-loop-requirements)

[Appendix A: Definitions 24](#appendix-a-definitions)

[Appendix B: Acronyms 29](#appendix-b-acronyms)

[Appendix C: HRR NPG Compliance Matrix
31](#appendix-c-hrr-npg-compliance-matrix)

[Appendix D: NASA Standard 3000 Applicability Matrix
59](#appendix-d-nasa-standard-3000-applicability-matrix)

[Appendix E: MIL-STD-1472 Applicability Matrix
64](#appendix-e-mil-std-1472-applicability-matrix)

[Appendix F: Comments to NPG 8705.2, 2.10.5.1.a
66](#appendix-f-comments-to-npg-8705.2-2.10.5.1.a)

Table of Figures

[FIGURE 3.7.3-1. Joint OSP/ISS Program Control Process
13](#__RefHeading___Toc50537653)

[FIGURE 4-1. Example of workload rating scale.
22](#__RefHeading___Toc50537654)

[FIGURE 4-2. Modified Cooper-Harper Rating Scale
23](#__RefHeading___Toc50537656)

# Introduction:

The mission of Orbital Space Plane (OSP) Program is to develop a system
for crew transfer to and from the International Space Station (ISS) and
a system for crew rescue of personnel on the ISS. Both of these
capabilities concern human occupation of a space flight vehicle.
Therefore, it is necessary to define and execute a sound, consistent,
and complete approach that governs the process of human-rating these
space vehicles. It is also important for such an approach to be
developed and documented early enough in a program's life such that any
changes made will have minimal impacts. This Plan is intended to
identify the approaches and procedures for developing a system that will
be certified for human space flight.

## Program Philosophy on Human Rating

The Primary focus of this Program is to transfer humans to the
International Space Station and back to Earth. All aspects of this
system deal with human contact. It is therefore paramount that the OSP
Program protect the health and safety of humans involved in and exposed
to space flight activities, specifically the public, the crew,
passengers, and ground processing personnel. It is the goal of the
Program to design the safest and most reliable system possible, but at
the same time, without putting undue constraints on the designers. Some
technologies have made drastic changes in the past 3 decades and the
design of a new space flight system should be allowed to take advantage
of these advancements. There are also several solutions to improving
upon the problems that may have existed in the past. It is the
philosophy of the Program to allow new ideas and technologies to be
analyzed and traded to determine the most reliable and safe system
available. Due to this philosophy, the initial requirements by the
Program for human rating may deviate from some of the requirements in
NPG 8705.2. Tailoring and deviations will be implemented by the Program
where sound technical rationale provide justification and it is
demonstrated that the tailoring and deviations do not significantly
increase risk to human occupants. The tailoring and deviations will be
documented in this plan, approved by the AA for OSF and are subject to
the concurrence from the AA for SMA and the CHMO. These differences may
ultimately disappear if the trades and analyses determine that the
requirement as stated are, in fact, the best approach to safely design
the spacecraft and associated systems.

Throughout the Program Development, human rating will be an integral
part. The number one safety priority of the Program is to ensure the
safe return of the crew regardless of the outcome of the mission or
spacecraft. The Program will develop the human rating plan for all human
space flight program activities, based upon the unique mission goals,
technical and operational risk, other risk management plan requirements,
and other specific characteristics of the program. All aspects of the
system will be considered and determined to meet the criteria set forth
in this plan. Even as the Program looks to minimizing system complexity
and life cycle cost, safety and reliability of the system will not be
sacrificed.

# Documents

## Applicable Documents

  --------------------- --------------------------------------------------
  NPG 8705.2            NASA Human Rating Requirements and Guidelines for
                        Space Flight Systems

  NASA Standard 3000    Manned Systems Integration Standards

  MIL-STD-1472          DOD Design Criteria Standard -- Human Engineering

  NASA/TM-2003-210785   Guidelines and Capabilities for Designing Human
                        Missions

  JSC 26882             NASA Space Flight Health Requirements Document.

  JPG 8080.5            JSC Design and Procedural Standards Manual

  NASA Standard         Software Safety NASA Technical Standard
  8719.13A              
  --------------------- --------------------------------------------------

## Reference Documents

  ---------------- ------------------------------------------------------
  OSP-PLAN-005     OSP Program Plan

  OSP-PLAN-019     OSP NASA Design Reference Mission Document

  OSP-DOC-021      OSP Operations Concept Document

  OSP-PLAN-009     OSP Risk Management Plan

  OSP-PLAN-010     OSP Safety and Mission Success Plan

  OSP-PLAN-012     OSP Systems Engineering Management Plan

  OSP-PLAN-023     OSP System Verification Plan

  TBS              OSP Medical Operations Requirements Document

  LSP-OSPDEV-001   ELV Interface Definition Document (IDD)

  SSP 50677        ISS Interface Requirements Document (IRD)

  MSFC-RQMT-3370   Orbital Space Plane Mission Needs, Level I
                   Requirements, and Level I Operations Concept Document

  MSFC-RQMT-3360   Orbital Space Plane Level II System Requirements
                   Document

  NASA-STD-5001    Structural Design and Test Factors of Safety for
                   Spaceflight Hardware

  MPD 1280.1       Marshall Management Manual

  MPG 7120.1       Program/Project Planning

  MWI 7120.6       Program/Project Risk Management

  MPG 8060.1       Flight Systems Design/Development Control

  NPD 7120.4       Program/Project Management

  NPG 7120.5       NASA Program and Project Management Processes and
                   Requirements

  NPG 8715.3       NASA Safety Manual

  NPD 8730.3       NASA Quality Management System Policy (ISO 9000)

  SSP 50313        Display and Graphics Commonality Standard (DGCS)
  ---------------- ------------------------------------------------------

# Human Rating Process

This document will contain all of the relevant information related to
human-rating any space transportation system developed by the OSP
Program. The OSP Program will use this document to set the processes in
place to human-rate the OSP System, and execution of these processes
within the OSP domain. Human rating will be an integral aspect of the
Program throughout its life cycle.

## Human Rating Plan Development Process

A team of individuals around NASA was chartered to develop the Human
Rating Plan. The goals of the team were to develop a plan that addresses
each requirement in NPG 8705.2. The charter for this team is as follows:

[Purpose]{.underline}

Develop the Orbital Space Plane Program's Human Rating Plan (HRP) using
the Human Rating Requirements and Guidelines for Space Flight Systems
Document, NPG 8705.2, as guidance.

####### Objective {#objective .unnumbered}

Volume I:

-   Allocate each HRR Requirement to Programmatic, Verification,
    Deviation or Tailored, Trade, Technical, or SOW to identify where in
    the Program the requirement will be levied.

-   Assess each requirement called out in the NPG to determine if the
    program will

    -   Comply

    -   Deviate

    -   Perform Trade Studies to determine compliance or deviation from
        the requirement.

-   Develop and document a matrix to show the Program's position on each
    requirement.

-   Develop and document the contractor requirements that will go into
    the HRP.

-   Develop a plan for the trade studies that will be indicated.

-   Identify the processes established in the program that comply with
    requirements in the NPG.

Volume II:

-   Identify the tasks and methods required to verify the requirements
    in the HRR NPG 8705.2.

-   Work with the Architecture Contractors to document critical
    functions necessary for safe flight, design criteria, system
    designs, test requirements and procedures, software design, test and
    verification requirements, safety and reliability requirements,
    human factors engineering requirements, health, and other program
    elements required to achieve human rating.

####### Membership {#membership .unnumbered}

MSFC S&MA

JSC S&MA

Human Engineering Office

Astronaut Office

Launch Services Program

OSP Chief Engineer's Office

OSP Requirements Management Office

OSP Acquisition Management Office

This Plan will point to other documentation for details as they are
defined and identified if they are needed to support human rating. This
Plan will consist of two volumes. Volume I will contain the general
approach to human rating and the human rating requirements that will be
placed on the program. Any deviations or tailoring from NPG 8705.2,
"Human Rating Requirements and Guidelines for Space Flight Systems,"
will be documented and justification given for these deviations or
tailoring. This is consistent with the established guidelines in NPG
8705.2. The Associate Administrator for the Office of Space Flight (AA
for OSF) will approve Volume I subsequent to the System Requirements
Review (SRR) with concurrence from the Associate Administrator for the
Office of Aerospace Technology, the Associate Administrator for the
Office of Safety and Mission Assurance (AA for SMA), and the Chief
Medical Officer (CHMO). Volume II will be more comprehensive in nature
and will contain the tasks and methods necessary to accomplish and
verify each of the human rating requirements established in Volume I.
Verification of these requirements will be accomplished in several
different areas. The technical requirement verifications will be
accomplished through the Program and Contractor verification plans.
Verification of programmatic requirements will occur at the System
Acceptance Review (SAR). Volume II will also contain more design detail,
including vehicle descriptions, critical functions, and operational
concepts or point to documentation that contains this information. It
will be presented at each major milestone review in draft form and will
be baselined at the Critical Design Review (CDR).

Requirements from the NPG8705.2 that are not decomposed to become
contractor requirements, in this plan, will be traced to Program
documents such as the Program Plan, The System Verification Plan, The
Risk Management Plan, The Operations Concept Document, The Safety and
Mission Success Plan, and several Data Requirements Descriptions (DRDs)
or it will be the result of trades done by either NASA or the
Contractors. These trade results will then generate requirements that
will be in either the System Requirements Document (SRD) or in the
Contractor's System Specification.

## Compliance of requirements in NPG 8705.2

A matrix has been established to show how the Program will comply with
each of the requirements as called out in section 2.0 of the NPG. This
matrix is documented in Appendix C of this Plan. As the Program matures,
the traceability to actual sections of documents, Data Requirements, and
Designs will be documented in Volume II of the HRP. Requirements from
the NPG that are considered a contractual obligation for data and
processes from the OSP contractor will be indicated in the matrix and a
Data Requirement Description will be cited. Specifics on DRDs will be
given in Volume II of the HRP. Requirements from the NPG that are levied
against the OSP Program but do not flow down to the contracted effort
will be indicated in the matrix as to how the program will comply. The
requirement that will be deviated from or tailored out will have
Justification for doing so. The remaining technical requirements that
flow to the OSP Architecture Contractors are located in Section 4.0 of
this Plan.

## System Designs

The OSP architecture is envisioned to consist of flight systems and
ground infrastructure that are Government Owned and Government Operated
with Industry Operators, with the exception of the ELV, which will be a
government-furnished launch service to the OSP Contractor. The Program
has contracted with several companies to develop system architectures
that meet the goals of the program. Based on the Requirements given to
the Program from the Executive Council at NASA Headquarters, this
Program will use Expendable Launch Vehicles (ELV) as the boost stage for
a Crew Rescue or Crew Transfer mission. Even though the ELVs were
designed without human passengers in mind, the overall OSP System (which
includes the ELV) will be certified for human flight. The Program plan
for ELV certification is contained in OSP-DOC-046, "OSP Program Strategy
for Utilization of ELVs." For the OSP spacecraft, detail into the actual
system designs will come from the contractor's Level III (System
Specification) and lower level specifications. The System Specifications
will be reviewed and baselined subsequent to SDR.

## Design Philosophy

Design of the OSP System will be based on a thorough analysis of the
safety and reliability of the total system. The Program Level I
Requirements require a Probabilistic Risk Assessment (PRA) of 1/400 for
Crew Transfer and 1/800 for Crew Rescue per flight for Loss of
Crew(LOC). Also, estimations of casualties for general population and
ground personnel should reflect FAA Regulations for the Public.

The Program Level II System Requirements Document (SRD), MSFC-RQMT-3360,
details the functional capabilities and constraints that will be
necessary for design of the human rated system.

Additional guidelines contained in NASA program guidance and design
standards will be applied to OSP design activities through contracted
statements of work. For example, this document contains a high level of
detail regarding human acceleration loads since no acceptable NASA
standard exists. However, there are additional standards such as those
for structural design (e.g., NASA Standard 5001 for factors of safety)
which are invoked in the contracts. But the definition of an acceptable
human environment is found in NASA Standard 3000 and invoked by the
Human Rating Plan. The full development of a government approved, Level
III specification will define these requirements to the next level and
will reflect full tailoring of all applicable design documents.

## Software Design

Software is a vital aspect of any vehicle system design. Some form of
software/firmware is involved in all flight control, environmental
control and rudimentary functions of the spacecraft. This makes the
design and development of software a very important aspect of
human-rating a vehicle.

The OSP Contractor(s) will be required to provide (1) an initial
Software Development Plan (SDP) to support SRR, a draft SDP to support
SDR, and a baselined SDP to support Software Specification Review (SSR);
(2) initial Software Requirements Specification (SRS) at SDR, and
baselined SRS at SSR; (3) draft Software Design Description (SDD) at PDR
and baselined SDD at CDR. The contractor developed Software Test Plan is
required to support the Software Specification Review (SRR).

## Test and Verification Requirements and Plans

The OSP Program employs a rigorous Validation and Verification (V&V)
process to ensure that the system's design will result in an
architecture that satisfies all system requirements. The primary purpose
of V&V is to establish criteria for conducting comprehensive
architecture verification (including software and interfaces) at the
system level, to ensure performance requirements are satisfied.
Coincidentally, the V&V process generates data to confirm that system,
subsystem, and lower level items satisfy their individual specification
requirements. Due to its system criticality, the Program also employs
Independent Verification and Validation (IV&V) of the developed software
to independently test performance, and validate that all system-level
requirements are satisfied.

The Program\'s System Verification Plan (SVP), OSP-PLAN-023, uses
defined methodologies (test, analysis, inspection, demonstration, or
similarity) to document how the Program verifies and validates each
system-level design and performance requirement.

The contractor will define the overall vehicle flight test program by
the Preliminary Design Review (PDR) and include the purpose of each
test, and describe how the resulting database is to be used to satisfy
flight certification. Volume II of the HRP will list the critical
functions, by mission phase, required to met vehicle safety requirements
and show how they are implemented in the design.

All spacecraft software that controls or interfaces with critical flight
hardware and/or critical flight systems is independently validated and
verified by the Goddard Space Flight Center-managed IV&V Facility. The
Launch Services Program will utilize existing, proven verification and
validation processes for ensuring the integrity of the ELV software.

## Configuration Management Approach

### Configuration Control

Configuration control is the systematic definition, evaluation,
coordination, and disposition of each proposed change to a controlled
item. Deviation(s), and/or waiver(s) will be used for NASA to document
and approve non-compliance(s) and track each implementation of each
approved change and it's associated documentation.

A formal change management system using the OSP Program/Project Control
Boards (PCBs) shall be established for the management and control of all
controlled items and associated baselines. The PCBs and control levels
shall be detailed in the OSP configuration management plan.

The OSP program shall implement approved NASA Headquarters OSP
requirements through a multi-level Program/Project Control Board (PCB)
structure. PCBs are chartered with the tasks and responsibility for
establishing controlled items and baselines and shall review and
disposition all changes, deviations, and waivers to those items and
baselines in accordance with MWI 8040.2 and MWI 8040.3. Each PCB is
chartered with a specified membership, stated authority, and
responsibilities.

### Deviations and Waivers 

The Configuration Management Requirements Plan, OSP-PLAN-040, contains
the details for deviations and waivers to requirements in the OSP
Program. Deviations and waivers are departures from requirements and/or
specifications established for hardware and software baseline items.
Proposed deviations and waivers shall be submitted on MSFC Form 847 in
accordance with MWI 8040.3. Deviations and waivers shall not be used to
avoid required processes and/or procedures.

### Change Process 

The change process shall consist of the following steps:

-   Change preparation and justification

-   Change review and evaluation

-   Change disposition

-   Change implementation (of approved changes)

Anyone may initiate a change. Changes initiated by contractors shall be
submitted in accordance with their respective contract requirements.

The OSP Program Board shall be Chaired by the Program Manager, with full
waiver authority for OSP level II requirements that do not affect the
ISS interface. All deviations and waivers generated against the Human
Rating Requirements, after the program human-rating plan approval from
NASA Headquarters, are presented at all program major milestone reviews.
The board structure shall include an Engineering Review Board, chaired
by the Program Chief Engineer and an Independent Safety Review Board.
All changes must be reviewed by the board members or their designees and
the Engineering and Safety Boards prior to acceptance by the program
Level 1 PCB.

For Deviations, waivers or requirement change requests related to ISS
interface requirements; a Joint ISS-OSP Program Board shall be
chartered.

[]{#__RefHeading___Toc50537653 .anchor}FIGURE 3.7.3-1. Joint OSP/ISS
Program Control Process

The OSP and ISS programs shall develop a matrix of all relevant OSP
Level II Requirements and ISS Interface Requirements that will be within
the scope of the Joint Program Board. If a change request, provided to
the OSP PCB, requires deviation or waiver to an item in the pre-approved
matrix, the CR shall be reviewed by the relevant OSP and ISS review
boards and presented to a Joint ISS-OSP Program Board as shown.

The Joint OSP -- ISS Board, as a minimum, will be comprised of the
following voting members:

-   OSP Program Manager (co-chair)

-   ISS Program Manager (co-chair)

-   OSP Safety and Mission Assurance representative

-   ISS Safety and Mission Assurance representative

-   OSP Crew Office representative

-   ISS Crew Office representative

-   ISS Chief Engineer

-   OSP Chief Engineer

-   ISS-OSP Integration Manager

This board will approve all changes to the OSP SRD and ISS IRD
requirements after the initial baseline.

## Human Rating Certification Process

The Program intends to initially certify the system for crew rescue
missions and, upon demonstrated reliability over multiple un-crewed
flights, will certify the system for crew transfer missions.

The Human Rating Independent Review Team will be invited to participate
at every major milestone review. At each of these reviews the design and
processes will be documented at the appropriate fidelity for assessment
in verifying that the requirements of NPG 8705.2, as indicated in the
Human Rating Plan Volume I, are being followed.

The HRP in Volume II will define the tasks to be performed in order to
verify the requirements from the NPG 8705.2. Verification to the design
will be shown at every major milestone review and at each of the Design
Certification Reviews (DCR). Along with the DCR, a System Acceptance
Review will provide verification that all the processes have been met
and the proper data was attained and found to be acceptable for
proceeding to Flight Readiness. Prior to the Flight Readiness Review,
the Program will submit a request to the AA for OSF for initial
certification. Certification for human rating will be acquired at the
Flight Readiness Review. A Certification for Flight Readiness (CoFR)
Process Document will be developed that contains in it the process to
certify the system for human rating.

To maintain the certification, the System will be operated and
maintained in an "as-certified" configuration. To sustain compliance
with certification the OSP System will establish a tracking system to
document the processing of system hardware and any modifications to
hardware that may result from process improvements. This certification
will extend through the life of the Program or until a modification is
made either as an upgrade or change in scope of mission or environment.
The Program will update the human-rating plan and identify all the
changes that impact system risk. The System will then require
recertification by the AA for OSF upon independent analysis of the
change.

##  {#section-1 .unnumbered}

# Decomposed Human Rating Requirements for the OSP System

The following sections contain the decomposed technical Human Rating
requirements that are binding on the OSP System. These requirements will
be a part of the total set of System Level Requirements of the Orbital
Space Plane System. This section combined with the requirements in the
System Requirements Document, International Space Station Interface
Requirements Document, and the OSP to ELV Interface Definition Document
make up the complete package of Level II System Requirements. It will be
the responsibility of the OSP Architecture Contractor to allocate the
requirements to the various pieces in the System. If the allocation
contains a need for modification to an existing interface or element
within the System, this will be brought to the Program Manager's
attention for approval and possible negotiations with the Program
controlling the interface or element in the System.

## Aerospace Design Standards

\[HRR 100\] Upon approval from the OSP Program, the System shall
incorporate the (contractor) tailored NASA Standard 3000 document into
the design of the system for all micro-gravity and zero-G human system
interfaces including those required for on-orbit maintenance.

\[HRR 110\] Upon approval from the OSP Program, the System shall
incorporate the contractor tailored MIL STD 1472 and NASA/TM-2002-210785
documents into the design of the system for all flight human system
interfaces utilized during ground processing, maintenance, and
operations as tailored for a specific program.

\[HRR 120\] Upon approval from the OSP Program, the System shall
incorporate the tailored JPG 8080.5 document into the design of the
system for design, manufacture, and test.

\[HRR 130\] Crew habitability and life support systems shall comply with
JSC 26882, "NASA Space Flight Health Requirements Document."

## System Safety and Reliability

### System Safety

\[HRR 300\] If a hazard cannot be eliminated, the System shall be
designed to preclude the occurrence of a hazard or to negate or reduce
the likelihood and effect of the hazard.

### Failure Tolerance and Reliability

\[HRR 500\] The System shall be designed so that no two failures shall
result in permanent disability or loss of life, unless it can be
demonstrated to the Program that:

> 1\) Two-failure tolerance is either impractical or negatively impacts
> overall system reliability, and
>
> 2\) Test data, hazard analyses, and comprehensive risk analyses
> together provide certainty that the system will have a very high
> reliability without two-failure tolerance.

\[HRR 510\] The System shall be designed so that neither two human
errors during operation or in-flight maintenance nor a combination of
one human error and one failure shall result in permanent disability or
loss of life, unless it can be demonstrated to the Program that:

> 1\) Error prevention is either impractical or negatively impacts
> overall system reliability, and
>
> 2\) Test data and comprehensive risk analyses together provide
> certainty that the system will provide personnel with the capability
> to detect and recover from errors prior to significant injury or
> death.

\[HRR 520\] The System shall not consider emergency systems (e.g., fire
suppression, crew escape) as a method to satisfy failure tolerance
requirements. Therefore, no two failures (as defined in HRR500) shall
preclude the crew's safe return to earth inside the spacecraft. However,
these emergency systems may be utilized in evaluation of failure
mitigation and in reducing probability of loss of life.

\[HRR 530\] The System shall be designed so that the interaction of the
components, operating as specified (including software), does not result
in a permanent disability or loss of life.

\[HRR 540\] The System shall assess the use of dissimilar redundancy in
the design of critical functions, as a defense against common cause
failure.

### Crew Survival

\[HRR 600\] The System shall provide an indication of a failure of a
critical system/component, including fault detection and isolation, and
the means to preclude a catastrophic safety risk to the flight crew for
all critical flight systems.

\[HRR 610\] The System shall assure accessibility to vital equipment,
such as, but not limited to, spacecraft compartment pressurization, life
support, and emergency systems, necessary for the space flight system to
recover from an emergency situation.

## Abort and Crew Escape

\[HRR 700\] The System shall provide the capability for rapid crew and
ground personnel egress during all pre-launch activities.

\[HRR 710\] The System shall provide the capability for crew survival
and recovery, from the time the hatch is closed on the launch pad until
a safe, sustainable (min. 24 hours) orbit is achieved, using

> 1\. A combination of abort and crew escape, or
>
> 2\. Abort, provided that during the return phase of an ascent abort,
> the spacecraft is capable of returning the crew safely to Earth
> without active attitude control and this capability is not used to
> meet the failure tolerance requirements.

\[HRR 720\] The System shall provide the capability for crew survival
and recovery during re-entry and landing using,

> 1\. A combination of abort and crew escape, or
>
> 2\. Abort, provided that during re-entry, the spacecraft is capable of
> returning the crew safely to Earth without active attitude control and
> this capability is not used to meet the failure tolerance
> requirements.

\[HRR 730\] Crew survival and recovery during the unmated orbit phase
shall be provided by the capability for the crew to rapidly target and
execute a de-orbit burn to a safe landing site.

\[HRR 740\] The System shall provide the capability for rapid crew
egress post landing.

Since the OSP spacecraft will launch on an ELV, the primary concern on
ascent is to ensure that the crew will survive a booster
malfunction/failure. This can be accomplished by separating the
spacecraft from the booster (abort) or by separating the crew from
spacecraft and booster (crew escape). Separating the spacecraft from the
booster (abort) on the launch pad or early in the ascent phase will
require some type of separation system (e.g. escape tower, separation
motors, etc). While this is technically not "crew escape", it meets the
intent of the NPG escape requirement.

Once the spacecraft has separated from the booster, it is preferable for
the crew to remain in the spacecraft (protected from the environment) to
take advantage of the vehicle failure tolerance capability. If the
spacecraft can safely return the crew to earth on an uncontrolled
trajectory (passive return), there is no compelling reason for the crew
to leave the spacecraft. The landing deceleration system for this type
of spacecraft must have fault tolerance for the nominal return mission
and offers more protection than an escape system, which requires zero
fault tolerance. Also, since the passive return capability may not be
used to meet fault tolerance requirements, the crew is provided an
additional level of protection that covers the entire return envelope
(unlike many escape systems). Therefore, a spacecraft with passive
return capability is inherently safer than a vehicle that relies on crew
escape for the uncontrolled re-entry scenario.

## Flight Termination

\[HRR 800\] For flight termination, the System shall include design
features, which allow sufficient time for safe abort or crew escape
prior to termination activation.

## Proximity Operations

\[HRR 900\] At a safe distance within the ISS approach ellipsoid, the
autonomously approaching spacecraft shall permit safety-critical
commanding from the ISS, including the abilities to station-keep,
separate, and breakout from the proximity operations at any time,
without violating the design and operational requirements of the ISS.

\[HRR 910\] The System shall provide a manual capability to monitor and
conduct proximity operations, docking, and undocking.

## Human-In-The-Loop Requirements:

### General Requirements

\[HRR 1100\] The crew shall be provided the capability to monitor and
operate the vehicle appropriate to the flight phase, system, and
function.

\[HRR 1110\] The System shall provide the capability to monitor its
health and status for all phases of operations.

\[HRR 1120\] The System shall have the capability to assess and identify
degradation(s) requiring an action.

\[HRR 1130\] The System shall provide onboard health and status to the
crew.

\[HRR 1140\] The System shall provide health and status to the control
center(s).

\[HRR 1150\] The system shall allow crew and ground intervention into
vehicle performance appropriate to the flight phase, system, and
function.

\[HRR 1160\] The system shall provide feedback of crew commands to the
crew and the ground.

\[HRR 1170\] The System shall provide the crew with the capability to
reverse or correct inputs where feasible.

### Minimum Crew Intervention Requirements

\[HRR 1200\] For missions where the spacecraft is crewed, the System
shall provide the capability for manual control of the vehicle flight
path and attitude, during orbit, re-entry and landing, where vehicle
structural, thermal, and performance margins allow.

\[HRR 1210\] The system shall provide the capability for human override
of spacecraft software and automation.

\[HRR 1215\] The system shall not adversely impact vehicle safety when
transitioning from software automation to manual control.

\[HRR 1220\] The System shall provide the crew the capability for
control of vehicle functions critical for safety of flight.

\[HRR 1230\] The System shall provide the crew with the capability to
monitor and control the habitable environment.

\[HRR 1240\] The System shall provide the crew the capability to select
and initiate abort modes.

\[HRR 1250\] The crew shall have the capability to initiate the escape
sequence.

\[HRR 1260\] The System shall provide ground personnel with a capability
to safe the crew escape system.

\[HRR 1270\] The crew and launch/mission control teams shall be provided
with the capability to disable/inhibit and re-enable the automated
initiation of the abort and crew escape systems.

\[HRR 1275\] The System shall provide the crew with the capability to
safe and arm the crew escape system while suited and restrained in the
launch and reentry positions.

\[HRR 1280\] The flight crew should be able to override automatic
initiation sequences.

\[HRR 1290\] The safety of the crew shall not depend on communication
with or real-time support from the ground or ISS.

\[HRR 1300\] Crew interactions with interfaces and all tasks required of
the crew shall be designed to meet a workload rating of 3 or better on
the Bedford Workload scale (Figure 4-1), or the Modified Cooper-Harper
Scale, or equivalent, workload scales used to evaluate flight crew
workload.

\[HRR 1310\] During periods of human-in-the-loop flight path and
attitude control, the vehicle shall exhibit Level I handling qualities
as defined by the Cooper-Harper Rating Scale, or equivalent.

\[HRR 1320\] The overall system and mission design, including task
design, procedures, and scheduling, shall not adversely affect the
ability of the crew to successfully operate spacecraft systems requiring
human interaction.

![](media/image1.wmf)

[]{#__RefHeading___Toc50537654 .anchor}FIGURE 4-1. Example of workload
rating scale.

![](media/image1.wmf)

[]{#__RefHeading___Toc50537656 .anchor}FIGURE 4-2. Modified
Cooper-Harper Rating Scale

##  {#section-2 .unnumbered}

#  Appendix A: Definitions {#appendix-a-definitions .unnumbered}

**Abort**: In the event of an anomaly that precludes mission
continuance, the safe return to Earth of the crew inside the spacecraft.
Safe recovery of the crew is mandatory. The capability to recover and,
if applicable, re-use the spacecraft is governed by the vehicle failure
tolerance requirements in the System Requirements Document. On re-entry,
"mission continuance" refers to the capability of the spacecraft to
safely land at the targeted site.

**Ascent:** The time from ELV liftoff to spacecraft separation

**Breakout:** During proximity operations, the ability to maneuver one
or more vehicles to a safe separation distance.

**Catastrophic hazard:** Any condition that may cause a disabling or
fatal personnel injury, or cause loss of one of the following: the OSP,
Orbiter, ISS, other visiting vehicles, or major ground facility. For
safety failure tolerance considerations, loss of the ISS is limited to
those conditions resulting from failures or damage to elements of the
ISS that render the ISS unusable for further operations, even with
contingency repair or replacement of hardware, or which render the ISS
in a condition which prevents further rendezvous and docking operations
with ISS launch elements.

**Certification**: The comprehensive evaluation of the technical and
non-technical features of a system and other safeguards, made as a part
of and in support of the accreditation process, to establish the extent
to which a particular design and implementation meets a set of specified
requirements.

**Crew:** Any human onboard the spacecraft after the hatch is closed for
flight or onboard the spacecraft during flight.

**Crew Escape:** 1. The safe return to Earth of the crew in the event of
an anomaly that requires the crew to exit the spacecraft using an escape
system (e.g. extraction, ejection, escape pod) or,

> 2\. The safe return to Earth of the crew inside a crew compartment
> that is no longer an integral part of the spacecraft element designed
> for nominal re-entry and landing.

**Crew Survival:** Capability and ability to keep the crew alive.

**Critical functions**: Capabilities or functions that are essential to
the safety of the public, crew, passengers, and/or vehicle.

**Critical software**: any software component whose failure or
unanticipated performance could lead to the loss of the crew and
passengers or space flight system. This includes the flight software as
well as ground software that can affect flight safety.

**Critical system**: A system is assessed as critical if loss of overall
system function or improper performance of a system function could
result in loss of life, loss of vehicle, or damage to a vehicle system.

**Deviation:** A variance that authorizes departure from a particular
safety requirement where the intent of the requirement is being met
through alternate means that provide an equivalent level of safety.

**Emergency Systems:** Safeguards against hazardous situations that
directly affect the crew that would be used only for the prevention of
loss-of-life. For example, fire suppression systems and crew escape
systems. Systems, which are used to execute an abort, are not considered
emergency systems.

**Expendable Launch Vehicle (ELV):** The Atlas V or Delta IV booster and
upper stage elements of the System used to launch the OSP into LEO

**Graceful degradation**: The combination of system architecture,
hardware design, and mission design that result in gradual reduction in
performance following failures of hardware or software, with the result
that multiple failures can be tolerated with minimum impact to mission
success.

**Hazard Analyses:** Identification and evaluation of existing and
potential hazards and the recommended mitigation for the hazard sources
found.

**Health & Status Data:** Data, including Emergency, Caution and Warning
data, that can be analyzed or monitored describing the ability of the
system or system components to meet their performance requirements.

**Human health management and care**: The set of activities, procedures
and systems that provides, (1) environmental monitoring and human health
assessment, (2) health maintenance and countermeasures, and (3) medical
intervention for the diagnosis and treatment of injury and illness.

**Human performance**: The physical and mental activity required of the
crew and other participants to accomplish mission goals. This includes
the interaction with equipment, computers, procedures, training
material, the environment, and other humans.

**Human rating**: The certification that a system has been developed and
is capable of being operated in a manner appropriate for use by human
crews at minimal risk. Human-rated certification must include (1) human
safety, (2) human performance (both nominal and degraded states of
operation), and (3) human health management and care as applicable.

**Human-rating plan**: A formal document outlining the elements and
rationale for the human-rating process to be applied to a specific space
flight system from system requirements review to system disposal at end
of life.

**Human-rating process**: The process steps used to achieve a
human-rated system. These steps include human safety risk
identification, reduction, control, visibility, and program management
acceptance criteria. Acceptable methods to assess the risk to human
safety include qualitative and/or quantitative methods (as approved by
the Human-rating Review Authority (HRA)) such as Fault Tree Analysis,
Probabilistic Risk Assessment and Failure Modes and Effects Analysis.

**Human Rating Independent Review Team**: An independent group of
technical experts tasked with review and concurrence of the proposed
requirements, test plans, verification plans and other program elements
that constitute the basis for achieving and maintaining human rating.

**Human rated space system**: A space system that incorporates those
design features, operational procedures, and requirements necessary to
accommodate human participants such that:

a.  risks have been evaluated and either eliminated or reduced to
    acceptable levels;

b.  human performance and health management and care have been
    appropriately addressed such that the system has been certified to
    safely support human activities;

the capability to safely conduct human-tended operations has been
provided, including safe recovery from any credible emergency
situation**.**

**Impractical:** Impacts to cost, schedule, or performance that would
cause program to be cancelled and design for minimum risk items if
applicable

**Intervention Capability**: The ability of the crew to assert control
over certain spacecraft functions in nominal and off-nominal situations.

**Insight**: The ability of the crew to determine where the spacecraft
is, its condition, and what it is doing. Insight provides situational
awareness (SA) which is critical to the performance of the human
operator.

**Manual Control**: The ability of the crew to bypass nonessential
levels of automation and exert direct control of critical space flight
systems functions.

**Pressure Vessel:** A container designed primarily for pressurized
storage of gases or liquids.

**Primary Structure:** The main skeleton of the vehicle by which all
items are affixed to make a complete system.

**Programmatic:** The requirement will be met by a Program action to
perform a function at the program level. Plans will be developed by the
program on how this function will be performed and that plan will be
indicated in the comments section.

**Public**: All humans not participating in the space flight activity
who could be potentially affected by the function or malfunction of the
space flight system.

**Risk Analyses:** Process of qualitative risk categorization or
quantitative risk estimation, followed by the evaluation of risk
significance.

**Safety**: The minimization of risk from damage or harm to hardware,
software, facilities, or humans.

**Safety Critical**: Functions, features, systems, status, or inhibits
necessary to identify prevent or control a critical or catastrophic
hazard.

**Space Flight System:** A flight hardware and software system whose
flight profile is partially or completely outside of the Earth's
atmosphere.

**Spacecraft:** The System flight element that serves as the crew rescue
or crew transfer vehicle for ISS.

**System:** The aggregate of the ground segment, flight segment, and
workforce required for crew rescue and crew transport.

**Tailoring:** The documentation and approval of the adaptation of the
requirements of this document to specific program or project needs. The
results of this activity are documented in the Human-Rating Plan and
must be approved by the cognizant AA's.

**Technical:** The requirement is technical in nature and will be met by
passing it on to the Architecture Contractor as a requirement for
development of the system. Modification of the wording may be required
to be consistent with the OSP Level II requirements.

**Test data:** As a justification for lower failure tolerance means that
approved test results show no reduction in system reliability.

**Traceability**: The ability to trace requirements to a source that
provides sufficient information for successful implementation.

**Verification**: The process of proving or demonstrating that
requirements have been satisfactorily met through design and/or
operational elements.

**Very High Reliability:** Predicted probability of system failure
causing loss of crew meets LOC requirements.

# Appendix B: Acronyms {#appendix-b-acronyms .unnumbered}

#  {#section-3 .unnumbered}

AA Associate Administrator

AA for OSF Associate Administrator for the Office of Space Flight

AA for SMA Associate Administrator for Safety and Mission Assurance

CDR Critical Design Review

CHMO Chief Health and Medical Officer

CoFR Certificate of Flight Readiness

CSCI Computer Software Configuration Item

DoD Department of Defense

DRD Data Requirements Description

DRM Design Reference Mission

ELV Expendable Launch Vehicle

EVA Extra Vehicular Activity

FAA Federal Aviation Administration

FRR Flight Readiness Review

FSRB Flight Safety Review Board

GSRP Ground Safety Review Panel

HRA Human-rating Review Authority

HRP Human Rating Plan

IHA Integrated Hazard Analysis

IOC Initial Operating Capacity

IRD Interface Requirements Document

ISAT Inter-center System Analysis Team

ISO International Standards Organization

ISS International Space Station

IV&V Independent Verification and Validation

KSC Kennedy Space Center

LEO Low Earth Orbit

LOC Loss of Crew

LOM Loss of Mission

LOV Loss of Vehicle

LSP Launch Services Program

MWI Marshall Work Instruction

MPD Marshall Policy Directive

MPG Marshall Procedures and Guidelines

MSFC Marshall Space Flight Center

NASA National Aeronautics and Space Administration

NPD NASA Policy Directive

NPG NASA Procedures and Guidelines

OAT Office of Aerospace Technologies

OSF Office of Space Flight

OSP Orbital Space Plane

PDR Preliminary Design Review

PRA Probabilistic Risk Assessment

RFP Request For Proposal

SDR System Definition Review

SLI Space Launch Initiative

SMA Safety and Mission Assurance

SOW Statement of Work

SRD System Requirements Document

SRR System Requirements Review

SVP System Verification Plan

S/W Software

TBR To Be Resolved

TPS Thermal Protection System

# Appendix C: HRR NPG Compliance Matrix {#appendix-c-hrr-npg-compliance-matrix .unnumbered}

The following compliance matrix shows each of the requirements from
section 2.0 of the HRR NPG. Beside each requirement is a set of columns
that specify the area in the program where this requirement will be
complied. Those requirements with trades associated or tailored will
contain rationale for the trades or tailoring. These areas will be
further broken down in the plan to show what is being done to satisfy
the requirements. The meanings of each column is as follows:

Programmatic -- The requirement will be met by a Program action to
perform a function at the program level. Plans will be developed by the
program on how this function will be performed and that plan will be
indicated in the comments section.

Program Verification -- The requirement will be met by a Program level
verification method and documented in the System Verification Plan.

Deviation or Tailoring -- The Program believes that a requirement
applies, but cannot be accomplished or can be satisfied by alternate
methods, or the Program believes the requirement does not apply. A "D"
in the column stands for Deviate and a "T" in the Column stands for
Tailored.

Program Trade -- The Program believes the requirement can be satisfied
through alternate methods or tailored out but first must trade all
issues to develop a sound rationale for the deviation or tailoring.

Contractor Technical -- The requirement is technical in nature and will
be met by passing it on to the Architecture Contractor as a requirement
for development of the system. Modification of the wording may be
required to be consistent with the OSP Level II requirements.

Contractor SOW -- The requirement is programmatic in nature and will be
met by passing it on to the Architecture Contractor to develop plans and
procedures to meet the requirement.

Contractor Verification -- The requirement will be met in part or whole
by verification of some aspect of the system developed by the
Architecture Contractor.

Contractor Trade - The Program believes the requirement can be satisfied
through alternate methods or tailored out but first must trade all
issues to develop a sound rationale for the deviation or tailoring. The
trade is of such a nature that it will require the services of the
contractor to perform in part or in whole.

<table>
<colgroup>
<col style="width: 30%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 49%" />
</colgroup>
<tbody>
<tr class="odd">
<td><strong>NPG 8705.2 Compliance Matrix</strong></td>
<td colspan="4"><strong>OSP Program</strong></td>
<td colspan="4"><strong>OSP Contractor</strong></td>
<td></td>
</tr>
<tr class="even">
<td><strong>Requirements of the Human Rating Requirements and Guidelines
for Space Flight Systems Document</strong></td>
<td><blockquote>
<p>Programmatic</p>
</blockquote></td>
<td><blockquote>
<p>Verification</p>
</blockquote></td>
<td><blockquote>
<p>Deviation or Tailored</p>
</blockquote></td>
<td><blockquote>
<p>Trade</p>
</blockquote></td>
<td><blockquote>
<p>Technical</p>
</blockquote></td>
<td><blockquote>
<p>SOW</p>
</blockquote></td>
<td><blockquote>
<p>Verification</p>
</blockquote></td>
<td><blockquote>
<p>Trade</p>
</blockquote></td>
<td><strong>Rationale and Comments</strong></td>
</tr>
<tr class="odd">
<td><strong>Section 1.0</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>a. Develop the human-rating plan for all human space flight
program activities, based upon the unique mission goals, technical and
operational risk, other risk-management plan requirements, and other
specific characteristics of the program.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>Section 1.0 of This HRP Volume I States:</p>
<p>Throughout the Program Development, human rating will be an integral
part. The Program will develop the human rating plan for all human space
flight program activities, based upon the unique mission goals,
technical and operational risk, other risk management plan requirements,
and other specific characteristics of the program.</p></td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<ol start="2" type="a">
<li><p><strong>Integrate the human-rating plan into overall program
management planning and execution and decision-making processes,
including cost, schedule, performance, and other programmatic risks
consistent with NPG 7120.5, latest revision.</strong></p></li>
</ol></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>Human Rating is part of the Program in the development of the Human
Rating Plan, OSP-PLAN-022; Program Plan, OSP-PLAN-005; System
Requirements Document, MSFC-RQMT-3360; and the System Verification Plan,
OSP-PLAN-023</td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>c. Obtain approval of the program's human-rating plan by the
AA for OSF, the AA for SMA, and the CHMO during the program approval
process.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This will be accomplished by the initial approval of the HRP Volume
I (requirements) and Later Approval of HRP Volume II
(verification).</td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>d. Justify proposed tailoring and deviations from these
requirements. Tailoring and deviations may be implemented by the program
manager where sound technical rationale provides justification and it is
demonstrated that the tailoring and deviations do not significantly
increase risk to human occupants. The tailoring and deviations shall be
documented in the program human-rating plan, approved by the AA for OSF
and are subject to the concurrence from the AA for SMA and
CHMO.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>Section 1.1 of this HRP Volume I states:</p>
<p>Tailoring and deviations will be implemented by the Program where
sound technical rationale provide justification and it is demonstrated
that the tailoring and deviations do not significantly increase risk to
human occupants. The tailoring and deviations will be documented in this
plan, approved by the AAOSF and are subject to the concurrence from the
AASMA and the CHMO.</p></td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>e. Ensure that all deviations and waivers generated after the
program human-rating plan approval from NASA Headquarters are presented
at all program major milestone reviews.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>Section 3.7.3 of this HRP Vol. I states:</p>
<p>All deviations and waivers generated against the Human Rating
Requirements, after the program human-rating plan approval from NASA
Headquarters, are presented at all program major milestone
reviews.</p></td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>f. Ensure that compliance and verification processes have
clear traceability with all functional and performance design
requirements established in this document.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>Section 3.2 of HRP Volume I states:</p>
<p>A matrix has been established to show how the Program will comply
with each of the requirements as called out in section 2.0 of the NPG.
This matrix is documented in Appendix C of this Plan. As the Program
matures, the traceability to actual sections of documents, Data
Requirements, and Designs will be documented in Volume II of the
HRP.</p></td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>g. Ensure that issues, problems, and decisions regarding the
specification and achievement of human rating are elevated to
appropriate management levels using a formal management review process,
with an emphasis on risk management.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>The establishment of the Program Control Boards as indicated in
Section 3.7 shows how decisions will be elevated to the appropriate
management levels. This is further documented in the Risk Management
Plan, OSP-PLAN-009; and the Configuration Management Plan,
OSP-PLAN-040.</td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>h. Establish and utilize a continuous tracking method for
documenting and sustaining compliance with all human-rating requirements
after initial human-rating certification.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>Section 3.8 of HRP Volume I states:</p>
<p>To maintain the certification, the System will be operated and
maintained in an “as-certified” configuration. To sustain compliance
with certification the OSP System will establish a tracking system to
document the processing of system hardware and any modifications to
hardware that may result from process improvements.</p></td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>i. Use systems engineering, safety, health, and management
approaches in which all aspects of design, development, fabrication,
operations, maintenance, and disposal are considered in the human-rating
process. This should be accomplished by utilization of tools such as
failure modes and effects analyses, fault trees, hazard analyses,
maintainability analyses, reliability predictions, human error analysis,
and probabilistic risk assessments to identify, quantify, mitigate, and
manage hazards.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This is addressed in the Safety and Mission Success Plan,
OSP-PLAN-010, System Engineering Management Plan, OSP-PLAN-012, and the
Program Plan, OSP-PLAN-005. These plans lay out the systems engineering,
safety, health and management approaches for a human rated space flight
system.</td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>j. Demonstrate program compliance with the approved
human-rating and verification plans to ensure the flight system
certification is achieved and maintained.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement is satisfied with the development and approval
of the Human Rating Plan Vol. I &amp; II; OSP-PLAN-022, and the System
Verification Plan; OSP-PLAN-023.</p>
<p>This will also include a variety of DRDs that dictate to the
contractor the development of human rating documentation and
verification plans.</p></td>
</tr>
<tr class="even">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>k. Ensure that all records generated in the process of
complying with this document are managed and dispositioned in accordance
with NPG 1441.1, NASA Records Retention Schedules, latest
revision.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This requirement is satisfied by the Data Management;
OSP-PLAN-030</td>
</tr>
<tr class="odd">
<td><p><strong>1.5 The Program Manager shall:</strong></p>
<p><strong>l. Ensure that all performance data are archived to be
available for recertification of program human rating.</strong></p></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This requirement is satisfied by the Data Management;
OSP-PLAN-030</td>
</tr>
<tr class="even">
<td><strong>Section 2.0</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>2.2.1 The space flight system shall be designed, built,
inspected, tested, and certified specifically addressing the
requirements for human rating as defined in this document.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a paragraph in the
Statement of Work that will state:</p>
<p>The Contractor shall design, build, inspect, test, and certify the
System specifically addressing the requirements for human rating.</p>
<p>And the development of this Human Rating Plan, OSP-PLAN-022 and the
System Verification Plan, OSP-PLAN-023.</p></td>
</tr>
<tr class="even">
<td><strong>2.2.2 The design of the space flight system shall address
the aspects of human rating beginning in the formulation
phase.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a paragraph in the
Statement of Work that will state:</p>
<p>The Contractor shall address the aspects of human rating beginning in
the formulation phase.</p>
<p>And the development of this Human Rating Plan, OSP-PLAN-022 and the
System Verification Plan, OSP-PLAN-023.</p></td>
</tr>
<tr class="odd">
<td><strong>2.2.3 The space flight system design shall incorporate NASA
Standard 3000, “Manned Systems Integration Standards” for all
micro-gravity and zero-G human system interfaces including those
required for on-orbit maintenance.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td><strong>X</strong></td>
<td><p>The document as written contains many items that are admittedly
out of date and not applicable to the present Program. In order to have
a better document to design from, the Program has chosen to perform the
following steps:</p>
<p>A Data Requirement Description in the Statement of Work that will
state:</p>
<p>The Contractor shall evaluate and tailor all applicable sections of
NASA Standard 3000 as identified in appendix D.</p>
<p>The Contractor shall document the evaluation of NASA Standard 3000
with justification or rationale for any requirement altered from the
applicable document.</p>
<p>And a requirement in section 4.0 that states:</p>
<p>[HRR 100] Upon approval from the OSP Program, the System shall
incorporate the (contractor) tailored NASA Standard 3000 document into
the design of the system for all micro-gravity and zero-G human system
interfaces including those required for on-orbit maintenance.</p></td>
</tr>
<tr class="even">
<td><strong>2.2.4 The space flight system shall incorporate MIL STD
1472, DOD Design Criteria Standard – Human Engineering and
NASA/TM-2002-210785, “Guidelines and Capabilities for Designing Human
Missions”,</strong> <strong>for all flight human system interfaces
utilized during ground processing, maintenance, and operations as
tailored for a specific program.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td><strong>X</strong></td>
<td></td>
<td><strong>X</strong></td>
<td><p>The documents as written contain many items that are admittedly
out of date or are not applicable to the present Program. In order to
have a better document to design from, the Program has chosen to perform
the following steps:</p>
<p>A Data Requirement Description in the Statement of Work that will
state:</p>
<p>The Contractor shall evaluate and tailor all applicable sections of
MIL STD 1472 and NASA/TM-2003-210785 as identified in appendix E.</p>
<p>The Contractor shall document the evaluation of MIL STD 1472 and
NASA/TM-2002-210785 with justification or rationale for any requirement
altered from the applicable document.</p>
<p>And a requirement in section 4.0 that states:</p>
<p>[HRR 110] Upon approval from the OSP Program, the System shall
incorporate the (contractor) tailored MIL STD 1472 and
NASA/TM-2003-210785 documents into the design of the system for all
flight human system interfaces utilized during ground processing,
maintenance, and operations as tailored for a specific program.</p></td>
</tr>
<tr class="odd">
<td><strong>2.2.5 Crew habitability and life support systems shall
comply with JSC 26882, “NASA Space Flight Health Requirements
Document.”</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 130] Crew habitability and life support systems shall comply
with JSC 26882, “NASA Space Flight Health Requirements Document.”</p>
<p>A Medical Operations Requirements Document will be generated for the
Program. The MORD will act as guidance to the contractor in development
of the Level III System Specification. The Space Flight Health
Requirements that were considered applicable to the program by the
flight surgeons in JSC-SA have been incorporated into the System
Requirements Document.</p></td>
</tr>
<tr class="even">
<td><strong>2.3.1 The space flight system design, manufacture, and test
shall comply with JSCM 8080.5, “JSC Design and Procedural Standards
Manual”.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td><strong>X</strong></td>
<td><p>The document as written contains many items that are admittedly
out of date and not applicable to the present Program. In order to have
a better document to design from, the Program has chosen to perform the
following steps:</p>
<p>A Data Requirement Description in the Statement of Work that will
state:</p>
<p>The Contractor shall evaluate JPG 8080.5 for applicability to the
design.</p>
<p>The Contractor shall document the evaluation of JPG8080.5 with sound
technical justification or rationale for any requirement altered from
the applicable document.</p>
<p>And the requirement in section 4.0 that states:</p>
<p>[HRR 120] Upon approval from the OSP Program, the System shall
incorporate the contractor tailored JPG 8080.5 document into the design
of the system for design, manufacture, and test.</p></td>
</tr>
<tr class="odd">
<td><strong>2.3.2 The space flight system design, manufacture, and test
should comply with applicable military and aerospace design
standards.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td>An Applicable Documents List will be placed into the Statement of
Work. This list will contain applicable military and aerospace design
standards. The Program intends to perform tailoring on any applicable
document to produce standards that are inline with the design of the OSP
System.</td>
</tr>
<tr class="even">
<td><strong>2.4.1 A comprehensive flight test program shall be completed
to validate predicted flight environments, flight control
characteristics, critical design parameters, preflight analysis, and
analytical math models, to verify the safe flight envelope and to
provide a performance data base prior to the first operational
flight.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td><p>This requirement shall be satisfied by a Verification Data
Requirement Description in the Statement of Work that will state:</p>
<p>The Contractor shall complete a comprehensive flight test program to
validate predicted flight environments, flight control characteristics,
critical design parameters, preflight analysis, and analytical math
models, to verify the safe flight envelope and to provide a performance
database prior to the first operational flight.</p>
<p><mark></mark></p>
<p>This is also stated in the System Verification Plan, OSP-PLAN-023
that is levied as a requirements document on the Contractor.</p></td>
</tr>
<tr class="odd">
<td><strong>2.4.2 A comprehensive flight test program shall be defined
as either a flight test program conducted across the entire mission
profile and/or a series of tests encompassing all elements of the
mission profile under actual or high fidelity simulated
conditions.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td><p>This requirement shall be satisfied by a Verification Data
Requirement Description in the Statement of Work that will state:</p>
<p><mark></mark></p>
<p>The Contractor shall define a comprehensive flight test program as
either a flight test program conducted across the entire mission profile
and/or a series of tests encompassing all elements of the mission
profile under actual or high fidelity simulated conditions.</p>
<p>This is also stated in the System Verification Plan, OSP-PLAN-023
that is levied as a requirements document on the Contractor..</p></td>
</tr>
<tr class="even">
<td><strong>2.5.1.1 In accordance with</strong> <strong>NPG 8715.3,
“NASA Safety Manual,” latest revision, a systematic program for system
safety and human health shall be established to identify, analyze,
track, and eliminate or mitigate hazards throughout the lifetime of the
program.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall establish a systematic program for system safety
and human health to identify, analyze, track, and eliminate or mitigate
hazards throughout the lifetime of the program.</p>
<p>The Program shall establish the systematic program for system safety
and human health in the Safety and Mission Assurance Plan,
OSP-PLAN-010.</p>
<p>For System Safety, the Program has the responsibility for defining
and controlling the system safety process. The contractor(s) has the
responsibility for establishing their own processes, which feed the
government defined processes. The program has the responsibility to
provide oversight of the contractor’s implementation of institutional
health and safety (i.e. OSHA). The contractor has the responsibility for
their own institutional health and safety processes.</p></td>
</tr>
<tr class="odd">
<td><strong>2.5.1.2 If a hazard cannot be eliminated, the space flight
system shall be designed to preclude the occurrence of a hazard or to
negate or reduce the likelihood and effect of the hazard.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 300] If a hazard cannot be eliminated, the System shall be
designed to preclude the occurrence of a hazard or to negate or reduce
the likelihood and effect of the hazard.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.1.3 The program shall establish a rigorous health,
safety and reliability process using qualitative and quantitative tools
(e.g., Hazards Analysis, Fault Tree Analysis, Probabilistic Risk
Assessment, Human Error Analysis and Failure Modes and Effects Analysis)
for risk identification and control including a formal review
process.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall establish a rigorous health, safety and
reliability process using qualitative and quantitative tools (e.g.,
Hazards Analysis, Fault Tree Analysis, Probabilistic Risk Assessment,
Human Error Analysis and Failure Modes and Effects Analysis) for risk
identification and control<strong>.</strong></p>
<p>The Program shall satisfy this requirement with the development of
the Safety and Mission Assurance Plan, OSP-PLAN-010, the Risk Management
Plan, OSP-PLAN-009, and the OSP System Reliability, Maintainability, and
Supportability Plan, OSP-PLAN-011.</p></td>
</tr>
<tr class="odd">
<td><strong>2.5.2.1 Software safety shall be an integral part of the
overall system safety and software development efforts associated with
human rated space flight systems.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall make software safety an integral part of the
overall system safety and software development efforts associated with
human rated space flight systems.</p>
<p>The Program shall satisfy this requirement with the development of
the Safety and Mission Assurance Plan, OSP-PLAN-010, the Risk Management
Plan, OSP-PLAN-009, and the OSP System Reliability, Maintainability, and
Supportability Plan, OSP-PLAN-011.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.2.2 The requirements in NASA Standard 8719.13A,
“Software Safety NASA Technical Standard,” or equivalent, shall be
followed to implement a systematic approach to software safety as an
integral part of the overall system safety program.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td><strong>X</strong></td>
<td><p>This requirement shall be satisfied by Data Requirement
Descriptions in the Statement of Work:</p>
<p>DRDs that support software development and safety are as
followed:<br />
SW-IDD: Interface Design Description<br />
SW-IRD: Interface Requirements Specification<br />
SW-SCMP: Software Configuration Management Plan<br />
SW-SDD: Software Design Description<br />
SW-SDP: Software Development Plan<br />
SW-SPS: Software Product Specification<br />
SW-SRS: Software Requirements Specification<br />
SW-STD: Software Test Description<br />
SW-STP: Software Test Plan<br />
<br />
Software Quality Assurance Plan following DRDs are:<br />
SW-MSMR: Mission Software Metrics Report (in the works)<br />
SW-STR: Software Test Report<br />
SW-SUM: Software User Manual<br />
SW-SVD: Software Version Description</p>
<p>The Program shall satisfy this requirement with the development of
the Safety and Mission Success Plan, OSP-PLAN-010.</p></td>
</tr>
<tr class="odd">
<td><strong>2.5.3.1 All human rated space flight systems shall be
designed so that no two failures shall result in permanent disability or
loss of life.</strong></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>The Program felt that the requirement in section 2.5.3.3 is a
continuation of this requirement and has added it to the existing
requirement. The resultant requirement is in section 4.0 of this Plan
and is tailored as follows, which satisfies the intent.</p>
<p>[HRR 500] The System shall be designed so that no two failures shall
result in permanent disability or loss of life, unless it can be
demonstrated to the Program that:</p>
<p>1) Two-failure tolerance is either impractical or negatively impacts
overall system reliability, and</p>
<p>2) Test data, hazard analyses, and comprehensive risk analyses
together provide certainty that the system will have a very high
reliability without two-failure tolerance.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.3.2 All human rated space flight systems shall be
designed so that neither two human errors during operation or in-flight
maintenance nor a combination of one human error and one failure shall
result in permanent disability or loss of life.</strong></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>The Program felt that the requirement in section 2.5.3.4 is a
continuation of this requirement and has added it to the existing
requirement. The resultant requirement is in section 4.0 of this Plan
and is tailored as follows, which satisfies the intent.</p>
<p>[HRR 510] The System shall be designed so that neither two human
errors during operation or in-flight maintenance nor a combination of
one human error and one failure shall result in permanent disability or
loss of life, unless it can be demonstrated to the Program that:</p>
<p>1) Error prevention is either impractical or negatively impact
overall system reliability, and</p>
<p>2) Test data and comprehensive risk analyses together provide
certainty that the system will provide personnel with the capability to
detect and recover from errors prior to significant injury or
death.</p></td>
</tr>
<tr class="odd">
<td><p><strong>2.5.3.3 The program shall consider tailoring requirement
2.5.3.1 if:</strong></p>
<blockquote>
<p><strong>1) It can demonstrate that two-failure tolerance is either
impractical or negatively impacts overall system reliability,
and</strong></p>
<p><strong>2) Test data, hazard analyses, and comprehensive risk
analyses together provide certainty that the system will have a very
high reliability without two-failure tolerance.</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>Requirement 2.5.3.1 has been tailored to include the intent of this
requirement. The resultant text is found in [HRR500]</td>
</tr>
<tr class="even">
<td><p><strong>2.5.3.4 The program shall consider tailoring requirement
2.5.3.2 when:</strong></p>
<blockquote>
<p><strong>1) Error prevention has been demonstrated to be either
impractical or negatively impact overall system reliability,
and</strong></p>
<p><strong>2) Test data and comprehensive risk analyses demonstrate that
the system will provide personnel with the capability to detect and
recover from errors prior to significant injury or death.</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>Requirement 2.5.3.2 has been tailored to include the intent of this
requirement. The resultant text is found in [HRR510]</td>
</tr>
<tr class="odd">
<td><strong>2.5.3.5 All human rated space flight systems shall be
designed so that the interaction of the components operating as
specified (including software) does not result in a permanent disability
or loss of life.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 530] The System shall be designed so that the interaction of the
components, operating as specified (including software), does not result
in a permanent disability or loss of life.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.3.6 Emergency systems (e.g., fire suppression, crew
escape) shall not be considered to satisfy failure tolerance
requirements; however, these systems may be utilized in evaluation of
failure mitigation and in reducing probability of loss of
life.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 520] The System shall not consider emergency systems (e.g., fire
suppression, crew escape) as a method to satisfy failure tolerance
requirements. Therefore, no two failures (as defined in HRR500) shall
preclude the crew’s safe return to earth inside the spacecraft. However,
these emergency systems may be utilized in evaluation of failure
mitigation and in reducing probability of loss of life.</p>
<p>It is also understood that although crew escape cannot be considered
a leg of redundancy, abort can be used as one of the legs against loss
of life and permanent disability.</p></td>
</tr>
<tr class="odd">
<td><strong>2.5.3.7 As a defense against common cause failure, use of
dissimilar redundancy shall be assessed in the design of critical
functions.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 540] The System shall assess the use of dissimilar redundancy in
the design of critical functions, As a defense against common cause
failure.</p>
<p>The Program shall review the results to ensure that a proper
assessment has been completed by the Contractor.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.4.1 As part of the design process, program management
(with approval from the CHMO, AA for OSF and AA for SMA) shall
establish, assess, and document the program requirements for an
acceptable life cycle cumulative probability of safe crew and passenger
return. This probability requirement can be satisfied through the use of
all available mechanisms including nominal mission completion, abort,
safe haven, or crew escape.</strong></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This flows out of the existing Level 1 requirements and are
calculated on a per mission basis. The contractor will have to show that
they meet the number determined from Level 1 PRA requirement. This
requirement has been flowed into the Level II SRD as 1/400 for crew
transfer and 1/800 for crew rescue. The Program will be assessed against
the Level I requirements through metrics defined in the Mission
Assessment Plan, OSP-PLAN-006.</td>
</tr>
<tr class="odd">
<td><strong>2.5.4.2 The cumulative probability of safe crew and
passenger return shall address all missions planned for the life of the
program, not just a single space flight system for a single
mission.</strong></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>The Level 1 requirement dictates on a per mission basis for
calculation of probability of risk.</td>
</tr>
<tr class="even">
<td><strong>2.5.4.3 A systems engineering model to estimate and allocate
component, subsystem, and human reliability factors shall be developed,
maintained, and used throughout the development of the
system.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall develop and maintain a systems engineering model
to estimate and allocate component, subsystem, and human reliability
factors and use this model throughout the development of the
system.</p></td>
</tr>
<tr class="odd">
<td><strong>2.5.4.4 All critical flight systems shall be designed to
provide an indication of a failure of a critical system/component,
including fault detection and isolation, and the means to preclude a
catastrophic safety risk to the flight crew.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 600] The System shall provide an indication of a failure of a
critical system/component, including fault detection and isolation, and
the means to preclude a catastrophic safety risk to the flight crew for
all critical flight systems.</p></td>
</tr>
<tr class="even">
<td><strong>2.5.4.5 All space flight systems shall be designed to assure
accessibility to vital equipment involved in immediate and follow-up
action to effect emergency recovery of the space flight system, such as,
but not limited to spacecraft compartment pressurization, life support,
and emergency systems.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 610] The System shall assure accessibility to vital equipment,
such as, but not limited to, spacecraft compartment pressurization, life
support, and emergency systems, necessary for the space flight system to
recover from an emergency situation.</p>
<p>The requirements as stated was difficult to understand. It has been
reworded to meet the intent of the requirement in the NPG.</p></td>
</tr>
<tr class="odd">
<td><ol type="1">
<li><p><strong>The capability for rapid crew and occupant egress shall
be provided during all pre-launch activities.</strong></p></li>
</ol></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 700] The System shall provide the capability for rapid crew and
ground personnel egress during all pre-launch activities.</p>
<p>An additional requirements was added for post landing.</p>
<p>[HRR 740] The System shall provide the capability for rapid crew
egress post landing.</p></td>
</tr>
<tr class="even">
<td><ol start="2" type="1">
<li><p><strong>The capability for crew and occupant survival and
recovery shall be provided on ascent using a combination of abort and
escape.</strong></p></li>
</ol></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 710] The System shall provide the capability for crew survival
and recovery, from the time the hatch is closed on the launch pad until
a safe, sustainable (min24 hours) orbit is achieved, using</p>
<p>1. A combination of abort and crew escape, or</p>
<p>2. Abort, provided that during the return phase of an ascent abort,
the spacecraft is capable of returning the crew safely to Earth without
active attitude control and this capability is not used to meet the
failure tolerance requirements.</p>
<p>Rationale:</p>
<p>HRP 710 differs from the NPG requirement for the following
reasons:</p>
<p>1. The NPG requirement refers to “ascent”. The HRP requirement
includes the vehicle on the pad with the crew inside (more stringent).
The HRP interprets the end of ascent as the vehicle safely on orbit
(most stringent possible interpretation).</p>
<p>2. Since the OSP spacecraft will launch on an ELV, the primary
concern on ascent is to ensure that the crew will survive a booster
malfunction/failure. This can be accomplished by separating the
spacecraft from the booster (abort) or by separating the crew from
spacecraft and booster (crew escape). Separating the spacecraft from the
booster (abort) on the launch pad or early in the ascent phase will
require some type of separation system (e.g. escape tower, separation
motors, etc). While this is technically not “crew escape”, it meets the
intent of the NPG escape requirement.</p>
<p>Once the spacecraft has separated from the booster, it is preferable
for the crew to remain in the spacecraft (protected from the
environment) to take advantage of the vehicle failure tolerance
capability. If the spacecraft can safely return the crew to earth on an
uncontrolled trajectory (passive return), there is no compelling reason
for the crew to leave the spacecraft. The landing deceleration system
for this type of spacecraft must have fault tolerance for the nominal
return mission and offers more protection than an escape system, which
requires zero fault tolerance. Also, since the passive return capability
may not be used to meet fault tolerance requirements, the crew is
provided an additional level of protection that covers the entire return
envelope (unlike many escape systems). Therefore, a spacecraft with
passive return capability is inherently safer than a vehicle that relies
on crew escape for the uncontrolled re-entry scenario.</p></td>
</tr>
<tr class="odd">
<td><ol start="3" type="1">
<li><p><strong>The capability for crew and occupant survival and
recovery shall be provided during all other phases of flight (including
re-entry and landing) using a combination of abort and escape, unless
comprehensive safety and reliability analyses indicate abort and escape
capability is not required to meet crew survival
requirements.</strong></p></li>
</ol></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirements in Section
4.0 of this Plan which state:</p>
<p>[HRR 720] The System shall provide the capability for crew survival
and recovery during re-entry and landing using,</p>
<p>1. A combination of abort and crew escape, or</p>
<p>2. Abort, provided that during re-entry, the spacecraft is capable of
returning the crew safely to Earth without active attitude control and
this capability is not used to meet the failure tolerance
requirements.</p>
<p>[HRR 730] Crew survival and recovery during the unmated orbit phase
(not mated to ISS) shall be provided by the capability for the crew,
acting autonomously, to rapidly target and execute a de-orbit burn to a
safe landing site somewhere on the Earth.</p>
<p>Rationale:</p>
<p>HRP 720 is more stringent than the corresponding NPG requirement,
which allowed for abort / escape to be eliminated by analysis.</p></td>
</tr>
<tr class="even">
<td><ol start="4" type="1">
<li><p><strong>Determinations regarding escape and abort shall be made
based upon comprehensive safety and reliability analyses across all
mission profiles.</strong></p></li>
</ol></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall make determinations regarding escape and abort
based upon comprehensive safety and reliability analyses across all
mission profiles.</p>
<p>The Program will review the results of the DRD submittal to ensure
that the Contractor has completed a proper assessment and approve the
assessment upon satisfaction that the data and results are accurate and
complete.</p></td>
</tr>
<tr class="odd">
<td><strong>2.7 Any flight termination system (e.g., range safety
system) for human rated launch vehicles shall include design features
(e.g., thrust termination), which allow sufficient time for safe human
escape prior to activation of the destruct system.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 800] For flight termination, the System shall include design
features, which allow sufficient time for safe abort or crew escape
prior to termination activation..</p>
<p>This is also captured in the ELV to OSP Interface Definition
Document, LSP-OSPDEV-001</p></td>
</tr>
<tr class="even">
<td><strong>2.8.1 Space flight systems operations in proximity to or
docking with a human space flight system shall comply with joint system
requirements (both space flight and operational).</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td>X</td>
<td></td>
<td></td>
<td>The development of the SSP 50677, “ISS/OSP IRD” will satisfy this
requirement. The document is an agreement of interfaces, both technical
and operability, between the OSP and ISS Programs. This IRD then forms a
part of the Level II requirements set.</td>
</tr>
<tr class="odd">
<td><strong>2.8.2. The autonomous approaching vehicle shall permit
safety-critical commanding from the human space flight system, including
the abilities to station-keep, separate, and breakout from the proximity
operations at any time, without violating the design and operational
requirements of the human space flight system.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 900] At a safe distance within the ISS approach ellipsoid, the
autonomously approaching spacecraft shall permit safety-critical
commanding from the ISS, including the abilities to station-keep,
separate, and breakout from the proximity operations at any time,
without violating the design and operational requirements of the
ISS.</p></td>
</tr>
<tr class="even">
<td><strong>2.8.3 Designs shall provide a manual capability to monitor
and conduct proximity operations, docking, and undocking.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 910] The System shall provide a manual capability to monitor and
conduct proximity operations, docking, and undocking.</p></td>
</tr>
<tr class="odd">
<td><strong>2.9.1 The program shall identify and document, in the Human
Rating Plan, a specific set of critical functions to ensure human safety
during each phase of the mission.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall identify and document critical functions to
ensure human safety during each phase of the mission.</p>
<p>The Program Office shall review the contractor provided list and
document it in the second volume of the HRP.</p></td>
</tr>
<tr class="even">
<td><strong>2.9.2 The program shall incorporate critical functions,
defined in the human rating plan, into the design documentation prior to
PDR.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall document critical functions into the design
prior to PDR.</p>
<p>The Program shall assure that the critical function have been
incorporated into the design at PDR.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.1 A crew station, or equivalent capability, shall be
provided to allow the crew to monitor and operate the vehicle
appropriate to the flight phase, system, and function.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1100] The crew shall be provided the capability to monitor and
operate the vehicle appropriate to the flight phase, system, and
function.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.2 The space flight system shall provide the flight crew
and ground crew with insight into vehicle performance, and the
capability for flight crew and ground crew intervention appropriate to
the flight phase, system, and function.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirements in Section
4.0 of this Plan which states:</p>
<p>[HRR 1110] The System shall provide the capability to monitor its
health and status for all phases of operations.</p>
<p>[HRR 1120] The System shall have the capability to assess and
identify degradation(s) requiring an action.</p>
<p>[HRR 1130] The System shall provide onboard health and status to the
spacecraft crew.</p>
<p>[HRR 1140] The System shall provide health and status to the control
center(s).</p>
<p>[HRR 1150] The system shall allow crew and ground intervention into
vehicle performance appropriate to the flight phase, system, and
function.</p>
<p>“Insight” is unverifiable. Plus the requirement as written contains
multiple independent requirements. The requirement has therefore been
separated and captured in the 5 requirements stated. While attached, the
health and status data will include both the spacecraft and the
ELV.</p></td>
</tr>
<tr class="odd">
<td>2.10.3 The space flight system shall provide feedback for all human
commands to the flight crew and, where applicable, ground crew.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1160]The system shall provide feedback of crew commands to the
crew and the ground.</p>
<p>The Contractor will exploit forever the word “all”. It is far too
open and unverifiable. The above requirement narrows the scope to what
the intent of the requirement is.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.4 The space flight system shall provide the flight crew
with the capability to reverse or correct inputs where
feasible.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1170]The space flight system shall provide the crew with the
capability to reverse or correct inputs where feasible.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.5.1a The control of vehicle flight path and attitude,
during dynamic phases of flight such as ascent and entry, shall be
provided by independently developed and redundant software
systems.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>This requirement has been allocated to Level III per the rationale
in <a href="#_Appendix_F:_">Appendix F</a>.</td>
</tr>
<tr class="even">
<td><strong>2.10.5.1.b The crew shall have the capability to select
between two independently developed versions of flight control software
systems during flight.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>X</td>
<td>This requirement has been allocated to Level III per the rationale
shown in 2.10.5.1.a.</td>
</tr>
<tr class="odd">
<td><strong>2.10.5.1.c On orbit and during entry, manual control of
vehicle flight path and attitude shall be provided, where vehicle
structural, thermal, and performance margins allow.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1200] For missions where the spacecraft is crewed, the System
shall provide the capability for manual control of the vehicle flight
path and attitude, during orbit, re-entry and landing, where vehicle
structural, thermal, and performance margins allow.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.5.1.d On ascent, manual control of the vehicle flight
path and attitude shall be provided where vehicle structural, thermal,
and performance margins allow.</strong></td>
<td></td>
<td></td>
<td>T</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td><p>The Program will tailor out this requirement for implementation
in the primary ELV control system. The Level I Operations concept has
required that ELVs will be used for the ascent stage of the OSP System.
However, this capability will be studied in combination with the other
proposed modifications to ELV in an ELV Safety Study.</p>
<p>Rationale:</p>
<p>Ref: Launch Services Program Office Document, “Impacts To Existing
ELV Designs Due To NPG 8705.2, Requirement 2.10.5.1d – Manual Control on
Ascent” dated 7 August 2003 (NASA Internal Use Only)</p>
<p>Based on the reference paper, the OSP Program has concluded that
modifications to the ELV to provide ascent manual control would increase
overall risk to human safety. This conclusion is based on the following
logic:</p>
<p>1. The modification (scenario ‘a’ is considered the only feasible
implementation) would require a <a href="#OLE_LINK1">redesign of the ELV
flight computer software</a>, <a href="#OLE_LINK2">a new autopilot mode
within that software</a>, and a <a href="#OLE_LINK1">hardware
modification to the flight computer</a>. [Ref. Scenario (a), Paragraph 3
&amp; 5.]</p>
<ol start="3" type="1">
<li><p><span id="OLE_LINK1" class="anchor"></span><em>The ELV flight
computer software interface between ELV guidance and ELV autopilot would
be modified to provide a "disconnect" capability that would effectively
disable the ELV guidance output commands to the ELV autopilot. There is
no history of implementing this type of modification on either ELV
family. Implementation will be highly intrusive to the existing software
architectures. ELV flight software programs are designed as tightly
integrated systems of interdependent function based code elements. These
programs have evolved into highly optimized designs tailored to meet the
demands of real-time flight and constraints of avionics hardware.
Specifically Atlas Guidance provides outputs to flight event sequencing,
booster throttle control, propellant utilization, antenna selection, and
steering interface. Two code elements, steering interface and attitude
error, perform front-end data management for the autopilot. Powered
phase autopilot receives simultaneous inputs from flight sequencing,
propellant utilization, and engine controller. Outputs are cascaded
through a series of code elements to select target hardware, implement
command formatting and coordinate timing. Introduction of an alternate
command path within such a highly interdependent system will pose
significant challenges and introduce risk points to nominal operation.
While the degree of integration within the flight software differs
significantly between the existing ELV providers the net difficulty is
comparable.</em></p></li>
</ol>
<p>{This means that the guidance and autopilot functions are tightly
coupled in the software. Separating the two functions is a fundamental
change to the software structure. The disconnect feature would require a
signal from the spacecraft (hardware) into the flight computer.}</p>
<ol start="5" type="1">
<li><p><span id="OLE_LINK2" class="anchor"></span><em>The rate and
attitude data that the pilot uses to guide the vehicle must be the same
as that used by the autopilot. For this reason, IMS synchronization data
must be sent from the launch vehicle IMS to the OSP flight computer.
This data consists of body rate and attitude information that is
displayed to aid the pilot in flying the vehicle.</em></p></li>
</ol>
<p>{However, level 1 handling qualities can not be achieved with this
type of autopilot. At a minimum, a rate command mode of the autopilot
would have to be developed. This results in more “unique” ELV flight
control software.}</p>
<p>2. This redesign would result in a unique OSP software configuration
that would negate the flight experience of the heritage software.</p>
<p>3. This unique software configuration would not benefit from
continued improvements (hardware and software) to the ELV flight control
system driven by the DOD customers.</p>
<p>4. The manual control implementation described in the reference paper
(scenario a) protects for only one very specific failure - a problem in
the guidance output to the autopilot. Furthermore, all the software,
including the guidance module, must continue to function “normally”
except for the guidance commands to the autopilot. [Ref. Scenario (a),
Paragraph 1.]</p>
<ol type="1">
<li><p><em>All existing ELV avionics hardware and software function
properly throughout the entire flight. The capability of the spacecraft
to successfully steer the ELV to a new target is entirely dependent upon
the ELV sub-systems to continue operating. This scenario does not in any
way address any capability of the spacecraft to successfully take
control of a failed ELV avionics sub-system. This capability only
addresses the capability of the spacecraft to take control of a properly
functioning ELV that is steering properly to an undesired target
(possibly due to some human or system error during pre-launch
flight-constant test and check-out).</em></p></li>
</ol>
<p>5. Given the ability to independently verify guidance targets and
algorithms prior to launch, the risk mitigated by manual control
capability is extremely small and does not justify the loss of a proven
flight control software system and the future advantages of commonality
with the DOD customers.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.5.2.a The design shall allow the human operator to
override higher-level software and automation (e.g., configuration
change, mode change, etc.), and the transition from software/automation
to manual control will not adversely impact vehicle
safety</strong>.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirements will be satisfied by the requirement in Section
4.0 of this Plan which state:</p>
<p>[HRR 1210] The system shall provide the capability for human override
of spacecraft software and automation.</p>
<p>[HRR 1215] The system shall not adversely impact vehicle safety when
transitioning from software automation to manual control</p></td>
</tr>
<tr class="even">
<td><strong>2.10.5.3.a The space flight system shall be designed to
provide the capability to the crew to monitor and control the vehicle
functions critical for safety of flight.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirements in Section
4.0 of this Plan which states::</p>
<p>[HRR 1110] The System shall provide the capability to monitor its
health and status for all phases of operations.</p>
<p>[HRR 1120] The System shall have the capability to assess and
identify degradation(s) requiring an action.</p>
<p>[HRR 1130] The System shall provide onboard health and status to the
crew.</p>
<p>[HRR 1140] The System shall provide health and status to the control
center(s).</p>
<p>[HRR 1220] The System shall provide the crew the capability for
control of vehicle functions critical for safety of flight.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.5.3.b The space flight system shall provide the
capability to the crew to monitor and control sub-systems that directly
interface with the crew and, therefore, could impact crew
effectiveness.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1230] The System shall provide the crew with the capability to
monitor and control the habitable environment.</p>
<p>Rationale:</p>
<p>The requirement as written was too vague to adequately verify. The
present requirement still meets the intent of the requirement but
narrows the scope to those areas defined by the NPG. The habitable
environment includes life support, lighting, and communications controls
that are needed to provide the crew with the appropriate environment to
perform required tasks to ensure human safety.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.5.4.a The flight crew shall be able to select and
initiate abort modes.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1240] The system shall provide the crew the capability to select
and initiate abort modes.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.5.5.a The flight crew shall be able to initiate the
escape sequence.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1250] The crew shall have the capability to initiate the escape
sequence.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.5.5.b The ground crew shall be able to disarm the
escape system by some mechanical means (pin, handle, lever lock, etc.)
which guarantees the system is safe.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1260] The System shall provide ground personnel with a
capability to safe the crew escape system.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.5.5.c The flight crew shall be able to disable/inhibit
the automated initiation of the crew escape system.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirements will be satisfied by the requirement in Section
4.0 of this Plan which state:</p>
<p>[HRR 1270] The crew and launch/mission control teams shall be
provided with the capability to disable/inhibit and re-enable the
automated initiation of the abort and crew escape systems.</p>
<p>[HRR 1275] The System shall provide the crew with the capability to
safe and arm the crew escape system while suited and restrained in the
launch and reentry positions.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.5.5.d The flight crew should be able to override
automatic initiation sequences.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1280] The crew shall be able to override automatic initiation
sequences.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.6 The safety of the flight crew shall not depend on
communication with or real-time support from the ground and other space
flight systems.</strong></td>
<td></td>
<td></td>
<td><strong>D</strong></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1290] The safety of the crew shall not depend on communication
with or real-time support from the ground or ISS.</p>
<p>Rationale:</p>
<p>The exclusion of “other space flight systems” is a tremendous design
driver to put additional systems on board the spacecraft to determine
it’s own location since GPS Satellites are also considered “space flight
systems”.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.7 Flight crew interactions with interfaces and all
tasks required of the flight crew shall be designed to meet a workload
rating of 3 or better on the Bedford Workload scale, or the Modified
Cooper-Harper Scale, or equivalent, workload scales used to evaluate
flight crew workload.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td><p>This requirement will be satisfied by the verification
requirement in Section 4.0 of this Plan which states:</p>
<p>[HRR 1300] Crew interactions with interfaces and all tasks required
of the flight crew shall be designed to meet a workload rating of 3 or
better on the Bedford Workload scale (Figure 4-1), or the Modified
Cooper-Harper Scale, or equivalent, workload scales used to evaluate
flight crew workload.</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.8 During periods of human-in-the-loop flight path and
attitude control, the vehicle shall exhibit Level I handling qualities
as defined by the Cooper-Harper Rating Scale, or
equivalent</strong>.</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td><p>This requirement will be satisfied by the verification
requirement in Section 4.0 of this Plan which states:</p>
<p>[HRR 1310] During periods of human-in-the-loop flight path and
attitude control, the vehicle shall exibit Level I handling qualities as
defined by the Cooper-Harper Rating Scale, or equivalent.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.9 Human factors engineering shall be applied to the
flight human-system interfaces for ground personnel and flight crew to
ensure the system will operate within human performance
capabilities.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Paragraph in the
Statement of Work that will state:</p>
<p>Human factors engineering shall be applied to the human-system
interfaces for ground personnel and crew. A human engineering team will
be implemented to ensure the system shall operate within human
performance capabilities and provide for a habitable environment for all
mission phases.</p>
<p>This will also be satisfied by the requirements for NASA-STD-3000 and
MIL-STD-1472 and the following DRs.</p>
<p>OSP DRD HE-001 Human Engineering Plan</p>
<p>OSP DRD HE-006 HE System Analysis Report</p>
<p>OSP DRD HE-007 HE Design Approach – Operator (Onboard and Ground
based)</p>
<p>OSP DRD HE-008 HE Design Approach – Maintainer (Ground and
In-flight)</p>
<p>OSP DRD HE-009 HE Critical Task Analysis Report</p></td>
</tr>
<tr class="odd">
<td><strong>2.10.10 The overall system and mission design, including
task design, procedures, and scheduling, shall not adversely affect the
ability of the crew to successfully operate the
spacecraft.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><p>This requirement will be satisfied by the requirement in Section
4.0 of this Plan which states:</p>
<p>[HRR 1320] The overall system and mission design, including task
design, procedures, and scheduling, shall not adversely affect the
ability of the crew to successfully operate spacecraft systems requiring
human interaction.</p>
<p>The Program will aid in the development of operational tasks,
procedures, and scheduling to fit within the abilities of the crew. This
will be accomplished within the human engineering and mission planning
elements of the Program.</p></td>
</tr>
<tr class="even">
<td><strong>2.10.11 Human performance criteria and system usability
requirements shall be established to assure crew safety.</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td><p>This requirement shall be satisfied by a Data Requirement
Description in the Statement of Work that will state:</p>
<p>The Contractor shall establish human performance criteria and system
usability requirements to assure crew safety.</p>
<p>The Program has established additional requirements in the System
Requirements Document, MSFC-RQMT-3363 and this Human Rating plan,
OSP-PLAN-022 that encompass human performance criteria and system
usability to assure crew safety. The Safety and Mission Success Plan,
OSP-PLAN-010 also contains information on how the Program will assure
crew safety.</p></td>
</tr>
<tr class="odd">
<td><strong>2.11.1. The program shall verify space flight systems
reliability and safety by test and analysis at the integrated system
level prior to the first flight with humans on board.</strong></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This requirement is satisfied by the System Verification Plan,
OSP-PLAN-023. The plan calls for several atmospheric tests and a minimum
of two orbital tests without crew on-board. One test will be designed to
rendezvous and mate with the ISS.</td>
</tr>
<tr class="even">
<td><strong>2.11.2 The program shall develop and implement a formal
process to maintain the human rating certification for the life of the
program.</strong></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>A Certificate of Flight Readiness (CoFR) Process document will be
developed that includes the process to maintain the human rating
certification. This will also contain how each flight test is certified
and the reviews that lead up to the certification. This plan will be
developed prior to CDR.</td>
</tr>
<tr class="odd">
<td><strong>2.11.3. Structured usability testing with crew involvement
shall be completed to verify that the system design meets the required
human performance criteria during system operation, maintenance, and
control.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td>This requirement is satisfied in the System Verification Plan,
OSP-PLAN-023.</td>
</tr>
<tr class="even">
<td><strong>2.11.4.1 The performance, security, and reliability of all
critical software across the entire flight envelope, as well as mission
functions, modes and transitions, shall be tested, verified, and
validated .</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td>This requirement is satisfied in the System Verification Plan,
OSP-PLAN-023.</td>
</tr>
<tr class="odd">
<td><strong>2.11.4.2 The testing facility shall use a flight-equivalent
avionics test-bed operating in a real-time, closed-loop test
environment.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td>This requirement is satisfied in the System Verification Plan,
OSP-PLAN-023.</td>
</tr>
<tr class="even">
<td><strong>2.11.4.3 Ground software shall be tested on the computer
platforms that will be used to support flights.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td>This requirement is satisfied in the System Verification Plan,
OSP-PLAN-023.</td>
</tr>
<tr class="odd">
<td><strong>2.11.4.4 The development of all flight and ground software
should comply with aerospace software development standards, such as
IEEE/EIA 12207 – Information Technology, Software Life-cycle Process
(12207.0 – S/W Life-cycle Processes, 1207.1 – Life-Cycle Data, and
12207.2 – Implementation Considerations).</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td>The Contractor System Specification will contain applicable
documents that will be evaluated by the Program and any additions that
are necessary for support of flight and ground software will be levied
on the contractor at the System Definition Review.</td>
</tr>
<tr class="even">
<td><strong>2.11.4.5 The program shall confirm the integrity of the
software design and testing process via independent verification and
validation methods (NPD 8730.4 “Software Independent Verification and
Validation (IV&amp;V) Policy.”).</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This requirement is satisfied in the System Verification Plan,
OSP-PLAN-023.</td>
</tr>
<tr class="odd">
<td><strong>2.11.4.6 The program shall verify that the critical
functions defined in the human rating plan have been implemented in the
design at CDR.</strong></td>
<td><strong>X</strong></td>
<td><strong>X</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>The Program shall verify that critical functions defined in the
human rating plan have been implemented in the design at CDR. Volume II
of the HRP will detail the various tasks that will be performed to
verify this requirement.</td>
</tr>
<tr class="even">
<td><strong>Section 3.0</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>3.1.2.2 Sustaining Certification - To maintain
certification, the space flight system must be operated and maintained
in the "as-certified" condition. The length of a certification shall be
documented in the program's Human-Rating Plan.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This is documented in Section 3.8 of HRP Volume I</td>
</tr>
<tr class="even">
<td><strong>3.1.2.3 Recertification - If the space flight system
undergoes major modifications or any changes to mission or environment,
the program manager must update the human-rating plan and identify all
the changes that impact system risk. The updated information must be
submitted to the AA for OSF, and the vehicle must be recertified prior
to flight.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This is documented in Section 3.8 of HRP Volume I</td>
</tr>
<tr class="odd">
<td><strong>3.3.3 All programs shall demonstrate compliance with these
human-rating requirements and obtain certification from the AA for OSF
prior to first operational flight and first flight with humans
onboard.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This is documented in Section 3.8 of HRP Volume I</td>
</tr>
<tr class="even">
<td><strong>3.3.4 All programs shall develop a process to ensure
compliance throughout the life of the program.</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>This is documented in Section 3.8 of HRP Volume I</td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

# Appendix D: NASA Standard 3000 Applicability Matrix {#appendix-d-nasa-standard-3000-applicability-matrix .unnumbered}

+-------------------+------+------------------------------------------+
| **MSIS Sections / | App  | **Alternatives/Comments**                |
| Titles**          | lica |                                          |
|                   | ble? |                                          |
+-------------------+------+------------------------------------------+
| Section 2 -       | #### |                                          |
| General           | #### |                                          |
| Requirements      | # Y  |                                          |
|                   | {#y  |                                          |
|                   | .unn |                                          |
|                   | umbe |                                          |
|                   | red} |                                          |
+-------------------+------+------------------------------------------+
| Section 3 -       | Y    | Use MSIS section 3 as is with the        |
| Anthropometry &   |      | following exceptions:                    |
| Biomechanics      |      |                                          |
|                   |      | \* 5th percentile Japanese female data   |
|                   |      | is not included in this section. For     |
|                   |      | this data, see "Japanese body size data, |
|                   |      | 1992-1994", Research Institute of Human  |
|                   |      | Engineering for Quality Life,            |
|                   |      | Dokita-Daibiru Bldg. 3F, 2-5, 1-choume,  |
|                   |      | Dojima, Kita-ku, Osaka 530-0003 JAPAN,   |
|                   |      | TEL:+81-6-6346-0234,                     |
|                   |      | FAX:+81-6-6346-0456, http://www.hql.jp/  |
|                   |      |                                          |
|                   |      | \* Data in this section is for           |
|                   |      | non-suited crew and does not address     |
|                   |      | crew wearing a Launch and Entry Suit     |
|                   |      | (LES) as required to be addressed by OSP |
|                   |      | Level II System Requirements Document    |
|                   |      | (SRD), para. 3.3.1, Human                |
|                   |      | Engineering/Human Performance            |
|                   |      |                                          |
|                   |      | \* Data focuses on zero-g and does not   |
|                   |      | address gravitational acceleration       |
|                   |      | conditions during launch and entry       |
+-------------------+------+------------------------------------------+
| Section 4 - Human | Y    | Use MSIS section 4 as is with the        |
| Performance       |      | following exceptions:                    |
| Capability        |      |                                          |
|                   |      | \* 4.9.3, Strength:                      |
|                   |      |                                          |
|                   |      | \* Strength data for 5th percentile      |
|                   |      | Japanese females is not included and is  |
|                   |      | not available                            |
|                   |      |                                          |
|                   |      | \* Data in this section is for           |
|                   |      | non-suited crew and does not address     |
|                   |      | crew wearing a Launch and Entry Suit     |
|                   |      | (LES) as required to be addressed by OSP |
|                   |      | Level II System Requirements Document    |
|                   |      | (SRD), para. 3.3.1, Human                |
|                   |      | Engineering/Human Performance            |
|                   |      |                                          |
|                   |      | \* Data focuses on zero-g and does not   |
|                   |      | address gravitational acceleration       |
|                   |      | conditions during launch and entry       |
|                   |      |                                          |
|                   |      | \* Use MSIS section 4.11.3, Effects of   |
|                   |      | Deconditioning, as is with the following |
|                   |      | exception:                               |
|                   |      |                                          |
|                   |      | \* Add \", ill or injured\" to           |
|                   |      | \"deconditioned\"                        |
+-------------------+------+------------------------------------------+
| Section 5 -       | Y    | Use MSIS section 5 as is with the        |
| Natural & Induced |      | following exceptions:                    |
| Environments      |      |                                          |
|                   |      | \* Replace MSIS section 5.1.3.1.a,       |
|                   |      | Atmosphere Environment, beginning with,  |
|                   |      | \"Concentrations of atmospheric          |
|                   |      | contaminants\...\", with Shuttle Medical |
|                   |      | Operations Requirements Document (MORD)  |
|                   |      | (JSC 13956, Rev. H), paras. 4.2,         |
|                   |      | \"Atmosphere\", & 4.3, \"Microbiology\", |
|                   |      | and ISS MORD (SSP 50260), paras. 5.3,    |
|                   |      | \"Air Quality\", & 5.4, \"Microbiology\" |
|                   |      |                                          |
|                   |      | \* 5.1.3.1.d, ECLSS: Remove \"EVA        |
|                   |      | support\"                                |
|                   |      |                                          |
|                   |      | \* Replace entire MSIS sections 5.1.3.2  |
|                   |      | and 5.1.3.4, Atmosphere Monitoring, with |
|                   |      | Shuttle MORD (JSC 13956, Rev. H), paras. |
|                   |      | 4.2, \"Atmosphere\", & 4.3,              |
|                   |      | \"Microbiology\", and ISS MORD (SSP      |
|                   |      | 50260), paras. 5.3, \"Air Quality\", &   |
|                   |      | 5.4, \"Microbiology\"                    |
|                   |      |                                          |
|                   |      | \* 5.1.3.5, Baro-Thermal Monitoring: N/A |
|                   |      |                                          |
|                   |      | \* 5.3.3.1 & 5.3.3.2, Linear &           |
|                   |      | Rotational Acceleration: Replace MSIS    |
|                   |      | sections with MSFC-RQMT-3360, \"OSP      |
|                   |      | Level II System Requirements Document    |
|                   |      | (SRD)\", para. 3.2.1.11, Acceleration    |
|                   |      | Environment                              |
+-------------------+------+------------------------------------------+
| Section 6 - Crew  | Y    |                                          |
| Safety            |      |                                          |
+-------------------+------+------------------------------------------+
| Section 7 -       | Y    | Use MSIS section 7 as is with the        |
| Health Management |      | following exceptions:                    |
|                   |      |                                          |
|                   |      | \* Replace MSIS Section 7.2.2.3.1, Food  |
|                   |      | Design Requirements with the Dietary     |
|                   |      | Reference Intakes for Energy,            |
|                   |      | Carbohydrate, Fiber, Fat, Fatty Acids,   |
|                   |      | Cholesterol, Protein, and Amino Acids,   |
|                   |      | dated September 5, 2002, available from  |
|                   |      | the Institute of Medicine, National      |
|                   |      | Academy of Sciences, Washington DC       |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.2.2.3.2, Potable   |
|                   |      | Water, as is with the following          |
|                   |      | exceptions:                              |
|                   |      |                                          |
|                   |      | \* 7.2.2.3.2.a, Quality: Replace with    |
|                   |      | Shuttle Medical Operations Requirements  |
|                   |      | Document (MORD) (JSC 13956, Rev. H),     |
|                   |      | paras. 4.1, \"Water Quality\", & 4.3,    |
|                   |      | \"Microbiology\". If water system        |
|                   |      | interfaces with ISS, also use ISS MORD   |
|                   |      | (SSP 50260), paras. 5.2, \"Water Quality |
|                   |      | Specifications\", & 5.4,                 |
|                   |      | \"Microbiology\". Additional             |
|                   |      | ground-based requirements for potable    |
|                   |      | water are in the Space Shuttle           |
|                   |      | Specification, \"Fluid Procurement and   |
|                   |      | Use Control\", SE-S-0073, Rev. G         |
|                   |      |                                          |
|                   |      | \* 7.2.2.3.2.d.1, Cold Water: N/A        |
|                   |      |                                          |
|                   |      | \* 7.2.2.3.2.d.3, Hot Water: N/A         |
|                   |      |                                          |
|                   |      | \* 7.2.3.3.3, Exercise Counter Measures: |
|                   |      | N/A                                      |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.2.4.3, Sleep, as   |
|                   |      | is with the following exception:         |
|                   |      |                                          |
|                   |      | \* 7.2.4.3.a, Sleep Facilities: Delete   |
|                   |      | paranthetical reference to Paragraph     |
|                   |      | 10.4, Crew Quarters                      |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.2.5.3, Personal    |
|                   |      | Hygiene, as is with the following        |
|                   |      | exceptions:                              |
|                   |      |                                          |
|                   |      | \* 7.2.5.3.1.c, Hair Grooming: N/A.      |
|                   |      |                                          |
|                   |      | \* 7.2.5.3.4, Whole Body Cleansing: N/A. |
|                   |      |                                          |
|                   |      | \* 7.2.5.3.5, Clothing & Equipment       |
|                   |      | Cleaning: Change, \"clean clothing and   |
|                   |      | other washable items, including bedding  |
|                   |      | and linens, over the duration of the     |
|                   |      | mission\" to \"clean clothing over the   |
|                   |      | duration of the mission\". Also delete   |
|                   |      | paranthetical reference to Paragraph     |
|                   |      | 10.10.3, Laundry Facility                |
|                   |      |                                          |
|                   |      | \* 7.2.5.3.6, Personal Hygiene Water:    |
|                   |      | N/A                                      |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.2.7.3, Routine     |
|                   |      | Health Monitoring, as is with the        |
|                   |      | following exceptions:                    |
|                   |      |                                          |
|                   |      | \* 7.2.7.3.1, Routine Crew Health        |
|                   |      | Monitoring: N/A                          |
|                   |      |                                          |
|                   |      | \* 7.2.7.3.2, Water Quality Monitoring:  |
|                   |      | Replace with Shuttle Medical Operations  |
|                   |      | Requirements Document (MORD) (JSC 13956, |
|                   |      | Rev. H), paras. 4.1, \"Water Quality\",  |
|                   |      | & 4.3, \"Microbiology\". If water system |
|                   |      | interfaces with ISS, also use ISS MORD   |
|                   |      | (SSP 50260), paras. 5.2, \"Water Quality |
|                   |      | Specifications\", & 5.4,                 |
|                   |      | \"Microbiology\"                         |
|                   |      |                                          |
|                   |      | \* 7.2.7.3.3, Environmental Monitoring:  |
|                   |      | Replace with Shuttle MORD (JSC 13956,    |
|                   |      | Rev. H), Chapter 4, \"Environmental      |
|                   |      | Health\", and ISS MORD (SSP 50260),      |
|                   |      | Chapter 5, \"Environmental Health\"      |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.3.3, Medical Care, |
|                   |      | as is with the following exceptions:     |
|                   |      |                                          |
|                   |      | \* 7.3.3.1, General: Change \"facility\" |
|                   |      | to \"system\". Delete \"preventive,      |
|                   |      | diagnostic, and\" and paranthetical      |
|                   |      | reference to section 10.9                |
|                   |      |                                          |
|                   |      | \* 7.3.3.2, Prevention: N/A              |
|                   |      |                                          |
|                   |      | \* 7.3.3.3, Diagnostic: N/A              |
|                   |      |                                          |
|                   |      | \* 7.3.3.4, Treatment: Change            |
|                   |      | \"facility\" to \"system\". Delete       |
|                   |      | \"anticipated\" and \"In the event an    |
|                   |      | illness or injury is not treatable at    |
|                   |      | the module\".                            |
|                   |      |                                          |
|                   |      | \* Use MSIS section 7.4.3, Crew          |
|                   |      | Survival, as is with the following       |
|                   |      | exception:                               |
|                   |      |                                          |
|                   |      | \* 7.4.3.1, Medical Kit: Replace entire  |
|                   |      | section with \"The vehicle shall provide |
|                   |      | an emergency medical kit.\"              |
+-------------------+------+------------------------------------------+
| Section 8 -       | Y    | Use MSIS Section 8 as is with the        |
| Architecture      |      | following exceptions:                    |
|                   |      |                                          |
|                   |      | \* 8.6.3.2, Habitable Volume: Last       |
|                   |      | sentence, \"Design shall                 |
|                   |      | permit...growth...\" is N/A              |
|                   |      |                                          |
|                   |      | \* 8.12.3.2, Decor Flexibility: N/A      |
|                   |      |                                          |
|                   |      | \* 8.13.3.1, Illumination Levels: EVA    |
|                   |      | references are N/A                       |
|                   |      |                                          |
|                   |      | \* 8.13.3.5, Medical Lighting: N/A       |
+-------------------+------+------------------------------------------+
| Section 9 -       | Y    | Use MSIS Section 9 as is with the        |
| Workstations      |      | following exceptions:                    |
|                   |      |                                          |
|                   |      | \* 9.2.5.2.2, Maintenance Area: N/A.     |
|                   |      |                                          |
|                   |      | \* 9.4.4.3.1.1.b.1, Annunciation: Change |
|                   |      | \"For the emergencies identified those   |
|                   |      | tones shall be: a)...b)...c)...\" to     |
|                   |      | \"For the emergencies identified those   |
|                   |      | three emergency tones shall be audibly   |
|                   |      | distinct from each other and from Class  |
|                   |      | 2 and 3 tones.\"                         |
|                   |      |                                          |
|                   |      | \* 9.4.4.3.1.2.b.1, Annunciation: \"The  |
|                   |      | tone shall be a 50% duty cycle square    |
|                   |      | wave\...for equal durations at 2.5 Hz    |
|                   |      | +/- 10%\" is N/A.                        |
|                   |      |                                          |
|                   |      | \* 9.6, User-Computer Interaction:       |
|                   |      | Replace MSIS section 9.6 with            |
|                   |      | MIL-STD-1472F, section 5.14              |
|                   |      | User-computer interface.                 |
+-------------------+------+------------------------------------------+
| Section 10 -      | Y    | Use MSIS section 10 as is with the       |
| Activity Centers  |      | following exceptions:                    |
|                   |      |                                          |
|                   |      | Overall: Use of the word \"facility\"    |
|                   |      | shall either be deleted or replaced with |
|                   |      | \"system\" or \"capability\" as          |
|                   |      | appropriate                              |
|                   |      |                                          |
|                   |      | \* 10.2.3.2, Whole Body Cleansing: N/A   |
|                   |      |                                          |
|                   |      | \* 10.2.3.4, Hair Cutting: N/A           |
|                   |      |                                          |
|                   |      | \* 10.3.3.1.c, Ease of Urination: N/A    |
|                   |      |                                          |
|                   |      | \* 10.3.3.1.d, Number of Facilities: N/A |
|                   |      |                                          |
|                   |      | \* 10.4, Crew Quarters: N/A              |
|                   |      |                                          |
|                   |      | \* 10.5, Galley & Wardroom: Use of the   |
|                   |      | word \"galley\" shall be interpreted to  |
|                   |      | mean \"food preparation system or        |
|                   |      | capability\". Also, delete all           |
|                   |      | references to \"wardroom\"               |
|                   |      |                                          |
|                   |      | \* 10.5.3.2.d & 10.5.3.2.e, Heating &    |
|                   |      | Chilling: N/A                            |
|                   |      |                                          |
|                   |      | \* 10.5.3.2.h, Table: N/A                |
|                   |      |                                          |
|                   |      | \* 10.6, Meeting Facility: N/A           |
|                   |      |                                          |
|                   |      | \* 10.7, Recreation Facility: N/A        |
|                   |      |                                          |
|                   |      | \* 10.8, Microgravity Countermeasure     |
|                   |      | Facility: N/A                            |
|                   |      |                                          |
|                   |      | \* 10.9, Space Medical Facility: N/A     |
|                   |      |                                          |
|                   |      | \* 10.10, Laundry Facility: N/A          |
+-------------------+------+------------------------------------------+
| Section 11 -      | Y    |                                          |
| Hardware and      |      |                                          |
| Equipment         |      |                                          |
+-------------------+------+------------------------------------------+
| Section 12 -      | Y    |                                          |
| Design for        |      |                                          |
| Maintainability   |      |                                          |
+-------------------+------+------------------------------------------+
| Section 13 -      | Y    | Use MSIS Section 13 as is with the       |
| Facility          |      | following exception:                     |
| Management        |      |                                          |
|                   |      | \* 13.2.3.3, Vacuum Cleaning: N/A        |
|                   |      |                                          |
|                   |      | Also, add Microbial Contamination        |
|                   |      | Control: Shuttle Medical Operations      |
|                   |      | Requirements Document (MORD) (JSC 13956, |
|                   |      | Rev. H), para 4.3, \"Microbiology\", and |
|                   |      | ISS MORD (SSP 50260), para. 5.4,         |
|                   |      | \"Microbiology\"                         |
+-------------------+------+------------------------------------------+
| Section 14 - EVA  | N    | EVA airlock capability is not required   |
|                   |      | but exterior maintenance from ISS or     |
|                   |      | other vehicle isn\'t precluded. If EVA   |
|                   |      | support is planned use the appropriate   |
|                   |      | standards from MSIS section 14           |
+-------------------+------+------------------------------------------+

# Appendix E: MIL-STD-1472 Applicability Matrix {#appendix-e-mil-std-1472-applicability-matrix .unnumbered}

MIL-STD 1472F was reviewed for application to OSP. While most paragraphs
are applicable, the paragraphs in Table 1 are intended mainly for
military systems. Also, at least one paragraph (5.14) should be tailored
using alternate sources (Table 2).

Table 1: MIL-STD 1472F Non-Applicable Paragraphs

  ------------- -------------------------------- --------------------------
  Paragraph     Title                            Rationale

  5.2.6.12      Head-up Displays (HUDs)          Assumes aircraft-type HUD

  5.2.6.13      Helmet Mounted display (HMDs)    Assumes aircraft-type HMD

                                                 

  5.2.1.4.14    Aircrew station signals          Applies to aircraft
                                                 systems

  5.3.1.7       Silent Operations at Night       Military application

  5.4.1.4.5.2   Immediate Action controls        Aircraft application

                                                 

  5.11.2        Small Systems and Equipment:     Military "gun system"
                Tracking                         

  5.11.3        Small Systems and Equipment:     Military "gun system"
                Optical instruments and related  
                equipment                        

                                                 

  5.13.9        Stealth and covert operations    Military application

                                                 

  5.14.3.6.17   Drawing Lines                    Application fits "office"
                                                 environment

  5.14.3.6.18   Drawing Figures                  Application fits "office"
                                                 environment

  5.14.3.6.19   Drawing Lines and Figures with   Application fits "office"
                numeric coordinates              environment

                                                 

  5.14.3.7      Text/program editing             Software programming
                                                 application

  5.14.4.5      Command Language                 Software programming
                                                 application

  5.14.4.6      Question and answer              Software programming
                                                 application

  5.14.4.7      Query Language                   Software programming
                                                 application
  ------------- -------------------------------- --------------------------

Table 2: MIL-STD 1472F Paragraphs Which Merit Alternate Sources

  ----------- ------------------------ ---------------- ------------------
  Paragraph   Title                    Rationale        Alternate Source
                                                        **^(1)^**

  5.14        User-Computer Interface  Technology       HFS-100 or similar
                                       possibly not     
                                       current or       
                                       applicable to    
                                       OSP              
  ----------- ------------------------ ---------------- ------------------

\*For information only.

**^(1)^** Alternate Source References:

> a\. User Interface Design by Ray E. Eberts,
>
> b\. Ergonomic Design for People At Work (Vols. I & II) by Eastman
> Kodak Company
>
> c\. Handbook of Virtual Environments by Kay M. Stanney.

# Appendix F: Comments to NPG 8705.2, 2.10.5.1.a {#appendix-f-comments-to-npg-8705.2-2.10.5.1.a .unnumbered}

The OSP Program chooses to allocate this requirement to the contractor
system specification (Level III) in the form of a trade. This
requirement will also be allocated as a trade study for the Launch
Services Program (LSP) as part of an overall ELV Safety Study.

Rationale:

For the OSP System the Program shall include a Data Requirement that
will force a trade by the contractors to show a comparison between the
contractor proposed system and the use of independently developed and
redundant software. This trade will have to show why the proposed
software system is better than the system as indicated in the NPG. It
will look at failure modes common to software systems such as common
faults in code, single event upsets, etc. The goal is for the
contractors to have the freedom to be innovative in their development
but at the same time not sacrifice the overall safety of the system.

For the ELV, the trade will focus on modifications to the present ELV
and whether these modifications will increase the overall safety,
maintain the same level, or negatively impact the safety of the OSP
system.

The Program chooses not to levy this requirement at Level II for several
reasons.

By levying this requirement, the Program believes that it will bias the
results of the trade study. It would be easier for the contractor to
just go with the requirement as stated than to add a waiver to the
system.

Also, this requirement as stated:

1\) Would have the potential for increases in cost for developing and
maintaining s/w by a factor of at least 2.

It is assumed from the requirement that redundant software must have the
same level of functionality as the primary software. In this case, the
development effort would be doubled. In addition, another piece of
software is necessary for the integration of the two independent
developments.

2\) Require substantial testing to show that the safety critical
software transitions can occur without interruption of flight control in
all flight regimes.

On top of doubling the development effort for each set of software,
there is the concern that these software development pieces will require
an integration piece of software that handles the transfer of data so
that they can be switched at any time without loss of functionality.
This leads to complications with integration that may actually decrease
the reliability of the system. It is possible that errors are actually
introduced by efforts to make the systems compatible.

3\) Doesn't gain any benefit for safety since the errors to be found are
almost always traced back to the specification and not the design,
implementation, nor testing (failures).

The intent of this requirement is to guard against general faults in the
code that would also be in the identical redundant piece of software. As
previously stated, this is not the typical failure mode. Even in the
events that this error does manifest itself, new development in the area
of software sensors and new code development and testing may be able to
identify this error before correct for it. In order to guard against
this and any other software failures the requirements as stated below,
found in the SRD and HRP, as well as requirements to be placed in the
Statement of Work, will force the Contractor to make trades in the
development to determine the safest and most reliable software
attainable.

\[SYS2500\] No single failure (excluding items that are designed for
minimum risk) shall result in a critical hazard or catastrophic hazard.
Catastrophic hazards that lead to loss of life or permanent disability
are addressed in \[HRR 500\].

\[SYS2540\] Subsystems or components of the System performing safety
critical functions shall be physically separated, isolated, or protected
such that any credible event does not result in the loss of more than
one hazard control.

\[SYS2590\] The System software/firmware performing, controlling, or
supporting safety critical functions shall be isolated or protected such
that any failure of non-critical software/firmware does not affect the
performance of the critical software/firmware.

\[HRR 500\] The System shall be designed so that no two failures shall
result in permanent disability or loss of life, unless it can be
demonstrated to the Program that:

1\) Two-failure tolerance is either impractical or negatively impacts
overall system reliability, and

2\) Test data, hazard analyses, and comprehensive risk analyses together
provide certainty that the system will have a very high reliability
without two-failure tolerance.

\[HRR 530\] The System shall be designed so that the interaction of the
components, operating as specified (including software), does not result
in a permanent disability or loss of life.

\[HRR 540\] The System shall assess the use of dissimilar redundancy in
the design of critical functions, As a defense against common cause
failure.

\[DRD\] The Contractor shall follow the requirements in NASA Standard
8719.13A, "Software Safety NASA Technical Standard," or equivalent to
implement a systematic approach to software safety as an integral part
of the overall system safety program.

\[DRD\] The Contractor shall test, verify, and validate the performance,
security, and reliability of all critical software across the entire
flight envelope, as well as mission functions, modes and transitions

\[DRD\] The Contractor shall use a flight-equivalent avionics test-bed
operating in a real-time, closed-loop test environment.

\[DRD\] The Contractor shall test ground software on the computer
platforms that will be used to support flights.

\[DRD\] The Contractor shall confirm the integrity of the software
design and testing process via independent verification and validation
methods.

DRDs that support software development are as followed:

SW-IDD: Interface Design Description\
SW-IRD: Interface Requirements Specification\
SW-SCMP: Software Configuration Management Plan\
SW-SDD: Software Design Description\
SW-SDP: Software Development Plan\
SW-SPS: Software Product Specification\
SW-SRS: Software Requirements Specification\
SW-STD: Software Test Description\
SW-STP: Software Test Plan\
\
Software Quality Assurance Plan following DRDs are:\
SW-MSMR: Mission Software Metrics Report (in the works)\
SW-STR: Software Test Report\
SW-SUM: Software User Manual\
SW-SVD: Software Version Description