Spacecraft Design II: Foundations and First Principles

Abstract

Spacecraft design is fundamentally a problem of translating mission needs into a producible, verifiable system. This article examines the core frameworks and checkpoints that govern modern spacecraft development, with emphasis on the System Engineering V Diagram and the critical design review milestones. We show how requirements flow through decomposition and recompose through integration, and why formal baselines and configuration control are essential to preventing costly rework.

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 or operational opportunity. This high cost of failure has driven the aerospace industry to develop rigorous, structured development processes that emphasize early verification, traceability, and formal checkpoints.

The foundation of modern spacecraft design is the System Engineering V Diagram ^{[system-engineering-v-diagram]}, a lifecycle framework that maps the entire development path from conception through retirement. The V-shape is not merely aesthetic; it encodes a critical principle: every requirement defined during the left-side (decomposition) phase must have a corresponding verification activity on the right side (integration and validation). This bidirectional structure prevents requirements from being lost or forgotten during implementation.

The left side of the V flows downward through mission needs, feasibility studies, concept of operations, system requirements, and progressively detailed design phases. The right side flows upward through unit testing, subsystem verification, system verification, and validation back to operational requirements. The bottom of the V contains development processes, timelines, and documentation activities that support both sides ^{[system-engineering-v-diagram]}.

Key Results

The Requirements-to-Verification Chain

The V Diagram's central insight is that traceability must be bidirectional. Each system requirement must be allocated to one or more subsystems or components (left side), and each subsystem or component must be verified to satisfy its allocated requirements (right side). This prevents the common pitfall of building something that technically works but does not meet the original mission needs.

Design Review Milestones

Spacecraft development is gated by a sequence of formal design reviews, each serving a distinct purpose in the lifecycle:

System Requirement Review (SRR) ^{[system-requirement-review]} occurs near the top of the V Diagram, before significant design effort is invested. SRR validates that derived requirements properly decompose and capture the high-level system requirements established during mission definition. By catching misinterpretations early, when changes are least costly, SRR prevents downstream rework and ensures alignment with stakeholder needs.

System Design Review (SDR) ^{[system-design-review]} bridges requirements and detailed design by examining how system requirements have been allocated across configuration items (subsystems and components). SDR assesses manufacturing feasibility and confirms the proposed system decomposition is sound. This review prevents architectural mistakes that would be expensive to correct later.

Preliminary Design Review (PDR) ^{[preliminary-design-review]} is a major commitment gate. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems. PDR demonstrates that the proposed design approach is feasible and mature enough to justify proceeding to final detailed design. It is the last major review before the design is "locked down" for final implementation, reducing risk by catching fundamental design flaws before they propagate into expensive detailed work.

Critical Design Review (CDR) ^{[critical-design-review]} is the final design checkpoint. CDR certifies that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements, and that the final design fulfills all specifications and commitments established at PDR ^{[critical-design-review]}. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft. Changes after CDR are exponentially more expensive because they may require rework of manufacturing plans, tooling, and already-produced components.

The Build-to Baseline

The Build-to Baseline ^{[build-to-baseline]} is the locked, approved set of complete hardware and software specifications established and approved at CDR. It serves as the single source of truth for manufacturing and assembly teams, eliminating ambiguity by containing all detailed specifications—drawings, interface definitions, performance parameters, and acceptance criteria—necessary to manufacture and assemble the spacecraft in compliance with functional and performance requirements.

Once approved, the build-to baseline is controlled through formal change management processes. This prevents ambiguity, ensures consistency across distributed manufacturing activities, and provides an auditable record of what was actually built versus what was designed. The baseline prevents costly rework by locking design decisions with sufficient detail that production can proceed without interpretation.

Documentation Markers: TBD and TBC

During design development, not all details can be determined simultaneously. Two markers are used to flag unresolved items:

To Be Decided (TBD) ^{[to-be-decided-tbd]} indicates that the decision-making process itself is still pending and the outcome is uncertain. TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts. Design reviews like CDR require that TBDs be minimized and justified.

To Be Confirmed (TBC) ^{[to-be-confirmed-tbc]} indicates an item that is not yet finalized but is expected to be confirmed during development. TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback. This is distinct from TBD, which implies the decision itself is still pending.

The distinction matters: TBC allows teams to proceed with design work while acknowledging that certain parameters will be confirmed later, whereas TBD signals that active decision-making is still required. Both must be resolved before the design can be considered complete and ready for manufacturing.

Worked Example: Requirement Flow Through the V Diagram

Consider a hypothetical Earth observation satellite with a mission requirement: "The spacecraft shall image a 100 km × 100 km ground area with 5 m spatial resolution from a 500 km altitude sun-synchronous orbit."

Left side (decomposition):

• This mission requirement is decomposed into system requirements: optical aperture diameter, focal length, detector pixel size, orbital altitude, and attitude control accuracy.
• System requirements are allocated to subsystems: the optical subsystem must achieve a certain diffraction-limited resolution; the attitude control subsystem must maintain pointing to within a specified tolerance; the power subsystem must supply sufficient energy for imaging operations.
• Each subsystem requirement is further decomposed into component specifications: lens focal length, detector array format, reaction wheel torque, solar panel area, etc.

Right side (integration and verification):

• Component-level tests verify that each lens, detector, and reaction wheel meets its specification.
• Subsystem-level tests verify that the optical subsystem achieves the required resolution, and the attitude control subsystem achieves the required pointing accuracy.
• System-level tests verify that the integrated spacecraft, when placed in the specified orbit, can image a 100 km × 100 km area with 5 m resolution.
• Validation confirms that the spacecraft, when operated in the actual mission environment, meets the original mission requirement.

At each level, a design review (SRR, SDR, PDR, CDR) confirms that the decomposition is correct, the allocations are feasible, and the design is ready to proceed to the next phase. The V Diagram ensures that no requirement is lost and that every design decision is traceable back to a mission need.

References

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

AI Disclosure

This article was drafted with AI assistance using Obsidian Zettelkasten notes from Spacecraft Design II coursework. All factual and technical claims are cited to source notes. The structure, synthesis, and worked example were generated by Claude (Anthropic) under human direction. The author reviewed all claims for technical accuracy against source materials before publication.