Mars Satellite Architecture
Architecture study for delivering useful orbital infrastructure to Mars on a faster, cheaper timeline.
- Target window
- 2028 launch
- Architecture
- Mothership + smallsats
- Constellation
- 3 initial
- Roadmap
- 2028 – 2034
Premise
Mars is about to get a lot busier. NASA's Mars Sample Return campaign, ESA's ExoMars rover, commercial landers, and a long tail of academic smallsats are all converging on a four-year window with essentially no dedicated orbital infrastructure to support them. Telemetry today still hitches a ride on whatever happens to be overhead — MRO, MAVEN, TGO — assets engineered for science, not for relay-as-a-service.
This study takes the inverse stance: design the orbital infrastructure first, sell the services to the missions, and treat the science as the side effect. The thesis is that a small, fast, deliberately bus-agnostic program can deliver useful Mars infrastructure on a faster and cheaper timeline than the current programs of record.
Architecture
A single mothership performs the Earth → Mars transfer and hosts an areostationary relay node from a stable equatorial orbit. Three smallsats deploy after aerobraking into complementary orbits chosen for coverage, not science:
- Mothership
- Areostationary relay
- Smallsat 1
- Sun-sync imaging
- Smallsat 2
- Polar weather / dust
- Smallsat 3
- Drifter / opportunity
The study is deliberately bus-agnostic. The architecture is sized against a range of commercial mothership options rather than tied to any single provider, so the trade closes (or doesn't) on its own merits. The questions driving the work are uncomfortably simple: does the mass budget close for a four-payload Mars injection across realistic bus choices; does aerobraking shave enough Δv to make smallsat ADCS realistic on commercial buses; and does the relay arc pay back its own mass in deferred ground-station cost across a realistic customer manifest.
Current state
This is internal working-level trade-study material, not a funded program. The repository contains the executive summary, the architecture trade study, orbit + Δv + mass + power + link budgets, a Python modeling toolchain (Hohmann transfers, aerobraking, SPICE kernel integration), and a multi-mission roadmap through 2034.
The numbers close across the studied bus options. The business case clears at a defensible steady-state revenue against the aggregate investment — defensible internally, not yet against any specific customer commitment.
What's next
Two open threads. First, sharpen the customer story: identify three named missions whose mission-control cost falls measurably when relay coverage exists, and quantify the savings. Second, harden the bus-trade matrix so the architecture stays robust against whichever commercial mothership options actually become available in the launch window.
∴⎯Related work