Skip to content

Systems Engineering

Systems engineering provides the framework for designing, integrating, and operating a CubeSat as a coherent system. Rather than focusing on individual subsystems, it addresses how requirements, interfaces, constraints, and tradeoffs are managed across the entire mission lifecycle. This section covers requirements definition, system architecture, interfaces, margins, verification, and risk management for CubeSat missions.


Mission Objectives and Requirements

To be added here:

  • Translating mission goals into technical requirements
  • Science vs. technology demonstration missions
  • Requirement hierarchy and traceability
  • Avoiding over- and under-specification

Concept of Operations (CONOPS)

To be added here:

  • Describing how the mission is intended to operate end-to-end
  • Mission phases from launch to end-of-life
  • Nominal and off-nominal operational scenarios
  • Interaction between spacecraft, ground segment, and operators

System Architecture

To be added here:

  • Functional vs. physical architectures
  • Centralised vs. distributed designs
  • Partitioning responsibilities across subsystems
  • Architectural drivers and constraints

Interfaces and Interface Control Documents (ICDs)

To be added here:

  • Electrical, mechanical, and software interfaces
  • Defining clear ownership and boundaries
  • Interface versioning and change management
  • Common interface-related failure modes

Budgets and Margins

To be added here:

  • Mass, power, data rate, and thermal budgets
  • Allocating and tracking margins
  • Conservative vs. aggressive margin strategies
  • Iterating budgets as the design matures

Trade Studies and Design Decisions

To be added here:

  • Comparing architectural and component options
  • Evaluating cost, risk, and complexity
  • Documenting rationale for decisions
  • Knowing when “good enough” is sufficient

Reliability and Risk Management

To be added here:

  • Identifying single points of failure
  • Risk classification and mitigation strategies
  • Redundancy vs. simplicity tradeoffs
  • Designing for partial failures

Configuration and Change Management

To be added here:

  • Managing hardware and software versions
  • Controlling design changes
  • Documentation and review practices
  • Preventing configuration drift

Verification and Validation (V&V)

To be added here:

  • Requirement verification methods
  • Test, analysis, inspection, and demonstration
  • Linking requirements to AIT activities
  • Knowing when a requirement is “verified enough”

Mission Phases and Operations

To be added here:

  • Development, launch, commissioning, and operations
  • Mode transitions and operational constraints
  • Ground segment interaction
  • End-of-life considerations

Lessons Learned and Common Pitfalls

To be added here:

  • Typical failure patterns in CubeSat missions
  • Integration and interface issues
  • Organisational and communication pitfalls
  • Capturing and reusing lessons learned