Page History
...
d. Verify that the software test results meet the associated acceptance criteria to ensure that software correctly implements the associated requirements.
| Note |
|---|
The IV&V Provider assesses the testing artifacts within the context of the system’s meaning concerning the desired capabilities and expected operational system environment. The assessment includes an examination of testing at system boundary conditions to include unexpected conditions. The testing analysis assures that the project tests all of the requirements and that the system does what the requirements state it should do. The testing analysis also includes analysis of the traceability information between the tests and the requirements. |
e. Verify that the project tests the required software security risk mitigations to ensure that the security objectives for the software are satisfied.
...
b. The second level of tailoring is the tailoring in the project’s Software Requirements Mapping Matrix, see NPR 7150.2.
NASA-STD-8739.8A – 2020-06-10
54 of 59
c. The third level of tailoring is the tailoring by the Software Assurance TA of the Software Assurance and Software Safety Standard requirements that correspond to the project’s Software Requirements Mapping Matrix requirements. The .
4.5.2 The Software Assurance and Software Safety Standard establishes a baseline set of requirements for software assurance, software safety, and IV&V to reduce risks on NASA projects and programs. Each project has unique circumstances, and tailoring can be employed to modify the requirements set for software assurance, software safety, and IV&V effort. Determining the tailoring of requirements is a joint software engineering effort and SMA effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts. Per .
4.5.3 Per SWE-121, the software assurance organization maintains a requirements mapping matrix or multiple requirements mapping matrices against requirements in the Software Assurance and Software Safety Standard, including those delegated to other parties or accomplished by contract vehicles. Per SWE-013 and SWE-039, the software assurance organization conducts risk assessment efforts to determine the software assurance, software safety, and IV&V tasks to be performed, and the rigor of each task. The software assurance organization will develop, maintain, and execute plans and procedures that cover the entire software life-cycle and, as a minimum, address the requirements of the Software Assurance and Software Safety Standard with approved tailoring. The .
4.5.4 The approval of the Software Assurance and Software Safety Standard tailoring is determined by the SMA management at the Center Level in conjunction with the project. The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that justifies supporting acceptance. The organization submitting the tailoring request informs the next higher level of involved management of the tailoring request in a timely manner. The dispositioning organization reviews the request with the other organizations that could be impacted or have a potential risk (i.e., to safety, quality, cybersecurity, health) with the proposed changes; and obtains the concurrence of those organizations.
4.5.5 The . The Center SMA TA shall review and agree with any tailored Software Assurance and Software Safety Standard requirements. (SASS-09) If
4.5.6 If a system or subsystem development evolves to meet a higher or lower software classification as defined in NPR 7150.2 then the software assurance, software safety, and IV&V organizations shall update their plan(s) to fulfill the applicable requirements per the Requirements Mapping Matrix and any approved changes, and initiate adjustments to applicable contracts to meet the modified requirements. (SASS-10)
4.5.7 The The responsibilities for approving changes to the software engineering requirements are in the NPR 7150.2. When the requirement and software class are applicable, the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix.
NASA-STD-8739.8A – 2020-06-10
55 of 59
...
Appendix A GUIDELINES FOR THE HAZARD DEVELOPMENT INVOLVING SOFTWARE
A.1 Software Contributions to Hazards
A.1.
...
1 Hazard Analysis should consider software’s ability, by design, to cause or control a given hazard. It is a best practice to include the software within the system hazard analysis. The general hazard analysis should consider software common-mode failures that can occur in instances of redundant flight computers running the same software.
A.1.
...
2 Software Safety Analysis supplements the system hazard analysis by assessing the software performing critical functions serving as a hazard cause or control. The review assures compliance with the levied functional software requirements, including SWE-134. The software should not violate the independence of hazard inhibits, and the software should not violate the independence of hardware redundancy. The Software Safety Analysis should follow the phased hazard analysis process. A typical Software Safety Analysis process begins by identifying the must work and must not work functions in Phase 1 hazard reports. The system hazard analysis and software safety analysis process should assess each function, between Phase 1 and 2 hazard analysis, for compliance with the levied functional software requirements, including SWE-134. For example, Solar Array deployment (must work function) software should place deployment effectors in the powered off state when it boots up and requires arm and fire commands in the correct order within 4 CPU cycles before removing a deployment inhibit. The analysis also assesses the channelization of the communication paths between the inputs/sensors and the effectors to assure there is no violation of fault tolerance by routing a redundant communication path through a single component. The system hazard analysis and software safety analysis also assures the redundancy management performed by the software supports fault tolerance requirements. For example, software can’t trigger a critical sequence in a single fault-tolerant manner using a single sensor input. Considering how software can trigger a critical sequence is required for the design of triggering events such as payload separation, tripping FDIR responses that turn off critical subsystems, failover to redundant components, and providing closed-loop control of critical functions such as propellant tank pressurization.
A.1.
...
3 The design analysis portion of software safety analysis should be completed by Phase 2 safety reviews. At this point, the software safety analysis supports a requirements gap analysis to identify any gaps (SWE-184) and ensuring the risk and control strategy documented in hazard reports are correct, as stated. Between Phase 2 and 3 safety reviews, the system hazard analysis and software safety analysis supports the analysis of test plans to assure adequate off-nominal scenarios (SWE-62, SWE-65a). Finally, in Phase 3, the system hazards analysis should verify the final implementation and verification upholds the analysis by ensuring test results permit closure of hazard verifications (SWE-68) and that the final hazardous commands support the single command and multi-step command needs and finalized pre-requisite checks are in place.
A.1.
...
4 The following section includes useful considerations and examples of software causes and controls:
a. Does software control any of the safety-critical hardware?
...
b. Does software perform critical reconfiguration of the system during the mission?
c. Does the software perform redundancy management for safety-critical hardware?
d. Does the software determine when to perform a critical action?
e. Does the software trigger logic to meet failure tolerance requirements?
f. Does the software monitor hazard inhibits, safety-critical hardware/software, or issue a caution and warning alarm used to perform an operational control?
g. Does the software process or display data used to make safety-critical decisions?
h. Does the flight or ground software manipulate hazardous system effectors during prelaunch checkouts or terminal count?
i. Does the software perform analysis that impacts automatic or manual hazardous operations?
j. Does the software serve as an interlock preventing unsafe actions?
k. Does the software contain stored command sequences that remove multiple inhibits from a hazard?
l. Does the software initiate any stored command sequences, associated with a safety-critical activity?
m. Does software violate any hazard inhibits or hardware redundancy independence (channelized communication/power paths, stored command sequences/scripts, FDIR false positive, etc.)?
n. Can the software controls introduce new hazard causes?
o. Are the software safety-critical controls truly independent?
p. Can common cause faults affect the software controls?
q. Can any of the software controls used in operational scenarios cause a system hazard?
r. Does the software control switch-over to a backup system if a failure occurs in a primary system?
s. Is the software that makes safety-critical decisions fault-tolerant?
t. Does the software provide an approach for recovery if the system monitoring functions fail?
u. Does the software allow the operators to disable safety-critical controls unintentionally?
...
...
v. Does the software provide safety-critical cautions and warnings?
w. Is the software capable of diagnosing and fixing safety-critical faults that might occur in operations?
x. Does the software provide health and status of safety-critical functions?
y. Does the software process safety-critical commands (including autonomous commanding)?
z. Can software that provides full or partial verification or validation of safety-critical systems generate a hazard if it has a defect, fault, or error?
aa. Can a defect, fault, or error in the software used to process data or analyze trends lead to safety decisions that cause a system hazard?
bb. Do software capabilities exist against the potential use cases and planned operations throughout all phases of use, and through transitions between those phases/states?
A.1.
...
5 Additional considerations when identifying software causes in a general software-centric hazard analysis are found in Table 2 below.
Table 2. Additional considerations when identifying software causes in hazard analysis
| Additional |
|---|
...
| Considerations | Causes | Controls |
|---|---|---|
| Computer Reset | 1. Reset with no restart 2. Reset during program upload (PROM corruption) 3. Boot PROM corruption preventing reset 4. Watchdog active during reboot causing infinite boot loop | 1. Disable FDIR and watchdogs during boot 2. Redundant computers |
| Memory | 1. Memory corruption 2. Out of Memory 3. Buffer overrun 4. Deadlock (trying to write to same memory at the same time or trying to update while reading it) 5. Single Event Upset/bit flip 6. Shared Memory (can defeat redundancy independence) | 1. No Dynamic allocation of memory after initialization 2. EDAC/Memory scrubbing 3. Memory margin |
| CPU | 1. Cycle overrun 2. Cycle jitter 3. Stack processing/ordering incorrect (e.g., FIFO vs. LIFO vs. unknown) 4. One task failing to release shared resource 5. Single Event Upset 6. Hardware failure | 1. CPU utilization and cycle time margin 2. Self-checking CPU cores |
...
...
| Commanding | 1. Inadvertent/Erroneous commanding 2. Failure to command 3. Command out of sequence 4. Command corrupted or illegitimate command= | 1. Command validation (cyclic redundancy check, timestamp, destination/source) 2. Acknowledgment/ negative acknowledgment |
| Communication and Input/Output | 1. Communication bus overload 2. Lack of or intermittent communication 3. Complex configuration input 4. Babbling Node | 1. Communication bus utilization margin 2. Use of lossless protocol 3. Downstream input voting 4. External safing function 5. Bus Guardian |
| Display Data | 1. Incorrect Data (unit conversion, incorrect variable type, etc.) 2. Stale Data | 1. Visual indication of stale data 2. Watchdog timer |
| Events and Actions | 1. Out-of-sequence event protection 2. Multiple events/actions trigger simultaneously (when not expected) 3. Error/Exception handling missing or incomplete 4. Inadvertent mode transition | 1. Fault Management 2. Pre-requisite logic 3. Interlocks |
| Timekeeping | 1. Time runs fast/slow 2. Time skips (e.g., Global Positioning System time correction) 3. Time sync across components 4. Oscillator Drift | 1. Diverse/redundant time sources with fault down logic 2. Robust time sync design that can deal with the loss of external time sources 3. Prelaunch checkout of Oscillators |
| Timing Problems | 1. Priority inversion 2. Failure to terminate/complete process in a given time 3. Data latency/sampling rate too slow 4. Race Conditions 5. Non-determinism | 1. Static and Dynamic Analysis Tools 2. Coding standards |
| Coding, Logic, and Algorithm failures | 1. Division by zero 2. Bad data in = bad data out (no parameter range & boundary checking) 3. Dead code 4. Unused code 5. Non-functional loops |
...
6. Endless do loops 7. Incorrect passes (too many or too few or not at the correct time) 8. Incorrect “if-then” and incorrect “else.” 9. Too many or too few parameters for the called function 10. Case/type mismatch 11. Precision mismatch 12. Rounding or truncation fault 13. Resource contention (e.g., thrashing: two or more processes accessing a shared resource) 14. Bad configuration data/no checks on external input files and data 15. Inappropriate equation 16. Undefined or non-initialized data 17. Limit ranges 18. Relationship logic for interdependent limits 19. Overflow or underflow in the calculation | 1. Use of industry-accepted coding standard | |
| Input Failures | 1. Noise 2. Sensors or actuators stuck at some value (all zeros, all ones, some other value) 3. A value above or below range 4. Value in range but incorrect 5. Physical units incorrect 6. Inadequate data sampling rate | 1. Sensor Health Checks 2. Input Validation, Sanity Checks |
| User Interface Errors | 1. Wrong commands are given by the operator 2. No commands are given by the operator 3. Status and messages not provided for operations, systems, and inhibits 4. Ambiguous or incorrect messages 5. User display locks up/fails | 1. Two-step commands 2. GUI style guide 3. Software interlocks to prevent human error |
| Configuration Management | 1. Incorrect version loaded 2. Incorrect configuration values | 1. Version CRC check after software/configuration load |
| Security | 1. Denial/Interruption of Service 2. Spoofed/Jammed inputs 3. An unauthorized input/access | 1. Message filtering to detect spoofing 2. Ensure software has data source validation checking features |
