Spacecraft Design II: Foundations and First Principles
Abstract
Spacecraft design is fundamentally a problem of translating mission needs into verifiable hardware and software specifications while managing risk and cost across a complex development lifecycle. This article examines the core structural framework—the System Engineering V Diagram—and the critical design review checkpoints that ensure requirements remain traceable from conception through manufacturing. Understanding these foundations is essential for any engineer entering spacecraft development.
Background
Spacecraft are among the most complex engineered systems. A single mission failure can cost hundreds of millions of dollars and years of scientific opportunity. Unlike many terrestrial systems, spacecraft cannot be easily repaired or modified after launch. This constraint makes the design process fundamentally different from iterative consumer product development.
The discipline of spacecraft design rests on a simple principle: every requirement must be verifiable, and every verification must trace back to an original mission need. This principle is embedded in the System Engineering V Diagram [system-engineering-v-diagram], a structured framework that has become standard across aerospace organizations.
The V Diagram maps the complete lifecycle of a spacecraft from initial mission conception through operational deployment and eventual retirement. The left side of the V represents decomposition—the progressive breakdown of high-level mission objectives into increasingly detailed subsystem and component requirements. The right side represents integration and verification—the assembly and testing of components back into subsystems, subsystems into the complete system, and finally validation against the original mission needs.
This bidirectional structure embodies a critical insight: every requirement defined during decomposition must have a corresponding verification activity during integration. A requirement without a verification plan is unmanageable; a verification activity without a traced requirement is wasteful. The V Diagram prevents both pathologies.
Key Results
The Design Review Hierarchy
Spacecraft development is punctuated by formal design reviews, each serving as a quality gate and commitment point. These reviews are not bureaucratic overhead—they are risk-reduction mechanisms that catch errors before they propagate into expensive manufacturing and assembly phases.
System Requirement Review (SRR) [system-requirement-review] occurs near the top of the V Diagram, after mission needs have been translated into derived system requirements but before significant design investment. SRR validates that lower-level derived requirements properly decompose and capture the original mission objectives. Its purpose is to catch misinterpretations or gaps in requirements translation early, when changes are least costly. By verifying alignment between high-level system requirements and their decomposition, SRR acts as a quality gate before proceeding to detailed system design.
System Design Review (SDR) [system-design-review] follows SRR and evaluates how system requirements have been allocated across the spacecraft's configuration items—the subsystems and major components that will be designed, built, and tested independently. SDR assesses the feasibility of the proposed allocation and examines manufacturing considerations. It bridges the gap between requirements and detailed design by confirming that the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems.
Preliminary Design Review (PDR) [preliminary-design-review] represents a major commitment point. 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 is the last major review before the design is "locked down" for detailed specification work. Proceeding past PDR without confidence in the design approach risks propagating fundamental flaws into expensive detailed work.
Critical Design Review (CDR) [critical-design-review] is the final design review, occurring after detailed design is complete but before manufacturing begins. CDR certifies that the "build-to" baseline—the complete set of hardware and software specifications—is correct, complete, and ready for manufacturing. It is the last opportunity to catch design errors without incurring manufacturing costs. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft [build-to-baseline].
Documentation Discipline
Spacecraft design documents must be precise about what is known and what is not. Two markers are essential: TBD (To Be Decided) and TBC (To Be Confirmed).
TBD [to-be-decided-tbd] flags items where the decision-making process is still pending and the outcome is uncertain. A TBD indicates that active decision-making is required before the design can be considered complete. TBDs are tracked rigorously because unresolved decisions cascade into schedule delays and design conflicts.
TBC [to-be-confirmed-tbc] indicates an item that is not yet finalized but is expected to be confirmed during development. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback. Using TBC explicitly maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments.
Design reviews like CDR require that TBDs be minimized and justified. A design cannot be considered ready for manufacturing if critical decisions remain unmade.
Worked Examples
Consider a hypothetical Earth observation satellite mission. The mission need is to image a specific geographic region with 5-meter ground resolution at least once per day.
At SRR, this mission need is decomposed into system requirements:
- Optical subsystem must achieve 5-meter ground resolution at nominal orbital altitude
- Attitude control subsystem must point the spacecraft to within 0.1° of target
- Data handling subsystem must store and downlink at least one full image per day
- Power subsystem must supply sufficient energy for imaging and downlink operations
At SDR, these system requirements are allocated to configuration items. The optical requirement is assigned to the Payload subsystem; attitude control to the ADCS (Attitude Determination and Control System); data handling to the Command and Data Handling subsystem; and power to the Electrical Power System. Each subsystem manager becomes responsible for meeting their allocated requirements.
At PDR, each subsystem presents preliminary designs showing how they will meet their requirements. The Payload team presents optical design trades and preliminary specifications. The ADCS team presents attitude control architecture and pointing accuracy analysis. The C&DH team presents data storage and downlink architecture. The Power team presents power budget and battery sizing. The review confirms that the integrated design is feasible.
At CDR, all preliminary designs are finalized into detailed specifications. The Payload subsystem provides detailed optical drawings, material specifications, and performance test plans. The ADCS provides detailed control algorithms and sensor/actuator specifications. The C&DH provides detailed software architecture and interface specifications. The Power subsystem provides detailed electrical schematics and component datasheets. Every requirement has a corresponding specification, and every specification has a corresponding verification plan.
Only after CDR approval does manufacturing begin. The build-to baseline is now frozen, and any changes must go through formal change control.
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 AI assistance from class notes (Zettelkasten). All factual claims are cited to source notes. The structure, synthesis, and worked example were generated by AI based on the provided notes. The author reviewed and validated all technical content for accuracy and completeness.