The payload project shall identify all safety critical software in accordance with NASA-STD-8719.13, Software Safety Standard, and the provisions of this document. The payload project shall identify all safety critical computer system functions (SCCSFs). These functions are defined as any computer system function that, (1) if not performed, (2) if performed out of sequence, or (3) if performed incorrectly, may directly or indirectly cause a safety hazard to exist. Safety critical computer system functions include, but are not necessarily limited to, the following:
I
|
|
|
It is recommended that SCCSFs be identified and agreed to by the PSWG and Range Safety very early in the program along with detailed documentation for each.
|
I
|
|
|
16.2.1. Software used to control and/or monitor safety critical systems.
|
C
|
|
|
16.2.2. Software used for fault detection in safety critical computer hardware or software.
|
C
|
|
|
16.2.3. Software used to transmit safety critical data, including time-critical data and data about hazardous conditions.
|
C
|
|
|
16.2.4. Software that responds to the detection of a safety critical fault.
|
C
|
|
|
16.2.5. FTS Software.
|
C
|
|
|
16.2.6. Software that computes safety critical data.
|
C
|
|
|
16.2.7. Software used to access safety critical data.
|
C
|
|
|
16.2.8. Processor interrupt software associated with previously designated safety critical computer system functions.
|
C
|
|
|
Hardware and Software Safety Design Requirements
The following subparagraphs identify general hardware and software requirements that shall be met for all safety critical computer system functions.
|
I
|
|
|
16.3.1. Computer Systems
|
I
|
|
|
16.3.1.1. Computer systems shall be validated for operation in the intended environment.
|
C
|
|
|
Validation of central processing unit (CPU) functionality should be based on testing.
|
I
|
|
|
16.3.1.2. Under maximum system loads, CPU throughput shall not exceed 80 percent of its design value.
|
C
|
|
|
Although CPU throughput of 80 percent is acceptable, experience has shown that a value of 70 percent is desirable.
|
I
|
|
|
16.3.1.3. Computer system architecture shall be single failure tolerant.
|
C
|
|
|
16.3.1.3.1. No single software failure/output shall initiate a hazardous operation.
|
C
|
|
|
Safety will also be enhanced if the system is designed so that memory locations not intended to be used during a particular operation will tend to bring the system to a safe or stable state if inadvertently executed.
|
I
|
|
|
16.3.1.3.2. No single software failure/output shall cause a critical accident.
|
C
|
|
|
16.3.1.3.3. No single or double software failure/output shall cause a catastrophic accident.
|
C
|
|
|
16.3.1.3.4. Fulfilling the following requirements in addition to the other requirements in 16.3.1 shall constitute meeting the computer system requirements in 16.3.1.3.1 through 16.3.1.3.3 above. The payload project shall identify and provide the following items to the PSWG and Range Safety:
|
C
|
|
|
16.3.1.3.4.1. All hazardous operations that can be triggered by software, either intentionally or unintentionally.
|
C
|
|
|
16.3.1.3.4.2. All critical accidents that can be triggered by software.
|
C
|
|
|
16.3.1.3.4.3. Catastrophic accidents that can be triggered by software.
|
C
|
|
|
16.3.1.3.4.4. Scenarios where a single software failure/output can create a condition that can trigger a hazardous operation or critical accident. Consideration shall be given to data integrity, memory use, timeliness and correct sequencing of data, and situations where the interaction of modules, hardware, software, and/or users may be problematic.
|
C
|
|
|
16.3.1.3.4.5. Scenarios where a single or double software failure/output can produce a condition that can trigger a catastrophic accident.
|
C
|
|
|
16.3.1.3.4.6. Analyses and test reports that verify the capability to monitor the system during runtime to ensure the faulty conditions are corrected.
|
C
|
|
|
16.3.1.4. Safety critical computer system function flight architecture that will be exposed to cosmic radiation shall protect against CPU single event upset (SEU) and other single event effects (SEE). An SEU occurs when an energetic particle travels through a transistor substrate and causes electrical signals within the transistor.
|
C
|
|
|
SEUs can be protected against through redundancy, error correcting memory, voting between parallel CPUs, or other approved approaches.
|
I
|
|
|
16.3.1.5. Sensitive components of computer systems shall be protected against the harmful effects of electromagnetic radiation and/or electrostatic discharge.
|
C
|
|
|
16.3.1.6. The computer system shall periodically verify that safety critical hardware and SCCSF, including safety data transmission, are operating correctly, as agreed to by the PSWG and Range Safety.
|
C
|
|
|
16.3.2. Computer System Power
|
I
|
|
|
16.3.2.1. Computer systems shall be powered up and/or restarted in a safe state.
|
C
|
|
|
16.3.2.2. A computer system shall not enter a hazardous state as a result of an intermittent power transient or fluctuation.
|
C
|
|
|
16.3.2.3. In the event of the single failure of primary power to a computer system or computer system component, that system or some cooperating system shall take action automatically to transition to a stable state.
|
C
|
|
|
In the context of response to failure or retreat from some unsafe state, a stable state is the safest possible state that can be achieved without causing a more hazardous state to occur during that transition.
|
I
|
|
|
16.3.2.4. Software used to power up safety critical systems shall power up the required systems in a safe state.
|
C
|
|
|
16.3.3. Computer System Anomaly and Failure Detection
|
I
|
|
|
In addition, software should be designed to alert appropriate operators to such things as:
(1) CPU running at greater than 80 percent of specified load.
(2) Pending memory overflow.
(3) Pending buffer overflows.
|
I
|
|
|
16.3.3.1. Before initiating hazardous operations, computer systems shall perform checks to ensure that they are in a safe state and functioning properly. These checks include checking safety critical circuits, components, inhibits, interlocks, exception limits, safing logic, memory integrity, and program loads.
|
C
|
|
|
16.3.3.2. The following hazardous conditions and failures, including those from multiple sources, shall be detected:
|
C
|
|
|
16.3.3.2.1. Invalid input - data or sequences of data passed to software modules, either by human input, other software modules, or environmental sensors, that are outside a specified range for safe operation.
|
C
|
|
|
16.3.3.2.2. Invalid output - data output from software modules that are outside a specified range for safe operation.
|
C
|
|
|
16.3.3.2.3. Timing errors - the state when software-timed events do not happen according to specification.
|
C
|
|
|
16.3.3.2.4. Data transmission errors.
|
C
|
|
|
16.3.3.2.5. Loss of memory integrity.
|
C
|
|
|
16.3.3.2.6. Greater than allowed safe input data rates.
|
C
|
|
|
16.3.3.2.7. The existence of a pattern other than the arm or safe codes in the arm/safe data register.
|
C
|
|
|
16.3.3.2.8. Software exceptions, such as “divide by zero” or “file not found.”
|
C
|
|
|
16.3.3.2.9. Data transfer messages corrupted or not in the proper format.
|
C
|
|
|
16.3.4. Computer System Anomaly and Failure Response
|
I
|
|
|
16.3.4.1. All events mentioned in 16.3.3 shall be reported to the appropriate system operator consoles in real time, prioritized as to severity, and logged to an audit file.
|
C
|
|
|
Displays that support SCCSFs can vary widely but every attempt should be made to ensure that the operators are alerted to the most important anomalies. A method of prioritization is necessary. For example, anomalies of the same priority should be grouped together; all warnings displayed first, cautions next, and advisories last. The most recent anomaly should be displayed at the top of the priority subgroup. Details of each anomaly should be accessible with a single operator action.
|
I
|
|
|
16.3.4.1.1. The display shall distinguish between read and unread anomaly alerts.
|
C
|
|
|
16.3.4.1.2. The display shall support reporting multiple anomalies.
|
C
|
|
|
16.3.4.1.3. The display shall distinguish between anomaly alerts for which corrective action has been taken and those that are still pending.
|
C
|
|
|
16.3.4.2. Upon detecting an event described in 16.3.3, the software shall remain in or revert to a stable state.
|
C
|
|
|
16.3.4.3. For payloads with a FTS, upon detecting a failure during processing, the software shall maintain the FTS in its current state in addition to meeting the requirements in 16.3.4.1 and 16.3.4.2 above.
|
C
|
|
|
16.3.4.3.1. The software shall maintain the FTS in the safe state before arming.
|
C
|
|
|
16.3.4.3.2. After the FTS is armed, the software shall retain the FTS in the armed state.
|
C
|
|
|
16.3.4.3.3. When the FTS receiver is on internal power, the software shall maintain the FTS receiver on internal power.
|
C
|
|
|
16.3.4.3.4. During flight, all detected FTS-related system errors shall be transmitted to the range.
|
C
|
|
|
16.3.5. Computer System Testing and Maintenance
|
I
|
|
|
16.3.5.1. Non-operational hardware and software required for testing or maintenance shall be clearly identified.
|
C
|
|
|
16.3.5.2. Systems shall include interlocks, as necessary, to mitigate hazards when performing maintenance or testing.
|
C
|
|
|
16.3.5.3. Interlocks shall be designed to prevent an inadvertent override.
|
C
|
|
|
16.3.5.4. Interlocks that are required to be overridden shall not be autonomously controlled by a computer system, unless dictated by a timing requirement.
|
C
|
|
|
16.3.5.5. Interlocks that are required to be overridden and are autonomously controlled by a computer system shall be designed to prevent an inadvertent override.
|
C
|
|
|
16.3.5.6. The status of overridden interlocks shall be displayed on the appropriate operator console(s).
|
C
|
|
|
16.3.5.7. A positive indication of interlock(s) restoration shall be provided and verified on the appropriate operator console(s) before restoring a system to its operational state.
|
C
|
|
|
16.3.5.8. Compilers
|
C
|
|
|
16.3.5.8.1. Existing code compiled with a new compiler or new release of a compiler shall be regression tested.
|
C
|
|
|
16.3.5.8.2. Beta test versions of language compilers shall not be used for safety critical functions.
|
C
|
|
|
| |
