Spacecraft Design II: Edge Cases and Boundary Conditions
Abstract
Spacecraft design operates within a structured lifecycle defined by formal review gates and configuration baselines. This article examines the critical boundary conditions that separate design phases—particularly the transition from preliminary to detailed design, and the role of design reviews in managing uncertainty. We explore how documentation markers (TBD/TBC) function as explicit acknowledgments of incomplete knowledge, and how the build-to baseline enforces design closure before manufacturing begins.
Background
The spacecraft design process follows a hierarchical decomposition-and-integration framework known as the System Engineering V Diagram [system-engineering-v-diagram]. This structure ensures that every requirement defined during the downward (decomposition) phase has a corresponding verification activity during the upward (integration) phase. However, the V-diagram is not a continuous process; it is punctuated by formal review gates that serve as decision points and quality checkpoints.
The early phases of this process—concept exploration and mission definition—establish high-level mission needs. These flow into the System Requirement Review (SRR), which validates that derived system requirements properly capture and decompose the original mission objectives [system-requirement-review]. The SRR acts as a quality gate before significant design investment, preventing misinterpretations from propagating downstream.
Following SRR, the System Design Review (SDR) examines how system requirements have been allocated across configuration items and evaluates manufacturing feasibility [system-design-review]. This review bridges the gap between abstract requirements and concrete architectural decisions.
Key Results
The PDR–CDR Boundary as a Critical Transition
The Preliminary Design Review (PDR) and Critical Design Review (CDR) mark the most significant boundary in spacecraft design: the transition from design exploration to design closure [preliminary-design-review], [critical-design-review].
PDR validates that the proposed design approach is feasible and mature enough to justify proceeding to detailed design. At this stage, trade studies are complete, candidate technologies have been selected, and preliminary designs exist for all major subsystems. PDR is a commitment gate: passing it signals organizational confidence that the design strategy is sound. However, the design is not yet locked. Subsequent detailed design work may reveal implementation challenges that require refinement of the preliminary approach.
CDR, by contrast, occurs after detailed design is complete. It certifies that the "build-to" baseline contains all specifications necessary to manufacture and assemble the spacecraft [critical-design-review]. At CDR, the design is frozen. Changes after CDR approval incur exponentially higher costs because they may require rework of manufacturing tooling, procurement, and already-produced components.
The boundary between PDR and CDR thus represents a shift in the nature of acceptable change. Before PDR, significant design changes are expected and relatively low-cost. Between PDR and CDR, changes are permitted but increasingly constrained. After CDR, changes are exceptional and require formal change control.
The Build-to Baseline as Design Closure
The build-to baseline is the locked, approved set of complete hardware and software specifications that serves as the authoritative reference for manufacturing and assembly [build-to-baseline]. It is formally established at CDR and contains all detailed specifications—drawings, interface definitions, performance parameters, and acceptance criteria—necessary to manufacture the spacecraft in compliance with functional and performance requirements.
The build-to baseline eliminates ambiguity by locking all design decisions with sufficient detail that production can proceed without interpretation. Once approved, it becomes the single source of truth for manufacturing teams. All subsequent changes are controlled through formal change management processes, ensuring configuration integrity and traceability from original requirements through the final product.
This baseline serves a critical function: it defines the boundary between design and manufacturing. Before the baseline is approved, design teams retain flexibility to explore alternatives and refine specifications. After approval, that flexibility is constrained to prevent cascading impacts on production schedules and costs.
TBD and TBC as Explicit Uncertainty Markers
Spacecraft design does not proceed uniformly across all subsystems. Some components are well-understood and can be fully specified early; others depend on vendor feedback, analysis results, or parallel development efforts. To manage this asynchrony, design teams use two documentation markers: TBD (To Be Decided) and TBC (To Be Confirmed) [to-be-decided-tbd], [to-be-confirmed-tbc].
TBD indicates that the decision-making process itself is still pending and the outcome is uncertain. For example, a subsystem architecture might be marked TBD if the team has not yet chosen between two competing approaches.
TBC indicates that an item is not yet finalized but is expected to be confirmed during development. For example, a component's exact mass might be marked TBC pending receipt of the vendor's detailed design.
These markers serve a critical function: they make uncertainty explicit and traceable. Rather than hiding incomplete decisions in informal notes or email threads, TBD/TBC flags ensure that stakeholders understand which items are provisional versus firm commitments. Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.
The presence of TBDs and TBCs also defines a boundary condition: a design cannot be considered complete for manufacturing purposes if it contains unresolved TBDs. At CDR, all TBDs must either be resolved or explicitly justified as acceptable risks.
Worked Examples
Example 1: Thermal Control Subsystem Specification
Consider a spacecraft thermal control subsystem being designed for a mission to low Earth orbit. During PDR, the team proposes a passive radiator design with active heater elements for contingency. The preliminary design specifies radiator area as approximately based on worst-case thermal loads.
At this stage, the radiator material selection is marked TBC—the team has narrowed it to two candidates (aluminum or composite), but final selection awaits detailed thermal analysis and cost trade studies. The heater power budget is marked TBD because the team has not yet decided whether to use resistive heaters or heat pipes.
Between PDR and CDR, the thermal analysis team completes detailed modeling. They confirm that aluminum radiators with area will satisfy all thermal requirements with acceptable margin. The heater trade study concludes that resistive heaters are more reliable for this mission profile. At CDR, both the TBC and TBD are resolved: radiator material is specified as aluminum, heater type is specified as resistive, and power budget is locked at .
The build-to baseline now contains detailed drawings of the radiator assembly, electrical schematics for the heater circuit, and acceptance test procedures to verify thermal performance. Manufacturing can proceed without ambiguity.
Example 2: Interface Definition Across Subsystems
The spacecraft's power subsystem must interface with the thermal control subsystem (heater power), the attitude determination and control subsystem (momentum wheel power), and the communication subsystem (transmitter power). During SDR, these interfaces are identified but not fully specified. Each subsystem team estimates its power requirements, but the exact voltage levels, current limits, and fault protection schemes are marked TBD pending detailed design.
During detailed design (between PDR and CDR), each subsystem team develops its detailed power specifications. The power subsystem team then integrates these specifications into a unified power distribution architecture. Interface control documents (ICDs) are created that specify voltage levels, current limits, connector types, and fault protection for each interface.
At CDR, all interface TBDs are resolved. The build-to baseline includes the ICDs, which become binding commitments for all subsystem teams. If, during manufacturing, one subsystem team discovers that their actual power draw exceeds the specification in the ICD, they must request a formal change order rather than simply increasing their draw. This change control process ensures that impacts on other subsystems (e.g., larger power bus conductors, higher battery capacity) are assessed and approved before implementation.
References
- [system-engineering-v-diagram]
- [system-requirement-review]
- [system-design-review]
- [preliminary-design-review]
- [critical-design-review]
- [critical-design-review]
- [preliminary-design-review]
- [build-to-baseline]
- [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 note content, verify all factual claims against source notes, and avoid inventing unsupported claims. All mathematical notation and technical terminology have been reviewed for accuracy. The worked examples are illustrative and based on typical spacecraft design practices documented in the source notes; they do not represent actual flight projects.