Spacecraft Design II: Core Equations and Relations

Abstract

Spacecraft design follows a structured lifecycle governed by the System Engineering V-diagram, which enforces bidirectional traceability between requirements decomposition and verification integration. This article synthesizes the core framework and design review checkpoints that govern modern spacecraft development, emphasizing how requirements flow through successive design phases and how each phase is validated before proceeding. The material is drawn from Spacecraft Design II coursework and provides a foundation for understanding the formal processes that prevent costly rework and ensure mission success.

Background

The development of a spacecraft is not a linear process but a carefully orchestrated sequence of decomposition, design, and reintegration. ^{[system-engineering-v-diagram]} provides the overarching framework: requirements flow downward through successive levels of detail (system → subsystem → unit), while verification and integration flow upward, ensuring that every requirement has a corresponding validation activity.

This bidirectional structure prevents a common failure mode in complex engineering: building something that is technically sound but does not meet the original mission needs. By enforcing traceability at each level, the V-diagram creates a balanced development path where no requirement is lost and no design decision proceeds without justification.

The spacecraft design lifecycle is punctuated by formal design reviews that serve as quality gates. Each review occurs at a specific point in the V-diagram and has a distinct purpose: to validate that the current phase is complete, correct, and ready to proceed to the next phase.

Key Results

The System Engineering V-Diagram Framework

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

• Left side (decomposition): Mission needs → feasibility studies → concept of operations → system requirements → preliminary design → detailed design
• Right side (integration/verification): Unit testing → subsystem verification → system verification → validation → operational requirements
• Bottom: Development processes, timelines, and documentation activities

The key insight is that decomposition and integration are not sequential but concurrent concerns. Every requirement defined on the left must have a matching verification activity on the right. This prevents requirements from being lost during implementation and ensures that design decisions remain traceable to mission objectives.

System Requirement Review (SRR)

The System Requirement Review occurs early in the V-diagram, near the top ^{[system-requirement-review]}. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. By catching misinterpretations or gaps early, SRR prevents downstream rework when changes are least costly. It acts as a quality gate before significant design effort is invested.

System Design Review (SDR)

Following SRR, the System Design Review examines how system requirements have been allocated across configuration items (subsystems and components) ^{[system-design-review]}. SDR assesses:

• Allocation of system requirements to responsible subsystems
• Manufacturing feasibility and constraints
• Readiness to proceed to detailed design

SDR bridges the gap between requirements and detailed design by validating the high-level architectural decisions. It ensures that the proposed system decomposition is sound and that each requirement has been assigned to a responsible subsystem.

Preliminary Design Review (PDR)

The Preliminary Design Review is a major commitment point ^{[preliminary-design-review]}. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems. PDR demonstrates:

• The proposed design is expected to meet all functional and performance requirements
• Sufficient maturity in the design approach to justify proceeding to final detailed design

PDR reduces risk by catching fundamental design flaws before they propagate into expensive detailed work. It is the last major review before the design is "locked down" for final implementation.

Critical Design Review (CDR)

The Critical Design Review is the final design review before manufacturing ^{[critical-design-review]}. CDR certifies that:

• The "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements
• The final design fulfills all specifications and commitments established at PDR

CDR is critical because it is the last opportunity to catch design errors without incurring manufacturing costs. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft.

Build-to Baseline

The Build-to Baseline is the approved, detailed set of hardware and software specifications established at CDR ^{[build-to-baseline]}. It serves as 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. This baseline prevents ambiguity, ensures consistency, and provides traceability from requirements through final product.

Documentation Markers: TBD and TBC

Two key documentation markers are used throughout the design process to track the maturity of decisions and confirmations:

To Be Decided (TBD) ^{[to-be-decided-tbd]} flags items where the decision-making process is still pending and the outcome is uncertain. TBDs are tracked rigorously because unresolved decisions can 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. 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.

Design reviews, particularly CDR, require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.

Worked Example: Traceability Through the V-Diagram

Consider a hypothetical Earth observation spacecraft with a mission requirement: "The spacecraft shall acquire panchromatic imagery with 1-meter ground resolution over a 100-kilometer swath."

Left side (decomposition):

1. Mission need: 1-meter resolution, 100 km swath
2. System requirement: Optical system shall provide 1-meter GSD at nominal altitude
3. Subsystem requirement: Telescope focal length and detector pixel size shall yield 1-meter GSD
4. Component specification: Detector shall have 5-micrometer pixels; focal length shall be 2.5 meters

Right side (integration/verification):

1. Unit test: Detector pixel size verified to specification
2. Subsystem test: Telescope optical performance measured in vacuum chamber
3. System test: Integrated spacecraft imaged ground resolution target
4. Validation: Operational imagery compared against ground truth

Each level of decomposition has a matching verification activity. If the unit test fails to confirm pixel size, the entire chain is broken and must be reworked. This traceability prevents the common failure mode where a spacecraft is built correctly but does not meet the original mission need.

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 the assistance of an AI language model using class notes as source material. All factual and mathematical claims are cited to the original notes. The article has been reviewed for technical accuracy and consistency with the source material.