Spacecraft Design II: Reference Tables and Quick Lookups

Abstract

This article consolidates essential reference material from Spacecraft Design II coursework into a compact lookup guide. It covers the critical design baseline, review gates, and key configuration management concepts that engineers use to transition from detailed design into manufacturing. The material emphasizes the role of formal design reviews and locked specifications in preventing costly rework and maintaining traceability throughout the spacecraft development lifecycle.

Background

Spacecraft development follows a structured sequence of design phases, each culminating in a formal review that gates progression to the next phase. The transition from detailed design to manufacturing is particularly consequential: once a design is approved for production, the cost of change increases exponentially ^{[critical-design-review]}. This article provides quick reference definitions and context for the key artifacts and processes that manage this transition.

Key Results

Critical Design Review (CDR)

The Critical Design Review is the final formal design checkpoint before manufacturing commitment ^{[critical-design-review]}. At CDR, the design team certifies three essential facts:

1. The build-to baseline contains all detailed hardware and software specifications necessary to satisfy functional and performance requirements
2. The finalized design fulfills every specification and commitment established during the Preliminary Design Review (PDR)
3. All design errors have been identified and resolved before manufacturing begins

CDR represents the last gate before committing to expensive manufacturing tooling and production ^{[critical-design-review]}. At this stage, the detailed design phase is complete, and every component, interface, and subsystem has been fully specified. The review validates traceability from each requirement down to specific design specifications, confirms that all interfaces are properly defined and compatible, and verifies the design is actually manufacturable with available processes and resources.

Once CDR is approved, the design becomes "frozen" ^{[critical-design-review]}. This baseline is locked and serves as the authoritative reference for building the spacecraft. Any changes after CDR approval incur exponentially higher costs because they may require rework of manufacturing plans, tooling, and already-produced components.

Build-to Baseline

The build-to baseline is the locked, approved set of complete hardware and software specifications that serves as the authoritative reference document for all manufacturing, assembly, integration, and testing activities ^{[build-to-baseline]}.

Once approved, the build-to baseline becomes the single source of truth for manufacturing and assembly teams ^{[build-to-baseline]}. It eliminates ambiguity by locking all design decisions with sufficient detail that production can proceed without interpretation. All subsequent changes are controlled through formal change management processes, ensuring configuration integrity and traceability from original requirements through the final product.

The baseline prevents costly rework, maintains consistency across distributed manufacturing activities, and provides an auditable record of what was actually built versus what was designed ^{[build-to-baseline]}.

Configuration Management

Configuration management is the formal process that controls all changes to the build-to baseline after CDR approval ^{[build-to-baseline]}. Any modification to the baseline must pass through formal change control to assess impacts and maintain configuration integrity.

This process serves several functions:

• Prevents ambiguity: Locked specifications eliminate interpretation during manufacturing
• Ensures consistency: Distributed teams work from a single authoritative source
• Provides traceability: Every requirement can be traced through design specifications to final product
• Maintains auditability: A formal record documents what was designed versus what was built

Worked Examples

Scenario: Design Change After CDR

Situation: During manufacturing, the thermal team identifies that a component operating temperature will exceed the original specification by 5°C under worst-case conditions. The manufacturing team proposes using a higher-temperature-rated part.

Process:

1. The proposed change is submitted through formal change control (not directly implemented)
2. Impact assessment evaluates effects on:
   • Power budget (higher-temperature parts may have different electrical characteristics)
   • Mass and volume (alternative parts may have different footprints)
   • Reliability and mission life (different material properties)
   • Cost and schedule (procurement lead times, tooling modifications)
3. The change is either approved (with documentation), rejected, or approved with additional modifications
4. If approved, the build-to baseline is formally updated and all affected drawings and specifications are revised
5. The change is recorded in configuration management for traceability

Outcome: The change is traceable, its impacts are understood, and the final product documentation accurately reflects what was actually built.

Scenario: CDR Readiness Check

Situation: A spacecraft design team is preparing for CDR. The lead engineer must verify that the build-to baseline is complete and correct.

Checklist:

• All requirements from the requirements specification have corresponding design specifications
• All interface control documents (ICDs) between subsystems are signed and approved
• All drawings are at the detailed level (not conceptual sketches)
• All performance parameters include acceptance criteria and test methods
• All manufacturing processes are identified and verified as available
• All long-lead components have been identified and procurement initiated
• All design errors from PDR have been closed and verified resolved

Outcome: CDR can proceed with confidence that the design is ready for manufacturing.

References

• ^{[build-to-baseline]}
• ^{[build-to-baseline]}
• ^{[critical-design-review]}

AI Disclosure

This article was drafted with AI assistance. The structure, synthesis, and explanatory text were generated by Claude (Anthropic) based on class notes provided by the author. All factual claims are cited to source notes. The author reviewed and verified technical accuracy before publication.