Spacecraft Design II: Real-World Engineering Case Studies

Abstract

Spacecraft development follows a structured lifecycle that maps requirements through design phases and into manufacturing. This article examines the System Engineering V Diagram as a framework for managing this complexity, then traces how design reviews and configuration baselines enforce traceability and prevent costly rework. By understanding the gates and checkpoints that govern real spacecraft projects, engineers can apply these principles to manage risk and maintain alignment between mission needs and final hardware.

Background

Complex systems like spacecraft cannot be designed in a linear sequence. Requirements must be decomposed into subsystem specifications, detailed designs must be verified against those specifications, and the entire process must maintain traceability from the original mission need down to the final manufactured component. Without a structured approach, teams risk building systems that technically work but fail to meet the actual mission objectives.

The System Engineering V Diagram provides a conceptual framework for this lifecycle ^{[system-engineering-v-diagram]}. The left side of the V represents decomposition: mission needs flow downward through feasibility studies, concept of operations, system requirements, and progressively finer design phases. The right side represents integration and verification: unit testing flows upward through subsystem verification, system verification, and validation back to operational requirements. The bottom of the V contains the actual development work—manufacturing, assembly, and integration activities.

The key insight is bidirectional traceability. Every requirement defined on the left side must have a corresponding verification activity on the right side. This prevents the common pitfall of building something that technically meets specifications but fails to address the original mission problem. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing, creating a balanced, verifiable development path ^{[system-engineering-v-diagram]}.

Key Results: Design Reviews as Quality Gates

Spacecraft development is punctuated by formal design reviews that serve as gates between phases. Each review validates that the current level of design maturity is sufficient to proceed to the next phase, and each review enforces traceability to ensure nothing is lost in translation.

System Requirement Review (SRR)

The System Requirement Review occurs near the top of the V-diagram, before significant design effort is invested ^{[system-requirement-review]}. Its purpose is to validate that derived requirements properly capture and decompose the original mission objectives. By catching misinterpretations or gaps in requirements translation early, SRR prevents downstream rework when changes are least costly. It acts as a quality gate that ensures the entire development effort remains aligned with stakeholder needs.

System Design Review (SDR)

Following SRR, the System Design Review bridges requirements and detailed design by examining high-level architectural decisions ^{[system-design-review]}. SDR assesses how system requirements have been allocated across configuration items (subsystems, components) and evaluates manufacturing feasibility. This review prevents architectural mistakes that would be expensive to correct later and confirms the team is ready to proceed with detailed design work on individual subsystems.

Preliminary Design Review (PDR)

The Preliminary Design Review represents a significant 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 approach is feasible and mature enough to justify proceeding to final detailed design. It reduces risk by catching fundamental design flaws before they propagate into expensive detailed work. PDR is the last major review before the design is "locked down" for final implementation.

Critical Design Review (CDR)

The Critical Design Review is the final design review and the last opportunity to catch design errors without incurring manufacturing costs ^{[critical-design-review]}. CDR certifies that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements, and that the final design fulfills all specifications and commitments established at PDR ^{[critical-design-review]}.

After CDR approval, the design is "frozen" and becomes the authoritative baseline for building the spacecraft. This review is critical because changes after CDR are exponentially more expensive—they may require rework of manufacturing plans, tooling, and already-produced components.

Configuration Management and the Build-to Baseline

Once the Critical Design Review approves the design, the organization establishes the build-to baseline—the locked, approved set of complete hardware and software specifications that serves as the authoritative reference for all manufacturing, assembly, integration, and testing activities ^{[build-to-baseline]}.

The build-to baseline contains all detailed specifications: drawings, interface definitions, performance parameters, and acceptance criteria necessary to manufacture and assemble the spacecraft in compliance with functional and performance requirements ^{[build-to-baseline]}. Once approved, it becomes the single source of truth for manufacturing and assembly teams. All subsequent changes are controlled through formal change management processes, ensuring configuration integrity and traceability from original requirements through the final product.

This prevents costly rework, maintains consistency across distributed manufacturing activities, and provides an auditable record of what was actually built versus what was designed.

Managing Uncertainty: TBD and TBC

Not all design details can be determined simultaneously. Two markers help teams manage this uncertainty:

To Be Decided (TBD) indicates items where the decision-making process is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. TBD flags areas requiring active decision-making before the design can be considered complete. In spacecraft design, TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts.

To Be Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development ^{[to-be-confirmed-tbc]}. TBC allows teams to proceed with design work while acknowledging that certain parameters, component selections, or performance values will be confirmed later through analysis, testing, or vendor feedback. This is distinct from TBD—TBC assumes an existing value will be confirmed, whereas TBD implies the decision itself is still pending.

Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. Items marked TBC must have a clear path to confirmation before manufacturing begins.

Worked Example: Traceability Through the V-Diagram

Consider a hypothetical Earth observation satellite with a mission requirement: "Provide 5-meter ground resolution imagery over a 100 km swath."

Left side (decomposition):

1. Mission need: 5 m resolution, 100 km swath
2. System requirement: Optical system must achieve 5 m ground sample distance (GSD)
3. Subsystem requirement: Focal plane array must have pixel pitch $p$ and lens must have focal length $f$ such that GSD $= \frac{h \cdot p}{f}$, where $h$ is orbital altitude
4. Component specification: Focal plane array selected with 5 μm pixels; lens focal length specified as 500 mm

Right side (verification):

1. Unit test: Focal plane array tested to confirm 5 μm pixel pitch
2. Subsystem verification: Optical system tested in thermal vacuum to confirm GSD = 5 m at orbital altitude
3. System verification: Integrated satellite imaged ground targets; confirmed 5 m resolution achieved
4. Validation: Operational imagery compared to ground truth; confirmed mission requirement met

Each level of decomposition has a matching verification activity. If the focal plane array test had revealed 6 μm pixels instead of 5 μm, the team would have caught the problem before integration, allowing time to source a different detector or adjust the optical design.

Conclusion

The System Engineering V Diagram, design reviews, and configuration management form an integrated system for managing spacecraft development complexity. Design reviews serve as gates that enforce traceability and prevent requirements from being lost during implementation. The build-to baseline locks the design and provides a single source of truth for manufacturing. TBD and TBC markers help teams manage uncertainty while maintaining visibility into unresolved items.

By following this structured approach, spacecraft programs reduce risk, prevent costly rework, and ensure that the final hardware actually meets the original mission objectives.

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). All factual claims are cited to source notes. The worked example (Earth observation satellite) was constructed to illustrate the traceability principle but does not represent a specific real-world mission. The author reviewed all claims for technical accuracy before publication.