[NASA Logo]

NASA Procedures and Guidelines

This Document is Obsolete and Is No Longer Used.
Check the NODIS Library to access the current version:
http://nodis3.gsfc.nasa.gov


NPR 8705.2
Eff. Date: June 19, 2003
Cancellation Date: February 07, 2005

Human-Rating Requirements and Guidelines for Space Flight Systems w/Change 2 (6/25/04)

| TOC | Change | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |


Chapter 2: Technical Requirements


2.1 Introduction

2.1.1 The technical requirements specified in this document are based on a history of successful space flight experience. Spacecraft operate in an inherently high-risk environment, especially during the ascent and descent phases, and only the best practices of the aerospace industry are sufficient to give reasonable assurance of success.

2.1.2 The following technical requirements shall be followed for the human rating of all space flight systems (hardware and software, ground and flight) which are developed and/or operated by, or for NASA to support human activity in space or which interact with NASA human space flight systems (Requirement 30720). Since these space missions vary significantly from one mission to another, not all of the human-rating requirements are applicable to each. Example systems that are covered by these requirements include:

a. Earth-to-Orbit (ETO) systems, including launch vehicles and entry vehicles, reusable launch vehicles, or any vehicle operating in the launch and/or landing phase;

b. Space Station (SS) systems, including space flight systems operating exclusively in a low Earth orbit environment;

c. Beyond Earth Orbit (BEO) systems, including space flight systems that operate away from the Earth and beyond easy access for on-demand logistics resupply or crew escape;

d. Crew Rescue Systems, including space flight systems planned for emergency or other nonroutine entry;

e. Crew Transfer Systems, including space flight systems used to transfer crews, passengers, and/or hardware between any of the other listed space flight systems;

f. Planetary Surface Systems (PSS) and Surface Transportation Systems including habitats, Extravehicular Activity (EVA) suits, and other support systems;

g. Extravehicular Mobility Units (EMU), space suits, and other stand-alone systems critical to human survival in space; and

h. Planetary Landing and Ascent Vehicles (PLAV) and other space flight systems used to land and ascend from planetary surfaces, including minor planets.

2.2 Design for Human Space Flight

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 (Requirement 30722).

In addition to system and subsystem testing to ensure that design requirements are achieved, components should be qualification tested to ensure that adequate design margin exists at the component level for vibration, acoustic, thermal, shock (including pyrotechnic shock), and pressure/aerodynamic/structural loads, as applicable. Military Standard 1540, Test Requirements for Launch, Upper-Stage and Space Vehicles, dated September 1994, or equivalent component qualification and acceptance testing standards should be used as guidelines. The use of dedicated qualification components is recommended. Flight components should be acceptance tested in the previously noted environments, as applicable, to ensure that each individual component has adequate performance margin for its intended use. Policies for required margins for each environment for qualification and acceptance should be developed by the program. This reference to component qualification and acceptance testing is necessary to emphasize crew and passenger safety requirements, but the discussion is also applicable to other requirements for safety and mission assurance/objectives. Systems requiring incremental assembly in or BEO should conduct multiple-element integrated testing prior to launch. Use of approaches such as testing elements in logical groupings with appropriate fidelity emulations of interfaces is acceptable. Testing should be carried out with software possessing flight functionality and flight hardware in flight configuration. Priority should be given to interface validations of hardware and hardware/software interaction. If applicable, end-to-end testing of command and telemetry links between the control center(s) and the vehicle should be accomplished.

2.2.2 The design of the space flight system shall address the aspects of human rating beginning in the formulation phase (Requirement 30724).

Spacecraft and other space flight systems intended to support humans have significantly different characteristics from other aerospace vehicles such as aircraft, and it is essential that the design of a human-rated space flight system fully account for these differences. While space flight systems design is built upon decades of aircraft experience, the unique operations and environments of the space flight systems missions lead to a different and even more stringent set of design requirements. Historically, human rating was accomplished through the use of aircraft safety factors instead of the lower safety factors typical of unmanned military launch vehicles, eliminating single failure points, and providing escape systems to rescue the crew in case of a catastrophic vehicle failure. Incorporating historical and evolving lessons learned is critical to ensuring the highest level of design safety. As the design evolves, all system trades should ensure the integrity of the system design to meet human-rating requirements.

2.2.3 The space flight system design shall incorporate NASA Standard 3000, Manned Systems Integration Standards, for all microgravity and zero-G human system interfaces, including those required for on-orbit maintenance (Requirement 30726).

NASA has developed life-support systems requirements that encompass all habitable space environments inclusive of the preflight, in-flight, and postflight phases. An environment suitable for human habitation has been defined for pressurized elements according to the specifications and standards in NASA STD 3000. Human-factor-compliant designs and monitoring of critical environmental health parameters are required for optimal human performance. These standards also apply to uninhabited space flight systems volumes that may require ingress and egress by a crewmember or passenger in flight such as a pressurized logistics mission cargo carrier (Requirement 30727). These requirements have evolved from NASA's Mercury, Gemini, Apollo, Skylab, Shuttle Transportation System, the International Space Station (ISS), and multiple extravehicular suited programs. Long-duration space flight requirements are derived from NASA's Lunar, Skylab, Extended Duration Orbiter, ISS, and Phase One MIR life sciences programs.

2.2.4 The space flight system shall incorporate MIL STD 1472, DOD Design Criteria Standard - Human Engineering, and NASA/TM-2003-210785, Guidelines and Capabilities for Designing Human Missions, for all human flight system interfaces utilized during ground processing, maintenance, and operations as tailored for a specific program (Requirement 30728).

2.2.5 Crew habitability and life support systems shall comply with JSC 26882, NASA Space Flight Health Requirements (Requirement 30729).

2.3 Aerospace Design Standards

2.3.1 The space flight system design, manufacture, and test shall comply with JSCM 8080.5, "JSC Design and Procedural Standards Manual" (Requirement 30731).

Emphasis is placed on using established aerospace design standards, since these standards are based on lessons learned regarding the design and operation of space flight systems (Requirement 30732). The detailed design requirements and practices specified in JSCM 8080.5 shall be incorporated in the design of human-rated space flight systems. Programmatic use of alternative approaches to these practices will have to demonstrate to the CHMO, AA for OSF, and AA for SMA that they are as effective as the accepted methods.

2.3.2 The space flight system design, manufacture, and test should comply with applicable military and aerospace design standards.

Program and project managers should encourage the access to and use of the NASA Headquarters Office of the Chief Engineer Web site (http://www.hq.nasa.gov/office/ codea/codeae/tech_stan.html), which includes links to standards-developing organizations as well as links to lessons learned and best practices for aerospace design. Additional information on traditionally accepted design and verification methods and standards can be obtained through historical certification requirements documents listed in Appendix A of this document. The intent of the detailed design requirements and practices specified in these documents should be incorporated in the design of human-rated space flight systems. Programmatic use of alternative approaches to these practices will have to demonstrate that they are as effective as the accepted methods.

2.4 Flight Test

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 database prior to the first operational flight (Requirement 30736).

No space flight system can be certified on the basis of analysis alone. Flight experience has shown that many critical performance parameters are highly design-specific and require thorough operational test and checkout to verify. Virtually all flight programs have shown important areas where flight and operational experience did not match the predictions. The design process for space flight systems is based on analyses and simulations that are highly dependent upon the analytical math models of the flight environment and the space flight systems hardware. Current and expected technologies require that many of these math models be based on estimates, approximations, and simplifications of the real world. Therefore, a flight test program must be performed to provide two critical functions. First, the flight test program is used to verify the integrated performance of the space flight system hardware and software in the operational flight environment. Second, the flight test program is used to validate the analytical math models that are the foundation of all other analyses, including those used to define operating boundaries not expected to be approached during normal flight.

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 (Requirement 30738).

Whenever possible, the flight test program should be conducted across the entire mission profile. A sufficient number of flights should be flown such that the flight test data for the analytical math models can be extrapolated to predict the performance of the space flight systems at the edges of the operational envelopes and to predict the margins of the critical design parameters. This is generally possible for systems with discrete mission profiles of manageable duration such as ETO and crew rescue space flight systems. These systems can usually be operated through several complete ascents, orbital transfers, and/or descent profiles and should give good confidence in the suitability of the design for the planned mission. A flight test across the entire mission profile may not be feasible, either due to the excessive amount of time required to cover the planned mission duration, or the lack of suitable conditions to test, as in the case of planetary landing space flight systems. In these cases, a series of tests encompassing all elements of the mission profile under actual or high-fidelity simulated conditions is required (Requirement 30739). For an SS or BEO space flight systems, flight test across the entire mission profile is not feasible. Limited testing, backed with extensive analyses and simulation, may be used in these cases to verify space flight systems performance across the integrated mission profile.

EMU's or other systems, including those that have a self-contained propulsion system, should also be flight tested throughout the expected flight envelope.

2.5 System Safety and Reliability

2.5.1 System Safety

2.5.1.1 In accordance with NPR 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 (Requirement 30743).

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 (Requirement 30744).

2.5.1.3 The program shall establish a rigorous health, safety, and reliability process using qualitative and quantitative tools (such as 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 (Requirement 30745).

2.5.2 Software Safety

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 (Requirement 30747).

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 (Requirement 30748).

Providing effective safety of a space flight system dictates that controls be established for computer-based control systems. A computer-based control system utilizes computer hardware, software, and/or firmware to accept input information and processes that information to provide outputs to a defined task. Specific requirements for computer-based control of systems should be developed and address the following: computer-based control system software requirements that should be applied regardless of function; requirements that must be met in the control of functions that must work; and requirements for functions whose inadvertent operation would cause a hazard (such as must-not-work functions). An example reference for these technical requirements is SSP 50038, Computer-Based Control System Safety Requirements, ISS program.

2.5.3 Failure Tolerance and Reliability

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 (Requirement 30751).

a. Failure tolerance is a term frequently used to describe minimum acceptable redundancy, but it may also be used to describe two similar systems, cross-strapping, or functional interrelationships that ensure minimally acceptable system performance despite failures. It is highly desirable that the space flight system performance degrades in a predictable fashion that allows sufficient time for failure detection and, when possible, system recovery even when experiencing multiple failures. Where necessary, system design should incorporate cross strapping, failure tolerance, failure detection, and failure recovery capabilities to minimize the negative consequences of failures.

b. System design for reliability is a definitive element of space flight system design. Space flight system hardware is designed for inherent reliability at the component level, but the architecture of the system must also protect against random failures and minimize the probability of loss of mission, space flight system, crew, or passengers. In systems with relatively short periods of operation, or where dynamic flight modes (such as powered ascent) are involved, installed redundancy is the principal means of ensuring the system's reliability. In space flight systems with longer missions and/or more time for recovery from failures, maintenance and logistics resupply are critical.

c. For ascent and descent space flight systems, the time constraints of the dynamic flight modes may preclude the opportunity to use in-flight maintenance and system reconfiguration to recover from failures. Therefore, two-failure tolerance is a critical element in ensuring adequate space flight systems reliability. Elements that are designed for minimum risk (such as primary structure, and pressure vessels) are excluded from failure tolerance requirements.

d. In the case of BEO space flight systems, it is unlikely that resupply space flight systems can supplement the resources aboard the space flight systems unless that capability was planned for in advance through pre-positioned spares. Therefore, safe operation of the space flight systems requires that sufficient reliability be achieved through a combination of reliable hardware design, installed redundancy (both similar and dissimilar), and logistics capability to support maintenance (Requirement 32710).

e. For long-duration missions, maintenance and system reconfiguration may be used to restore redundancy to the failed functions. For long-duration missions such as on a SS or a BEO space flight system, failure tolerance and functional redundancy are not sufficient since NASA cannot fully predict failure rates, causes, or environments. For these missions, multiple failures are expected, and the response must include maintenance and system reconfiguration to restore the failed functions. In the case of an SS, the maintenance capability and associated logistics inventory need only support critical systems until the arrival of the next resupply vessel. This is likely to be a period of a few weeks to several months. Maintenance may be considered as an additional level of redundancy beyond two-failure tolerance when mission operations, time criticality, and logistics allow it.

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 (Requirement 30752).

2.5.3.3 The program shall consider tailoring requirement 2.5.3.1 if:

a. It can demonstrate that two-failure tolerance is either impractical or negatively impacts overall system reliability, and

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

Impractical refers to cost prohibitive. Certainty that a system will have a high reliability refers to demonstration of high confidence. Very high reliability is reliability consistent with the accepted crewed aerospace industry standard at the time of each program's initiation.

2.5.3.4 The program shall consider tailoring requirement 2.5.3.2 when:

a. Error prevention has been demonstrated either to be impractical or negatively impact overall system reliability, and

b. 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 (Requirement 30759).

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 (Requirement 30760).

2.5.3.6 Emergency systems (such as fire suppression and 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 (Requirement 30761).

2.5.3.7 As a defense against common cause failure, use of dissimilar redundancy shall be assessed in the design of critical functions (Requirement 30762).

2.5.4 Crew survival

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 (Requirement 30764). This probability requirement can be satisfied through the use of all available mechanisms including nominal mission completion, abort, safe haven, or crew escape.

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 (Requirement 30765).

The overall probability of crew and passenger survival must meet the minimum program requirements (as defined in section 2.5.4.1) for the stated life of a space flight systems program (the predeclared time period or number of missions over which the system is expected to operate without major redesign or redefinition) (Requirement 30766). This approach is required to reflect the different technical challenges and levels of operational risk exposure between the various missions. For example, the large number of expected launch operations in the ETO mission represent fundamentally different risks than conducting the first BEO mission to Mars. Single mission risk on the order of 0.99 for a BEO mission may be acceptable, while considerably better performance, on the order of 0.9999, is expected for a reusable ETO design that will fly 100 or more flights.

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 (Requirement 30768).

The allocation process should begin early in order to guide the program management and engineer in design trades throughout the design phase. Inclusion of reliability estimation and allocation during system definition facilitates timely and effective decisionmaking before critical design solutions are precluded. Reliability allocation should be used to assign the reliability requirement for complex systems to lower levels and provide insight into fundamental design and architectural requirements to meet system goals.

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 (Requirement 30770).

The failure, detection, isolation, recovery, and prognostics approach should be used to maximize the potential to identify component failures that endanger the flight crew and allow for the isolation and recovery of the system, if possible.

2.5.4.5 All space flight systems shall be designed to ensure accessibility to vital equipment involved in immediate and followup action to effect emergency recovery of the space flight system, such as, but not limited to, spacecraft compartment pressurization, life support, and emergency systems (Requirement 30772).

2.6 Abort and Crew Escape

2.6.1 The capability for rapid crew and occupant egress shall be provided during all prelaunch activities (Requirement 30774).

2.6.2 The capability for crew and occupant survival and recovery shall be provided on ascent using a combination of abort and escape (Requirement 30775).

2.6.3 The capability for crew and occupant survival and recovery shall be provided during all other phases of flight (including on-orbit, reentry, and landing) using a combination of abort and escape, unless comprehensive safety and reliability analyses indicate that abort and escape capability is not required to meet crew survival requirements (Requirement 30776).

2.6.4 Determinations regarding escape and abort shall be made based upon comprehensive safety and reliability analyses across all mission profiles (Requirement 30777).

a. Crew escape systems are required on ascent, regardless of analytical risk assessments, due to the highly dynamic nature of the ascent flight regime and the increased likelihood of catastrophic, uncontainable failures (Requirement 30778). Crew escape is also required to offset the uncertainty associated with verification of high probabilities of safe crew and passenger return (Requirement 30779).

b. An intact abort provides for the recovery of the space flight system and its crew and occupants to a suitable site without exceeding stability and control, structural or thermal limits of the system, or cognitive or physiological limits of the crew. Intact abort is the preferred alternative when a successful mission is not possible because it permits the safe recovery of the crew, passengers, and space flight hardware for various levels of system malfunction that do not require crew escape. A contingency abort provides for the recovery of the space flight system and its crew and passengers while potentially exceeding certified limits of the system. The design of intact and contingency abort modes should remain within the performance envelope of the crew escape system, if applicable, to address additional system failures or other problems during the abort trajectory.

c. The reliability, abort, and escape requirements, as defined in this document, may result in different design solutions for the different mission scenarios, levels of risk exposure during a mission, and system architectures. See Appendix D for mission-specific implementation guidance.

2.7 Flight Termination

Any flight termination system (such as range safety system) for human-rated launch vehicles shall include design features (such as thrust termination), which allow sufficient time for safe human escape prior to activation of the destruct system (Requirement 30782).

A flight termination system will most likely be required for ETO space flight systems (including BEO space flight systems launched intact) that cannot demonstrate sufficiently low hazard to the public throughout the launch phase. Range safety and flight termination requirements are dictated by the Eastern and Western Range Safety Regulation, EWR 127-1, for Government launch complexes, and the Federal Aviation Administration for commercially licensed facilities. Flight termination systems that do not require the destruction of the space flight systems are preferred for space flight systems that carry humans to space. However, regardless of system requirements, the flight termination system should be designed to work in concert with the human escape system to maximize the capability for the safe return of the humans on board without endangering people on the ground.

2.8 Proximity Operations

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) (Requirement 30786).

Space flight systems operations in proximity to another space flight system constitute a significant hazard to both vehicles. Therefore, the design and operation of both space flight systems must be compatible with and responsive to the unique requirements of proximity operations (Requirement 30787).

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 (Requirement 30788).

Specific requirements are unique to space flight systems and missions but should address the following: human Situational Awarenes , s ( , SA) , an , d a , bil , ity , to , mo , nit , or , and , co , ntr , ol; , do , cki , ng , mechanisms and mating hardware; interspace flight systems communications; power; software; command and telemetry; trajectory monitoring, and attitude control; remote station-keeping, separation, and breakout commanding for uninhabited space flight systems and external environments including pluming, contamination, induced structural loads, electromagnetic interference, and thermal. Example references for these requirements include the Interface Definition Document for ISS Visiting Vehicles, SSP 50235, January 1998, and the Rendezvous and Proximity Operations Design Reference for the ISS, JSC 27240, May 1999.

2.8.3 Designs shall provide a manual capability to monitor and conduct proximity operations, docking, and undocking (Requirement 30790).

This requirement does not preclude autonomous operations.

2.9 Analysis and Assurance of Critical Functions

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 (Requirement 30793).

A specific set of critical functions is required to ensure human safety and mission success during each phase of the mission (Requirement 30794). Priority should be given to those functions required to provide a safe return of the crew and passengers and protect ground processing personnel and the public. The set of critical functions will vary with the mission (such as ETO, BEO, and the phase of the mission). For example, a different set of functions is required for an Earth-Orbiting SS than for a planetary surface mission. Likewise, a different set is required to safely return a crew from the cruise portion of a mission to Mars than that required during the descent to landing phase. The human-rating plan must describe critical functions required to meet system and program safety requirements by mission phase and design features to ensure their availability (Requirement 30795).

2.9.2 The program shall incorporate critical functions, defined in the human-rating plan, into the design documentation prior to the Preliminary Design Review (PDR) (Requirement 30796).

This set of critical functions should be specifically identified early in the system design phase to ensure all potential mission scenarios

| TOC | Change | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |
 
| NODIS Library | Program Management(8000s) | Search |

DISTRIBUTION:
NODIS


This Document is Obsolete and Is No Longer Used.
Check the NODIS Library to access the current version:
http://nodis3.gsfc.nasa.gov