Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


Set Data
01. Introduction
12. Resources

1. Introduction

1.1 Software Hazard Causes


Provides some requirements for consideration when the software has hazardous commands.

The identification of hazardous commands is required for implementation of the Computing System Requirements in both the current Standard, NASA-STD-8739.8, and in the previous version, NASA-STD-8719.13.A hazardous command is defined as:

  • A command whose execution could lead to a critical or catastrophic hazard as identified in the Hazard Analysis. This includes but not limited to:
    • inadvertent execution
    • out-of-sequence execution or
    • incorrect execution
  • A command whose execution can lead to a reduction in the control of a hazard identified in the Hazard Analysis reports. This includes but not limited to:
    • reduction in failure tolerance against a hazard or
    • the elimination of an inhibit a hazard).

Commands can be internal to a software set (e.g., from one component to another) or external (e.g., crossing an interface to/from hardware or a human operator or any other external source).

Longer command paths increase the probability of an undesired or incorrect command response due to:

  • noise on the communications channel,
  • link outages,
  • equipment malfunctions, or
  • human error.  

1.2 Hazard Considerations

When there is a hazardous command, the following should be considered:

  • All defined prerequisite conditions for the safe execution of an identified hazardous command should be met prior to executing the command. Examples of prerequisite conditions include:
    • correct mode,
    • correct parameters
    • correct configuration,
    • component availability,
    • proper sequence,
    • parameters in range, and
    • input verification.

If prerequisite conditions have not been met, the software should reject the command and alert the crew, ground operators, or controlling executive.

  • Software that executes hazardous commands should notify the initiating crew, ground operator, or controlling executive upon execution or provide the reason for failure or response of completion to execute a hazardous command.
  • The software interface should have the ability to identify and display the status of each software inhibit. 
  • Software should make available the current status of software inhibits associated with hazardous commands to the crew, ground operators, or controlling executive.
  • All software inhibits associated with a hazardous command should have a unique identifier.
  • If an automated sequence is already running when a software inhibit associated with a hazardous command is executed, the sequence should complete before the software inhibit is started unless automated sequence contributes to the hazard.
  • Software should have the ability to resume control of an inhibited operation after deactivation of a software inhibit associated with a hazardous command and after all prerequisite checks have been verified.

2. Resources

2.1 References


Show If
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted

SWEREFs NOT called out in text but listed as germane: 

SWEREFs called out in the text: 

2.2 Tools

Include Page
Tools Table Statement
Tools Table Statement