Spacecraft Design II: Problem-Solving Patterns and Heuristics

Abstract

Spacecraft design is fundamentally a problem of managing complexity through structured decomposition and verification. This article examines the core patterns and heuristics that guide spacecraft development, focusing on the System Engineering V-diagram as a unifying framework and the role of design reviews as quality gates. Rather than treating design as a linear sequence, we show how bidirectional traceability between requirements and verification prevents costly rework and ensures mission success.

Background

Spacecraft development involves thousands of interdependent decisions spanning mission objectives, subsystem architecture, component selection, manufacturing constraints, and operational procedures. Without systematic structure, these decisions easily become misaligned, leading to designs that fail to meet mission needs or exceed budget and schedule.

The aerospace industry has converged on a set of problem-solving patterns that address this challenge. Chief among these is the System Engineering V-diagram, which provides a conceptual map of the entire development lifecycle ^{[system-engineering-v-diagram]}. The V-diagram is not merely a flowchart; it encodes a fundamental principle: every requirement defined during the decomposition phase must have a corresponding verification activity during integration and testing.

This principle prevents a common failure mode in complex projects: building something that technically works but fails to meet the original mission need. By enforcing bidirectional traceability, the V-diagram ensures that requirements do not become lost or reinterpreted as design work progresses.

Key Results

The V-Diagram as a Traceability Framework

The V-diagram structures spacecraft development into two complementary flows ^{[system-engineering-v-diagram]}:

• Left side (decomposition): Mission needs flow downward through feasibility studies, concept of operations, system requirements, and progressively detailed design phases. At each level, higher-level requirements are decomposed into lower-level derived requirements assigned to specific subsystems or components.

• Right side (integration and verification): Unit testing flows upward through subsystem verification, system verification, and validation back to operational requirements. Each level of integration mirrors a level of decomposition, ensuring that every requirement has a corresponding test or verification activity.

• Bottom: Development processes, timelines, and documentation activities that support both flows.

The V-shape itself is the key insight: it prevents the "waterfall trap" where requirements are defined once and then forgotten. Instead, every requirement is actively verified, and every verification activity is traced back to a specific requirement.

Design Reviews as Quality Gates

Spacecraft development employs a series of formal design reviews that serve as quality gates and commitment points. These reviews enforce the V-diagram principle by requiring evidence of traceability and maturity before proceeding to the next phase.

System Requirement Review (SRR) occurs near the top of the V-diagram, validating that high-level mission needs have been correctly translated into derived system requirements ^{[system-requirement-review]}. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.

System Design Review (SDR) bridges requirements and detailed design by examining how system requirements have been allocated across subsystems and configuration items ^{[system-design-review]}. SDR ensures the proposed architecture is sound and that manufacturing constraints have been considered before detailed design begins.

Preliminary Design Review (PDR) demonstrates that the proposed design approach is feasible and mature enough to justify proceeding to final detailed design ^{[preliminary-design-review]}. By this stage, trade studies are complete, technologies are selected, and preliminary designs for all major subsystems exist. PDR is the last major review before the design is "locked down."

Critical Design Review (CDR) certifies that the detailed design is complete, correct, and ready for manufacturing ^{[critical-design-review]}. CDR ensures that every requirement has a corresponding design specification, that all interfaces are properly defined, and that the design is producible. After CDR approval, the design becomes the "build-to baseline"—the authoritative reference for manufacturing ^{[build-to-baseline]}.

Managing Uncertainty: TBD and TBC

Spacecraft design cannot resolve all details simultaneously. Two complementary markers manage this uncertainty:

To Be Decided (TBD) flags items where the decision-making process is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. A TBD indicates that active choice is required before the design can be considered complete.

To Be Confirmed (TBC) flags items that are not yet finalized but are expected to be confirmed during development ^{[to-be-confirmed-tbc]}. Unlike TBD, TBC assumes an existing value or approach that will be validated rather than chosen.

The distinction is subtle but important: TBD requires decision-making, while TBC requires confirmation. Design reviews, particularly CDR, require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. TBCs are acceptable if confirmation is scheduled and tracked.

Worked Example: Allocating a Power Budget

Consider a spacecraft with a mission requirement: "The spacecraft shall maintain continuous operation for 5 years in low Earth orbit." This high-level requirement must be decomposed through the V-diagram.

At SRR, this mission requirement is translated into derived system requirements:

• "The power subsystem shall provide an average of 500 W continuous power."
• "The power subsystem shall include redundancy to tolerate single-point failures in the primary bus."

At SDR, these system requirements are allocated to configuration items:

• Solar arrays: 750 W peak (accounting for eclipse and degradation)
• Battery: 50 Wh capacity (for eclipse periods)
• Power distribution unit: dual-string architecture with automatic switchover

At PDR, preliminary designs are proposed:

• Silicon solar cells with 28% efficiency (TBC pending vendor data)
• Lithium-ion battery pack with 95% depth of discharge (TBD pending thermal analysis)
• Custom power distribution unit with redundant regulators

At CDR, detailed specifications are locked:

• Specific solar cell model with measured efficiency: 28.2%
• Battery pack with confirmed depth of discharge: 93% (revised based on thermal analysis)
• Power distribution unit with detailed schematics, interface specifications, and test procedures

On the right side of the V, each specification has a corresponding verification:

• Solar array performance verified by thermal vacuum testing
• Battery capacity verified by charge/discharge cycling
• Power distribution unit verified by functional testing and redundancy validation
• System power balance verified by integrated testing with all subsystems operating

This example illustrates how the V-diagram enforces traceability: the original mission requirement is never lost; it is progressively refined and verified at each level.

References

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

AI Disclosure

This article was drafted with AI assistance. The structure, examples, and synthesis are based on the author's class notes from Spacecraft Design II. All factual claims are cited to specific notes. The worked example (power budget allocation) was generated to illustrate the V-diagram principle and should be verified against course materials before use in professional contexts.