Spacecraft Design II: Worked Example Walkthroughs

Abstract

This article walks through the critical design review milestones and baselines that structure spacecraft development, using concrete examples to illustrate how requirements flow through decomposition and verification phases. We examine the System Engineering V-diagram framework, trace a requirement from mission need through design reviews, and demonstrate how the build-to baseline serves as the authoritative reference for manufacturing. The goal is to make the abstract machinery of systems engineering tangible for practitioners and students.

Background

Spacecraft development is inherently complex: thousands of requirements, hundreds of subsystems, and distributed teams across multiple organizations must coordinate to produce a single integrated product. Without structured processes, requirements get lost, interfaces conflict, and expensive rework cascades through manufacturing and assembly.

The System Engineering V-diagram provides the foundational framework ^{[system-engineering-v-diagram]}. It maps the entire lifecycle from mission conception through retirement as a bidirectional process. The left side decomposes mission needs downward through feasibility studies, concept of operations, system requirements, and progressively detailed design. The right side integrates and verifies upward through unit testing, subsystem verification, system verification, and validation. The bottom contains development processes, timelines, and documentation.

The key insight is that every requirement defined on the left must have a corresponding verification activity on the right. This ensures traceability and prevents requirements from vanishing during implementation. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing.

Key Results

The Design Review Sequence

Spacecraft design proceeds through a series of formal reviews that serve as quality gates and commitment points.

System Requirement Review (SRR) occurs near the top of the V-diagram, before significant design investment ^{[system-requirement-review]}. Its purpose is to validate that derived requirements properly decompose and capture the original mission objectives. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.

System Design Review (SDR) bridges requirements and detailed design ^{[system-design-review]}. It evaluates how system requirements have been allocated across configuration items (subsystems, components) and assesses manufacturing feasibility. SDR ensures the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems.

Preliminary Design Review (PDR) is a major commitment point ^{[preliminary-design-review]}. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems. PDR demonstrates that the proposed design is expected to meet all functional and performance requirements and has achieved sufficient maturity to justify proceeding to detailed design. It is the last major review before the design approach is "locked down."

Critical Design Review (CDR) is the final design review ^{[critical-design-review]}. It certifies that the detailed design is complete, correct, and ready for manufacturing. CDR ensures the "build-to" baseline contains detailed hardware and software specifications capable of meeting all requirements, and that the final design fulfills all specifications established at PDR. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft.

The Build-to Baseline

The build-to baseline is the approved, detailed set of hardware and software specifications established at CDR ^{[build-to-baseline]}. It contains all drawings, interface definitions, performance parameters, and acceptance criteria necessary to manufacture, assemble, integrate, and test the spacecraft.

Once approved, the build-to baseline becomes the single source of truth for manufacturing and assembly teams. All subsequent changes are controlled through formal change management processes. This prevents ambiguity, ensures consistency across distributed manufacturing activities, and provides traceability from requirements through final product. Changes after CDR are exponentially more expensive because they may require rework of manufacturing plans, tooling, and already-produced components.

Handling Uncertainty: TBD and TBC

Not all details can be determined simultaneously. Two markers flag unresolved items in design documents.

To Be Decided (TBD) indicates that the decision-making process itself is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. TBD flags areas where active decision-making is required before the design can be considered complete. Design reviews like CDR require that TBDs be minimized and justified.

To Be Confirmed (TBC) indicates an item that is not yet finalized but is expected to be confirmed during development ^{[to-be-confirmed-tbc]}. TBC assumes an existing value or approach will be confirmed later through analysis, testing, or vendor feedback. This is distinct from TBD, which implies the decision itself is still pending.

Using these markers explicitly maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments.

Worked Examples

Example 1: Tracing a Thermal Requirement Through Design Reviews

Consider a mission requirement: "The spacecraft shall maintain all electronics within the operating temperature range of $-10°\text{C}$ to $+50°\text{C}$ during all mission phases."

At SRR: This high-level requirement is decomposed into derived requirements:

• Thermal control subsystem shall reject $X$ watts of heat in eclipse
• Radiator area shall be at least $Y$ m²
• Heater power shall not exceed $Z$ watts

The review confirms these derived requirements properly capture the original mission objective and are internally consistent.

At SDR: The thermal control requirement is allocated to specific configuration items:

• Radiator assembly (hardware)
• Thermal control software (flight code)
• Ground support equipment for thermal testing

Manufacturing considerations are assessed: Can the radiator be fabricated with available processes? Are materials compatible with the spacecraft structure?

At PDR: Preliminary designs for the radiator and heater are presented. Trade studies show that a deployable radiator with $Y = 2.5$ m² and passive louvers will meet the requirement with acceptable margin. The design approach is validated through thermal analysis and is deemed mature enough to proceed to detailed design.

At CDR: Detailed specifications are complete:

• Radiator drawing with all dimensions, tolerances, and material specifications
• Louver actuation mechanism fully specified
• Thermal control software requirements and interface definitions locked
• Acceptance test procedures defined: thermal vacuum testing to validate the design meets the requirement

The build-to baseline now contains all information necessary for manufacturing to produce the radiator and for test teams to verify it works.

Example 2: Handling Uncertainty in Power Budget

Early in design, the power consumption of a new instrument is uncertain. The power budget document might state:

"Instrument power draw: TBD (preliminary estimate 150 W, pending detailed design of signal processing electronics)"

This TBD is appropriate because the signal processing architecture has not yet been selected. During preliminary design, the team evaluates two candidate architectures and selects one. Now the power draw can be estimated more precisely:

"Instrument power draw: TBC 145 W (detailed design of signal processing electronics in progress, final confirmation pending component selection)"

The TBC indicates that the value is now based on a selected approach but awaits confirmation through detailed component specifications and testing. By CDR, this must be resolved:

"Instrument power draw: 145 W (confirmed via detailed design review and component datasheets)"

The progression from TBD → TBC → confirmed value demonstrates how uncertainty is systematically reduced as the design matures.

References

• ^{[system-engineering-v-diagram]}
• ^{[system-requirement-review]}
• ^{[system-design-review]}
• ^{[preliminary-design-review]}
• ^{[critical-design-review]}
• ^{[build-to-baseline]}
• ^{[critical-design-review]}
• ^{[preliminary-design-review]}
• ^{[to-be-decided-tbd]}
• ^{[to-be-confirmed-tbc]}

AI Disclosure

This article was drafted with AI assistance from class notes (Zettelkasten). All factual claims are cited to source notes. The worked examples are original constructions designed to illustrate the concepts; they do not represent actual mission data. The author reviewed and validated all technical content for accuracy.