NASA has two significant independent classification schemas for software: (1) a software engineering classification as described in NPR 7150.2, NASA Software Engineering Requirements, Appendix D, and (2) a software safety definition as described in NASA-STD-8739.8, Software Assurance Standard, Appendix A. SWE-020SWE-020 - Software Classification describes the relationship between these classifications. For a given system or subsystem, software is expected to be uniquely defined within a single classification pair (software engineering classification X software safety definition). Knowing this pair determines the minimal set of software requirements from NPR 7150.2 needing to be addressed (via Appendix C of NPR 7150.2) by the project's software team.
The tools found here are aides to those responsible for determining both the software classification and the software safety criticality.
1.1 Safety Criticality
Defining software safety criticality involves the determination of whether the software is performing a safety-critical function, including verification of a safety-critical software, hardware, or operations component, subsystem, or system.
The safety-critical assessment tool is a question-and-answer-based guide that has been built as a starting point in determining if software is safety critical. The tool is created from the "Litmus Test" as captured in NASA-STD-8719.13, NASA Software Safety Standard $param0. Performing this test is part of the software safety criticality assessment. It is only the first step, and other analyses need to follow. These follow-on analyses assess the amount of critical software within a system, the level of autonomy of that software, the time to criticality, as well as the severity and likelihood of failure of each software safety control or hazard mitigation feature implemented in the software.
All Safety-critical software has to be classified as Class D or higher.
1.2 Classification Diagrams and Descriptions
Software classification is the determination of NPR 7150.2 requirement applicability for a specific system or sub-system. As stated in NPR 7150.2: "These definitions are based on 1) usage of the software with or within a NASA system, 2) criticality of the system to NASA's major programs and projects, 3) extent to which humans depend upon the system, 4) developmental and operational complexity, and 5) extent of the Agency's investment."
For a given system or subsystem, software is expected to be uniquely defined within a single class. If more than one software class appears to apply, then assign the higher of the classes to the system/subsystem. Any potential discrepancies in classifying software within Classes A through E are to be resolved using the definitions and the five underlying factors listed in the previous paragraph. Engineering and Safety and Mission Assurance provide dual Technical Authority chains for resolving classification issues. The NASA Chief Engineer is the ultimate Technical Authority for software classification disputes concerning definitions in this NPR.
The software classification tool is a question-and-answer-based guide that has been built to help identify the most likely software classification, based on the answers that one provides to each question. This tool is only an additional resource to help determine a system's or sub-system's classification and is not meant to be an authority regarding software classifications. As stated in Appendix D of NPR 7150.2: "Any potential discrepancies in classifying software within Classes A - E are to be resolved using the definitions and the five underlying factors listed in the previous paragraph. Engineering and Safety and Mission Assurance provide dual Technical Authority chains for resolving classification issues, and the NASA Headquarters' Chief Engineer is the ultimate Technical Authority for software classification disputes..."