bannerc

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

UNDER CONSTRUCTION

8.22 - Hazardous Commands

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


Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.


  • No labels

0 Comments