NASA Procedural Requirements

NPR 8715.3D Effective Date: December 16, 2021 Expiration Date: December 21, 2026

Subject: NASA General Safety Program Requirements

Responsible Office: Office of Safety and Mission Assurance

Chapter 2. System Safety

2.1 Introduction

2.1.1 This chapter establishes requirements for the implementation of system safety processes to support decision making aimed at ensuring human safety, asset integrity, and mission success in programs/projects.

2.1.2 System safety assessment is a disciplined, systematic approach to the analysis of risks resulting from hazards that can affect humans, the environment, and mission assets. It is a critical first step in the development of risk management strategies. System safety covers the total spectrum of technical risk and management activities including safety and risk assessments and safety performance monitoring.

2.1.3 The format of this chapter is different than that of the rest of this NPR because of the need to discuss advanced concepts in system safety by the references.

2.2 Institutional Roles and Responsibilities

2.2.1 Mission Directorate Associate Administrators, Center Directors, program and project managers, and line managers shall ensure that system safety activities are conducted for all programs and projects including system acquisitions, in-house developments (research and technology), design, construction, fabrication and manufacture, experimentation and test, packaging and transportation, storage, checkout, launch, flight, reentry, retrieval and disassembly, maintenance and refurbishment, modification, and disposal.

2.2.2 Center Directors, through their Center SMA Directors, shall ensure that knowledgeable system safety and technical risk analysts are made available to program/project managers and Center engineering directors to define and conduct system safety activities, including assurance of prime contractor system safety activities.

2.3 System Safety Framework

NASA's framework for system safety is described in NASA/SP-2010-580, NASA System Safety Handbook, Volume 1: System Safety Framework and Concepts for Implementation, and NASA/SP-2014-612, NASA System Safety Handbook Volume 2: System Safety Concepts, Guidelines, and Implementation Examples.

2.4 Scope of System Safety Modeling

2.4.1 Decision makers throughout the entire life cycle of the project, beginning with concept design and concluding with decommissioning, must consider safety. However, the level of formality and rigor that is involved in implementing the system safety processes should match project potential consequences, life cycle phase, life cycle cost, and strategic importance. To assist in determining the scope of activities for safety evaluations as a function of project characteristics, two tables are provided. The categorization scheme identified in Table 2.1 is used to determine a project priority. This table is similar to Table 1 from NPR 8705.5, Probabilistic Risk Assessment (PRA) Procedures for NASA Programs and Projects.

2.4.2 Once the project priority is determined, the scope of system safety modeling is determined using Table 2.2.

2.4.3 Projects identified as "Priority I" ranking from Tables 2.1 are generally the most visible and complex of NASA's product lines. Because of this, the system safety technical processes for Priority I projects must include probabilistic risk assessment as specified in NPR 8705.5, Probabilistic Risk Assessment (PRA) Procedures for NASA Programs and Projects. For Priority II or III projects, Table 2.2 provides latitude to adjust the scope of system safety modeling. This graded approach to the application of system safety modeling also operates on another dimension. That is, the level of rigor and detail associated with system safety modeling activities must be commensurate with the availability of design and operational information. The two-dimensional nature of the graded approach is intended to ensure that allocation of resources to system safety technical activities considers the visibility and complexity of the project and to ensure that the level of rigor associated with system safety models follows the level of maturity of the system design.

Note: For example, during the formulation phase, an order-of-magnitude or bounding assessment may be performed. In this type of assessment, the probability and/or the magnitude of consequence is approximated or bounded instead of deriving a best-estimate. These assessments are useful for screening purposes and initial risk tradeoff studies.

2.5 Core Requirements for System Safety Processes

2.5.1 The system safety modeling approaches previously described should be implemented as part of technical processes that represent system safety activities. Conceptually, system safety activities consist of three major technical processes as shown in the circular flow diagram in Figure 2.6. These processes are designed to systematically and objectively analyze hazards and identify the mechanism for their elimination or control. These processes begin in the conceptual phase and extend throughout the life cycle of a system including disposal. In general, requirements for safety system technical processes must provide a risk-informed perspective to decision makers participating in the project life cycle. The three critical technical processes to a successful system safety program are (1) system safety modeling, (2) life cycle applications of models for risk-informed decisions and, (3) monitoring safety performance. The circular flow indicates that these technical processes are linked and are performed throughout the project life cycle. A System Safety Technical Plan is used to guide the technical processes and establish roles and responsibilities. This plan is established early in the formulation phase of each project and updated throughout the project life cycle.

Figure 2.1, The System Safety Technical Processes

2.5.2.1 The SSTP is designed to be a technical planning guide for the technical performance and management of the system safety activities. The SSTP can be a stand-alone document, or part of the SMA plan or the Systems Engineering Management Plan (SEMP). It provides the specifics of the system safety modeling activities and describes what and how safety adverse consequences will be modeled, how system safety models (qualitative and probabilistic risk assessments) will be integrated and applied for risk-informed decision making and safety monitoring, how the technical team(s) responsible for generating and maintaining system safety models will interact with the system engineering organizations, the reporting protocol, and the cost and schedule associated with accomplishing system safety modeling activities in relation to the critical or key events during all phases of the life cycle.

2.5.2.2 Project managers shall:

a. Ensure, for Category I project/programs, that the SSTP is approved by the governing Program Management Council (PMC) and has concurrence by the cognizant SMA managers and the project's senior engineer.

b. Ensure that the System Safety Manager and the prime contractor (for out-of-house projects) have the resources to implement the SSTP.

c. Ensure, for Category I project/programs, that changes to the SSTP are approved by the governing PMC and have concurrence by the Chief, Safety and Mission Assurance.

d. When the SSTP is not an integral part of the SEMP, ensure the SSTP is coordinated with the SEMP for the integration of system safety activities with other system engineering technical processes.

2.5.2.3 The Center SMA Director shall:

a. In coordination with the program/project manager, assign a System Safety Manager to have specific responsibility for the development and implementation of the SSTP.

b. Ensure that the assigned System Safety Manager has demonstrated expertise in safety analysis including, in the case of Category I and II projects, the application of probabilistic risk assessment techniques.

c. Ensure that all personnel with project safety oversight responsibilities are funded by other than direct project funding sources.

2.5.2.4 The assigned System Safety Manager shall:

a. Develop a SSTP during the project formulation phase and update the plan throughout the system life cycle.

b. Ensure that the scope of system safety technical processes in the SSTP follows the graded approach specified in Tables 2.1 and 2.2.

c. Ensure that the SSTP provides the specifics of the system safety modeling activities and their application to risk-informed decision making and safety monitoring throughout the project life cycle.

d. In consultation with the project managers, establish and document in the SSTP the objectives and scope of the system safety tasks and define applicable safety deliverables and performance measures.

e. Provide technical direction and manage implementation of system safety activities as specified in the SSTP.

f. Ensure that system safety engineering activities are integrated into system engineering technical processes.

g. Determine the acceptability of residual risk stemming from safety assessments.

h. Ensure that specific safety requirements are integrated into overall programmatic requirements and are reflected in applicable program and planning documents including the statement of work for contractor designs.

i. Maintain appropriate safety participation in the program design, tests, operations, failures and mishaps, and contractor system safety activities at a level consistent with mishap potential for the life of the program.

j. Establish an independent safety reporting channel to keep the Center SMA Director apprised of the system safety status (including tests and operations), particularly regarding problem areas that may require assistance from the Center, the NASA Engineering and Safety Center, or Headquarters.

k. Support OSMA requirements for audits, assessments, and reviews.

2.5.3 System Safety Modeling

2.5.3.1 Developing and maintaining technically sound and tractable safety models are essential activities for ensuring safety. In these activities, analysts use all the relevant and available information including design documents, operational procedures, test results, operational history, and human and software performance to develop comprehensive system safety models. Developing these models is multidisciplinary and may involve diverse and geographically dispersed groups. Thus, it is important for the safety modeling activities to be coordinated in order to ensure consistency and technical quality.

2.5.3.2 Safety models need to be synchronized with the system design and operational state-of-knowledge to ensure the models match the collected engineering information during operation with model predictions.

2.5.3.3 System Safety Managers shall ensure that the system safety modeling activities are fully integrated into system engineering and are supported by domain, systems, and specialty engineers.

2.5.3.4 System engineers shall:

a. Ensure that system safety models use systematic, replicable, and scenario-based techniques to identify hazards, to characterize the risk of accidents, to identify risk control measures, and to identify key uncertainties.

b. Initially conduct system safety analyses during project formulation and design concept phases (prior to the Preliminary Design Review) and maintain and update these analyses continuously throughout the project life cycle.

c. Ensure, for Category I and II program/projects, probabilistic risk assessment techniques are used for system safety analysis.

d. Ensure that the system safety models are developed in an iterative process to allow model expansion, model updating, and model integration as the design evolves and operational experience is acquired.

Note 1: Relevant leading-indicator (or precursor) events should be documented and evaluated for their impact on the system safety analyses assumptions. Trending of these precursor events should be conducted and contrasted to applicable performance measures.

Note 2: A precursor is an occurrence of one or more events that have significant failure or risk implications.

e. Use system specific and all relevant data including failure histories, mishap investigation findings, and the NASA Lessons Learned Information System in system safety analysis.

f. Maintain an up-to-date database of identified hazards, accident scenarios, probabilities and consequences, and key uncertainties throughout the life of the program.

g. Document the bases for the system safety analyses including key assumptions, accident scenarios, probabilities, consequence severities, and uncertainties such that they are traceable.

2.5.4 Application of System Safety Models for Risk-informed Decisions

2.5.4.1 Safety and technical risk considerations are critical in the decision-making process. When faced with a decision, several conflicting alternatives may be available to the decision maker. In a risk-informed decision-making framework, the decision maker considers safety and other technical attributes as well as programmatic attributes, such as cost and schedule, to select the best decision alternative.

2.5.4.2 Program/project managers shall:

a. Ensure that a framework is constructed for systematically incorporating system safety analysis results into the evaluation of decision alternatives.

b. Establish and document a formal and transparent decision-making process for hazard closure and formally accepting residual risk that has been determined to be acceptable by the cognizant technical authority.

Note: Closure of a hazard condition or other safety issue is the demonstration that all safety requirements expressly formulated to address the condition or issue have been satisfied.

c. Ensure acceptable residual risks are accepted in writing. (See paragraph 1.6 of this NPR.)

Note: Residual risk is the level of risk that remains present after applicable safety-related requirements have been satisfied. In a risk-informed context, such requirements may include measures and provisions intended to reduce risk from above to below a defined acceptable level.

d. Ensure that decisions to accept risk are coordinated with the governing SMA organization and communicated to the next higher level of management for review. (See paragraph 1.6.2 of this NPR.)

e. Where residual risks have been determined by either the cognizant technical authority or the cognizant SMA authority as "unacceptable," initiate risk mitigation/control activities, as appropriate, to reduce the risk to an acceptable level.

f. Ensure that the requirements of this Chapter are specified in related contracts, memoranda of understanding, and other agreement documents. (See Chapter 9 of this NPR.)

2.5.4.3 The System Safety Manager shall:

a. Ensure that system safety models are constructed to support the implementation of the risk-informed decision framework.

b. Ensure that the system safety models incorporate all the safety attributes important to risk-informed decision making by working with the project manager and other decision makers as deemed appropriate.

c. Establish the methods and tools that are used in the risk-informed framework.

d. Check and validate the methods and tools before implementation and obtain concurrence from the project manager.

e. Document the bases for the methods and tools used and analytical results.

2.5.5 Performance Monitoring

2.5.5.1 Safety, like other performance attributes, is monitored during the entire life cycle to ensure that an acceptable level of safety is maintained.

2.5.5.2 Project managers shall ensure that the performance attributes and precursors that are identified as being important indicators of system safety are monitored.

2.5.5.3 The System Safety Manager shall:

a. Establish the methods and tools that are used in the performance monitoring and precursor assessments.

b. Check and validate the methods and tools used for performance monitoring and precursor assessments before implementation.

c. Maintain an up-to-date database of the performance monitoring results and precursor results.

d. Ensure that the performance monitoring and precursor data are fed back into system safety analyses and the results updated.

e. Document the bases for the methods and tools that are used in the performance monitoring and precursor assessments.

2.6 System Safety Reviews

2.6.1 System Safety and Mission Success Program Reviews are conducted in conjunction with other program milestones. The purpose of these reviews is to evaluate the status of system safety and risk analyses, risk management, verification techniques, technical safety requirements, and program implementation throughout all the phases of the system life cycle.

2.6.2 The program/project manager shall:

a. Conduct periodic system safety and mission success reviews of their program/project depending on the complexity of the system.

Note: The greater the risks, complexity of the system, or visibility of the programs, the greater the independence and formality of the reviews.

b. Document the periodicity of the System Safety and Mission Success Program Reviews in the SSTP.

c. Ensure that the System Safety and Mission Success Program Reviews focus on the evaluation of management and technical documentation, hazard closure, and the safety residual risks remaining in the program at that stage of development.

d. Establish and maintain dedicated independent assessment activities for Priority I programs and projects, such as the Constellation Program.

2.6.3 The System Safety Manager shall:

a. Conduct periodic independent reviews of the system safety tasks keyed to project milestones.

b. Assist and support independent review groups established to provide independent assessments of the program.

c. Support the OSMA independent safety assessment process to determine readiness to conduct tests and operations having significant levels of safety risks.

2.7 Change Review

2.7.1 Systems are changed during their life cycle to enhance capabilities, improve safety, provide more efficient operation, and incorporate new technology. With each change, the original safety aspects of the system can be impacted, either increasing or reducing the risk. Any aspect of controlling hazards can be weakened, risks can be increased, or conversely, risks can be decreased. Even a change that appears inconsequential could have significant impact on the baseline risk of the system. Accordingly, proposed system changes should be subjected to a safety review or analysis, as appropriate, to assess the safety and risk impacts, including implications on controls and mitigations for significant hazards and failure modes.

2.7.2 The project manager and the System Safety Manager shall:

a. Update the system safety analyses to identify any change in risk.

b. Ensure that safety personnel assess the potential safety impact of the proposed change and any changes to the baseline risk and previously closed hazards.

c. Ensure that proposed changes to correct a safety problem are analyzed to determine the amount of safety improvement (or detriment) that would result from incorporation of the change.

d. Ensure that the safety impact for every change that is proposed to a program baseline (even if the statement is "No Impact") is documented.

2.8 Documentation

2.8.1 The maintenance of the SSTP is required to provide ready traceability from the baseline safety requirements, criteria, and efforts planned in the conceptual phases through the life cycle of the program.

2.8.2 The project manager (or designated agent) and the System Safety Manager shall:

a. Ensure that all pertinent details of the system safety analysis and review are traceable from the initial identification of the risks through their resolution and any updates in the SSTP.

b. Ensure that records are maintained per NPR1441.1, NASA Records Retention Schedules.

2.8.3 The System Safety Manager shall:

a. Submit a system safety analysis report to the program/project manager at each milestone (formulation, evaluation, implementation, or other equivalent milestones [e.g., Safety Requirements Review, Preliminary Design Review, Critical Design Review, and Flight Readiness Review]) detailing the results of the system safety analyses completed to date to document the status of system safety tasks.

Note: Safety requirements include both deterministic and risk-informed requirements. A deterministic safety requirement is the qualitative or quantitative definition of a threshold of action or performance that must be met by a mission-related design item, system, or activity in order for that item, system, or activity to be acceptably safe. A risk-informed requirement is a safety requirement that has been established, at least in part, on the basis of the consideration of a safety-related risk metric and its associated uncertainty.

b. Ensure that each submitted revision to the system safety analysis report lists the risks that have been addressed, the risks that have yet to be addressed, and expected residual risks that will remain following the implementation of risk reduction strategies.

c. Ensure that the system safety analysis report documents management and technical changes that affect the established safety baseline (by changes in the planned approach, design, requirements, and implementation) and is revised when required.

d. Ensure that a final approved system safety analysis report is produced that contains a verification of the resolution of the risks and a written acceptance of the residual risks from the program/project manager to complete the audit trail.

DISTRIBUTION:
NODIS

This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.