Spacecraft Design II: Geometric and Physical Intuition
Abstract
Spacecraft design is fundamentally a problem of translating mission needs into producible hardware through a structured, verifiable process. This article examines the conceptual framework underlying spacecraft design methodology—specifically the V-diagram model and its associated design reviews—and explains why this geometric structure prevents costly rework and ensures requirements traceability. The goal is to build intuition for why these processes exist and how they map to the physical reality of building complex systems.
Background
Spacecraft are among the most complex engineered systems humans build. A single mission failure can cost hundreds of millions of dollars and years of scientific opportunity. Unlike many engineered products, spacecraft cannot be easily recalled or repaired once deployed. This constraint creates a fundamental design philosophy: get it right before you build it.
The traditional approach to managing this risk is the System Engineering V Diagram [system-engineering-v-diagram], a bidirectional process that decomposes mission needs into detailed specifications on the left side, then reintegrates and verifies those specifications on the right side. The diagram's power lies in its geometric simplicity: every requirement defined during decomposition must have a corresponding verification activity during integration. This one-to-one mapping prevents requirements from being lost or forgotten.
The left side of the V flows downward through progressive decomposition:
- Mission needs and feasibility studies
- System requirements
- Subsystem requirements
- Component specifications
The right side flows upward through integration and verification:
- Unit testing
- Subsystem verification
- System verification
- Validation against operational requirements
The bottom of the V contains the actual development work—manufacturing, assembly, and integration—where the abstract specifications become physical hardware.
Key Results
The Design Review Hierarchy
Spacecraft development is gated by formal design reviews, each serving a specific purpose in the decomposition-integration cycle. These reviews are not bureaucratic overhead; they are quality checkpoints that prevent exponentially increasing costs of rework.
System Requirement Review (SRR) [system-requirement-review] occurs near the top of the V, validating that high-level mission needs have been correctly translated into derived system requirements. Its purpose is to catch misinterpretations early, when changes are least costly. By verifying that lower-level requirements properly decompose the original mission objectives, SRR ensures the entire development effort remains aligned with stakeholder intent.
System Design Review (SDR) [system-design-review] follows SRR and evaluates how system requirements have been allocated across the spacecraft's configuration items (subsystems and components). SDR bridges requirements and detailed design by examining architectural decisions. It ensures that each requirement has been assigned to a responsible subsystem and that manufacturing constraints have been considered before detailed design work begins.
Preliminary Design Review (PDR) [preliminary-design-review] represents a major commitment point. By this stage, the design team has completed trade studies, selected candidate technologies, and developed preliminary designs for all major subsystems. PDR confirms that the chosen approach is sound before investing in detailed specifications and procurement. It is the last major review before the design approach is "locked down."
Critical Design Review (CDR) [critical-design-review] is the final design gate. It certifies that the detailed design is complete, correct, and ready for manufacturing. At CDR, the "build-to baseline"—the approved, detailed set of all hardware and software specifications [build-to-baseline]—is formally established and frozen. After CDR approval, changes become exponentially more expensive because they may require rework of manufacturing plans, tooling, and already-produced components.
The Build-to Baseline and Configuration Control
Once the build-to baseline is approved at CDR, it becomes the single source of truth for manufacturing and assembly teams. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes [build-to-baseline]. This baseline prevents ambiguity, ensures consistency across distributed manufacturing activities, and provides traceability from requirements through the final product.
The geometric intuition here is critical: the build-to baseline is the narrowest point of the V. Everything above it is decomposition and analysis; everything below it is integration and manufacturing. The baseline itself is the interface between abstract design and physical production. By locking this interface, the organization prevents the chaos that would result from manufacturing teams interpreting specifications differently or making ad-hoc design changes.
Managing Uncertainty: TBD and TBC
Not all design details can be determined simultaneously. Spacecraft design teams use two complementary markers to manage this uncertainty:
To Be Decided (TBD) [to-be-decided-tbd] flags items where the decision-making process itself is still pending. TBD indicates that the actual choice or direction has not been determined. TBDs are tracked rigorously because unresolved decisions cascade into schedule delays and design conflicts.
To Be Confirmed (TBC) [to-be-confirmed-tbc] flags items that are not yet finalized but are expected to be confirmed during development. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback.
The distinction matters: TBD requires active decision-making; TBC requires validation of an existing assumption. Design reviews, particularly CDR, require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. TBCs are acceptable at PDR but should be resolved before CDR.
Worked Example: Requirement Traceability
Consider a simple example: a mission requirement states "the spacecraft shall survive launch vibration without structural failure."
At SRR, this mission requirement is decomposed into derived system requirements:
- "The spacecraft structure shall withstand 10 g peak acceleration in the launch vehicle's primary axis"
- "All fasteners shall be rated for 1.5× the maximum expected vibration load"
At SDR, these system requirements are allocated to configuration items:
- The structural subsystem is responsible for the first requirement
- The mechanical integration team is responsible for the second
At PDR, preliminary designs are proposed:
- Finite element analysis shows the proposed structure survives 12 g acceleration
- Fastener selection is preliminary; specific part numbers are TBC pending vendor data
At CDR, the design is finalized:
- Detailed FEA with manufacturing tolerances confirms 11 g survival margin
- Specific fastener part numbers are selected and locked in the build-to baseline
- Acceptance test procedures are defined: each spacecraft will be subjected to a vibration test that validates the design
This traceability chain ensures that the original mission requirement flows all the way through to the acceptance test that validates the final hardware. If the requirement had been lost or misinterpreted at any stage, the test would catch it—but at much higher cost than catching it at SRR.
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 the assistance of Claude (Anthropic). The structure, synthesis, and explanatory framing are original; all factual claims are sourced from the cited class notes. The author reviewed and validated all technical content for accuracy.