Spacecraft Design II: Pitfalls and Debugging Strategies
Abstract
Spacecraft design is a high-stakes, irreversible process where errors discovered late in development incur exponential costs. This article examines the structural framework that governs spacecraft development—the System Engineering V Diagram—and explores how design reviews function as debugging mechanisms. By tracing the decomposition and integration phases, we identify common failure modes and demonstrate why early verification of requirements-to-design traceability prevents costly rework.
Background
Spacecraft development differs fundamentally from iterative software or consumer product design. Once manufacturing begins, changes become prohibitively expensive. The industry has converged on a structured lifecycle model to manage this constraint: the System Engineering V Diagram [system-engineering-v-diagram].
The V-diagram maps the entire development lifecycle as a bidirectional flow. The left side descends through decomposition—from mission needs through feasibility studies, concept of operations, system requirements, and progressively detailed design phases. The right side ascends through integration and verification: unit testing, subsystem verification, system verification, and validation back to operational requirements. The critical insight is that every requirement defined on the left must have a corresponding verification activity on the right [system-engineering-v-diagram].
This structure prevents a pervasive pitfall: building a system that is technically sound but fails to meet the original mission. Without explicit traceability, requirements can be lost, misinterpreted, or abandoned during the pressure of detailed design work.
Key Results
The Requirement-to-Verification Chain
The V-diagram enforces a principle: each level of decomposition (system → subsystem → unit) must have a matching level of integration and testing. This creates a balanced, verifiable development path. However, the diagram is only as effective as the rigor applied at each checkpoint.
Four major design reviews serve as debugging gates:
System Requirement Review (SRR) [system-requirement-review] occurs near the top of the V, before significant design investment. Its purpose is to validate that derived requirements properly decompose high-level mission objectives. 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 are allocated across configuration items (subsystems, components). It assesses manufacturing feasibility and confirms the architectural decomposition is sound. This review prevents architectural mistakes that would be expensive to correct later.
Preliminary Design Review (PDR) [preliminary-design-review] represents a significant commitment point. By this stage, trade studies are complete, technologies are selected, and preliminary designs exist for all major subsystems. PDR confirms the chosen approach is sound before investing in detailed specifications and procurement. It is the last major review before the design is "locked down."
Critical Design Review (CDR) [critical-design-review] is the final design review, occurring after detailed design is complete but before manufacturing begins. It certifies that the "build-to" baseline—the approved, detailed set of hardware and software specifications [build-to-baseline]—is complete, correct, and ready for manufacturing. CDR is the last opportunity to catch design errors without incurring manufacturing costs.
The Cost of Late Discovery
The progression from SRR through CDR reflects a fundamental principle: the cost of fixing an error increases exponentially with the phase in which it is discovered. An error caught at SRR may require rethinking a few requirements. The same error discovered at CDR may invalidate months of detailed design work. An error discovered during manufacturing or in orbit is catastrophic.
This cost structure explains why design reviews are not bureaucratic overhead but essential debugging mechanisms. Each review is a checkpoint where the design is interrogated for internal consistency and alignment with requirements.
Managing Uncertainty: TBD and TBC
Not all details can be determined simultaneously. Two markers manage this reality:
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 cascade into schedule delays and design conflicts.
To Be Confirmed (TBC) [to-be-confirmed-tbc] indicates an item that is not yet finalized but is expected to be confirmed during development. Unlike TBD, TBC assumes an existing value will be validated later through analysis, testing, or vendor feedback.
Design reviews require that TBDs be minimized and justified. A design cannot be approved for manufacturing with unresolved decisions; the baseline must be locked. TBCs are more acceptable if confirmation is scheduled and tracked, but they too must be resolved before the build-to baseline is approved at CDR.
Worked Examples
Example 1: Requirement Ambiguity Caught at SRR
A mission requires "attitude determination accuracy of 0.1 degrees." This requirement is ambiguous: does it mean 0.1 degrees 1-sigma, 3-sigma, or worst-case? Does it apply to all three axes equally, or only the nadir-pointing axis?
At SRR, the requirements team and mission operations team review this requirement. The ambiguity is caught and resolved: the requirement is clarified to "0.1 degrees 3-sigma about the nadir axis, 0.5 degrees 3-sigma about the roll axis." This clarity propagates through all downstream design work. Without this clarification at SRR, subsystem designers would make conflicting assumptions, leading to an attitude determination system that does not meet the actual mission need.
Example 2: Architectural Flaw Caught at SDR
The spacecraft architecture allocates power management to a single power distribution unit (PDU). At SDR, the reliability analysis reveals that a single-point failure in the PDU would disable the entire spacecraft. The mission requires 0.95 probability of mission success over a 5-year lifetime.
The architectural flaw is caught before detailed design of the PDU begins. The team decides to implement redundant PDUs with automatic switchover. This decision, made at SDR, cascades through the rest of the design: power budgets must account for two PDUs, the command and data handling subsystem must implement switchover logic, and the thermal design must accommodate additional hardware. Making this decision at SDR costs weeks of rework. Making it at CDR would cost months.
Example 3: Manufacturing Constraint Discovered at PDR
During PDR, the propulsion subsystem team presents a preliminary design for the reaction control system (RCS) thrusters. The design uses a specific thruster model selected for its performance characteristics. However, the manufacturing team notes that this thruster requires a specialized test facility that is not available in-house and has a 12-month lead time.
At PDR, the team has time to evaluate alternatives: a slightly lower-performance thruster with shorter lead time, or investment in the specialized test facility. The decision is made with full visibility of schedule and cost impacts. If this constraint had been discovered at CDR, the project would face a choice between delaying the entire spacecraft or accepting a lower-performance design without proper evaluation.
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 AI assistance. The structure, worked examples, and synthesis of connections between notes were generated by Claude (Anthropic). All factual claims are grounded in the cited course notes and have not been independently verified against external sources. The author is responsible for accuracy and should review all technical claims before publication.