New in SWEHB

Lessons Laerned from Psyche Project Report

1. Late and Incomplete Flight Software (FSW) Delivery

Incident:
The Psyche mission experienced an eight‑month late delivery of the final GNC flight software build, with hundreds of control parameters and fault protection behaviors still undefined. This delay, combined with numerous unresolved software issues, contributed directly to the missed 2022 launch opportunity. 

Lesson Learned:

• Early Software Definition & Maturity: Mission‑critical software requirements, parameters, and behaviors must be fully defined and matured early to prevent cascading delays.
• Rigorous Defect Disposition: “Use‑as‑is” and unverified failure dispositions must undergo strict technical review to prevent acceptance of excessive residual risk. 

Implication:
Delays and ambiguity in software maturity directly threaten launch schedules, increasing cost, workforce strain, and mission‑risk exposure.

2. Incomplete Verification & Validation (V&V)

Incident:
The project faced major V&V shortfalls, including approximately 1,000 unverified system requirements and incomplete GNC, fault protection, and FSW test coverage. Immature and incompatible testbeds further hindered simulation and closed‑loop testing. 

Lesson Learned:

• Comprehensive V&V Execution: V&V must be resourced, scheduled, and monitored with the same rigor as hardware development.
• Validated Testbeds: Testbeds and simulations must be synchronized early with vendor tools to ensure accurate system‑level testing.

Implication:
Insufficient V&V undermines mission confidence and may conceal system defects until it is too late to correct them within the launch window.

3. Undefined and Insufficiently Tested Fault Protection

Incident:
Fault protection logic was not fully defined or validated prior to the launch delay, leaving mission‑critical behaviors unverified. citeturn1search1.page21

Lesson Learned:

• Early Fault Management Definition: Fault detection, isolation, and recovery logic must be fully specified and integrated into system testing well before ATLO.
• Hazard‑Driven Validation: Fault responses must be validated against hazards and off‑nominal scenarios using high‑fidelity simulations.

Implication:
Incomplete fault protection risks spacecraft safety, autonomy, and ability to recover from anomalies during critical mission phases.

4. Immature Testbeds and Simulation Environments

Incident:
Major incompatibilities between JPL and Maxar testbeds delayed verification activities and prevented execution of essential closed‑loop GNC testing. Early assumptions about vendor simulation capabilities proved incorrect. 

Lesson Learned:

• Interface Verification: Simulation environments must be verified early with contractual clarity on capabilities, interfaces, and data integration.
• End‑to‑End Fidelity: High‑fidelity closed‑loop simulation must be operational well before system‑level V&V.

Implication:
Faulty assumptions about vendor simulation capacity or testbed interoperability can cripple software testing and threaten mission readiness.

5. Poor Metrics and Lack of Visibility into Software Health

Incident:
Psyche’s project metrics masked true software progress. Software risk was consistently under‑reported due to an aversion to categorizing issues as “red,” preventing leadership from recognizing schedule‑threatening problems. 

Lesson Learned:

• Objective Software Metrics: Software maturity must be tracked using measurable indicators such as defect trends, verification progress, and test coverage.
• Risk Transparency: Leadership must encourage open reporting and avoid cultural pressures that suppress accurate risk assessments.

Implication:
When metrics fail to reflect reality, management loses the ability to make timely decisions, creating preventable launch‑critical failures.

6. Insufficient Staffing in Software, GNC, and Systems Engineering

Incident:
Psyche suffered from persistent understaffing in key areas such as flight software, GNC, systems engineering, and V&V. Many roles were filled with inexperienced personnel, with excessive reliance on stretch assignments and limited mentoring.

Lesson Learned:

• Adequate Expertise: Complex missions require experienced staff in critical roles (e.g., Project Chief Engineer, GNC CogE, Fault Protection Lead).
• Sustainable Staffing Models: Workforce planning must account for burnout, skill mix, mentoring, and retention of highly specialized talent.

Implication:
Understaffing reduces software quality, increases risk of technical debt, delays development, and undermines mission execution.

7. Communication Failures Suppressing Software Concerns

Incident:
Software and system engineers raised concerns that were not acted upon. The culture fostered a “prove there is a problem” mentality, making it difficult to elevate software risks. No Independent Technical Authority (ITA) dissents were filed despite significant issues. 

Lesson Learned:

• Open Technical Channels: Projects must maintain safe, responsive pathways for raising technical concerns, including through independent authorities.
• Cultural Reinforcement: Leadership must encourage early reporting and prohibit cultures that penalize raising risks.

Implication:
When team members feel unheard, systemic issues go unaddressed, increasing mission risk and slowing problem resolution.

8. Misalignment with Commercial Vendor (Maxar) Software Capabilities

Incident:
Misaligned expectations for Maxar’s simulation, interface details, and heritage design significantly delayed testing and integration activities. COVID‑related limitations reduced the required face‑to‑face interaction needed to align on software behaviors. 

Lesson Learned:

• Deep Early Integration: NASA personnel must work side‑by‑side with commercial partners early to align on simulation capabilities, interface assumptions, and development processes.
• Contractual Clarity: Software deliverables and testbed capabilities must be unambiguously specified in contracts.

Implication:
Weak alignment with vendor software ecosystems causes delays, rework, and verification gaps that can push missions off launch schedules.

We updated the software milestone review criteria to strengthen alignment with current engineering best practices and project needs. As part of this revision, we introduced new AI‑focused evaluation criteria to ensure teams are appropriately addressing model reliability, validation and verification, data integrity, risk assessment, and responsible use considerations throughout the development lifecycle.

Objective evidence plays a crucial role in ensuring accountability, traceability, and reliability across software assurance and safety activities. It provides documented, unbiased proof that a specific activity has been performed or confirmed by the responsible software assurance/safety personnel — and it’s not just about checking a box. It amplifies the credibility of your processes.

Documenting objective evidence can take multiple forms depending on the activity being verified. Some examples include:

• Audit Records and Checklist Results: Observations, findings, or risks identified, documented in a tracking system, or captured in emails.
• Meeting Records: Attendance lists, meeting minutes, or notes stored in the project repository.
• Status Updates: Memos, emails, or reports confirming an activity took place, supported by summaries or confirmation checklists.
• Reviewed/Witnessed Activities: Signatures on reviewed products or processes to validate completion or compliance.
• Short Summaries: Concise statements that provide insight into specific activities or milestones, such as:
  • Progress on IV&V Program Execution.
  • Percentage of hazards traced to software requirements.

When implemented consistently, objective evidence strengthens your project’s integrity, enhances collaboration, and aligns with the guidelines set forth in Section 8.16 of the handbook. Not only does it enable teams to track progress effectively, but it also instills confidence in the accuracy of assurance efforts.

The bottom line? Every requirement deserves solid, verifiable evidence. By prioritizing documentation, you’re not just managing activities — you’re building trust across the project.

Guidance for the Minimum Recommended Content of the Software Requirements Specification was rewritten and expanded using AI content. This rewrite includes expanded guidance, examples, and new guidance for Software Assurance. PAT-059 - Software Requirements Specification Assessment was updated to coincide with this new guidance.

Guidance for the Minimum Recommended Content of the Software Test Plan was rewritten and expanded using AI content. Due to the breadth of information and examples added, this enhanced guidance has been spread across multiple tabs.

Topic 7.23 - Software Fault Prevention and Tolerance This topic guides developers to reduce the likelihood of software faults pre-flight and to detect/mitigate the effects of software errors should they occur in-flight.  

PLDs, especially FPGAs, are becoming increasingly critical in complex avionics and space systems. Establishing a standardized and scalable approach to their development and assurance will not only improve consistency across NASA projects but also enhance mission safety and reliability. By emphasizing early planning, hazard management, training, cross-center collaboration, and consistent application of best practices, NASA can address current limitations while building a foundation for future advancements.

It includes a checklist, a list of Compliance Data Needs and a Safety Case with guidance. It ensures compliance with applicable safety standards, regulatory requirements (NASA NPR 7150.2D, SSP 50038, FAA, 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.

Contracts must align with safety, reliability, regulatory, and operational readiness requirements to ensure that the software meets the stringent demands of FAA regulations, NASA standards, space system requirements, cybersecurity expectations, and military-grade fault-tolerance protocols.

Each Review Checklist is contained in a PAT (MS Word Document) which may be downloaded and used in your project. Each of the 13 PATs has a table which may be used: 

• to prepare for the review - listing all the documents and expectations that will be covered in the review, 
• in the review - the criteria for successful completion are listed as well as an area to note (Y/N) if the criteria is met, and a Comments cell in the table to record any discussion about the item. 

8.27 - Software Engineering and Software Assurance Checklists - Checklists provide a mechanism to independently evaluate the conformance of software products and processes to applicable requirements, standards, guidelines, plans, and procedures.

8.10 - Facility Software with Safety Considerations - Facility software safety exists to ensure the safe and continuous operation of software associated with ground-based facilities. This topic provides guidance on the Facility Life Cycle, document maturity schedules, milestone entry/exit criteria, and SW Engineering and SA responsibilities. 

Software Assurance is required to perform audits and assessments. Thirty (30) new Process Asset Templates (PATs) (i.e., compliance audit and work product assessment checklists) were created for SA personnel use while performing these activities. Schedules were also created with guidance on when to perform these audits and assessments.

Each Activity page includes links to all related  SWEs, Topics, PATs, and other pages. Links to relevant SPAN pages are also included. 

As new content is added to SWEHB, it will also be added to the appropriate Activity page. This collects all content related to a specific Development or Assurance Activity in a single place.