National Aeronautics and Space Administration

5...4...3...2...1...

SPACE LAUNCH SYSTEM

November 18, 2019

IATF Safety Process Overview

Rayfael Roman
IATF Software Safety SME
www.nasa.gov/sls
www.nasa.gov/sls
 Overview

Software Safety (SwS) Process Overview:

• Before a hazardous condition/event occurs:

– Safety ensures that the system (HW & SW) detects malfunctions and takes appropriate
corrective actions. These are your functional safety requirements.

• A Fault-Tolerant design (Follows a Safety strategy):

– Defines the (worst) conditions that a system must cope with.
– Defines safety mechanisms for fault detection and recovery that must be implemented.
– Ensures that a system experiencing malfunctions remains operational and transitions into a
safe state.

• The Integrated Avionics Test Facility (IATF)(Using model based approach):

– Must carefully provide an environment to simulate the execution of fault tolerance in its
design and implementation when verifying and validating highly dynamic safety-critical
applications (e.g., SLS Flight Software (FSW)).

2
www.nasa.gov/sls
 Knowns

ARTEMIS & MAESTRO will not be used in the Space Launch System
(SLS) vehicle.

• The purpose of using the IATF is to:

1. To simulate components that will be used in the SLS mission and identify
defects in the system and its individual components.
2. Increase confidence that the flight system will perform reliably and safely and
respond to any hazards that could occur during flight.

3
www.nasa.gov/sls
 NASA Standards

NASA-STD-8719.13C NASA Software Safety Standard

– Scope – “Describes the activities necessary to ensure that safety is designed into
the software that is 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 individual 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 1.2.1 - “This Standard applies to all software … that is determined to be

safety critical per the Software Safety Litmus Test in Appendix A. Software
includes software tools (e.g. simulators, models, emulators, compiler libraries,
built in memory checkers, materials analysis, trajectory analysis, and those used
for generation and testing of both hardware and software), are assessed for any
contributions to hazards to the extent possible”.

4
www.nasa.gov/sls
 NASA Standards

NASA-STD-8719.13C NASA Software Safety Standard

– Section A.3.2 - Software Safety Litmus Test: Software is classified as safety

critical (see below for note A-1.0 and A-1.4) if it meets at least one of the
following criteria:
f) Provides full or partial verification or validation of safety critical
systems, including hardware or software subsystems. (e.g., this includes
models and simulations)

– Section 7.5.5 – “If a model, simulator or emulator is used to test our critical
systems (hardware, software or a combination) it is necessary to make sure our
tests and associated models and simulators are of sufficient rigor, accuracy and
depth to reliably supply results that are trusted and true … It is important that
an analysis of the risks to critical software tests, models and simulators be
performed and the resultant level of safety and software engineering rigor be
applied as for any safety critical software”.

5
www.nasa.gov/sls
 NASA Standards

NPR 7150.2B NASA Software Engineering Requirements

– Class C: Mission Support Software or Aeronautic Vehicles, or Major

Engineering/Research Facility Software
a. Definition
1. Space Systems include the following types of software:
d) Software used for the testing of space assets.

– Examples of Class C:
• Simulators, emulators, stimulators, or facilities used to test Class A, B, or C software
in development; integration and test environments (development environment,
including environment 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 control system performance verification by
analysis)

6
www.nasa.gov/sls
 Safety Criticality (S-C) ASSESSMENT

SLS-PLAN-013 – SLSP Safety & Mission Assurance Plan – provides the

following information applicable to the approach being used:

• Section 4.2.7, Software Safety Certification, states in part,

– “Identify all software related hazards
– Identify ... all hazard controls that are implemented with software
– Identify and track of all safety-critical software requirements from the
associated hazard ...
– Verify results indicating [that the] software control methods function as
required”

7
www.nasa.gov/sls
 Definition

Safety-Critical (S-C) Software Requirements

A safety-critical software requirement is classified as safety-critical if it addresses

at least one of the following:
1. Detects a documented hazardous, or potentially hazardous condition/event.
2. Provides control by reporting to the user and/or responding to the detected
hazardous condition/event.
3. Detects and transitions the software to a safe state.
4. Actively models and/or simulates the operational environment of safety-critical
systems.
5. Verifies & validates proper execution of 1 thru 4 by accurately simulating the
execution of fault tolerance.

8
www.nasa.gov/sls
 Software HR Control Determination to S-
C Requirements Process
*** Desirable
process as
Begins with Hazard that is Developed and Documented by
described by documented in IATF Hazard Report Safety (QD34)
SLS-PLAN-013***
Integrated participation of System Safety, SwS,
System functionality and Software SwS Cause Record SW Reqs/Design, HW Reqs & Design, VM FDIR,
aspects of the hazard are identified (CR) Evaluation and subject matter experts.

SwS Team develops SW CTRL Developed Developed Developed

descriptions compatible with the HW Hazard Control Hazard Control Hazard Control
CTRLs and resolves any incompatibility. 1 2 x...

A) ES53 IATF SW B) QD34 SwS Team

Engineering develops evaluates the requirements
the SW Safety-Critical to ensure that they
Hazard Control 1 Hazard Control 1 Hazard Control 1...
Requirements that adequately implement the
Requirement 1 of Requirement 2 of Requirement X of
correctly will simulate desired CTRLs and are
X X X...
the FSW CR CTRLs compatible with the overall
HW/SW design.
Safety-Critical Requirements
• Detect errors during processing • Display notification of fatal error
• Provide interface to inject faults • Monitor temperature of hardware
• Execute/Integrate models correctly • Simulate subsystem faults
• Simulate I/O communication bus • Perform a system shutdown upon
Faults with user specified values. receipt of a fatal error message. 9
www.nasa.gov/sls
 Safety-Critical Requirements
Determination Example
Hazard Controls (These are the S-C Reqs)
What Hazard Cause
needs to be controlled By SW Eng. Reqs.
by the software?
MAE.SR.XXS
If there is NOT a
Hazard Cause it is CTRL 1 ART.SR.XXS
NOT a primary
FAC.SR.XXS
“Safety Concern”
Requirements to
By SW Eng. Reqs.
Implement the
QD34 Controls for the
Identified/Documented ART.SR.XXS Hazard Cause are
Hazard Cause CTRL 2 written by
MAE.SR.XXS Engineering’s
Software
By SW Eng. Reqs. Requirements
Note: Every Team
MAE.SR.XXS
requirement that must
work that traces to a
safety-critical control
CTRL 3 ART.SR.XXS
should be FAC.SR.XXS
“Safety-Critical”.

*** Desirable process as described by SLS-

PLAN-013*** 10
www.nasa.gov/sls
 Use of the S-C Designation

During evaluation of a requirement:

• All safety-critical (S) designation must have traceability to hazard control.

• Determine if a safety designation applies only if a hazard exists.
• Changes to a safety critical requirement must be reviewed to ensure that the hazard
control implemented by the current requirement is not weakened or lost by
accepting the change.

11
www.nasa.gov/sls
 Goals

Software Safety Goals:

• To acknowledge the effort ES53 has completed to mitigate hazards that exists in
the system (HW & SW)
• To document that ES53 has adequately done due diligence to provide verifications
to close out hazard controls and reduce the likelihood of occurrence to the lowest
level.
• To assist ES53 is resolving any verifications that remain open.
• To present to the ASCB that a adequate Safety Analysis has been accomplished by
SMA and the IATF facility is safe.
• To help NASA safely put the first Woman on the Moon!

12
www.nasa.gov/sls
 Questions?

13
www.nasa.gov/sls
 Backup

14
www.nasa.gov/sls
 NPR 7150.2C NASA Software Engineering Requirements

If a project has safety-critical software or mission-critical software, the project manager shall
implement the following items in the software:
• a. The software is initialized, at first start and restarts, to a known safe state.
• b. The software safely transitions between all predefined known states.
• c. Termination performed by software of functions is performed to a known safe state.
• d. Operator overrides of software functions require at least two independent actions by an
operator.
• e. Software rejects commands received out of sequence when execution of those commands
out of sequence can cause a hazard.
• f. The software detects inadvertent memory modification and recovers to a known safe state.
• g. The software performs integrity checks on inputs and outputs to/from the software system.
• h. The software performs prerequisite checks prior to the execution of safety-critical software
commands.
• i. No single software event or action is allowed to initiate an identified hazard.
• j. The software responds to an off-nominal condition within the time needed to prevent a
hazardous event.
• k. The software provides error handling.
• l. The software can place the system into a safe state.

15
www.nasa.gov/sls
 NASA Standards

• NPR 7150.2C
– Class C: Mission Support Software or Aeronautic Vehicles, or Major
Engineering/Research Facility Software
a. Definition
1. Space Systems include the following types of software:
d) Software used for the testing of space assets

– Examples of Class C:
• Simulators, emulators, stimulators, or facilities used to test Class A, B, or C
software in development; integration and test environments; software used to verify
system-level requirements associated with Class A, B, or C software by analysis (e.g.,
guidance, navigation, and control system performance verification by analysis)

16
www.nasa.gov/sls