1. Introduction

1.1 Software Hazard Causes

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

2.2 Tools