I
|
|
|
16.4.1. Software Design, Development, and Test Requirements. NPR 7150.2 NASA Software Engineering Requirements provides requirements for software design, development, and testing. Additionally, software shall be designed, developed, and tested in accordance with NASA-STD-8719.13, Software Safety Standard, NASA-STD-8739.8, NASA Software Assurance Standard, and commercial software development standard IEEE/EIA 12207, Standard for Information Technology. NASA-GB-8719.13, NASA Software Safety Guidebook, is recommended for guidance in ensuring software safety.
|
C
|
|
|
16.4.2. Software Coding Practices. The payload project’s software developers should develop or adopt software coding practices applicable to the programming languages used.
|
I
|
|
|
Some examples include Appendixes D and E of the Joint Software Safety Committee, Software System Safety Handbook; Code Conventions for the Java Programming Language by Sun Microsystems; and C++ Coding Standards by Herb Sutter and Andrei Alexandrescu.
|
I
|
|
|
Experience has indicated that computer systems architectures that contain separate instruction and data memory and buses, or separate program memory and data memory through memory protection hardware, segment protection, or page protection prove useful for risk mitigation.
|
I
|
|
|
16.4.3. Human-Computer Interface
|
I
|
|
|
16.4.3.1. General human-computer interfaces should use the “DoD Human-Computer Interface Style Guide” as specified in Section 2.5 of Version 3.1 of the Joint Technical Architecture (JTA).
|
C
|
|
|
16.4.3.2. The system shall be designed such that the operator may exit current processing to a known stable state with a single action.
|
C
|
|
|
Care should be taken to prevent the operator from inadvertently initiating a hazardous operation; therefore, the "single action" should be designed to minimize that possibility. That action may include pressing two keys at the same time.
|
I
|
|
|
16.4.3.3. Computer systems shall minimize the potential for inadvertent actuation of hazardous operations.
|
C
|
|
|
16.4.3.4. Only one operator at a time shall control safety critical computer system functions.
|
C
|
|
|
16.4.3.5. Operator-initiated hazardous functions shall require two or more independent operator actions.
Examples of acceptable actions to initiate a hazardous operation are:
(1) Pressing a key which produces an alert to notify the operator of the impending hazardous operation, followed by a second keystroke to invoke the operation.
(2) Removal of a physical block such as a switch cover followed by flipping the switch.
|
C
|
|
|
16.4.3.6. Software shall provide confirmation of valid command and/or data entry to the operator.
|
C
|
|
|
16.4.3.7. Software shall provide feedback to the operator that indicates command receipt and status of the operation commanded.
|
C
|
|
|
The system should provide both visual and aural feedback to ensure the operator knows that the system has accepted the action and is processing it.
|
I
|
|
|
16.4.3.8. Software shall provide the operator with real-time status reports of operations.
|
C
|
|
|
16.4.3.9. Error messages that distinguish safety critical states/errors from non-safety critical states/errors shall be provided.
|
C
|
|
|
16.4.3.10. The system shall ensure that a single failure or error cannot prevent the operator from taking safing actions.
|
C
|
|
|
16.4.4. Software Data Standards
|
I
|
|
|
16.4.4.1. Software shall not use a bit pattern of all 1s or all 0s to denote the safe and arm (potentially hazardous) states.
|
C
|
|
|
16.4.4.2. The arm and safe states shall be represented by unique bit patterns of length at least 4 bits in such a way that the safe state pattern cannot represent the arm pattern as a result of a 1 or 2-bit error.
|
C
|
|
|
16.4.5. Configuration Control
|
I
|
|
|
16.4.5.1. The payload project shall provide a software configuration management (SCM) plan in accordance with NPR 7150.2, Software Engineering Requirements, to the PSWG for PSWG and Range Safety review.
|
C
|
|
|
The system should be designed to prevent or minimize the chance for inadvertent or unauthorized access to and modification of system software by system operators.
|
I
|
|
|
16.4.5.2. Software and firmware shall be put under formal configuration control as soon as a software baseline is established.
|
C
|
|
|
16.4.5.3. A Software Configuration Control Board (SCCB) shall be established to approve changes to configuration-controlled software before implementation.
|
C
|
|
|
16.4.5.4. A member from the system safety engineering team shall be a member of the SCCB and tasked with the responsibility of evaluating all software changes for their potential safety impact.
|
C
|
|
|
16.4.5.5. A member of the hardware Configuration Control Board (CCB) shall be a member of the SCCB and vice versa to keep members apprised of hardware/software changes and to ensure that hardware/software changes do not conflict with or introduce potential safety hazards due to hardware/software incompatibilities.
|
C
|
|
|
16.4.5.6. Object code patches shall not be performed unless the SCCB and the PSWG and Range Safety give specific approval.
|
C
|
|
|
| |
