Spacecraft Design II: Underlying Assumptions and Validity Regimes

Abstract

Spacecraft design operates within a structured framework of reviews and baselines that enforce traceability from mission needs to manufacturing specifications. This article examines the underlying assumptions embedded in the System Engineering V-diagram and the design review process, identifies the validity regimes in which these assumptions hold, and discusses what happens when those regimes are violated. The analysis reveals that the entire design control architecture depends on early, accurate requirements definition and assumes that design maturity can be assessed discretely at review gates.

Background

The spacecraft design process is governed by a formal sequence of reviews and baselines that map the lifecycle from concept through manufacturing ^{[system-engineering-v-diagram]}. This structure—the System Engineering V-diagram—represents a bidirectional flow: decomposition of mission needs into detailed specifications on the left side, and integration and verification flowing upward on the right ^{[system-engineering-v-diagram]}. The diagram's central assumption is that every requirement defined during decomposition must have a corresponding verification activity during integration, creating a closed loop of traceability.

The design review process instantiates this principle through a series of gates. The System Requirement Review (SRR) validates that high-level mission needs have been correctly translated into derived system requirements ^{[system-requirement-review]}. The System Design Review (SDR) examines how those requirements have been allocated to configuration items and manufacturing approaches ^{[system-design-review]}. The Preliminary Design Review (PDR) confirms that the proposed design approach is feasible and mature enough to justify proceeding to detailed design ^{[preliminary-design-review]}. Finally, the Critical Design Review (CDR) certifies that the detailed design is complete, correct, and ready for manufacturing ^{[critical-design-review]}.

Upon CDR approval, the design is frozen into the build-to baseline—the locked, authoritative set of specifications that governs all manufacturing and assembly activities ^{[build-to-baseline]}. This baseline becomes the single source of truth, with all subsequent changes controlled through formal configuration management.

Key Results: Assumptions and Their Validity Regimes

Assumption 1: Requirements Can Be Accurately Defined Early

The entire V-diagram assumes that mission needs can be translated into stable, complete system requirements before detailed design begins. This assumption is valid when:

• The mission is well-understood and stakeholder needs are stable
• The operational environment is predictable
• Technology maturity is sufficient to bound the design space
• Stakeholders can articulate requirements without ambiguity

This regime holds for mature mission classes (e.g., Earth observation satellites following established patterns) where requirements have been refined through previous programs. It breaks down for novel missions, emerging technologies, or when stakeholder needs evolve during development. In such cases, requirements become provisional, and the review process must accommodate iteration rather than treating SRR as a one-time gate ^{[system-requirement-review]}.

Assumption 2: Design Maturity Can Be Assessed at Discrete Review Gates

The review sequence assumes that design maturity is a monotonic function that can be evaluated at specific checkpoints. PDR assumes the design is mature enough to proceed; CDR assumes it is mature enough to manufacture ^{[preliminary-design-review]}, ^{[critical-design-review]}.

This assumption is valid when:

• Design work is sequential and well-partitioned
• Subsystem interdependencies are well-understood before detailed design
• Technology selections are stable and proven
• The design team has sufficient experience with similar systems

The assumption breaks down in highly integrated systems where subsystem interactions emerge only during detailed design, or when new technologies introduce unforeseen constraints. In these regimes, the review gates become risk assessments rather than maturity certifications, and design often iterates backward across review boundaries.

Assumption 3: The Build-to Baseline Is Achievable and Stable

CDR produces the build-to baseline—a locked set of specifications assumed to be both achievable and stable through manufacturing ^{[build-to-baseline]}. This assumption holds when:

• Manufacturing processes are well-characterized
• Supplier capabilities are well-understood
• No fundamental design flaws exist
• The design includes adequate margins for manufacturing variation

The assumption fails when manufacturing reveals unforeseen constraints, suppliers cannot meet specifications, or design margins are insufficient. In these cases, formal change control processes must manage deviations, but the cost and schedule impact can be severe.

Assumption 4: Traceability Is Sufficient for Correctness

The V-diagram assumes that if every requirement has a corresponding verification activity, the design will be correct. This assumes:

• Requirements are correct (not just traceable)
• Verification methods actually validate the requirements
• No emergent properties arise from system integration

This regime is valid for well-decomposed systems with clear functional boundaries. It breaks down for systems with complex emergent behavior, where verification of individual subsystems does not guarantee system-level correctness. In such cases, additional system-level testing and validation become necessary beyond what the V-diagram prescribes.

Worked Example: When Assumptions Fail

Consider a spacecraft with a novel propulsion system. At PDR, the propulsion subsystem design is preliminary but appears feasible ^{[preliminary-design-review]}. The design team proceeds to detailed design, allocating performance requirements to engine components.

At CDR, detailed specifications are locked, and the build-to baseline is approved ^{[critical-design-review]}. Manufacturing begins.

During manufacturing, the engine supplier discovers that the specified material cannot be reliably machined to the required tolerances. The design is not wrong—it is simply not manufacturable with available processes.

In this scenario:

1. Assumption 2 failed: Design maturity was not actually sufficient at PDR; the manufacturing constraint was not discovered until detailed design.
2. Assumption 3 failed: The build-to baseline is not achievable.
3. Assumption 4 partially failed: Traceability from requirement to specification did not catch the manufacturability issue because verification focused on functional performance, not process capability.

The program must now invoke formal change control, redesign the component, and absorb schedule and cost impacts. The review process did not prevent this failure because it operates within a validity regime that assumes manufacturing constraints are known before CDR.

Implications for Practice

The design review process is not a universal quality assurance mechanism; it is a structured approach that works well within specific validity regimes. Practitioners should:

1. Assess regime validity early: Determine whether the program's characteristics (mission novelty, technology maturity, integration complexity) align with the assumptions underlying the V-diagram.

2. Adjust review rigor accordingly: Programs in high-uncertainty regimes should conduct more frequent reviews, involve manufacturing and supply chain partners earlier, and treat design maturity assessments as risk evaluations rather than binary gates.

3. Manage TBD/TBC items explicitly: Items marked To Be Decided (TBD) or To Be Confirmed (TBC) represent assumption violations ^{[to-be-decided-tbd]}, ^{[to-be-confirmed-tbc]}. These should be tracked and resolved before CDR, with explicit justification for any that remain.

4. Invest in early verification: For novel systems, conduct manufacturing trials, supplier capability assessments, and subsystem integration testing before PDR to validate assumptions about feasibility and manufacturability.

5. Plan for iteration: If requirements or technology maturity are uncertain, design the program to accommodate iteration across review boundaries rather than treating reviews as one-way gates.

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. The structure, synthesis of assumptions, and worked example were generated by an AI language model based on source material. All factual claims are cited to original notes. The interpretation of "validity regimes" and the failure scenario are analytical extensions not explicitly present in the source material, offered as a framework for understanding when the design review process is and is not effective. Readers should verify technical claims against primary sources and course materials.