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.
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
a. The software is initialized, at first start and restarts, to a known safe state.
b. The software safely transitions between all predefined known states.
c. Termination performed by the software of functions is performed to a known safe state.
d. Operator overrides of software functions require at least two independent actions by an operator.
e. The software rejects commands received out of sequence when the execution of those commands out of sequence can cause a hazard.
f. The software detects inadvertent memory modification and recovers to a known safe state.
g. The software performs integrity checks on inputs and outputs to/from the software system. Including. The software rejects input and output data determined to be invalid by the integrity checks.
h. The software performs prerequisite checks prior to the execution of safety-critical software commands.
i. No single software event or action is allowed to initiate an identified hazard.
j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
k. The software provides error handling.
l. The software can place the system into a safe state.
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.
3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components. [SWE-156]
3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems. [SWE-154]
3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access. [SWE-157]
3.11.5 The project manager shall ensure that space flight software systems are assessed for possible cybersecurity vulnerabilities and weaknesses. [SWE-158]
3.11.6 The project manager shall address identified cybersecurity vulnerabilities and weaknesses. [SWE-155]
3.11.7 The project manager shall test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis. [SWE-159]
3.11.8 The project manager shall identify, record, and implement secure coding practices. [SWE-207]
3.11.9 The project manager shall verify that the software code meets the project’s secure coding standard by using the results from static analysis tool(s). [SWE-185]
Step 3. Implement the Software Safety-Critical Requirements and activities is contained in NASA-STD-8739.8:
1. Confirm that the identified safety-critical software components have implemented the safety-critical software assurance requirements listed in this standard.
2. 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.
3. Analyze the design and work with the project to implement NPR 7150.2 requirement items "a" through "l."
4. 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.
5. 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.
6. Assess each safety-critical software component to determine the software component’s cyclomatic complexity value.
7. 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.
8. 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.
9. 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.
10. 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.
11. Develop a software assurance cost estimation for the project, including cost estimation associated with handling safety-critical software.
12. 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.
13. Analyze the updated hazard reports and design at review points to determine if any newly identified software components are safety-critical.
14. Develop and maintain a list of all software safety-critical components that have been identified by the system hazard analysis.
15. Develop and maintain a software safety analysis throughout the software development lifecycle.
16. 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.
17. Analyze the software architecture features to determine if any software architecture features impact safety and mission assurance.
18. Develop a list of software architecture features that impact safety and mission assurance.
19. Confirm that the software design implements all of the required safety-critical functions and requirements.
20. Confirm that the project successfully executes the required unit tests, particularly those testing safety-critical functions.
21. Perform additional rigor (e.g., test witnessing, results in review) if applicable based on software classification and safety-criticality.
22. Confirm the software regression testing includes retesting of all safety-critical code components.
23. Analyze proposed changes to software products for impacts, particularly to safety, and security.
24. Assess that the software safety-critical items are configuration managed, including hazard reports and safety analysis.
25. 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.