Migration of unmigrated content due to installation of a new plugin
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:
out-of-sequence execution or
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,
equipment malfunctions, or
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:
parameters in range, and
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.
Visible to editors only
Enter the necessary modifications to be made in the table below:
SWEREFs to be added
SWEREFS to be deleted
SWEREFs NOT called out in text but listed as germane: