Spacecraft Design II: Core Equations and Relations
Abstract
This article synthesizes the foundational framework and key checkpoints of spacecraft design methodology, focusing on the system engineering V-diagram and the critical design review gates that govern the transition from concept through manufacturing. We examine how requirements flow through decomposition and integration phases, and how formal baselines lock design decisions at appropriate maturity levels. This treatment is intended for students and practitioners seeking a structured overview of spacecraft development processes.
Background
Spacecraft design is inherently a systems problem: a single mission requirement may decompose into dozens of subsystem specifications, each of which must be verified independently and then integrated back into a coherent whole. Without a disciplined framework, requirements can be lost, interfaces can conflict, and the final product may fail to meet its original purpose.
The System Engineering V Diagram [system-engineering-v-diagram] provides the canonical structure for managing this complexity. The diagram maps the entire lifecycle from mission conception through retirement as a bidirectional process: the left side decomposes high-level needs into progressively detailed requirements and designs, while the right side integrates and verifies those designs back up to the system level. The bottom of the V contains the actual development work—manufacturing, assembly, and testing.
The key insight is that every requirement defined on the left side must have a corresponding verification activity on the right side. This ensures traceability and prevents requirements from being lost during implementation.
Key Results
The Design Review Hierarchy
Spacecraft development proceeds through a series of formal design reviews, each serving as a gate that validates readiness to proceed to the next phase.
System Requirement Review (SRR) [system-requirement-review] occurs near the top of the V-diagram. Its purpose is to validate that derived requirements properly capture and decompose the original mission objectives. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.
System Design Review (SDR) [system-design-review] evaluates how system requirements have been allocated across configuration items (subsystems and components). SDR bridges requirements and detailed design by examining the high-level architectural decisions and ensuring that each requirement has been assigned to responsible subsystems.
Preliminary Design Review (PDR) [preliminary-design-review] is a major commitment point. At this stage, the design team has completed trade studies, selected 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 represents the last major review before the design is "locked down" for final implementation.
Critical Design Review (CDR) [critical-design-review] is the final design review. It certifies that the detailed design is complete, correct, and ready for manufacturing. CDR ensures that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements, and that every specification established at PDR has been fulfilled.
The Build-to Baseline
The Build-to Baseline [build-to-baseline] is the approved, detailed set of hardware and software specifications established and approved at CDR. It serves as the authoritative reference for manufacturing and assembly.
Once the build-to baseline is approved, 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. This baseline prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product. Any changes to the baseline after CDR must go through formal change control to assess impacts and maintain configuration integrity.
Documentation Markers: TBD and TBC
Two key markers appear in design documents 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. TBD flags areas where active decision-making is required before the design can be considered complete.
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 allows teams to proceed with design work while acknowledging that certain parameters, component selections, or performance values will be confirmed later through analysis, testing, or vendor feedback.
The distinction is important: TBD means the choice has not been made; TBC means a provisional value exists but requires confirmation. Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.
Worked Example: Requirement Traceability Through CDR
Consider a simple mission requirement: "The spacecraft shall maintain attitude knowledge to within 0.1 degrees."
At SRR, this requirement is decomposed into derived requirements:
- The attitude determination subsystem shall estimate spacecraft orientation to within 0.1 degrees
- The attitude control subsystem shall maintain spacecraft orientation to within 0.1 degrees
- The sensor suite shall provide measurements with sufficient accuracy to support 0.1-degree knowledge
At SDR, these derived requirements are allocated to specific configuration items:
- Attitude Determination and Control (ADCS) subsystem: primary responsibility
- Inertial Measurement Unit (IMU): sensor component within ADCS
- Star tracker: sensor component within ADCS
- Ground station: provides reference measurements for calibration
At PDR, preliminary designs are presented:
- ADCS architecture selected (e.g., three-axis stabilized with momentum wheels)
- Candidate sensors identified (star tracker model X, IMU model Y)
- Preliminary error budgets show 0.08-degree achievable attitude knowledge
- Some parameters marked TBC pending vendor data sheets
At CDR, detailed specifications are complete:
- All TBC items have been confirmed with actual vendor data
- Detailed error analysis shows 0.075-degree achievable attitude knowledge with margin
- Interface specifications between ADCS and all other subsystems are finalized
- Manufacturing drawings and acceptance test procedures are complete
- The build-to baseline is approved and locked
Throughout this process, traceability is maintained: the original 0.1-degree requirement can be traced through each decomposition level down to specific hardware specifications and test procedures.
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 an AI language model based on personal class notes from Spacecraft Design II. The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims and technical content derive from the cited notes; no external sources were consulted, and no results or claims were invented beyond what appears in the source material. The author retains responsibility for accuracy and completeness.