Spacecraft Design II: Underlying Assumptions and Validity Regimes

Abstract

Spacecraft design operates within a structured framework that decomposes mission needs into verifiable requirements and allocates them across subsystems. This article examines the foundational assumptions embedded in the System Engineering V-diagram and the design review process, clarifies the distinction between decision-making and confirmation activities, and identifies the validity regimes in which these tools remain effective. Understanding these assumptions is essential for practitioners to recognize when standard processes apply and when adaptation is necessary.

Background

The development of complex spacecraft requires a systematic approach to translate abstract mission objectives into concrete hardware and software specifications. The System Engineering V-diagram provides the canonical framework for this process ^{[system-engineering-v-diagram]}. The diagram's structure reflects a fundamental assumption: that requirements can be hierarchically decomposed on the left side (from mission needs through system, subsystem, and unit levels) and then verified through corresponding integration and testing activities on the right side.

This bidirectional flow is supported by a series of formal design reviews that serve as quality 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) assesses how those requirements have been allocated across configuration items ^{[system-design-review]}. The Preliminary Design Review (PDR) confirms that the proposed design approach is feasible and mature ^{[preliminary-design-review]}. Finally, the Critical Design Review (CDR) certifies that the detailed design is complete and ready for manufacturing ^{[critical-design-review]}.

Embedded within this process are two distinct documentation markers: To Be Decided (TBD) and To Be Confirmed (TBC). These terms are often conflated in practice, but they represent fundamentally different states of design maturity ^{[to-be-decided-tbd]}, ^{[to-be-confirmed-tbc]}.

Key Results

Assumption 1: Requirements Are Hierarchically Decomposable

The V-diagram assumes that mission-level objectives can be systematically broken down into lower-level requirements without loss of fidelity or emergence of new constraints. This assumption holds when:

• The problem domain is well-understood and stable
• Interactions between subsystems are predictable and can be captured in interface specifications
• Requirements are primarily functional or performance-based rather than emergent properties

The assumption breaks down when:

• The mission involves novel technologies or operational concepts with limited heritage
• System behavior depends on complex nonlinear interactions between subsystems
• Requirements are defined in terms of emergent properties (e.g., reliability, resilience) that cannot be simply summed across components

Assumption 2: Verification Is Bidirectional and Complete

The V-diagram's right side assumes that every requirement defined on the left has a corresponding verification activity that can definitively prove compliance. This assumption is valid when:

• Requirements are testable and measurable
• The test environment can adequately represent operational conditions
• Failure modes are well-characterized and can be detected by planned tests

The assumption fails when:

• Requirements are qualitative or subjective (e.g., "user-friendly interface")
• Operational environments cannot be replicated in ground testing (e.g., long-duration microgravity effects)
• Failure modes are rare or emerge only under combinations of conditions difficult to reproduce

Assumption 3: TBD and TBC Are Distinct States

A critical distinction exists between items that require a decision and items that require confirmation of an existing value ^{[to-be-decided-tbd]}, ^{[to-be-confirmed-tbc]}.

TBD indicates that the decision-making process itself is pending. The outcome is uncertain, and multiple viable options may exist. Examples include:

• Selection of a propulsion system architecture (monopropellant vs. bipropellant)
• Choice of attitude determination sensor suite
• Allocation of a functional requirement to a specific subsystem

TBC indicates that a provisional value or approach has been selected, but confirmation through analysis, testing, or vendor feedback is required before finalization. Examples include:

• Confirmation of a component's thermal performance under actual flight loads
• Validation of a software algorithm's execution time on flight hardware
• Confirmation of manufacturing feasibility for a novel structural design

The validity of this distinction depends on clear documentation and disciplined tracking. When TBD and TBC are used interchangeably, ambiguity propagates downstream, and design reviews cannot effectively assess readiness.

Assumption 4: Design Maturity Increases Monotonically

The review sequence (SRR → SDR → PDR → CDR) assumes that design maturity increases monotonically and that earlier reviews do not need to be revisited. This assumption holds when:

• Requirements remain stable
• Technology selections made at PDR remain feasible
• Manufacturing constraints identified at SDR do not invalidate architectural decisions

The assumption can fail when:

• Requirements change due to stakeholder feedback or external constraints
• Technology development reveals infeasibility of earlier selections
• Manufacturing studies reveal that the proposed architecture is not producible within cost or schedule constraints

In such cases, the design may need to iterate backward through earlier reviews, incurring schedule and cost penalties.

Assumption 5: The Build-to Baseline Is Achievable and Sufficient

Once approved at CDR, the build-to baseline becomes the authoritative specification for manufacturing ^{[build-to-baseline]}. This assumes that:

• The baseline contains sufficient detail for unambiguous manufacturing
• No significant unknowns remain that could affect producibility
• The baseline can be executed within the project's cost and schedule constraints

This assumption is valid when the design has been thoroughly analyzed and tested at the subsystem level. It becomes problematic when:

• Detailed design reveals manufacturing challenges not anticipated during PDR
• Supplier feedback indicates that specified tolerances or materials are not available
• Integration testing reveals unexpected interactions that require design changes

Validity Regimes

The System Engineering V-diagram and associated design review process are most effective in the following regimes:

1. Heritage-based programs: Projects using proven technologies and operational concepts from prior missions. The hierarchical decomposition and verification approach works well because requirements are well-understood and test environments can adequately represent flight conditions.

2. Well-defined, stable requirements: Programs where mission objectives are clear and unlikely to change significantly. The forward flow through SRR and SDR is efficient when requirements remain fixed.

3. Subsystem-level independence: Projects where subsystems interact primarily through well-defined interfaces and do not exhibit strong emergent properties. The V-diagram's assumption of bidirectional verification is valid when subsystem testing can be performed independently.

4. Mature manufacturing processes: Programs using established manufacturing techniques and suppliers with demonstrated capability. The build-to baseline assumption holds when producibility is not a significant risk.

The process requires adaptation or supplementation in the following regimes:

1. Novel technology development: Programs introducing new propulsion systems, materials, or operational concepts. These require parallel technology maturation activities and may not fit neatly into the standard V-diagram flow.

2. Emergent requirements: Missions where system-level properties (e.g., fault tolerance, cybersecurity) cannot be decomposed into independent subsystem requirements. These benefit from iterative design and integration testing rather than strict hierarchical decomposition.

3. High-uncertainty environments: Projects with significant unknowns in operational conditions, manufacturing feasibility, or technology performance. These require risk-driven design approaches that explicitly manage uncertainty rather than assuming requirements can be locked at SRR.

Worked Example: Distinguishing TBD from TBC

Consider a spacecraft attitude determination and control subsystem (ADCS) design at the PDR stage. The design team has selected a baseline architecture using star trackers and reaction wheels but has not finalized the specific component selections.

TBD items:

• "Reaction wheel manufacturer: TBD" — The team has not yet decided between three candidate suppliers, each with different performance and cost characteristics. A trade study is underway to evaluate options.
• "Attitude control law: TBD" — The control algorithm architecture (PID vs. model predictive control) has not been selected. Analysis is ongoing.

TBC items:

• "Star tracker accuracy: TBD [Note: expected to be confirmed as ±10 arcsec based on vendor datasheet]" — The team has identified a likely component and provisional specification, but confirmation requires detailed analysis of the sensor's performance under the spacecraft's thermal and radiation environment.
• "Reaction wheel momentum dumping strategy: TBC via magnetic torquer analysis" — The team has selected magnetic torquers for momentum management but must confirm through detailed electromagnetic analysis that the spacecraft's magnetic field environment permits the required dipole moment.

At CDR, all TBD items must be resolved (decisions made) and all TBC items must be confirmed (provisional values validated). Items remaining as TBD or TBC at CDR indicate incomplete design maturity and typically result in review non-compliance.

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 the assistance of an AI language model based on class notes from Spacecraft Design II. The AI was used to organize material, clarify logical structure, and generate examples. All factual claims are grounded in the cited notes. The author reviewed the final text for technical accuracy and relevance.