Below are additional detailed technical software safety requirements to be considered when you have safety-critical software on a program/project/facility. These requirements were derived from both the Constellation and International Space Station Software Safety Requirements, NPR 7150.2 (requirement SWE-134 in Revision C) and Software Assurance and Software Safety Standard, NASA-STD-8739.8. More information on the International Space Station Software Safety Requirements is in NASA-SSP-50038, Computer-Based System Safety Requirements 014.
1.1 General Software Safety Requirements- Approach for handling Software Safety-Critical components contained in NPR 7150.2 and in NASA-STD-8739.8.
Step 1. Implement the requirements in SWE-134 - Safety-Critical Software Design Requirements
Step 2. Assess and determine if security measures are in place to prevent viruses and other unwanted attacks that could contribute to a hazard
See the following requirements from NPR 7150.2, section 3.11:
3.11 Software Cybersecurity
- 3.11.1 Software defects are a central and critical aspect of computer security vulnerabilities. Software defects with cybersecurity ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.
- SWE-156 - Evaluate Systems for Security Risks
- SWE-154 - Identify Security Risks
- SWE-157 - Protect Against Unauthorized Access
- SWE-159 - Verify and Validate Risk Mitigations
- SWE-207 - Secure Coding Practices
- SWE-185 - Secure Coding Standards Verification
- SWE-210 - Detection of Adversarial Actions
Step 3. Implement the Software Safety-Critical Requirements and activities is contained in NASA-STD-8739.8:
- Confirm that the identified safety-critical software components have implemented the safety-critical software assurance requirements listed in this standard.
- Analyze the software design to ensure that partitioning or isolation methods used in the design to logically isolate the safety-critical design elements from those that are non-safety-critical.
- Analyze the design and work with the project to implement NPR 7150.2 requirement items "a" through "l."
- Assess that the source code satisfies the conditions in the NPR 7150.2 requirement "a" through "l" for safety-critical software at each code inspection, test review, safety review, and project review milestone.
- Confirm 100% code test coverage has been achieved or addressed for all identified software safety-critical components or provide a risk assessment explaining why the test coverage is not possible for the safety-critical code component.
- Assess each safety-critical software component to determine the software component’s cyclomatic complexity value.
- Confirm that all identified software safety-critical components have a cyclomatic complexity value of 20 or lower. If not, provide a risk assessment showing why the cyclomatic complexity value needs to be higher than ten and why the software component cannot be structured to be lower than 20.
- Develop a Software Assurance Plan. The plan should address the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety if required.
- The defined software assurance, software safety, and IV&V processes for the activities on the project per the requirements in the Software Assurance and Software Safety Standard.
- Develop a tailoring matrix of the software assurance and software safety requirements as needed and document the software assurance, software safety, and IV&V approach in the SA plan and schedule.
- Develop a software assurance cost estimation for the project, including cost estimation associated with handling safety-critical software.
- Confirm that the hazard reports contain (or safety data packages) all known software contributions or events where software; either by its action, inaction or incorrect action, lead to a hazard.
- Analyze the updated hazard reports and design at review points to determine if any newly identified software components are safety-critical.
- Develop and maintain a list of all software safety-critical components that have been identified by the system hazard analysis.
- Develop and maintain a software safety analysis throughout the software development lifecycle.
- Analyze that the software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software are in the software requirements documentation. The analysis must ensure the software does not violate the independence of hazard inhibits and hardware redundancy.
- Analyze the software architecture features to determine if any software architecture features impact safety and mission assurance.
- Develop a list of software architecture features that impact safety and mission assurance.
- Confirm that the software design implements all of the required safety-critical functions and requirements.
- Confirm that the project successfully executes the required unit tests, particularly those testing safety-critical functions.
- Perform additional rigor (e.g., test witnessing, results in review) if applicable based on software classification and safety-criticality.
- Confirm the software regression testing includes retesting of all safety-critical code components.
- Analyze proposed changes to software products for impacts, particularly to safety, and security.
- Assess that the software safety-critical items are configuration managed, including hazard reports and safety analysis.
- Assess the impact of non-conformances on the safety, quality, and reliability of the project software.
Step 4. Additional considerations to be accessed when you have safety-critical software components:
The provider should include the following general software safety requirements in the project software requirements:
- The software recovers to a known safe state when an anomaly is detected.
- The software properly handles missing and spurious data.
- The software checks the quality of loaded configuration data (such as day of launch guidance parameters) used by the software.
- The software provides at least one independent command for each operator initiated action used to shutdown a function leading to or reducing the control of a hazard.
- The software provides independent safety-critical threads.
- The software commands are required to be diverse from other commands so that a single bit flip could not transform a benign command into an inhibit.
- The software provides a unique command message to remove or change an inhibit that controls a hazard.
- The software provides the status of the inhibits controlling hazards to the operator.
- The software rejects input and output data determined to be invalid by the integrity checks.
- The software provides and checks a functionally independent parameter before issuance of any sequence that could remove an inhibit or perform a hazardous action.
- The software uses separate control paths with different functionality for each inhibit to control a hazard.
1.2 Additional Guidance
Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.
2.2 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
2.3 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
2.4 Associated Activities
This topic is associated with the following Life Cycle Activities: