Spacecraft Design II: Key Theorems and Proofs
Abstract
This article synthesizes core theorems and structural principles from Spacecraft Design II, focusing on the system engineering V-diagram framework and its associated design review checkpoints. We establish the logical foundation for requirement traceability, design maturity gates, and configuration control, then demonstrate how these principles prevent common development failures through worked examples.
Background
Spacecraft development is a high-stakes, irreversible process. Once a vehicle launches, design errors cannot be corrected. This constraint motivates a rigorous, stage-gated development methodology that decomposes requirements downward and verifies them upward, ensuring every mission need maps to a testable specification and every specification traces back to an operational requirement.
The System Engineering V Diagram [system-engineering-v-diagram] provides the structural framework for this process. It models development as a bidirectional flow: the left side decomposes mission needs into progressively detailed requirements and designs; the right side integrates and verifies those designs back against the original requirements. The diagram's power lies in its enforcement of requirement traceability—the principle that every requirement must have a corresponding verification activity, and vice versa.
This framework is operationalized through a sequence of formal design reviews, each serving as a quality gate that prevents advancement until specific maturity criteria are met.
Key Results
Theorem 1: The Traceability Principle
Statement: In a well-structured spacecraft development program, every system requirement must have at least one corresponding verification activity, and every verification activity must map back to at least one system requirement. Failure to maintain this bidirectional mapping results in either unverified requirements or wasted verification effort.
Proof sketch: Consider a system requirement that lacks a verification activity. At delivery, there is no evidence that the spacecraft satisfies , violating the contract with stakeholders. Conversely, a verification activity without a corresponding requirement represents either redundant testing or scope creep. The V-diagram [system-engineering-v-diagram] enforces this principle by requiring that decomposition on the left (requirements) be matched by integration and testing on the right (verification). The diagram's symmetry is not aesthetic—it is a logical necessity for complete, non-redundant development.
Theorem 2: Design Maturity Gates
Statement: Advancement from one design phase to the next should occur only when the current phase has achieved sufficient maturity to justify the cost of the next phase. Specifically:
- System Requirement Review (SRR) [system-requirement-review] gates advancement from mission definition to system design by validating that derived requirements properly decompose high-level mission needs.
- System Design Review (SDR) [system-design-review] gates advancement to detailed design by confirming that system requirements have been allocated to configuration items and that manufacturing is feasible.
- Preliminary Design Review (PDR) [preliminary-design-review] gates advancement to final design by demonstrating that the proposed approach is feasible and mature.
- Critical Design Review (CDR) [critical-design-review] gates advancement to manufacturing by certifying that detailed specifications are complete and correct.
Intuition: Each review prevents a class of costly errors. SRR catches requirement misinterpretation early. SDR catches architectural flaws before detailed design begins. PDR catches fundamental design infeasibility before detailed specifications are written. CDR catches specification errors before manufacturing begins. The cost of fixing an error grows exponentially with the phase in which it is discovered; these gates minimize that cost by catching errors as early as possible.
Theorem 3: Baseline Freezing and Change Control
Statement: Once a design baseline is approved (at CDR), it must be frozen and controlled through formal change management. The build-to baseline [build-to-baseline] becomes the single authoritative source of truth for manufacturing and assembly.
Justification: After CDR, the design is sufficiently detailed that manufacturing can proceed. Any change to the baseline at this stage affects procurement, assembly procedures, test plans, and potentially schedule and cost. Uncontrolled changes introduce inconsistency, break traceability, and create ambiguity for manufacturing teams. Formal change control ensures that every modification is assessed for impact and that the baseline remains internally consistent.
Theorem 4: TBD/TBC Minimization at CDR
Statement: At Critical Design Review, the number of unresolved items (TBD [to-be-decided-tbd] and TBC [to-be-confirmed-tbc] markers) must be minimized and explicitly justified. Any remaining TBDs or TBCs must have a clear resolution path and committed completion date.
Rationale: A TBD indicates a decision has not been made; a TBC indicates a value is provisional. Either marker in the build-to baseline introduces ambiguity for manufacturing. If a component selection is TBD at CDR, the manufacturing team cannot order parts. If a performance parameter is TBC, the test team cannot write acceptance criteria. CDR approval with unresolved items is a sign that the design is not mature enough to proceed to manufacturing, or that the project is accepting schedule risk by deferring decisions.
Worked Examples
Example 1: Requirement Traceability Failure
Scenario: A spacecraft project completes PDR with a mission requirement: "The spacecraft shall maintain attitude control to within 0.1 degrees for 30 days." The attitude control subsystem is designed and tested. However, no one explicitly verified the 30-day duration requirement—only the 0.1-degree accuracy was tested over a 7-day mission simulation.
Analysis: The requirement exists on the left side of the V-diagram (decomposed from mission needs), but the corresponding verification activity on the right side is incomplete. At CDR, this gap should be caught: the build-to baseline should specify a 30-day attitude control test or a justified alternative (e.g., analysis showing that the control system's propellant budget supports 30 days). Without this, the spacecraft may fail its mission despite passing all formal tests.
Resolution: The project must either (a) add a 30-day test to the verification plan, (b) conduct analysis demonstrating 30-day capability, or (c) revise the requirement if 30 days is not actually necessary. Traceability is restored only when every requirement has a corresponding verification activity.
Example 2: Premature Advancement Without Maturity
Scenario: A project skips PDR and proceeds directly from SDR to detailed design, believing that preliminary design is unnecessary overhead. The team begins writing detailed specifications for all subsystems.
Analysis: PDR exists to demonstrate that the overall design approach is feasible before investing in detailed specifications. By skipping it, the project risks discovering fundamental flaws (e.g., power budget infeasibility, thermal dissipation limits, or mass margin violations) only after detailed design is complete. At that point, rework is expensive and schedule impact is severe.
Resolution: The project should conduct PDR before proceeding further. PDR need not be lengthy, but it must demonstrate that trade studies have been completed, technologies have been selected, and preliminary designs for major subsystems show that requirements can be met.
Example 3: Unresolved TBD at CDR
Scenario: A project reaches CDR with the following item in the build-to baseline: "Attitude determination sensor: TBD (to be selected based on vendor availability)." Manufacturing is scheduled to begin in 2 weeks.
Analysis: The sensor selection is a critical design decision that affects power consumption, data interfaces, and test procedures. Deferring this decision to the manufacturing phase introduces risk: if the selected sensor has different electrical characteristics than assumed in the design, integration and test may fail. Additionally, procurement lead time for sensors is typically 8–12 weeks, so deferring the decision delays manufacturing.
Resolution: Before CDR approval, the project must either (a) select a specific sensor and include it in the build-to baseline, (b) identify a set of qualified alternative sensors with compatible interfaces and performance, or (c) explicitly justify why the decision cannot be made and commit to a resolution date before manufacturing begins. If (c) is chosen, the TBD must be tracked as a risk and a contingency schedule must be established.
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 class notes from Spacecraft Design II. The AI was instructed to paraphrase rather than copy, to cite all factual claims, and to avoid inventing results not present in the source material. All mathematical statements and design principles are derived from the cited notes. The author retains responsibility for accuracy and interpretation.