DOCUMENT HISTORY LOG

 
FOREWORD

This NASA technical standard provides uniform engineering and technical requirements for processes, procedures, practices, and methods that have been endorsed as standard for NASA programs and projects, including requirements for selection, application, and design criteria of an item. The publication of this standard prepares the way for update of NPR 8705.2C, Human- Rating Requirements for Space Flight Systems, that will address conformity with NPR 1400.1, NASA Directivies Directives and Charters Procedural Requirements, which mandates the exclusion of technical requirements in NASA directives. This NASA technical standard, together with the Human Rating Certification Process and associated requirements addressed in NPR 8705.2C and its’ future updates, provides a complete picture of human-rating of applicable space flight systems.

...

2.1.2 Non-Government Documents

None.

2.2 Reference Documents

The documents listed in this section are not incorporated by reference within this standard. These references are included to provide further clarification and guidance.

2.2.1 Government Documents

...

 2.3 Order of Precedence

2.3.1 Where conflicts exist between this standard and applicable federal regulations, the applicable regulations take precedence.

...

3.2 Definitions

Note: The following definitions are from NPR 8705.2 revision C.

...

4.3 System Safety Requirements -Failure Tolerance

4.3.1.1 The space system shall provide at least single failure tolerance to catastrophic events, with specific levels of failure tolerance and implementation (similar or dissimilar redundancy) derived via an integration of the design and safety analysis (required by NPR 8705.2).4.3.1.1 Failure of primary structure, structural failure of pressure vessel walls, and structural failure of pressurized lines are exempted from the failure tolerance requirement provided the potentially Failure of primary structure, structural failure of pressure vessel walls, and structural failure of pressurized lines are exempted from the failure tolerance requirement provided the potentially catastrophic failures are controlled through a defined process in which approved standards and margins are implemented that account for the absence of failure tolerance.

...

Note: An early mission termination utilizing nominal systems and operations is not considered to be part of emergency equipment and systems; and may, therefore, be considered part of the failure tolerance of the system. However, when aborts are used to remove the crew from a catastrophic event (e.g., abort on Earth ascent in the presence of a launch vehicle explosion), the catastrophic event has not been prevented, and the abort system (even though it may save the crew and passengers) cannot be considered as a leg of failure tolerance to the catastrophic event.

Note: An operator is defined as any human that commands or interfaces with the space system during the mission, including humans in the control centers. The appropriate level of protection (i.e., one, two or more inadvertent actions) is determined by the integrated human error and hazard analysis per NPR 8705.2.

Rationale: The intent of this requirement is to provide a robust human-system interface design that cannot be defeated by a system failure. Where the system is designed to protect for more than one inadvertent action, the level of protection after a single system failure may be reduced - but still protects from a single inadvertent operator action.

Note 1: According to current software standards, the software system will be designed, developed, and tested to:

...

Note 4: Mitigate the negative effects of hazardous software behavior. However, for complex software systems, it is very difficult to definitively prove the absence of hazardous behavior. Therefore, the crewed system has the capability to mitigate this hazardous behavior if it occurs. The mitigation strategy will depend on the phase of flight and the time to effect of the potential hazard. Hazardous behavior includes erroneous software outputs or performance.

Rationale: It is necessary to alert the crew to faults (not just failures) that affect critical functions. A fault is defined as an undesired system state. A failure is an actual malfunction of a hardware or software item's intended function. The definition of the term fault envelopes the word failure, since faults include other undesired events such as software anomalies and operational anomalies.

Note: This capability is not intended to imply a failure tolerance capability or expand upon the failure tolerance capability. The intent is to provide isolation and recovery from faults where the system design (e.g., redundant strings or system isolation) enables the implementation of this capability. Also, any faults identified during system development should be protected by isolation and recovery. However, it is acknowledged that not all faults that would cause catastrophic events can be detected or isolated in time to avoid the event. Similarly, system design cannot ensure that once the fault is detected and isolated that a recovery is always possible. In cases where recovery is not possible, isolation of the fault needs to be sufficient on its own to prevent the catastrophic event.

...

Rationale: Access to health and status data

...

is a key element of anomaly resolution during

...

Rationale: Access to health and status data is a key element of anomaly resolution during the mission, which the mission, which could prevent the crew from executing an abort or prevent the situation from developing into a catastrophic event. Resolving anomalies between missions is just as important. This requirement intentionally does not specify a crash survivable data recorder. That determination is left for the program. The program also determines what data should be available to facilitate anomaly resolution.

Note: This capability means that the crewed system does not depend on communication with Earth (e.g., mission control) to perform functions that are required to keep the crew alive(refer to the definition for Autonomous in Section 3.2).

...

4.4 System Control Requirements - General

4.4.1 The crewed space system shall provide the capability for the crew to monitor, operate, and control the crewed space system and subsystems, where: 

1. 1. The capability is necessary to execute the mission; or
   2. The capability would prevent a catastrophic event; or
   3. The capability would prevent an abort.

Include Page
HR-41 - Req HR-41 - Req

Rationale: This capability flows directly from the definition of human-rating. Within the Rationale: This capability flows directly from the definition of human-rating. Within the context of this requirement, monitoring is the ability to determine where the vehicle is, its condition, and what it is doing. Monitoring helps to create situational awareness that improves the performance of the human operator and enhances the mission. Determining the level of operation over individual functions is a decision made separately for specific space systems. Specifically, if a valve or relay can be controlled by a computer, then that same control could be offered to the crew to perform that function. However, a crew member probably could not operate individual valves that meter the flow of propellant to the engines, but the function could be replaced by a throttle that incorporates multiple valve movements to achieve a desired end state (reduce or increase thrust). Meeting any of the three stated conditions invokes the requirement. The first condition recognizes that the crew performs functions to meet mission objectives and, in those cases, the crew is provided the designated capabilities. This does not mean that the crew is provided these capabilities for all elements of a mission. Many considerations are involved in making these determinations, including capability to perform the function and reaction time. The second and third conditions recognize that, in many scenarios, the crew improves the performance of the system and that the designated capabilities support that performance improvement.

...

Include Page
HR-42 - Req HR-42 - Req

Rationale: This is a specific capability necessary for the crew to

...

Rationale: This is a specific capability necessary for the crew to control the crewed space system. While this capability control the crewed space system. While this capability should be derived by the program per paragraph 4.3.1, the critical nature of software control and automation at the highest system level dictates specific mention in this standard. Therefore, the crew has the capability to control automated configuration changes and mode changes, including automated aborts, at the system level as long as the transition to manual control is feasible and will not cause a catastrophic event. The program and Technical Authorities will determine the appropriate implementation of this requirement - which is documented in the program’s Human Rating Certification Plan (HRCP) and evidenced by HRCP deliverables.

4.4.3 The space system shall provide the capability for humans to remotely monitor, operate, and control the crewed system elements and subsystems, where:

...

Include Page
HR-43 - Req HR-43 - Req

...

Rationale: This capability will likely be implemented using a mission control on Earth. Logically, there will be times when the crew is unavailable to monitor, operate, and control the system. If the crew vacates one element of the system or transfers to another Human-Rated system as part of the reference mission, there is a capability for humans to monitor the unoccupied elements. In some of these cases, the crew may be able to perform this function from their new location. In other cases, mission control may perform this function.

...

4.5 System Control Requirements - Human-Rated Spacecraft

Rationale: The capability for the crew to control the spacecraft's flight path is a fundamental element of crew survival. The most robust satisfaction of this requirement is provided by direct manual control of the vehicle flight path, through an independent flight control system (bypassing the affected vehicle guidance, navigation, and flight control system failures). A minimum implementation of manual control allows for the crew to bypass the automated guidance of the vehicle by interfacing directly with the flight control system to effect any possible flight path within the capability of the flight control system. Limiting the crew to choices presented by the automated guidance function is not a valid implementation of manual control.

...

4.6 System Control Requirements - Proximity Operations with Human-Rated Spacecraft

4.6.1 The space system shall provide the capability for the crew to monitor, operate, and control an uncrewed spacecraft during proximity operations, where:

...

...

Note 1: Proximity operations cover several scenarios, but this term is specifically defined as two (or more) systems operating in space (not on a planetary surface) within the prescribed safe zone for either system.

...

Note: NASA/SP-2011-3421, Chapter 14, Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners, 2011, provides guidance on the evaluation of abort capability effectiveness in the context of probabilistic safety analyses.

4.7.1.3 The crewed space system shall monitor the Earth ascent launch vehicle performance and automatically initiate an abort when an impending catastrophic failure is detected.

of abort capability effectiveness in the context of probabilistic safety analyses.

Note: Launch vehicle performance monitoring may include specific system or subsystem performance. The program will determine the appropriate parameters to monitor in the launch vehicle. Not all potentially catastrophic failures can be detected prior to manifestation. Similarly, system design and analysis cannot guarantee the crew will survive all catastrophic failures of the launch system, but the abort system should provide the best possible chance for the crew to survive. When an impending catastrophic failure of the launch vehicle is detected, the time to effect requires the abort system to be initiated automatically. Also, if the catastrophic failure itself is detected by a monitoring system, the abort is initiated automatically. This is not intended to require independent implementation by the crewed space system of capabilities inherent to the launch vehicle (the launch vehicle is part of the crewed space system).

4.7.1.4 Earth Ascent Abort

Note: The ability to inhibit an automated abort initiation is described in paragraph 4.3.2.4.7.1.4.2 The space system shall provide the capability for the ground control to initiate the Earth ascent abort sequence.

Rationale: The crew and ground control will likely have access to more data than an automated abort system. Therefore, both the crew and ground control have the capability to initiate the abort when necessary for crew survival.

Rationale: Prior to destruction of the launch vehicle by means of a range safety destruct (flight termination) system, the abort system is initiated. An automated initiation of the abort sequence provides the best chance for crew survival while protecting the public from a range safety violation. It is left to the program to determine which range safety command (arm or fire) will result in the initiation of the abort sequence.

4.7.2 Earth Orbit SystemsThe crewed space system shall provide the capability to autonomously abort the mission from Earth orbit by targeting and performing a deorbit to a safe landing on Earth.

Note: Where possible, the crewed space system should provide a backup capability for entry to protect for loss of the primary attitude control and guidance system. Integration of design and safety analyses, per NPR 8705.2, addresses scenarios where this may not be applicable.

...