Project 13: Full Mission Simulator (The Digital Twin)

Build a full mission simulator that integrates orbit propagation, EPS, ADCS, telemetry scheduling, and ground passes into a single deterministic digital twin.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate 2-4 weeks
Main Programming Language Python
Alternative Programming Languages C/C++
Coolness Level Level 5: Mission Architect
Business Potential Level 4: Mission Simulation Tooling
Prerequisites Systems integration, scheduling, simulation modeling
Key Topics Multi-rate simulation, subsystem contracts, end-to-end validation

1. Learning Objectives

By completing this project, you will:

  1. Integrate orbit, EPS, ADCS, telemetry, and ground ops models into one simulator.
  2. Coordinate multi-rate subsystems under a deterministic scheduler.
  3. Enforce subsystem interface contracts with unit validation.
  4. Validate mission constraints with golden scenarios and fault injection.
  5. Produce mission logs, plots, and pass reports for operations review.

2. All Theory Needed (Per-Concept Breakdown)

Multi-Rate Simulation and Time Integration

Fundamentals Different subsystems run at different rates. ADCS may run at 10 Hz, EPS at 1 Hz, and telemetry scheduling at 0.1 Hz. A mission simulator must coordinate these rates without drifting or losing determinism. The simplest approach is a fixed global time step that is a common divisor of subsystem rates, with each subsystem updating when its next tick arrives. If you mishandle time integration, your simulation becomes inconsistent and meaningless.

Deep Dive into the concept Multi-rate simulation is about synchronizing subsystems that operate on different time scales. The key is to define a global timeline and schedule subsystem updates at their own cadence. For example, if the global step is 0.1 seconds, a 10 Hz controller updates every step, a 1 Hz EPS model updates every 10 steps, and a 0.1 Hz telemetry scheduler updates every 100 steps. This ensures that subsystems remain aligned in simulated time.

Deterministic scheduling is essential. The scheduler should iterate time in fixed increments with no reliance on wall-clock time. Each subsystem update should be pure (given the same inputs, it produces the same outputs). If you allow subsystems to update in an inconsistent order, you can introduce hidden nondeterminism. Therefore, define a strict update order (e.g., orbit -> attitude -> EPS -> thermal -> telemetry -> ground). Document this order and keep it stable.

Time integration also matters. Each subsystem may use its own integration method. For example, attitude dynamics might use RK4, while EPS uses Euler. That’s fine as long as each subsystem update uses the same global dt or its own dt derived from the global step. You must ensure that state updates are applied at the correct time boundaries. A common bug is applying a subsystem update based on stale inputs; for example, using yesterday’s attitude to compute today’s power generation. The solution is a clear dataflow: compute all new inputs for time t, then update subsystems, then commit new state.

Multi-rate systems can also suffer from aliasing. If one subsystem updates too slowly, it may miss fast dynamics. For instance, if ADCS runs at 10 Hz but you sample it at 1 Hz for logging, you may miss oscillations. The simulator should allow different logging rates but should compute the high-rate states internally.

Finally, simulation determinism depends on fixed seeds and stable rounding. Use fixed seeds for any stochastic inputs (e.g., sensor noise). Store results in consistent order. This ensures that tests can compare output files directly.

How this fit on projects This concept drives Section 3.2 integration requirements and Section 5.10 phases. It ties together all prior projects.

Definitions & key terms

  • Multi-rate simulation -> Coordinating subsystems with different update rates.
  • Global time step -> Base time increment for scheduler.
  • Deterministic scheduler -> Fixed update order and timing.

Mental model diagram (ASCII)

Time: t0 -> t1 -> t2 -> ...
ADCS: update every step
EPS:  update every 10 steps
TLM:  update every 100 steps

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

  1. Advance global time by dt.
  2. Update subsystems whose tick is due.
  3. Apply outputs to shared state.
  4. Log results deterministically.

Invariants: update order fixed; global time monotonic; subsystems use correct dt.

Failure modes: stale inputs, nondeterministic order, missed updates.

Minimal concrete example

for step in range(steps):
    t = step * dt
    if step % 1 == 0: adcs.update(dt)
    if step % 10 == 0: eps.update(10*dt)
    if step % 100 == 0: tlm.update(100*dt)

Common misconceptions

  • “All subsystems must run at same rate” -> Multi-rate is normal.
  • “Order doesn’t matter” -> It can change outcomes.

Check-your-understanding questions

  1. Why use a fixed global time step?
  2. What happens if subsystems update in different orders?
  3. How do you ensure determinism with stochastic inputs?

Check-your-understanding answers

  1. It guarantees consistent scheduling and reproducibility.
  2. Outputs can diverge because state dependencies differ.
  3. Fix random seeds and use consistent ordering.

Real-world applications

  • Mission simulation testbeds.
  • Hardware-in-the-loop testing environments.

Where you’ll apply it

References

  • Spacecraft Systems Engineering (systems integration)
  • Fundamentals of Software Architecture (integration patterns)

Key insights Multi-rate scheduling is the backbone of any realistic mission simulator.

Summary A deterministic scheduler synchronizes subsystems without drift.

Homework/Exercises to practice the concept

  • Choose a global dt that supports 10 Hz and 1 Hz subsystems.

Solutions to the homework/exercises

  • dt = 0.1 s supports 10 Hz and 1 Hz updates.

Subsystem Contracts and Interface Validation

Fundamentals When subsystems are integrated, mismatched units, assumptions, or timing can break the whole system. A subsystem contract defines the interface: inputs, outputs, units, update rate, and error conditions. Without contracts, integration becomes guesswork. A digital twin must enforce these contracts, checking units and ranges at runtime. This prevents subtle bugs that only appear late in the mission.

Deep Dive into the concept Subsystem contracts are formal agreements. For example, the EPS model might publish SoC in [0,1] and voltage in volts, updated at 1 Hz. The ADCS model might publish attitude quaternions at 10 Hz. The telemetry scheduler might expect SoC as a float in [0,1] but if EPS accidentally outputs percent (0-100), the scheduler will treat low SoC as high and transmit during unsafe periods. This is why contracts must include explicit units and ranges.

In a simulator, you can enforce contracts by adding validators. Each subsystem output is checked: numeric ranges, unit annotations, and timestamp freshness. If a contract is violated, the simulator should log an error and optionally halt. This makes integration bugs obvious. A simple approach is to define a schema dictionary: for each signal, specify min/max, units, and update rate. A validation layer checks each update and logs violations.

Contracts also include time semantics. For example, “attitude timestamp must be within 0.2s of current simulation time.” If a subsystem is late, other subsystems should not use its output. This prevents stale data from corrupting the simulation. You can implement this with a “data age” check and propagate a validity flag alongside each signal.

In real missions, these contracts are documented in ICDs. In the simulator, we can encode them as machine-readable schemas. This also enables automated tests: feed invalid values and ensure the simulator flags them. It’s a powerful tool for system-level validation.

How this fit on projects This concept drives Section 3.2 integration requirements and Section 6 testing, and connects to P02 mode gating and P07 scheduling.

Definitions & key terms

  • ICD -> Interface Control Document.
  • Contract -> Defined interface with units and constraints.
  • Data age -> Time since last update.

Mental model diagram (ASCII)

Subsystem Output -> Validator -> Shared State -> Other Subsystems

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

  1. Subsystem publishes output with timestamp.
  2. Validator checks units and ranges.
  3. Shared state updated with validity flag.
  4. Consumers reject stale or invalid data.

Invariants: units consistent; ranges respected; data age bounded.

Failure modes: unit mismatch, stale data use, silent contract violations.

Minimal concrete example

if not (0.0 <= soc <= 1.0): log_error("EPS_SOC_RANGE")

Common misconceptions

  • “Unit errors are obvious” -> They often look plausible.
  • “Contracts are documentation only” -> Enforce them in code.

Check-your-understanding questions

  1. Why include ranges in contracts?
  2. What happens if a subsystem publishes stale data?
  3. How can validation help integration testing?

Check-your-understanding answers

  1. To catch impossible values early.
  2. Other subsystems may make unsafe decisions.
  3. It makes violations explicit and testable.

Real-world applications

  • Integration testing of spacecraft subsystems.
  • Digital twins for mission rehearsal.

Where you’ll apply it

References

  • Spacecraft Systems Engineering (ICDs)
  • Fundamentals of Software Architecture (interfaces)

Key insights Integration failures are usually contract failures in disguise.

Summary Contracts and validation turn integration into a repeatable process.

Homework/Exercises to practice the concept

  • Define contracts for EPS SoC, ADCS attitude, and COMMS link status.

Solutions to the homework/exercises

  • SoC range [0,1], attitude quaternion norm ~1, link status boolean.

3. Project Specification

3.1 What You Will Build

A full mission simulator that runs a 24-hour scenario, integrates orbit propagation, EPS, ADCS, thermal, telemetry scheduling, and ground passes, and outputs logs and plots.

3.2 Functional Requirements

  1. Subsystem integration: orbit, EPS, ADCS, thermal, telemetry, ground passes.
  2. Multi-rate scheduler: deterministic timing across subsystems.
  3. Interface validation: enforce unit and range contracts.
  4. Mission logging: outputs for power, attitude, passes, and events.

3.3 Non-Functional Requirements

  • Determinism: fixed seeds, fixed dt, repeatable outputs.
  • Scalability: 24-hour sim in < 2 minutes.
  • Traceability: logs include timestamps and event reasons.

3.4 Example Usage / Output

$ python mission_sim.py --hours 24 --seed 42
[SIM] Started 24h run
[PASS] 12 passes scheduled
[SAFE] Entered safe mode at t=03:41 due to low SoC
[OUT] mission_log.json, power_plot.png, attitude_plot.png

3.5 Data Formats / Schemas / Protocols

Event log JSON:

{"t":13260,"event":"SAFE_MODE","reason":"LOW_SOC"}

3.6 Edge Cases

  • Unit mismatch between subsystems.
  • Telemetry backlog exceeding downlink.
  • ADCS failure causing power loss.

3.7 Real World Outcome

A full-day simulation with plots and logs that match a deterministic golden run.

3.7.1 How to Run (Copy/Paste)

python mission_sim.py --hours 24 --seed 42 --config configs/nominal.json

3.7.2 Golden Path Demo (Deterministic)

  • Use configs/nominal.json and seed 42.
  • Compare outputs to golden_mission.json and plots.

3.7.3 Failure Demo (Deterministic)

python mission_sim.py --hours 24 --config configs/low_power.json

Expected: safe mode entry and exit codes for violations.

3.7.4 If CLI: Exact Terminal Transcript

$ python mission_sim.py --hours 24 --seed 42
[SIM] Started 24h run
[PASS] 12 passes scheduled
[SAFE] Entered safe mode at t=03:41 due to low SoC
ExitCode=0

4. Solution Architecture

4.1 High-Level Design

Orbit -> Sunlight -> EPS -> ADCS -> Thermal -> Telemetry -> Ground Passes
             |                         |
             +--------- Validation ----+

4.2 Key Components

Component Responsibility Key Decisions
Scheduler Multi-rate updates Global dt
Subsystem Models EPS, ADCS, thermal Update order
Validator Unit/range checks Schema map
Logger Mission events JSON logs

4.3 Data Structures (No Full Code)

class Signal:
    value: float
    units: str
    t: float

4.4 Algorithm Overview

Key Algorithm: Simulation loop

  1. Advance time by dt.
  2. Update subsystems in fixed order.
  3. Validate outputs and log events.
  4. Produce scheduled downlink.

Complexity Analysis:

  • Time: O(steps * subsystems).
  • Space: O(steps) for logs.

5. Implementation Guide

5.1 Development Environment Setup

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

5.2 Project Structure

project-root/
+-- mission_sim.py
+-- configs/
+-- logs/
+-- README.md

5.3 The Core Question You’re Answering

“Can all subsystems work together without violating mission constraints?”

5.4 Concepts You Must Understand First

  1. Multi-rate scheduling.
  2. Subsystem interface contracts.
  3. Deterministic simulation.

5.5 Questions to Guide Your Design

  1. What is the global dt that supports all subsystems?
  2. What validation checks should halt the sim?
  3. How will you log events for ops review?

5.6 Thinking Exercise

Design a subsystem update order and justify it.

5.7 The Interview Questions They’ll Ask

  1. “How do you synchronize subsystems with different rates?”
  2. “How do you validate interfaces between models?”
  3. “How do you ensure deterministic simulation outputs?”

5.8 Hints in Layers

Hint 1: Start by integrating orbit + EPS only.

Hint 2: Add ADCS and validate sun-pointing impact on power.

Hint 3: Add telemetry scheduler and pass windows.

Hint 4: Add fault injection and safe mode transitions.

5.9 Books That Will Help

Topic Book Chapter
Systems integration Spacecraft Systems Engineering Integration chapters
Architecture Fundamentals of Software Architecture Interfaces
Simulation Law, Simulation Modeling and Analysis Discrete simulation

5.10 Implementation Phases

Phase 1: Core Scheduler (4-5 days)

Goals: deterministic time loop. Tasks: implement global dt and update order. Checkpoint: stable loop with logging.

Phase 2: Subsystem Integration (7-10 days)

Goals: integrate EPS, ADCS, thermal. Tasks: connect outputs/inputs, validate contracts. Checkpoint: cross-subsystem data flows consistent.

Phase 3: Ops Simulation (5-7 days)

Goals: add telemetry and passes. Tasks: schedule downlinks and log events. Checkpoint: pass reports generated.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
dt 0.1 / 0.5 / 1.0 s 0.1 s Supports high-rate ADCS
Validation warn / halt warn + halt on severe Balance insight and progress
Logging CSV / JSON JSON Rich structured events

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Validator unit mismatch cases
Integration Tests Full sim golden_mission.json
Edge Case Tests Fault injection low power scenario

6.2 Critical Test Cases

  1. Nominal run: no safe mode entry.
  2. Low power: safe mode entry logged.
  3. Unit mismatch: validation error logged.

6.3 Test Data

configs/nominal.json
configs/low_power.json

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Order drift inconsistent results fix update order
Unit mismatch invalid outputs enforce validation
Large dt unstable dynamics reduce dt

7.2 Debugging Strategies

  • Log intermediate signals with timestamps.
  • Replay simulations with fixed seeds.

7.3 Performance Traps

Large dt speeds simulation but can hide dynamics; balance accuracy and runtime.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a mission timeline visualization.

8.2 Intermediate Extensions

  • Support multiple satellites in the same simulator.

8.3 Advanced Extensions

  • Integrate hardware-in-the-loop with real sensors.

9. Real-World Connections

9.1 Industry Applications

  • Mission rehearsal and operations training.
  • Digital twins for satellite health monitoring.
  • Orekit for orbit dynamics.
  • cFS for flight software simulation.

9.3 Interview Relevance

  • Demonstrates systems integration and simulation design.

10. Resources

10.1 Essential Reading

  • Spacecraft Systems Engineering (integration chapters).
  • Fundamentals of Software Architecture (interfaces and contracts).

10.2 Video Resources

  • Mission simulation case studies.

10.3 Tools & Documentation

  • numpy, matplotlib.

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain multi-rate scheduling.
  • I can define subsystem interface contracts.
  • I can validate simulation determinism.

11.2 Implementation

  • Simulation outputs match golden files.
  • Fault injections trigger expected actions.
  • Logs include timestamps and reason codes.

11.3 Growth

  • I can extend the simulator to new subsystems.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Integrate orbit + EPS + ADCS with deterministic scheduler.

Full Completion:

  • Add telemetry scheduling and pass simulations with logs.

Excellence (Going Above & Beyond):

  • Add multi-satellite support and hardware-in-the-loop hooks.