1. Purpose

This topic discusses the relationship between the requirements and associated processes for NPR 7150.2, NASA Software Engineering Requirements

1.1 Introduction

1.1.1 Relevant Guidance in NPR 7150.2

As discussed elsewhere, the NPR 7150.2 requirements applicability to the software being developed is determined by the contents of its Appendix C, Requirements Mapping Matrix. Requirement SWE-139 implements the contents of Appendix C. NPR 7150.2 applies to the development of software models and simulations. The NASA-STD-7009, in turn, describes how models and simulations are to be verified within the bounds of the governing SWE requirements of the NPR 7150.2.

NPR 7150.2 references the content of NASA-STD-7009 via requirement SWE-070 in the presentation of the requirement in its section 4.5.6 and the accompanying Note:

"4.5.6 The project manager shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment." (See SWE-070)

1.1.2 Applicability and Scope of NASA-STD-7009

The applicability and scope are stated in section 1.2 of NASA-STD-7009, where the acronym "M&S" denotes "models and simulations":

This NASA Technical Standard establishes uniform practices in modeling and simulation to ensure essential requirements are applied to their design, development, and use, while ensuring acceptance criteria are defined by the program/project and approved by the responsible Technical Authority.

This NASA Technical Standard provides an approved set of requirements, recommendations, and criteria with which models and simulations (M&S) may be developed, accepted, and used in support of NASA activities. As the M&S disciplines employed and application areas involved are broad, the common aspects of M&S across all NASA activities are addressed. The discipline-specific details of a given M&S should be obtained from relevant recommended practices.

1.1.3 Implications for Other Models and Simulations

For all other models and simulations that are deemed by the M&S Risk Assessment to be in the scope of NASA-STD-7009, there is the need to ensure that the requirements of both documents are satisfied. From the perspective of NASA-STD-7009, some of the requirements in NPR-7150.2 are not related to M&S, some are supplemental to requirements in NASA-STD-7009, and others are subsets of requirements in NASA-STD-7009.

1.1.4 Rationale for STD-7009

The NASA Standard for Models and Simulations (NASA-STD-7009) had its genesis in the Space Shuttle Columbia Accident Investigation (2003). Generally, its purpose is to improve the "development, documentation, and operation of models and simulations" (Diaz Report) and per a September 2006 memo from the Office of the Chief Engineer "which include a standard method to assess the credibility of the models and simulations". After an approximately three-year development period, the NASA Standard for Models and Simulations, NASA-STD-7009 was approved by NASA's Engineering Review Board on July 11, 2008, for voluntary use.

NASA-STD-7009 holds a unique place in the world of modeling and simulation in that it is, by direction, generally applicable to all types of models and simulations (M&S) and in all phases of development, though it is primarily focused on the results of an M&S-based analysis. All standards and recommended practices for M&S to date have either been focused on a single type of M&S (e.g., structures, fluids, electrical controls, etc.) or a particular phase of M&S development (e.g., verification, validation, etc.). NASA management is confronted with numerous types of analyses that may be involved in making critical decisions. Depending on the situation at hand, a common framework for understanding the results and assessing the credibility of that analysis may seem intuitive. However, this is complicated by the vast differences in engineering systems, and, thus, the adoption of a standard like this has been slow.

After formal approval in July 2008, and the update in 2016, the NASA-STD-7009 was largely left to the individual program, project, or M&S practitioner to adopt as they wished. While already existing programs and projects were not required to adopt it, new programs and projects were to adopt it, depending on their needs, desires, and criticality of the M&S-based analysis at hand.

1.1.5 Guidance for NASA-STD-7009

Guidance for use and application of NASA-STD-7009 can be found in the NASA-HDBK-7009 Handbook 

2. Resources

2.1 References

2.2 Tools

3. Lessons Learned

3.1 NASA Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

• Performance Decrease due to Propulsion Thruster Plume Impingement on the Voyager Spacecraft, Lesson Number: 0377

  Swerefn
  refnum 582

  : "A 21% shortfall in Voyager's velocity change was suspected to be due to exhaust plume impingement. Due to the complexity of spacecraft/thruster configurations, additional care must be taken in the development and utilization of spacecraft and plume models. Analysis should be conducted on early and final designs.".

3.2 Other Lessons Learned

The requirements for a NASA Standard have matured from the Columbia Accident Investigation Board (CAIB) Report.  The CAIB report found problems pertaining to "ineffective and inconsistent application of M&S tools, along with cases of misuse."  It called on NASA to "develop, validate, and maintain physics-based computer models to evaluate Thermal Protection System damage from debris impacts. These tools should provide realistic and timely estimates of any impact damage from possible debris from any source that may ultimately impact the Orbiter." NASA was to establish impact damage thresholds that trigger responsive corrective action, such as on-orbit inspection and repair, when indicated.

Lessons Learned and their applicability to the need to perform verification and validation are well documented in the above identified resources.  These should be reviewed and retained by any program or project utilizing Modeling and Simulation products throughout the Software development life cycle.