Spacecraft Design II: Edge Cases and Boundary Conditions

Abstract

Spacecraft design operates within a structured framework of reviews and baselines that enforce traceability from mission requirements to manufacturing specifications. This article examines the critical boundary conditions in this process—the transition points where design decisions become locked, where ambiguity must be resolved, and where the cost of change becomes prohibitive. We focus on the role of design reviews, baseline management, and the handling of unresolved items (TBD/TBC) as mechanisms for managing risk at system boundaries.

Background

The spacecraft development lifecycle follows a structured decomposition-and-integration pattern ^{[system-engineering-v-diagram]}. Requirements flow downward from mission needs through successive levels of detail, while verification activities flow upward through testing and validation. This bidirectional process creates natural boundary conditions where design decisions must be finalized before proceeding to the next phase.

The V-diagram framework emphasizes that every requirement defined during decomposition must have a corresponding verification activity during integration. This principle prevents requirements from being lost or misinterpreted during implementation. However, the framework also creates decision points—gates where incomplete or ambiguous specifications can no longer be tolerated.

Key Results

The Design Review Hierarchy as Boundary Enforcement

Design reviews serve as formal checkpoints that enforce increasingly strict requirements for design maturity. Each review represents a boundary condition: a point beyond which certain types of changes become exponentially more expensive.

The System Requirement Review (SRR) occurs early in the V-diagram, validating that derived requirements properly decompose high-level mission objectives ^{[system-requirement-review]}. Its purpose is to catch misinterpretations before significant design investment occurs. At this boundary, the cost of requirement changes is still relatively low because detailed design has not yet begun.

The System Design Review (SDR) examines how system requirements have been allocated to configuration items and evaluates manufacturing feasibility ^{[system-design-review]}. This review bridges the gap between requirements and detailed design, ensuring the proposed architectural decomposition is sound. At the SDR boundary, architectural mistakes must be identified before they propagate into subsystem-level design work.

The Preliminary Design Review (PDR) represents a major commitment point ^{[preliminary-design-review]}. By this stage, trade studies are complete, technologies have been selected, and preliminary designs exist for all major subsystems. PDR validates that the design approach is feasible and mature enough to justify proceeding to detailed design. Passing PDR signals organizational confidence that the fundamental design strategy is correct. Changes after PDR are more costly because they may invalidate preliminary designs and require rework of technology selections.

The Critical Design Review (CDR) is the final design boundary before manufacturing ^{[critical-design-review]}. At CDR, the detailed design phase is complete, and all hardware and software specifications are finalized. The review certifies that the "build-to" baseline contains complete specifications capable of meeting all functional and performance requirements ^{[build-to-baseline]}. After CDR approval, the design is frozen. Changes after this boundary incur exponentially higher costs because they may require rework of manufacturing tooling, procurement, and already-produced components.

Baseline Management and Configuration Control

The build-to baseline represents the most critical boundary condition in spacecraft development. Once approved at CDR, the baseline becomes the single source of truth for manufacturing and assembly teams ^{[build-to-baseline]}. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes.

The baseline serves three essential functions:

1. Elimination of ambiguity: Manufacturing teams have a complete, unambiguous specification of what to build. No interpretation is required.

2. Traceability: Every requirement has a corresponding design specification, and every design specification traces back to a requirement. This traceability provides an auditable record of how mission needs were translated into hardware.

3. Configuration integrity: Formal change control processes ensure that modifications to one component are evaluated for impacts on other components and subsystems. This prevents unintended side effects and maintains consistency across distributed manufacturing activities.

Managing Uncertainty: TBD and TBC

Not all design details can be determined simultaneously. Spacecraft design documents use two mechanisms to flag unresolved items: To Be Decided (TBD) and To Be Confirmed (TBC) ^{[to-be-decided-tbd]}, ^{[to-be-confirmed-tbc]}.

TBD indicates that the decision-making process itself is still pending and the outcome is uncertain. TBC indicates that a value or specification is not yet finalized but is expected to be confirmed through analysis, testing, or vendor feedback. The distinction is important: TBD requires active decision-making, while TBC assumes confirmation of an existing value.

Design reviews, particularly CDR, require that TBDs be minimized and justified. Unresolved TBDs at CDR indicate that the design is not sufficiently mature for manufacturing. Each remaining TBD must have an explicit resolution plan and a committed completion date. This discipline ensures the project moves toward a locked baseline rather than deferring decisions indefinitely.

Worked Example: Thermal Control Subsystem Boundary Conditions

Consider a thermal control subsystem (TCS) in a spacecraft design. The boundary conditions manifest at each review:

At SRR: The mission requirement states "maintain payload temperature between $15°\text{C}$ and $25°\text{C}$ during nominal operations." The derived requirement might be "TCS shall maintain payload temperature within $\pm 5°\text{C}$ of $20°\text{C}$." SRR validates that this derived requirement properly captures the mission need.

At SDR: The TCS is allocated to a dedicated subsystem with responsibility for heat rejection. The review examines whether the proposed approach (passive radiators, active heat pumps, or hybrid) is feasible given spacecraft geometry and power constraints. Manufacturing considerations—radiator panel sizes, coating specifications, integration with structure—are evaluated.

At PDR: Preliminary designs for radiator panels and heat pipes are complete. Trade studies have justified the selection of a passive radiator approach. Thermal analysis predicts the payload will remain within $\pm 3°\text{C}$ of $20°\text{C}$ under worst-case conditions. The design margin is sufficient to justify proceeding to detailed design.

At CDR: Detailed specifications exist for every component: radiator panel dimensions, coating emissivity values, heat pipe specifications, mounting interfaces, and acceptance test criteria. The specification might state: "Radiator coating emissivity shall be $0.88 \pm 0.03$ at $300\text{ K}$, measured per ASTM E408." All TBDs have been resolved. The build-to baseline is approved.

After CDR: If thermal analysis later reveals that the payload will exceed $25°\text{C}$ under an unanticipated operational scenario, changes to the radiator design must go through formal change control. The impact assessment must evaluate effects on mass, power, schedule, and cost. The change may require new manufacturing tooling or rework of already-produced panels.

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 AI assistance from class notes (Zettelkasten). The structure, synthesis, and worked example were generated by an AI language model based on source material provided. All factual claims are cited to original notes. The author is responsible for accuracy and interpretation.