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

Budgets are how systems engineering keeps a CubeSat realistic. Each one tracks a finite resource – mass, power, data rate, link margin, thermal capacity – against the demands placed on it by every subsystem. They start as rough allocations at concept stage and tighten as the design matures, real components are selected, and test data replaces datasheet promises.

The main budgets

  • Mass budget: per-component mass summed against the form-factor allocation. The long-standing figure from the CDS is 1.33 kg per U,1 though CDS Rev 14 (2022) raised the 1U guideline to 2 kg – always verify against your specific launch provider's payload user guide, since their dispenser limits take precedence over the spec.2 The mass budget is the simplest to maintain and the one most often neglected until it's too late. See the Mass Budget Template under Tools.
  • Power budget: orbit-average consumption vs. generation, broken down by mission mode. See EPS – Power Requirements and Budgets for methodology and Tools for templates.
  • Link budget: gain and loss accounting between transmitter and receiver, producing a link margin in dB. See Comms – Link Budget.
  • Data budget: data generated per orbit vs. downlink capacity given pass duration, ground station availability, and link rate. Tightly coupled to the link budget – you can't plan your downlink schedule without knowing the link rate, and you can't know the link rate without closing the link budget first.
  • Thermal budget: heat generated by electronics and absorbed from the environment vs. radiated heat at hot and cold cases. See Thermal.
  • Volume budget: less rigorous than the others, but useful for tracking how much room is genuinely left after structure, harnessing, and mechanical clearances are accounted for. Especially easy to underestimate on dense 1U or 1.5U designs.

Margin philosophy

Margins exist because early estimates are wrong. A few principles that age well:3

  • Carry more margin early: 30% at PDR, 20% at CDR, 10% at flight is a defensible curve. Different programs use different numbers, but the shape is always tighter as you converge – NASA project guidelines, for instance, target ≥20% at end of Phase B and ≥15% at end of Phase C for mass and power.
  • Don't disguise growth as margin use: if a subsystem grows by 100 g, that's 100 g of growth – not 100 g of margin "spent." Track the two separately so growth trends remain visible. A budget where margin only ever shrinks, and never grows back when a component is swapped for something lighter, is not being managed – it's being consumed.
  • Per-subsystem margins are not additive: 20% margin on every line item is not the same as 20% margin on the total. Decide whether margin lives at the subsystem or system level, and stick to it.
  • Reserves are different from margins: reserves are unallocated budget held by the systems lead for emerging needs. Margins are buffers within an existing allocation. Mixing them up makes both useless – a subsystem that raids system reserve to cover its own growth has broken the accounting.

Iterating

Budgets are living documents. Update them after every major design decision, every test that produces real numbers, and every time a vendor delivers a component with different specs than the datasheet advertised. A budget that hasn't moved in months is either a finished design or, more often, an abandoned one.

For ready-to-use templates, see Calculators and Reference Tools.

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

👉 Please consider contributing!

  1. Cal Poly CubeSat Program, CubeSat Design Specification Rev. 13 – section 3.2.10 sets 1.33 kg as the maximum 1U mass. This was the widely adopted figure for most of the CubeSat community and remains the number many deployers still quote. ↩

  2. Cal Poly CubeSat Program, CubeSat Design Specification Rev. 14.1 (February 2022) – Rev 14 raised the 1U figure to 2 kg and reframed many requirements as guidelines rather than hard constraints. Always confirm the applicable limit with your launch provider; ISS deployers and rideshare providers maintain their own mass budgets and may be more restrictive. ↩

  3. The 30/20/10 curve is consistent with NASA's formal margin guidance. The NASA NTRS paper "Techniques for Conducting Effective Concept Design" (2015) describes project managers holding 25% margins at Phase B entry, with end-Phase-B targets of ≥20% and end-Phase-C targets of ≥15% for mass and power resources. The GSFC engineering standard GSFC-STD-1000 provides detailed margin calculation methodology. CubeSat teams typically adopt slightly more aggressive early margins (30% at PDR) to compensate for shorter schedules and less heritage data. ↩