Satellite Mission Digital Twin

In a spacecraft, power, thermal, attitude and communications are one system. A pointing error changes solar generation, which changes battery state of charge, which changes what the vehicle can afford to run, which changes what it can downlink. Studying any of those alone produces an answer that is wrong in exactly the situation that matters, which is the degraded one.

This system couples them and lets faults be injected into a running mission. The spacecraft, AIS-01, is fictional, does not exist, and represents no real satellite, mission or agency. Every parameter in it was invented for the demonstration.

A Python simulation engine propagates the vehicle's orbital, electrical, thermal, attitude and communications state and exposes it over REST and WebSocket. A Unity mission-control client visualises the mission and sends operator commands back. The engine is fully usable on its own without any client attached.

Orbit: position, velocity, altitude, ground track, period, orbital phase and beta angle, with conical eclipse geometry including a real penumbra rather than a hard shadow boundary.

Power: solar generation against the sun vector, battery state of charge, itemised loads, margin and time to depletion. Thermal: five nodes with warning and critical limits, and performance derating that follows from temperature rather than being applied to it.

Communications: ground station visibility, link budget, signal strength, adaptive data rate, contact windows and an on-board telemetry backlog that grows when the vehicle cannot downlink. Attitude: axis errors, body rates and control state.

Eight faults can be injected into a running mission at any moment, and their consequences propagate through the coupled subsystems as the physics dictates rather than along an authored path. Five predefined scenarios drive the vehicle through characteristic mission situations.

The vehicle carries its own autonomy: load shedding, downlink inhibit, safe-mode entry and recovery. Safe mode is entered because the state crossed a threshold, not because a timeline said so, which is the property that makes the behaviour worth watching.

The architectural rule is explicit: Python owns the simulation state and Unity is a viewer. The client computes no physics. If the engine stops, the client stops updating and says so rather than coasting on an animation.

Every displayed number originates in a state variable the simulation integrated. There are no animation curves driving the vehicle, no per-frame random values, no hard-coded timeline and no placeholder graphs. The engine carries 198 tests, and the mission event timeline is generated from observed state transitions rather than authored alongside them.

The system demonstrates a headless simulation engine with a strict client boundary, an API a third system can drive, coupled multi-physics state propagation in real time, fault injection with correct downstream propagation, and autonomous protective behaviour that emerges from state.

That boundary is the same one an industrial deployment needs. A twin that computes its state inside its visualisation cannot be integrated, tested or trusted, and cannot be driven by anything except its own interface.

Python 3.10 or newer for the engine, served over FastAPI with REST and WebSocket endpoints and covered by 198 tests. A Unity 6 mission-control client for desktop and browser. Docker Compose for the engine environment.

AIS-01 is fictional. This is not flight-certified software, it does not represent any real spacecraft or mission, and no parameter in it was taken from a real vehicle.

The physical models are mission-level rather than design-level. They are appropriate for reasoning about operational behaviour and are not a substitute for subsystem engineering analysis.

Its limitations are documented in the project's own technical limitations note rather than only here.

Demonstration. Built, runnable and published, and the clearest demonstration of the engine-and-viewer separation the platform is built around.