8.29 - Software Certification in Human-Rated Missions

Web Resources

See edit history of this section

Post feedback on this section

Section Labels:

Unknown macro: {page-info}

1. Introduction
2. Compliance Data Needs
3. Safety Case
4. Resources

1. Introduction

This checklist provides comprehensive data and evidence required to certify software for human-rated missions.It ensures compliance with applicable safety standards, regulatory requirements (NASA NPR 7150.2D ⁰⁸³ , SSP 50038 ⁰¹⁴ , FAA 450.141 Computing systems, NASA-STD-8739.8B ²⁷⁸), mission-critical functionality, and stakeholder acceptance of residual risks, demonstrating that the software is safe, reliable, and mission-ready for crewed spaceflight operations.

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.

PAT-082 - Software Certification in Human-Rated Missions Checklist

2. Key Software Compliance Data Needs

2.1 Summary Table of Key Software Compliance Data Needs

Requirements	Access to the software requirements or software user stories, software acceptance criteria, software use cases, software functional specifications, software behaviors, software feature descriptions, or software tickets. Access to the System/Software requirements traceability data Access to the hazard control software requirements traceability data Explanation on software safety constraints and assumptions Access to the software requirements analysis results
Design	Access to the software design Explanation on software fault containment and management approach Access to the software design analysis results Access to the Interface Control Documents (ICDs) for software interfaces Access to the data dictionary data Data demonstrating prerequisite checks for all hazardous commands Explanation on how the software design and requirements meet the safety critical requirements Explanation on how the safety-critical code is modifiable Demonstrate that the applicable human factors design principles are in place in the software
Development	Access to the software operational plans or user’s manual Explanation of the Fault Tolerance approach used in the design Access to the source code Approval data for all AI uses in flight software before deployment. Demonstrate that the displayed confidence levels are correct for all critical AI decisions and predictions. Demonstrate that the AI systems used in critical space flight software are managed with transparency to maintain safety, reliability, and accountability. Access to the software defect reports (open/closed with severity), anomaly logs, residual risk acceptance with stakeholder sign-off Access to all tailoring/waiver/deviation and TBR/TBD/FWD closure records. Evidence that the approved software processes were followed during all software development activities Evidence of closer of peer reviews/inspection findings for requirements, architecture/design, code and test artifacts review Evidence of qualification and pedigree of reused/third‑party software Provide an understanding of the certifications process for the software models & simulations used to qualify flight software. Data showing the Worst‑Case Execution Time (WCET), timing analysis, and scheduling evidence, including partitioning and multicore interference analysis where relevant.
Verification & Validation	Access to the software test results Access to the MC/DC coverage data for safety-critical components Access to the static and dynamic analysis testing approach and results Demonstrate the fault injection resilience under worst-case conditions Demonstrate how the software handles spurious signals and invalid inputs Provide an understanding of the certifications process for the software test environments used to qualify flight software. Provide results of a cyclomatic complexity analyses Provide a list of identified software issues, anomalies, and defects, with clear and traceable justifications for acceptance of any unresolved items. Provide data showing the operational test results and data confirming system resource margins under nominal and worst-case scenarios, including CPU/memory/throughput margins data Access to the IV&V reports and findings and an understanding of the IV&V scope
Hazard Analysis	Access to the software related hazard analysis reports, fault tree analysis, and FMEA addressing all software hazards and mitigation strategies. Demonstrate that all AI systems generate warnings and recommendations for anomalies that could lead to hazards Demonstrate the operator Action Validation Explanation of the software safing Procedures
Configuration Management	Access to the software documentation, Access to the software change Logs Access to the software version control, baseline definitions, and audit records for all changes.
Operational Procedures	Explanation of the software control Sequences, Explanation of any software manual safing data and processes
Cybersecurity	Demonstrate that the software has encryption, authentication, meets secure coding practices, and has access control Access to the results showing penetration testing and vulnerability analysis

2.2 Key Software Compliance Data Needs Rationale

Section: Requirements

Item	Rationale
Access to the software requirements or software user stories, software acceptance criteria, software use cases, software functional specifications, software behaviors, software feature descriptions, or software tickets	Demonstrated the software capability definition and software testing criteria. SWEHB emphasizes complete, correct, validated SRS content as the foundation for safe, verifiable software; early clarity prevents costly downstream defects and safety gaps.
Access to the System/Software requirements traceability data	Bi‑directional traceability is required to prove every design, code, and test artifact maps to a validated system need—preventing orphan functionality and ensuring hazards are controlled.
Access to the hazard control software requirements traceability data	Hazard controls must trace explicitly from hazard analysis to software requirements and back to verification evidence to avoid missing or partial mitigations.
Explanation on software safety constraints and assumptions	Documented constraints and assumptions prevent hidden coupling and incorrect operating expectations—frequent root causes in lessons learned for hazardous behavior.
Access to the software requirements analysis results	Structured requirements analysis (ambiguity checks, safety impacts, HSI considerations) provides objective evidence that requirements are testable, feasible, and complete before design.

Section: Design

Item	Rationale
Access to the software design	Architecture/design descriptions enable validation of partitioning, redundancy, timing, and safety mechanisms; undocumented design is a recurring integration‑failure source in SWEHB.
Explanation on software fault containment and management approach	A clear FDIR strategy limits fault propagation, preserves redundancy, and supports safe recovery for safety‑critical functions.
Access to the software design analysis results	Design reviews/analyses expose interface risks, safety gaps, and performance limits early, reducing costly rework during integration/test.
Access to the Interface Control Documents (ICDs) for software interfaces	ICDs prevent interface mismatch failures—one of the most common categories of integration defects called out in SWEHB checklists.
Access to the data dictionary data	Data dictionaries provide authoritative definitions and units, preventing misinterpretation and unit conversion defects across teams/tools. (SWEHB practice captured in certification checklist.)
Data demonstrating prerequisite checks for all hazardous commands	Prerequisite checks are explicitly required for safety‑critical design to block unsafe command execution unless the system state is validated.
Explanation on how the design and requirements meet safety‑critical requirements	Explicit mapping from safety‑critical requirements to design elements verifies that every control is implemented and testable—closing common gaps seen in hazard mitigations.
Explanation on how the safety‑critical code is modifiable	Modular, isolated safety‑critical code reduces regression risk during updates and enables focused assurance/maintenance. (Emphasized in SWEHB certification guidance.)
Demonstrate applicable human‑factors design principles in the software	HSI evidence (clear displays, alerts, error tolerance) mitigates operator error and automation surprise—frequent contributors to unsafe states in lessons learned and SWEHB checklists.

Section: Development

Item	Rationale
Access to the software operational plans or user’s manual	Operational manuals drive correct crew/operator actions; unclear procedures have historically led to unsafe system states—documented guidance is essential.
Explanation of the Fault Tolerance approach used in the design	Development evidence must confirm the implemented redundancy, monitoring, and recovery match the approved design/FDIR strategy.
Access to the source code	Assurance/IV&V require code access to assess correctness, safety patterns, and compliance; “code is the design” for verification in SWEHB practice.
Approval data for all AI uses in flight software before deployment	The human‑rated certification checklist in SWEHB requires governance of novel tech; AI decisions must be bounded, transparent, and verified before mission use.
Demonstrate correct AI confidence levels for critical decisions/predictions	Accurate confidence cues preserve appropriate human trust; misleading confidence can induce hazardous operator actions (SWEHB human‑rated checklist).
Demonstrate AI transparency/accountability in critical flight software	Transparency and auditable behavior enable assurance teams to verify AI outputs, edge cases, and failure handling consistent with safety requirements (SWEHB PAT guidance).
Access to defect reports, anomaly logs, and residual risk acceptance	Defect trends and residual‑risk approvals provide readiness evidence and ensure risks are visible and accepted prior to flight (SWEHB PAT‑082).
Access to tailoring/waiver/deviation and TBR/TBD/FWD closures	Tailoring/waiver records show what SWEHB/NPR expectations were modified and how verification gaps were closed—preventing undocumented process escapes.
Evidence that approved processes were followed during development	SWEHB lessons emphasize objective evidence (reviews, audits, checklists) to confirm disciplined execution—avoiding “process‑on‑paper” failures.
Evidence of closure of peer review/inspection findings	Peer reviews are high‑value defect prevention in SWEHB; closure evidence ensures findings are resolved, not deferred into flight risk.
Evidence of qualification/pedigree of reused/third‑party software	SWEHB certification content calls for assessing provenance, constraints, known defects, and verification completeness to control integration risk.
Certification process for models & simulations used to qualify flight software	SWEHB requires validated/accredited models/sims for qualification; unvalidated M&S can mask defects and create false confidence.
WCET/timing/scheduling evidence (partitioning & multicore interference)	Deterministic timing & schedulability evidence prevent deadline misses and resource starvation—common latent hazards noted in SWEHB certification checklists.

Section: Verification & Validation

Item	Rationale
Access to the software test results	Test evidence must trace to requirements and hazards to prove correctness and safety under nominal/off‑nominal conditions (SWEHB).
Access to MC/DC coverage data for safety‑critical components	For safety‑critical logic, MC/DC helps reveal untested decision paths—improving confidence that critical branches cannot hide defects (SWEHB practice).
Static and dynamic analysis approach/results	Static/dynamic analyses expose memory, concurrency, and API defects early, complementing functional tests with deeper correctness checks (SWEHB PAT‑082).
Fault‑injection resilience under worst‑case conditions	Fault‑injection validates robustness of error handling and safe‑state transitions under realistic fault scenarios (SWEHB).
Handling spurious signals and invalid inputs	Defensive input handling and integrity checks are SWEHB safety‑critical design requirements to prevent unsafe behavior from noise or corruption.
Certification of software test environments	Accredited test environments assure fidelity so test results represent flight behavior—preventing false positives/negatives (SWEHB PAT‑082).
Cyclomatic complexity analyses results	Complexity correlates with defect likelihood and test effort; tracking supports risk‑based testing and maintainability (SWEHB checklist).
Issues/anomalies/defects list with unresolved‑item justifications	Residual issues require documented operational mitigations and rationale to ensure informed risk acceptance before flight (SWEHB).
Operational test results & resource margins (CPU/memory/throughput)	Resource margin evidence demonstrates the system sustains mission loads without entering unsafe degraded states (SWEHB).
Access to IV&V reports/findings & IV&V scope understanding	Independent assessment adds rigor and identifies latent risks; scope clarity ensures findings are dispositioned (SWEHB/SMA IV&V discussion).

Section: Hazard Analysis

Item	Rationale
Hazard analysis, FTA, FMEA	Hazard analyses formally identify software causes/contributions and define controls; they are the backbone for safety‑critical requirements and tests (SWEHB).
AI warnings & recommendations for anomalies	AI components must surface anomaly cues and recommended mitigations in time for operator/software safing to prevent hazard escalation (SWEHB PAT‑082 scope).
Operator Action Validation	Operator action validation ensures human‑software interactions are unambiguous and error‑tolerant—reducing unsafe actions under stress (SWEHB checklist).
Software safing procedures	Safing procedures must reliably place the system into known safe states on detection of hazardous conditions—captured in SWEHB safety‑critical design items.

Section: Configuration Management

Item	Rationale
Access to the software documentation	CM control of documentation prevents divergence between what is built, tested, and flown—frequent contributors to integration defects (SWEHB PAT‑082).
Access to the software change logs	Change history enables traceability and impact assessment for safety‑critical components/interfaces (SWEHB).
Version control, baseline definitions, audit records	Version/baseline and audits ensure the exact tested configuration proceeds to flight and prevent unauthorized changes (SWEHB checklist).

Section: Operational Procedures

Item	Rationale
Explanation of the software control sequences	Clear control sequences reduce operator confusion and ensure predictable behavior during time‑critical operations (SWEHB).
Explanation of any software manual safing data/processes	Manual safing provides a human‑initiated fallback when automation fails; procedures must be explicit, tested, and accessible (SWEHB).

Section: Cybersecurity

Item	Rationale
Encryption, authentication, secure coding, access control	Security controls protect command authority, data integrity, and system availability—security weaknesses can become safety hazards (SWEHB).
Penetration testing and vulnerability analysis results	Pen/vuln testing finds exploitable weaknesses before flight, supporting remediation and risk reduction (SWEHB checklist practice).

3. Example Potential Safety Case for Human-Rated Software Certification

This safety case demonstrates that the software used in this human-rated mission adheres to rigorous safety, quality, and regulatory standards. Based on the evidence provided, the software is flight-ready and capable of supporting critical mission operations while ensuring the safety of the crew and spacecraft under both nominal and adverse conditions.

1. Requirements and Traceability

Argument: The software requirements are clearly defined, traceable, and aligned with safety-critical mission needs.
Evidence:
- Comprehensive Software Requirements Specification (SRS) covering high-level mission-critical systems (e.g., navigation, propulsion, anomaly detection, life support, and abort operations).
- Verified safety requirements (fault tolerance, redundancy, and safe initialization/termination).
- Acceptable quality of detailed low-level safety-critical requirements, including specifics like algorithm designs and timing constraints.
- A completed and validated Requirements Traceability Matrix (RTM) showing bi-directional traceability from requirements through design, code, and test results.
- Reviewed system-level safety analyses to document "Must Work" (MWF) and "Must Not Work" (MNWF) requirements, prerequisite checks for hazardous commands, and mitigation strategies.

2. Software Design and Architecture

Argument: The software architecture is resilient, modular, and designed for fault tolerance and safety-critical operations.
Evidence:

Architecture documentation detailing modular fault isolation, redundancy, and resiliency mechanisms.
Block diagrams illustrating fault containment, fail-safe control paths, and separation of critical functions.
Documentation and analysis of safety-critical subsystems (e.g., propulsion, crew displays, navigation) with clearly defined responsibilities.
Verified Interface Control Documents (ICDs), ensuring compatibility between internal software, hardware systems, and external interactions.
Safety validation evidence for safeguards like fault containment, error detection, operator validation, integrity checks, and anomaly recovery processes.
Independent redundant system designs ensuring physical and logical separation to mitigate single points of failure.
Validation of fault-tolerant mechanisms, including cosmic radiation protection in CPU designs.

3. Hazard Analysis and Safety Evidence

Argument: All hazards associated with software functionality are identified, analyzed, and mitigated to acceptable levels of risk.
Evidence:

A complete Hazard Analysis Report (HAR) identifying software-driving hazards and the mitigation strategies in place.
Fault Tree Analysis (FTA) and Failure Mode and Effects Analysis (FMEA) showing robust fault prevention and recovery mechanisms or a completed System Theoretic Process Analysis (STPA) showing robust fault prevention and recovery mechanisms.
Time-to-effect (TTE) analyses ensuring hazardous conditions can be addressed by safing systems within operational thresholds.
Residual risk documentation showing resolution or acceptance of remaining risks by stakeholders.

4. Verification and Validation (V&V) Evidence

Argument: Rigorous testing, validation, and coverage analyses demonstrate software compliance with safety-critical requirements.
Evidence:
- 100% Statement Coverage.
- 100% Decision Coverage.
- 100% Modified Condition/Decision Coverage (MC/DC) for safety-critical components.

Unit testing, system integration testing, end-to-end validation, and operational flight simulations confirming that expected functional performance aligns with safety goals.
Validation of reused components (COTS, GOTS, OSS, MOTS) to ensure compatibility and reliable integration into human-rated environments.
Coverage analysis demonstrating:
Static analysis reports showing compliance with coding standards and identification/remediation of software defects.
Fault injection testing results validating responses to corrupted data, anomalies during power disruptions, and memory errors.
Worst-case response timing analysis confirming safing systems meet TTE requirements under degraded conditions.

5. Configuration Management and Change Tracking

Argument: Configuration management processes ensure version control and traceability for all software changes.
Evidence:
- Documentation showing version-controlled baselines for flight-ready software and data loads, including configuration hashes and release notes.
- Audit records verifying modifications, regression testing, impact analyses, and stakeholder approvals

6. Cybersecurity and Security Validation

Argument: The software architecture incorporates robust cybersecurity measures to mitigate threats in operation environments.
Evidence:
- Security validation reports demonstrating encryption protocols, authentication mechanisms, access control, and secure coding practices.
- Penetration testing results validating resilience against cyberattacks and unauthorized system access during pre-launch and flight.
- Vulnerability analysis reports confirming detection, resolution, and closure of security-related risks.

7. Defect Management and Residual Risks

Argument: All software defects have been resolved or mitigated to acceptable levels of residual risk.
Evidence:

Defect reports showing all open and closed defects categorized by severity and justifications for acceptance of residual risks.
Logs documenting defect resolutions and testing data validating the outcomes of mitigation measures.
Residual risk acceptance documentation signed off by stakeholders, with sufficient evidence showing safe system behavior despite unresolved minor risks.

8. Resource Utilization and Performance Metrics

Argument: The software demonstrates sufficient resource margins and acceptable performance under normal and worst-case conditions.
Evidence:

Validation test results confirming acceptable command execution timing (e.g., abort triggers).
Operating analysis showing CPU utilization below 80% even under maximum load conditions.
Methods for anomaly detection and recovery to safe states outlined and validated.

9. Team Training and Software Process Compliance

Argument: Development teams adhere to validated processes and are properly trained in safety-critical mission standards.
Evidence:
- Records of team training addressing human-rated software workflows, defect management, and compliance with coding guidelines.
- Process compliance reports documenting adherence to validated development processes.
- Operator manuals ensuring deliberate, independent actions are necessary to execute critical safety commands

10. Certification and Regulatory Compliance

Argument: The software complies with all applicable standards and safety regulations for human-rated missions.
Evidence:

Certification artifacts for compliance with standards like NASA NPR 7150.2D ⁰⁸³ ,
NASA SSP 50038 ⁰¹⁴, FAA requirements, and NASA-STD-8739.8B ²⁷⁸ .
IV&V certification reports confirming operational maturity and compliance with safety standards by independent entities.
Regulatory compliance statements from authorities certifying readiness for human-rated missions.
Validation of software updates (patched or upgraded) ensuring continued compliance with safety requirements.

11. Flight Readiness Review (FRR) Certification

Argument: The software is flight-ready and capable of safely supporting mission operations.
Evidence:

Software Version Description Document (VDD) completion demonstrating proper documentation of the deployed software.
Final test results confirming readiness during flight operations in all mission environments.
FRR exit criteria signed off by stakeholders, certifying acceptance or resolution of all known risks, hazards, defects, and anomalies.

12. Flight Software Structural Quality

Argument: The software architecture and implementation are structurally sound and meet all quality standards for safety-critical applications.
Evidence:

Cyclomatic complexity analysis showing all safety-critical components meet thresholds (≤ 15).
Documentation verifying fault-tolerant mechanisms for error handling, failure recovery, and system operation under degraded conditions.
Maintainability analysis supporting modular coding practices for long-term sustainability and easy updates.
Code quality reports validating compliance with architecture, standards, security, and testability requirements.

4. Resources

4.1 References

Click here to view master references table.

(SWEREF-014)
Computer-Based Control System Safety Requirements
SSP 50038, Revision C, NASA International Space Station Program, 1995.
(SWEREF-083)
NPR 7150.2 NASA Software Engineering Requirements,
NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
(SWEREF-278)
SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
NASA-STD-8739.8B, NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A"

4.2 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

4.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

Related Links
PAT-082 - Software Certification in Human-Rated Missions Checklist

4.4 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 ¹⁹⁷

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).

SPAN Links

4.5 Related Activities

This Topic is related to the following Life Cycle Activities:

Related Links

Content

Space Tools