Spacecraft Design II: Common Mistakes and Misconceptions
Abstract
Spacecraft design is a highly structured discipline governed by formal processes and design reviews. Yet practitioners—especially those new to the field—frequently misunderstand the purpose and timing of key milestones, mishandle requirements traceability, and conflate distinct documentation markers. This article clarifies five common misconceptions encountered in Spacecraft Design II coursework and practice, grounded in the systems engineering V-diagram framework. Understanding these distinctions prevents costly rework and ensures alignment between mission needs and final hardware.
Background
The development of a spacecraft follows a structured lifecycle defined by the systems engineering V-diagram [system-engineering-v-diagram]. This framework decomposes the mission from high-level needs through increasingly detailed design phases, then reintegrates and verifies the system back up to operational requirements. At each level, formal design reviews serve as quality gates.
The V-diagram's power lies in its bidirectional traceability: every requirement on the left (decomposition) side must have a corresponding verification activity on the right (integration/verification) side. This prevents requirements from being lost and ensures the final product actually meets the original mission objectives.
However, the structure and purpose of individual reviews are frequently misunderstood. Additionally, documentation markers used to flag incomplete work—TBD and TBC—are often used interchangeably, creating ambiguity about what remains to be done.
Key Results
Misconception 1: SRR and SDR Are Redundant
The mistake: Many teams treat the System Requirement Review (SRR) and System Design Review (SDR) as overlapping checkpoints and skip one or compress both into a single review.
The reality: These reviews serve distinct purposes at different stages of decomposition [system-requirement-review], [system-design-review].
SRR validates that high-level mission needs have been correctly translated into derived system requirements. It occurs early, before significant design investment, and asks: "Have we understood the problem correctly?"
SDR, occurring after SRR, evaluates how those validated requirements have been allocated across subsystems and configuration items. It asks: "Have we chosen a sound architectural approach to solve the problem?"
Skipping SRR risks building the wrong system. Skipping SDR risks choosing an infeasible architecture. Both are necessary.
Misconception 2: PDR Means "Design Is Done"
The mistake: Teams sometimes treat the Preliminary Design Review as a final checkpoint, expecting that after PDR approval, only minor refinements remain.
The reality: PDR is a commitment point, not a completion point [preliminary-design-review]. At PDR, the design team has completed trade studies and selected technologies, but detailed specifications and drawings remain to be produced. PDR confirms the chosen approach is feasible and mature enough to justify proceeding to final design—not that final design is complete.
The work between PDR and Critical Design Review (CDR) is substantial: detailed subsystem specifications, interface control documents, manufacturing plans, and risk mitigation strategies must all be developed. Underestimating this effort is a frequent cause of schedule overruns.
Misconception 3: CDR Is a Formality After PDR
The mistake: Some teams view CDR as a rubber-stamp review, assuming that if PDR passed, CDR will too.
The reality: CDR is the final design review and the last opportunity to catch errors before manufacturing begins [critical-design-review]. At CDR, the "build-to" baseline [build-to-baseline] is approved—a complete, detailed set of hardware and software specifications that becomes the authoritative reference for manufacturing.
CDR ensures:
- Every requirement has a corresponding design specification
- All interfaces are fully defined
- The design is producible
- All PDR commitments have been fulfilled
After CDR, the design is frozen. Changes require formal change control and incur exponential cost increases. CDR is not a formality; it is a rigorous gate.
Misconception 4: TBD and TBC Are Interchangeable
The mistake: Design documents often use TBD and TBC without distinction, leaving stakeholders uncertain about what is pending.
The reality: These markers have different meanings [to-be-decided-tbd], [to-be-confirmed-tbc].
TBD (To Be Decided) indicates that a decision has not yet been made. The outcome is uncertain, and the decision-making process is still pending. Example: "Propulsion system type: TBD" means the team has not yet chosen between chemical, electric, or hybrid propulsion.
TBC (To Be Confirmed) indicates that a value or item is expected but not yet finalized. The decision direction is known; confirmation is pending. Example: "Reaction wheel momentum capacity: 150 N·m·s TBC" means the team expects 150 N·m·s based on preliminary analysis, but this will be confirmed through detailed analysis or vendor data.
Using these markers correctly maintains clarity about what remains uncertain versus what is provisionally set. Design reviews require that TBDs be minimized and justified before proceeding.
Misconception 5: Requirements Traceability Is Optional
The mistake: Some teams view traceability matrices as administrative overhead and defer building them until late in the project.
The reality: Traceability is fundamental to the V-diagram's effectiveness. Every requirement on the left side (decomposition) must map to a verification activity on the right side (integration/verification). Without traceability, requirements can be lost, and the final product may not meet mission needs.
Traceability must be established early and maintained throughout development. At each design review—SRR, SDR, PDR, CDR—traceability is verified to ensure no requirements have been orphaned and no design elements lack justification.
Worked Examples
Example 1: Recognizing the Scope of Work Between PDR and CDR
A team completes PDR with approval to proceed to detailed design. The preliminary design specifies a 3-axis stabilized spacecraft with a reaction wheel attitude control system. At PDR, the team has selected reaction wheel vendors and estimated momentum capacity at 150 N·m·s.
Between PDR and CDR, the team must:
- Develop detailed control laws and verify stability margins
- Produce detailed electrical schematics and power budgets
- Write interface control documents between attitude control and power subsystems
- Confirm reaction wheel momentum capacity with vendor data (TBC → confirmed)
- Resolve any TBDs from PDR (e.g., if momentum dumping strategy was TBD, it must now be decided)
- Perform failure mode and effects analysis (FMEA) on all subsystems
- Develop manufacturing and assembly procedures
This is not minor refinement; it is substantial engineering work. Underestimating it is a common source of schedule pressure and quality issues.
Example 2: Distinguishing TBD from TBC in a Thermal Design
A preliminary thermal analysis estimates the spacecraft's peak operating temperature at 45°C. The team documents this as "Peak operating temperature: 45°C TBC" because the estimate is based on preliminary component selections and orbital analysis.
Later, the team identifies that the thermal model depends on the final solar panel efficiency, which is still under vendor evaluation. This is documented as "Solar panel efficiency: TBD" because the team has not yet decided between two candidate vendors with different efficiency ratings.
At CDR, the solar panel vendor is selected (TBD → decided), and the thermal model is re-run with final component data (TBC → confirmed). The peak operating temperature is now locked at 43°C, and the design baseline is complete.
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 based on personal class notes from Spacecraft Design II. The AI was used to organize, clarify, and structure the material for publication. All factual claims are cited to the original notes and reflect course content. The author retains responsibility for accuracy and interpretation.