Spacecraft Design II: Problem-Solving Patterns and Heuristics

Abstract

Spacecraft design is fundamentally a problem of managing uncertainty and complexity across multiple development phases. This article examines the structural patterns and decision-making heuristics that govern spacecraft development, with emphasis on the verification framework, design review gates, and baseline management practices that prevent costly rework. These patterns emerge from the need to decompose mission requirements into implementable designs while maintaining traceability and catching errors early.

Background

Spacecraft development involves translating abstract mission objectives into concrete hardware and software specifications. The challenge is not merely technical but organizational: multiple teams must coordinate across design, manufacturing, integration, and testing without losing sight of original requirements. Traditional approaches to managing this complexity rely on formal structure rather than heroic individual effort.

The foundational framework for this structure is the System Engineering V Diagram ^{[system-engineering-v-diagram]}, which maps the entire lifecycle from mission conception through retirement. The V-shape embodies a critical insight: every requirement defined during decomposition must have a corresponding verification activity during integration. This bidirectional structure prevents the common failure mode where teams build something technically sound but misaligned with mission needs.

Key Results

The Verification-Decomposition Duality

The V Diagram establishes that decomposition and verification are not sequential but complementary. On the left side, mission needs flow downward through feasibility studies, concept of operations, and system requirements into progressively detailed design phases. On the right side, unit testing flows upward through subsystem verification, system verification, and validation back to operational requirements ^{[system-engineering-v-diagram]}.

This structure prevents requirements from being lost during implementation. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing. The pattern is not merely organizational convenience; it reflects a fundamental principle: traceability requires that every requirement have both a design artifact and a verification artifact.

Design Review Gates as Risk Reduction

Spacecraft development employs a sequence of formal design reviews that function as quality gates. Each review occurs at a specific point in the development lifecycle and addresses a distinct set of concerns.

The System Requirement Review (SRR) occurs near the top of the V Diagram, before significant design investment. Its purpose is to validate that derived requirements properly decompose high-level mission objectives ^{[system-requirement-review]}. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.

The System Design Review (SDR) bridges requirements and detailed design by examining how system requirements have been allocated across configuration items and manufacturing approaches ^{[system-design-review]}. It ensures the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems.

The Preliminary Design Review (PDR) represents a significant commitment point. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems ^{[preliminary-design-review]}. PDR confirms that the chosen approach is sound before investing in detailed specifications and procurement. It is the last major review before the design is "locked down" for final implementation.

The Critical Design Review (CDR) is the final design checkpoint. It certifies that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements ^{[critical-design-review]}. CDR occurs after detailed design is complete but before manufacturing begins—the last opportunity to catch design errors without incurring manufacturing costs.

The cost of error correction increases exponentially across these phases. An error caught at SRR may require rewriting a few requirement documents. An error caught at PDR may require redesigning subsystems. An error caught after CDR may require scrapping tooling and reworking manufactured components. This cost gradient creates a powerful incentive to invest in thorough reviews early.

The Build-to Baseline as Single Source of Truth

Once CDR is approved, the design transitions to the build-to baseline—the locked, approved set of complete hardware and software specifications that serves as the authoritative reference for manufacturing and assembly ^{[build-to-baseline]}. This baseline contains all detailed specifications: drawings, interface definitions, performance parameters, and acceptance criteria.

The build-to baseline eliminates ambiguity by locking all design decisions with sufficient detail that production can proceed without interpretation. All subsequent changes are controlled through formal change management processes, ensuring configuration integrity and traceability from original requirements through the final product. This prevents costly rework and maintains consistency across distributed manufacturing activities.

Managing Uncertainty: TBD and TBC

Not all design details can be determined simultaneously. Spacecraft design documents employ two markers to distinguish types of unresolved items:

To Be Decided (TBD) indicates items where the decision-making process itself is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. TBDs flag areas requiring active decision-making before the design can be considered complete.

To Be Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development ^{[to-be-confirmed-tbc]}. TBC assumes an existing value or approach will be validated later through analysis, testing, or vendor feedback.

The distinction matters because TBDs represent genuine uncertainty in the solution space, while TBCs represent provisional commitments awaiting confirmation. Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. Unresolved TBDs can cascade into schedule delays and design conflicts.

Worked Example: Requirement Traceability Through the V Diagram

Consider a spacecraft power subsystem with a high-level mission requirement: "The spacecraft shall maintain continuous power to critical systems during eclipse periods lasting up to 90 minutes."

Decomposition phase (left side of V):

• At SRR, this requirement is decomposed into derived requirements: battery capacity must store $E_{\text{min}} = P_{\text{crit}} \times t_{\text{eclipse}}$ joules, where $P_{\text{crit}}$ is critical load power and $t_{\text{eclipse}} = 5400$ seconds.
• At SDR, the requirement is allocated: the power subsystem is assigned responsibility for battery selection and thermal management; the attitude control subsystem is assigned responsibility for minimizing power draw during eclipse.
• At PDR, preliminary designs specify a lithium-ion battery pack with nominal capacity 50 kWh and a thermal control strategy using passive radiators.
• At CDR, detailed specifications lock the exact battery model, charge/discharge curves, thermal interface materials, and acceptance test procedures.

Integration/verification phase (right side of V):

• Unit testing verifies individual battery cells meet charge/discharge specifications.
• Subsystem verification tests the complete battery pack under simulated eclipse thermal conditions.
• System verification tests the power subsystem integrated with attitude control, confirming that the combined system maintains power during a full 90-minute eclipse simulation.
• Validation confirms the integrated spacecraft meets the original mission requirement in a representative operational scenario.

Each level of decomposition has a matching level of verification. If the original requirement is not met during validation, traceability allows engineers to identify which subsystem or component failed and which design decision caused the failure.

References

• ^{[system-engineering-v-diagram]}
• ^{[system-requirement-review]}
• ^{[system-design-review]}
• ^{[preliminary-design-review]}
• ^{[critical-design-review]}
• ^{[build-to-baseline]}
• ^{[critical-design-review]}
• ^{[preliminary-design-review]}
• ^{[to-be-decided-tbd]}
• ^{[to-be-confirmed-tbc]}

AI Disclosure

This article was drafted with AI assistance from class notes (Zettelkasten). All factual claims are cited to source notes. The structure, synthesis, and worked example were generated by an AI language model based on the provided notes. The author is responsible for accuracy and completeness of citations.