bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D

7.02 - Classification and Safety-Criticality

1. Introduction

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-020 - Software Classification describes the relationship between these classifications. For a given system or subsystem, the 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 safety-critical software, hardware, or operations component, subsystem, or system.

NASA recommends that projects used the updated guidance for determining safety-critical software, as defined in NASA-STD-8739.8.

Safety-Critical Software Determination

Software is classified as safety-critical if the software is determined by and traceable to a hazard analysis. Software is classified as safety-critical if it meets at least one of the following criteria:

  1. Causes or contributes to a system hazardous condition/event,
  2. Controls functions identified in a system hazard,
  3. Provides mitigation for a system hazardous condition/event,
  4. Mitigates damage if a hazardous condition/event occurs,
  5. Detects, reports, and takes corrective action if the system reaches a potentially hazardous state.

Note: See Appendix A for guidelines associated with addressing software in hazard definitions. See Table 1, 3.7.1, SWE-205 for more details. Consideration for other independent means of protection (software, hardware, barriers, or administrative) should be a part of the system hazard definition process.

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) the extent of the Agency's investment."

For a given system or subsystem, the software is expected to be uniquely defined within a single class. If more than one software class appears to apply, then assign the higher 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.

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..."

2. Classification Descriptions

The material in this table is from Appendix D of NPR 7150.2 039.

Definition Examples and Exclusions

Class A Human-Rated Space Software Systems

Human Space Flight Software Systems*:

Ground and flight software systems developed and/or operated by or for NASA that are needed to perform a primary mission objective of human space flight and directly interact with human space flight systems. Limited to software required to perform "vehicle, crew, or primary mission function," as defined by software that is:

1. Required to operate the vehicle or space asset (e.g., spacesuit, rover, or outpost), including commanding of the vehicle or asset,
2. Required to sustain a safe, habitable 1 environment for the crew,
3. Required to achieve the primary mission objectives,
4. Required to directly prepare resources (e.g., data, fuel, power) that are consumed by the above functions.


* - Includes software involving launch, on orbit, in space, surface operations, entry, descent, and landing.


1 - Current standards that address habitability and environmental health, including atmospheric composition and pressure, air and water quality and monitoring, acceleration, acoustics, vibration, radiation, thermal environment, combined environmental effects, and human factors, are documented in NASA-STD-3000, Volumes 2 – NASA Space Flight Human System Standard: Human Factors, Habitability, and Environmental Health  498.

Examples of Class A software (human-rated space flight) include but are not limited to the mission phases listed below: 

During Launch: abort modes and selection; separation control; range safety; crew interface (display and controls); crew escape; critical systems monitoring and control; guidance, navigation, and control; and communication and tracking.

On-Orbit/In Space: Extra Vehicular Activity (EVA); control of electrical power; payload control (including suppression of hazardous satellite and device commands); critical systems monitoring and control; guidance, navigation, and control; life support systems; crew escape; rendezvous and docking; failure detection; isolation and recovery; communication and tracking; and mission operations.

On Ground: pre-launch and launch operations; Mission Control Center (and Launch Control Center) front-end processors; spacecraft commanding; vehicle processing operations; re-entry operations; flight dynamics simulators used for ascent abort calls; and launch and flight controller stations for manned spaceflight.

Entry, Descent, and Landing (EDL): command and control; aero-surface control; power; thermal; and fault protection; and communication and tracking.

Surface Operations: planet/lunar surface EVA and communication and tracking.

Exclusions

Class A does not include:

  1. The software which happens to fly in space but is superfluous to mission objectives (e.g., software contained in an iPod carried on board by an astronaut for personal use);
     
  2. Software that exclusively supports aeronautics, research and technology, and science conducted without spaceflight applications; or
  3. Systems (e.g., simulators, emulators, stimulators, facilities) used to test Class A systems containing software in a development environment.

 Class B Non-Human Space Rated Software Systems or Large-Scale Aeronautics Vehicles

1. Space Systems involve flight and ground software that must perform reliably to accomplish primary mission objectives or major function(s) in non-human space-rated systems. Included is software involving launch, on orbit, in space, surface operations, entry, descent, and landing. These systems are limited to software that is:

(a) Required to operate the vehicle or space asset (e.g., orbiter, lander, probe, flyby spacecraft, rover, launch vehicle, or primary instrument) such as commanding of the vehicle or asset,

(b) Required to achieve the primary mission objectives, or

(c) Required to directly prepare resources (data, fuel, power, etc.) that are consumed by the above functions.

2. Airborne Vehicles include large-scale1 aeronautic vehicles unique to NASA in which the software:

(a) Is integral to the control of an airborne vehicle, 

(b) Monitors and controls the cabin environment, or 

(c ) Monitors and controls the vehicle's emergency systems. 

This definition includes software for vehicles classified as "test," "experimental," or "demonstration" that meets the above definition for Class B software. Also included are systems in a test or demonstration where the software's known and scheduled intended use is to be part of a Class A or B software system.


1 - Large-scale (life-cycle cost exceeding $250M) fully integrated technology development system — see NPR 7120.8, section  269.

Examples of Class B software include, but are not limited to:


1. Space, Launch, Ground,  EDL (Entry, Descent, and Landing), and Surface Systems:

Propulsion systems; power systems; guidance navigation and control; fault protection; thermal systems; command and control ground systems; planetary/lunar surface operations; hazard prevention; primary instruments; science sequencing engine; simulations that create operational EDL parameters; subsystems that could cause the loss of science return from multiple instruments; flight dynamics and related data; launch and flight controller stations for non-human spaceflight.

2. Aeronautics Vehicles (Large Scale NASA Unique):

Guidance, navigation, and control; flight management systems; autopilot; propulsion systems; power systems; emergency systems (e.g., fire suppression systems, emergency egress systems, emergency oxygen supply systems, traffic/ground collision avoidance system); and cabin pressure and temperature control.

Exclusions

Class B does not include:

  1. Software that exclusively supports non-primary instruments on non-human space-rated systems (e.g., low-cost non-primary university-supplied instruments), or
  2.  Systems (e.g., simulators emulators, stimulators, facilities) used in testing Class B systems containing software in a development environment.

Class C Mission Support Software or Aeronautic Vehicles, or Major Engineering/ Research Facility Software

1. Space Systems include the following types of software:

(a) Flight or ground software necessary for the science return from a single (non-primary) instrument, 

(b) Flight or ground software that is used to analyze or process mission data, 

(c) Other software for which a defect could adversely impact the attainment of some secondary mission objectives or cause operational problems,

(d) Software used for the testing of space assets, 

(e) Software used to verify system requirements of space assets by analysis, or 

(f) Software for space flight operations that are not covered by Class A or B software. 

2. Airborne Vehicles include systems for non-large scale aeronautic vehicles in which the software:

(a) Is integral to the control of an airborne vehicle,

(b) Monitors and controls the cabin environment, or 

(c) Monitors and controls the vehicle's emergency system. 

Also included are systems on an airborne vehicle (including large-scale vehicles) that acquire, store, or transmit the official record copy of flight or test data.

3. Major Engineering/Research Facility is a system that operates a major facility for research, development, testing, or evaluation (e.g., facility controls and monitoring, systems that operate facility-owned instruments, apparatus, and data acquisition equipment).

Examples of Class C software include, but are not limited to:


1. Space Systems:

Software that supports prelaunch integration and test; mission data processing and analysis; analysis software used in trend analysis and calibration of flight engineering parameters; primary/major science data collection storage and distribution systems (e.g., Distributed Active Archive Centers); simulators, emulators, stimulators, or facilities used to test Class A, B, or C software in a development; integration and test environments (development environment, including environments used from unit testing through validation testing); software used to verify system-level requirements associated with Class A, B, or C software by analysis (e.g., guidance, navigation and controls system performance verification by analysis); simulators used for mission training; software employed by network operations and control (which is redundant with systems used at tracking complexes); command and control of non-primary instruments; and ground mission support software used for secondary mission objectives, real-time analysis, and planning (e.g., monitoring, consumables analysis, mission planning).

2. Aeronautics Vehicles:

Guidance, navigation, and control; flight management systems; autopilot; propulsion systems; power systems; emergency systems (e.g., fire suppression systems, emergency egress systems, emergency oxygen supply systems, traffic/ground collision avoidance system); cabin pressure and temperature control; in-flight telescope control software; aviation data integration systems; and automated flight planning systems and primary/major science data collection storage and distribution systems (e.g., Distributed Active Archive Centers).

3. Major Engineering/Research Facility:

Major Center facilities; data acquisition and control systems for wind tunnels, vacuum chambers, and rocket engine test stands; ground-based software used to operate a major facility telescope; and major aeronautic applications facilities (e.g., air traffic management systems; high fidelity motion-based simulators).

Exclusions

Systems unique to a research, development, test, or evaluation activity in a major engineering/research facility or airborne vehicle in which the system is not part of the facility or vehicle and does not impact the operation of the facility or vehicle.


Class D Basic Science/Engineering Design and Research and Technology Software

1. Basic Science/Engineering Design includes:

(a) Ground software that performs secondary science data analysis,

(b) Ground software tools that support engineering development,

(c) Ground software used in testing other Class D software systems,

(d) Ground software tools that support mission planning or formulation,

(e) Ground software that operates a research, development, test, or evaluation laboratory (i.e., not a major engineering/research facility), or

(f) Ground software that provides decision support for non-mission critical situations.

2. Airborne Vehicle Systems include:

(a) Software whose anomalous behavior would cause or contribute to a failure of system function resulting in a minor failure condition for the airborne vehicle (e.g., the Software Considerations in Airborne Systems and Equipment Certification, DO-178B, "Class D"),

(b) Software whose anomalous behavior would cause or contribute to a failure of system function with no effect on airborne vehicle operational capability or pilot workload (e.g., the Software Considerations in Airborne Systems and Equipment Certification, DO-178B, "Class E"), or

(c) Ground software tools that perform research associated with airborne vehicles or systems.

3. Major Engineering/Research Facility related software includes research software that executes in a major engineering/research facility but is independent of the operation of the facility. 

Examples of Class D software include, but are not limited to:

1. Basic Science and Engineering Design:

Engineering design and modeling tools (e.g., computer-aided design and computer-aided manufacturing (CAD/CAM), thermal/structural analysis tools); project assurance databases (e.g., problem reporting, analysis, and corrective action system, requirements management databases); propulsion integrated design tools; integrated build management systems; inventory management tools; probabilistic engineering analysis tools; test stand data analysis tools; test stand engineering support tools; experimental flight displays evaluated in a flight simulator, and tools used to develop design reference missions to support early mission planning.

2. Airborne Vehicles:

Software tools for designing advanced human-automation systems; experimental synthetic-vision displays; and cloud-aerosol light detection and ranging installed on an aeronautics vehicle.

Exclusions

Class D does not include:

1. Software that can impact primary or secondary mission objectives or cause loss of data that is generated by space systems,

2. Software that operates a major engineering/research facility,

3. Software that operates an airborne vehicle, or

4. Space flight software (i.e., software that meets the space flight portions of Class A, B, or C Software Classifications).

Class E Design Concept and Research and Technology Software

Definition:

  1. Software developed to explore a design concept or hypothesis but not used to make decisions for an operational Class A, B, or C system or to-be-built Class A, B, or C system,
  2.  Software used to perform minor desktop analysis of science or experimental data. Class E software cannot be safety-critical software. If the software is classified as safety-critical software, then it has to be classified as Class D or higher.

Examples of Class E software include, but are not limited to:

Parametric models to estimate performance or other attributes of design concepts; software to explore correlations between data sets; line of code counters; file format converters; and document template builders.

Exclusions

Class E does not include:

1. Space flight systems (i.e., software that meets the space flight portions of Class A, B, or C Software Classifications),

2. Software developed by or for NASA to directly support an operational system (e.g., human-rated space system, robotics spacecraft, space instrument, airborne vehicle, major engineering/research facility, mission support facility, primary/major science data collection storage and distribution systems),

3. Software developed by or for NASA to be flight qualified to support an operational system,

4. Software that directly affects primary or secondary mission objectives,

5. Software that can adversely affect the integrity of engineering/scientific artifacts,

6. Software used in technical decisions concerning operational systems,

7. Software that has an impact on operational vehicles, or

8. safety-critical Software.

Business and Information Technology Infrastructure Software

Class F General Purpose Computing, Business and IT Software (Multi-Center or Multi-Program and Project)

Definition: General purpose computing Business and IT software used in support of the Agency, multiple Centers, or multiple programs and projects, as described for the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture)  070 , and for the following portfolios: voice, wide-area network, a local-area network, video, data Centers, application services, messaging and collaboration, and public Web. A defect in Class F software is likely to affect the productivity of multiple users across several geographic locations and may affect mission objectives or system safety. Mission objectives can be cost, schedule, or technical objectives for any work that the Agency performs.

Examples of Class F software include but are not limited to:

Agency-wide enterprise applications (e.g, WebTADS, SAP, eTravel, ePayroll, Business Warehouse), including mobile applications; agency-wide educational outreach software; software in support of the NASA-wide area network; and the NASA Web portal. 

Class G General Purpose Computing, Business and IT Software (Single Center or Project)

Definition: General purpose computing, business, and IT software used in support of a single Center or project, as described for locally deployed portions of the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture)  070 and the following portfolios: voice, a local-area network, video, data Centers, application services, messaging and collaboration, and public Web. A defect in Class G software is likely to affect the productivity of multiple users in a single geographic location or workgroup but is unlikely to affect mission objectives or system safety.

Examples of Class G software include but are not limited to:

Software for Center custom applications such as Headquarters' Corrective Action Tracking System; Headquarters' User Request Systems; content management system mobile applications; and Center or project educational outreach software. 

Class H General Purpose Desktop Software

Definition: General purpose desktop software as described for the General Purpose Infrastructure To-Be Component (Desktop Hardware and Software Portfolio) of the NASA Enterprise Architecture, Volume 5 (NASA To-Be Architecture) 070. A defect in Class H software may affect the productivity of a single user or small group of users but generally will not affect mission objectives or system safety, but a defect in desktop IT security-related software, e.g., anti-virus software, may lead to loss of functionality and productivity across multiple users and systems.

Examples of Class H software include but are not limited to:

Desktop applications such as word processing applications, spreadsheet applications, and presentation applications. 

3. Classification Examples

The following chart lists projects by software classification as examples of how software has been classified for Class A-E software. The project can use these examples to help inform its classification activities.

Projects

Software Classification

Flight Software on the Commercial Crew Programs

A

Free Flyer Project

A

Ground Systems Development and Operations (GSDO) Program - End-to-End Command and Control

A

International Space Station (ISS) Avionics & Software Critical Flight Software

A

Multi-Purpose Crew Vehicle (EFT-1) Flight Software

A

Multi-Purpose Crew Vehicle (EM-1) Flight Software

A

Multi-Purpose Crew Vehicle (EM-2) Flight Software

A

Orion Flight Software

A

Space Launch System Flight Software

A

Space Shuttle Flight Software

A

Chandra Space Telescope Flight Software

B

CloudSat and the Cloud-Aerosol Lidar and Infrared Pathfinder Satellite Observation (CALIPSO) Flight Software

B

Cyclone Global Navigation Satellite System (CYGNSS) Flight Software

B

Flight Software on Various Small Satellite Missions (e.g., EDSN, BioSentinel, EuCROPIS)

B

Geostationary Operational Environmental Satellites (GOES-R) Flight Software

B

Gravity Recovery and Climate Experiment (GRACE) Flight Software

B

Ice, Cloud, and land Elevation Satellite (ICESat II) Flight Software

B

InSight (Interior Exploration using Seismic Investigations, Geodesy, and Heat Transport) Flight Software

B

Ionospheric Connection (ICON) Explorer Flight Software

B

James Webb Space Telescope (JWST) Flight Software

B

Joint Polar Satellite System (JPSS) Flight Software

B

Joint Polar Satellite System (JPSS (Ground))

B

Kepler: Flight Software

B

Kepler: Science Pipeline Software

B

Laser Communication Rely Demo

B

Magnetospheric Multiscale (MMS)

B

Mars Surface Mission/Mars 2020

B

Origins, Spectral Interpretation, Resource Identification, Security, Regolith Explorer (OSIRIS-REx)

B

Solar Probe Plus (SPP)

B

Space Network Ground Segment Sustainment (SGSS)

B

Stratospheric Aerosol and Gas Experiment (SAGE III) Flight Software, Experiment on ISS

B

Transiting Exoplanet Survey Satellite (TESS)

B

Tropospheric Emissions: Monitoring of Pollution (TEMPO) Flight Software

B

14x22-Foot Subsonic Wind Tunnel

C

20-Foot Vertical Spin Tunnel Rotary Balance Control System, Fan Control System

C

8-foot High-Temperature Tunnel

C

Advanced Microgravity Combustion Experiment (ACME)

C

Airborne Collision Avoidance System For Unmanned Aircraft (ACAS Xu)

C

AirSTAR (Flight Software)

C

Archive Next Generation software (ANGe)

C

Astrobee Flight and Ground Software

C

B1221 Research Complex

C

B1230 Data Acquisition Systems Laboratory

C

Clouds and the Earth's Radiant Energy System (CERES FM5 on NPP)

C

Clouds and the Earth's Radiant Energy System (CERES FM6 FVTS Simulator)

C

Clouds and the Earth's Radiant Energy System (CERES FM6 on NPOESS)

C

CloudSat and the Cloud-Aerosol Lidar and Infrared Pathfinder Satellite Observation (CALIPSO) Science Level 1, 2, and 3 Code

C

Cockpit Motion Facility

C

Combined Loads Test System

C

Compressor Station Automation Project

C

Flow Boiling Condensation Experiment (FBCE)

C

General Aviation Main (GAMain)

C

Lang+B56:B80ley Standard Real-Time Simulation and Core Vehicle Models (LaSRS Core)

C

Langley Data Center Atmospheric Flight and Entry Systems Cluster

C

LaRC Transonic Dynamics Tunnel ABDAS Upgrade

C

LaRC Transonic Dynamics Tunnel FAS Upgrade

C

NASA Data Acquisitions System (Ndas)

C

National Transonic Facility

C

Radiation Budget Instrument (RBI)

C

Radiation Dosimetry Experiment (RAD-X)

C

Radio Frequency Mass Gauge (RF Mass Gauge)

C

SOFIA Science Pipeline

C

Space Communications and Navigation (SCaN) Testbed

C

Space Launch System System Integration Lab (SIL) Ground Software

C

Spacecraft Fire Safety (Saffire)

C

Spacecraft Fire Safety Demonstration

C

Steam Distribution System (Steam Plant)

C

Stratospheric Aerosol and Gas Experiment (SAGE III) Ground Software, Experiment on ISS

C

Stratton Road Substation

C

Structures Laboratory

C

System Power Analysis for Capability Evaluation

C

Transiting Exoplanet Survey Satellite (TESS) Science Processing Operations Center (SPOC) Software

C

Transonic Dynamics Tunnel (TDT) Facility Automation System Upgrade

C

Vacuum Facility #5 (VF-5) Control Software

C

Various Health and Human Countermeasures Projects

C

Advanced Stirling Radio-Isotope Generator

D

Airspace and Traffic Operations Simulations (ATOS)

D

AirSTAR (Phase V Ground Facility Software)

D

COBRA Data Acquisition System

D

Deterministic and Statistical Link Budget Simulator (DSLB)

D

Flutter and Strength optimization Program for Lifting-Surface (FASTOP)

D

Glenn Extreme Environment Rig Control System

D

Multiple Axis Space Test Inertia Facility (MASTIF)

D

Optimal Trajectories by Implicit Simulation (OTIS)

D

Suite of computational
fluid dynamics simulation and design tools (FUN3D)

D

Various Facility Data Acquisition Systems

D

Various Facility Industrial Control System Software

D

Various Models and Simulation Software

D

Various Research Software Projects

D

Various SCAN Program Tools

D

Global Integrated Design Environment (GLIDE)

E

Unmanned Aircraft Systems Integration in the National Airspace System project, or UAS in the NAS, ADS-B

E

Various Research Software Projects

E

 4. Classification Tool Flowcharts

The following diagrams describe the operation of the classification tool. If you follow the chart below or print off the diagrams, you can use the mechanics of the tool offline. To download a PDF of these diagrams, which are appropriate for printing, click the appropriate "Download Printable Diagram" link below.

Start Here - Page 1

 

Aero - Page 2



Ground - Page 3

 


Non-human Rated - Page 4

 

Aero Ground - Page 5

 

Facility - Page 6

 

Non-human Ground - Page 7

 


5. Resources

6. Safety Critical Assessment

NASA recommends that projects used the updated guidance for determining safety-critical software, as defined in NASA-STD-8739.8.

Safety-Critical Software Determination

Software is classified as safety-critical if the software is determined by and traceable to a hazard analysis. Software is classified as safety-critical if it meets at least one of the following criteria:

  1. Causes or contributes to a system hazardous condition/event,
  2. Controls functions identified in a system hazard,
  3. Provides mitigation for a system hazardous condition/event,
  4. Mitigates damage if a hazardous condition/event occurs,
  5. Detects, reports, and takes corrective action if the system reaches a potentially hazardous state.

Note: See Appendix A for guidelines associated with addressing software in hazard definitions. See Table 1, 3.7.1, SWE-205 for more details. Consideration for other independent means of protection (software, hardware, barriers, or administrative) should be a part of the system hazard definition process.

If a NASA project is still using NASA-STD-8719.13B, then the following guidance applies:

NASA SOFTWARE SAFETY STANDARD, NASA-STD 8719.13B 271, describes the activities necessary to ensure that safety is designed into the software acquired or developed by NASA. All Program/Project Managers, Area Safety Managers, IT managers, and other responsible managers are to assess the inherent safety risk of the software in their programs. The magnitude and depth of software safety activities should reflect the risk posed by the software while fulfilling the requirements of this Standard.

Section 5 of the NASA-STD 8719.13B standard guides conducting a Software Safety Criticality Assessment (SCCA). Included in this section are

  • SCCA Part 1: Software Safety Litmus Test
  • SCCA Part 2: Software Risk Assessment
  • Applicability Matrix
  • SCCA Form - Form to document the results of the Software Safety Criticality Assessment (SSCA) which are required to be documented and approved.
  • No labels