Project 3: EPS Power Budget Simulator (Energy Management)

Build a power and energy simulator that predicts battery state-of-charge across sunlight/eclipses, models loads and generation, and flags violations of power safety margins.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 1-2 weeks
Main Programming Language Python
Alternative Programming Languages C, Julia
Coolness Level Level 3: Power Wizard
Business Potential Level 2: Internal Mission Tooling
Prerequisites Basic physics, numerical integration, plotting
Key Topics Energy balance, eclipse modeling, battery SoC

1. Learning Objectives

By completing this project, you will:

  1. Model a CubeSat power system with solar generation, battery storage, and loads.
  2. Simulate orbital eclipse cycles and their impact on SoC.
  3. Implement deterministic time-step integration with fixed seeds.
  4. Produce power budget plots and identify unsafe operating windows.
  5. Create a simulation that can be reused in mission planning.

2. All Theory Needed (Per-Concept Breakdown)

Power Balance and Energy Integration

Fundamentals Power balance is the accounting rule for spacecraft survival: generation minus load equals energy stored. If generation exceeds load, the battery charges; if load exceeds generation, it discharges. Because spacecraft power varies with orbit and subsystem activity, you need to integrate power over time to understand energy. State-of-charge (SoC) is the battery’s percentage of usable energy. A simulator must compute SoC changes over time with consistent units and step sizes. If you mis-handle units or time steps, your SoC curve becomes nonsense and mission planning fails.

Deep Dive into the concept At its core, an EPS model is a bookkeeping system that enforces conservation of energy. The spacecraft has power sources (solar arrays) and sinks (loads). Solar array output depends on illumination, panel area, efficiency, and sun incidence angle. Loads include base avionics, communication bursts, payload operations, and heaters. Every time step, you compute net power: P_net = P_gen - P_load. The energy change for that step is E_delta = P_net * dt. The battery SoC changes by E_delta divided by battery capacity. This is simple, but real spacecraft introduce complexities: battery charging efficiency, discharge efficiency, maximum charge/discharge rates, and minimum safe SoC.

In a CubeSat, the EPS is often a simple system with a single battery pack and fixed solar panels. Yet the challenge is that loads are highly dynamic: the transmitter can draw several watts for a short burst, heaters can turn on during eclipse, and payloads might run only during sunlight. The simulator must model these events deterministically. A good design uses a schedule of load events with timestamps and durations. Each event has a power draw and a priority. The simulator accumulates total load each time step based on which events are active.

Battery modeling can be as simple or complex as you need. For this project, a linear SoC model is enough: SoC_t+1 = SoC_t + (P_net * dt / Capacity). But you must clamp SoC between 0 and 1 and enforce maximum charge/discharge rates. You should also include an efficiency factor (e.g., 90% charge efficiency, 95% discharge efficiency). These factors introduce asymmetry: charging is not as efficient as discharging. Another key aspect is battery voltage dependence on SoC. Even if you do not model voltage explicitly, you should include a low-SoC cutoff that forces safe mode or load shedding.

Numerical integration is the glue. Choose a fixed time step (e.g., 1 second or 10 seconds). Smaller dt yields more accurate curves but increases computation. For deterministic results, use fixed dt and avoid floating-point non-determinism by keeping operations order consistent. When you plot results, label axes with units and include thresholds for safe/unsafe regions. This transforms the simulator into a planning tool.

Finally, power balance ties into system-level decisions. If the simulator predicts SoC below threshold during long eclipses, you need to schedule payload operations differently or reduce comms. The output is not just a graph; it is a design decision engine.

How this fit on projects This concept drives Section 3.2 requirements and Section 4 architecture (energy integrator). It also feeds into P09 thermal and P13 mission simulator.

Definitions & key terms

  • SoC (State-of-Charge) -> Fraction of battery capacity available.
  • Capacity (Wh) -> Total usable battery energy.
  • Load profile -> Time-varying power consumption schedule.
  • Net power -> Generation minus load.

Mental model diagram (ASCII)

Solar (W) ---> [Power Balance] ---> Battery SoC
Loads (W) ---^         |
                      Logs + Plots

How it works (step-by-step, with invariants and failure modes)

  1. For each time step, compute solar generation.
  2. Sum active loads to get total consumption.
  3. Compute P_net and integrate energy.
  4. Update SoC and clamp to [0,1].

Invariants: SoC never < 0 or > 1; energy balance consistent with dt; load schedule deterministic.

Failure modes: sign errors, unit mismatch (W vs Wh), variable dt leading to drift.

Minimal concrete example

soc += (p_gen - p_load) * dt / capacity_wh
soc = max(0.0, min(1.0, soc))

Common misconceptions

  • “Average power is enough” -> Short high-power bursts can still drain the battery.
  • “SoC is linear” -> Linear SoC is an approximation; document it.

Check-your-understanding questions

  1. Why does time step size matter for SoC integration?
  2. How does a short transmitter burst affect SoC?
  3. What happens if P_net is negative for long periods?

Check-your-understanding answers

  1. Integration error grows with dt; too large and you miss dynamics.
  2. It can create deep dips even if average power is fine.
  3. SoC trends toward zero; safe mode must trigger.

Real-world applications

  • Mission power budgets and operations planning.
  • Battery sizing and load scheduling.

Where you’ll apply it

References

  • Spacecraft Systems Engineering (Power chapter)
  • Fundamentals of Space Systems (EPS sections)

Key insights Power is a time integral problem, not just a snapshot.

Summary Energy balance modeling is the backbone of EPS planning.

Homework/Exercises to practice the concept

  • Compute SoC for a 10-minute eclipse with a 2 W load and 10 Wh battery.

Solutions to the homework/exercises

  • SoC drop = (2 W * 0.167 h) / 10 Wh = 3.34%.

Eclipse Modeling and Solar Generation Geometry

Fundamentals A satellite alternates between sunlight and eclipse every orbit. In sunlight, solar arrays generate power; in eclipse, they generate nothing. The duration of eclipse depends on orbit altitude, inclination, and beta angle (angle between orbit plane and sun vector). For a simplified simulator, you can model eclipse as a periodic square wave: on for sunlight, off for eclipse. Even this crude model captures the main impact on power. The key is to compute eclipse start/stop times and integrate them into the power model.

Deep Dive into the concept Eclipse modeling can be simple or physically detailed. At minimum, you need orbital period and eclipse fraction. For low Earth orbit (LEO), orbital period is around 90 minutes, and eclipse fractions often range between 30-40%. A simple approach uses a fixed period (T) and an eclipse duration (T_ecl). If you align your simulator with a given epoch, you can compute whether a time t is in eclipse by t mod T and compare to the eclipse window. This yields deterministic patterns and is sufficient for power budgeting.

For more accuracy, you can incorporate a beta angle model. The beta angle depends on orbit plane orientation relative to the sun and varies slowly over days. When beta is high, eclipses are shorter; when beta is near zero, eclipses are longer. A simplified model can accept beta as a parameter and adjust eclipse fraction by a linear approximation. The important part is to expose this parameter so users can explore worst-case eclipse scenarios.

Solar generation also depends on panel area and angle to the sun. In CubeSats, panels are fixed, so the angle changes with attitude. If you assume sun-pointing in nominal mode, you can model generation as a constant maximum (P_max) during sunlight. If you assume uncontrolled attitude, reduce generation by a cosine factor or a fixed derating. This connects directly to ADCS and mode management: a satellite in SAFE mode may be sun-pointing and thus maximize power, while in NOMINAL it might not.

When modeling generation, include efficiency factors: cell efficiency, temperature derating, and power converter losses. You can bundle these into a single efficiency scalar for simplicity. Again, the goal is a realistic budget, not an exact electrical model.

Finally, eclipse modeling introduces sharp transitions in P_gen. Your integration should handle these discontinuities without instability. With fixed time steps, you can detect eclipse boundary crossings and adjust the fraction of the step that is in sunlight vs eclipse. This improves accuracy without complicating the code.

How this fit on projects This concept drives Section 3.2 (eclipse scheduling) and informs P04 orbit propagation and P13 integration.

Definitions & key terms

  • Eclipse fraction -> Portion of orbit in shadow.
  • Beta angle -> Sun-orbit plane angle influencing eclipse duration.
  • Solar incidence angle -> Angle between panel normal and sun vector.

Mental model diagram (ASCII)

Orbit Period T
| Sunlight | Eclipse | Sunlight | Eclipse |

How it works (step-by-step, with invariants and failure modes)

  1. Compute orbital period T.
  2. Define eclipse duration T_ecl.
  3. Determine sunlight/eclipsed status at time t.
  4. Set P_gen = 0 in eclipse, P_gen = P_max in sunlight.

Invariants: P_gen >= 0; eclipse windows repeat every orbit; boundary times deterministic.

Failure modes: wrong period leads to incorrect eclipse fraction; time units mismatch.

Minimal concrete example

phase = (t % T)
if phase < T_ecl:
    p_gen = 0
else:
    p_gen = P_max

Common misconceptions

  • “Eclipse is constant across all orbits” -> Beta angle changes it over time.
  • “Solar output is constant in sunlight” -> Attitude can reduce it.

Check-your-understanding questions

  1. What parameters determine eclipse duration in a simplified model?
  2. How does sun-pointing affect generation?
  3. Why handle eclipse boundaries within a time step?

Check-your-understanding answers

  1. Orbital period and eclipse fraction (or beta angle).
  2. Sun-pointing maximizes panel incidence and power.
  3. To reduce integration error at discontinuities.

Real-world applications

  • Ground planning for high-power payload ops.
  • Estimating worst-case energy margins.

Where you’ll apply it

References

  • Fundamentals of Space Systems (Thermal & Power)
  • Spacecraft Systems Engineering (Power generation)

Key insights Eclipse is the dominant driver of energy risk; model it explicitly.

Summary Even a simple eclipse model yields strong insight into power safety.

Homework/Exercises to practice the concept

  • Estimate eclipse time for a 90-minute orbit with 35% eclipse fraction.

Solutions to the homework/exercises

  • Eclipse duration = 31.5 minutes.

3. Project Specification

3.1 What You Will Build

A deterministic EPS simulator that models solar generation, load schedules, battery SoC, and power safety thresholds over multiple orbits.

3.2 Functional Requirements

  1. Generation model: compute solar power with eclipse gating.
  2. Load model: schedule base load, comms bursts, and payload ops.
  3. Battery model: integrate net power into SoC with efficiency.
  4. Safety checks: flag SoC below threshold and log events.
  5. Plots: generate SoC and power curves.

3.3 Non-Functional Requirements

  • Determinism: fixed timestep and deterministic event schedule.
  • Usability: CLI parameters for orbit period, eclipse fraction, loads.
  • Accuracy: energy conservation within tolerance.

3.4 Example Usage / Output

$ python eps_sim.py --orbits 3 --dt 10
[INFO] Min SoC: 0.32
[INFO] Max SoC: 0.78
[PLOT] eps_soc.png

3.5 Data Formats / Schemas / Protocols

Load schedule (CSV):

start_s,duration_s,power_w,label
600,120,3.0,TX_BURST
1800,900,2.5,PAYLOAD

3.6 Edge Cases

  • SoC hitting zero during eclipse.
  • Overcharge when load is low and sun-pointing is constant.
  • Multiple overlapping load events.

3.7 Real World Outcome

A plot and log file that show SoC evolution across orbits and highlight unsafe windows.

3.7.1 How to Run (Copy/Paste)

python eps_sim.py --orbits 5 --dt 10 --load loads.csv --seed 42

3.7.2 Golden Path Demo (Deterministic)

  • --seed 42 and a fixed load file produce identical plots.
  • Compare against golden_soc.csv.

3.7.3 Failure Demo (Deterministic)

Run with an aggressive load schedule:

python eps_sim.py --orbits 2 --load loads_overdraw.csv

Expected: simulator logs LOW_SOC event and exits with code 3.

3.7.4 If CLI: Exact Terminal Transcript

$ python eps_sim.py --orbits 2 --dt 10 --load loads.csv --seed 42
[INFO] Min SoC: 0.34
[INFO] Max SoC: 0.81
[PLOT] eps_soc.png
ExitCode=0

4. Solution Architecture

4.1 High-Level Design

Orbit Time -> Eclipse Model -> Power Gen
           -> Load Scheduler -> Net Power -> SoC Integrator -> Logs/Plots

4.2 Key Components

Component Responsibility Key Decisions
Eclipse Model Sunlight/eclipsed status Fixed fraction vs beta model
Load Scheduler Active loads over time CSV vs built-in schedule
Battery Model SoC integration Linear + efficiency
Plotter Output graphs CSV + matplotlib

4.3 Data Structures (No Full Code)

class LoadEvent:
    start_s: int
    duration_s: int
    power_w: float

4.4 Algorithm Overview

Key Algorithm: SoC integration

  1. For each timestep, compute P_gen and P_load.
  2. P_net = P_gen - P_load.
  3. SoC += P_net * dt / capacity.
  4. Clamp SoC and log events.

Complexity Analysis:

  • Time: O(steps + events)
  • Space: O(steps) for logs

5. Implementation Guide

5.1 Development Environment Setup

python -m venv .venv
source .venv/bin/activate
pip install matplotlib numpy

5.2 Project Structure

project-root/
+-- eps_sim.py
+-- loads.csv
+-- plots/
+-- README.md

5.3 The Core Question You’re Answering

“Will this mission survive its eclipses with the planned power loads?”

5.4 Concepts You Must Understand First

  1. Energy integration and SoC.
  2. Eclipse scheduling.
  3. Load profile modeling.

5.5 Questions to Guide Your Design

  1. What is the minimum safe SoC threshold?
  2. How often do high-power payloads run?
  3. What is the worst-case eclipse fraction?

5.6 Thinking Exercise

Compute SoC drop for a 35-minute eclipse with a 2 W load and 10 Wh battery.

5.7 The Interview Questions They’ll Ask

  1. “Why simulate SoC instead of using average power?”
  2. “What factors dominate eclipse energy loss?”
  3. “How do you validate a power model?”

5.8 Hints in Layers

Hint 1: Implement a fixed eclipse fraction first.

Hint 2: Add a CSV load schedule parser.

Hint 3: Add battery efficiency and SoC clamping.

Hint 4: Output CSV logs for plotting and verification.

5.9 Books That Will Help

Topic Book Chapter
Power systems Spacecraft Systems Engineering EPS chapter
CubeSat power Fundamentals of Space Systems Power sections
Numerical integration Numerical Recipes Integration basics

5.10 Implementation Phases

Phase 1: Basic SoC Model (3-4 days)

Goals: integrate net power into SoC. Tasks:

  1. Implement P_net and SoC update.
  2. Plot SoC over time. Checkpoint: SoC curve looks reasonable.

Phase 2: Eclipse + Loads (3-4 days)

Goals: add eclipse model and load schedule. Tasks:

  1. Implement eclipse gating.
  2. Parse load schedule file. Checkpoint: SoC drops during eclipse.

Phase 3: Safety Events (2-3 days)

Goals: detect unsafe SoC and log events. Tasks:

  1. Implement thresholds and event logs.
  2. Add exit codes for violations. Checkpoint: low SoC triggers deterministic exit code.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Time step 1s / 10s / 60s 10s Good tradeoff of speed/accuracy
Load model fixed / CSV schedule CSV schedule Realistic operations
SoC model linear / nonlinear linear Adequate for budgeting

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests SoC update math known power inputs
Integration Tests Full orbit sim golden_soc.csv
Edge Case Tests Overdraw loads_overdraw.csv

6.2 Critical Test Cases

  1. No eclipse: SoC increases monotonically.
  2. All eclipse: SoC decreases monotonically.
  3. Burst load: SoC dips then recovers.

6.3 Test Data

loads.csv: one TX burst at t=600s for 120s, 3 W

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Unit mismatch SoC explodes Use Wh consistently
Wrong eclipse timing SoC too high Verify period and fraction
Negative SoC Values below 0 Clamp and log event

7.2 Debugging Strategies

  • Plot intermediate P_gen and P_load curves.
  • Verify energy balance with small hand-calculated cases.

7.3 Performance Traps

Large dt can hide short bursts; keep dt <= 10s for burst modeling.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add CSV export of SoC timeline.

8.2 Intermediate Extensions

  • Add beta-angle input to vary eclipse duration.

8.3 Advanced Extensions

  • Couple to attitude model for sun incidence.

9. Real-World Connections

9.1 Industry Applications

  • Power budgeting for CubeSat mission planning.
  • Onboard autonomy rules for load shedding.
  • OpenSatKit: power monitoring examples.
  • cFS: EPS telemetry interfaces.

9.3 Interview Relevance

  • Demonstrates systems modeling and numerical integration.

10. Resources

10.1 Essential Reading

  • Spacecraft Systems Engineering - EPS chapter.
  • Fundamentals of Space Systems - power system modeling.

10.2 Video Resources

  • CubeSat power system lectures.

10.3 Tools & Documentation

  • matplotlib for plotting.
  • numpy for vectorized integration.

11. Self-Assessment Checklist

11.1 Understanding

  • I can compute SoC from a load schedule.
  • I can explain why eclipse dominates energy risk.
  • I can justify the chosen time step.

11.2 Implementation

  • Simulator matches golden outputs.
  • Low-SoC events are logged deterministically.
  • Plots are labeled with units and thresholds.

11.3 Growth

  • I can describe how I would add battery degradation.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Compute SoC over time with eclipse and loads.
  • Output a SoC plot.

Full Completion:

  • Include efficiency, safety thresholds, and event logs.

Excellence (Going Above & Beyond):

  • Couple EPS model to attitude or thermal effects.