Constellation Design Simulation

Overview

A tool for exploring satellite constellation design tradeoffs, including altitude, number of orbital planes, satellites per plane, coverage, sunlight exposure, and orbital constraints. The goal was to make constellation architecture tradeoffs tangible: instead of hand-deriving coverage geometry for each candidate design, the simulator sweeps a parameter space and reports the tradeoffs directly.

Constellation visualizationmedia pending — diagram

Problem

Constellation design is a high-dimensional tradeoff problem. Altitude affects coverage footprint, revisit time, radiation exposure, and launch cost. The number of planes and satellites per plane affects both coverage uniformity and constellation cost. Doing this by hand, or in a spreadsheet, makes it easy to miss non-obvious interactions between parameters — for example, how a small change in inclination can disproportionately affect coverage at high latitudes.

The project needed a framework that could:

• Sweep constellation parameters (altitude, inclination, planes, sats/plane) quickly
• Compute ground coverage and revisit statistics over a simulated time window
• Account for eclipse/sunlight exposure per satellite
• Present results in a way that made tradeoffs legible, not just numerically correct

Technical Architecture

System architecturemedia pending — diagram

The simulator is split into three layers:

• Orbit propagation core (C++) — Two-body and J2-perturbed propagation of each satellite in the constellation, using Walker-pattern generation to derive initial orbital elements from high-level constellation parameters.
• Analysis layer (Python) — Ground-track and coverage computation, sunlight/eclipse determination, and revisit-time statistics, built on top of the propagated ephemeris exported from the C++ core.
• Optimization driver — A parameter-sweep and optimization layer that explores the constellation design space against a coverage/cost objective and surfaces Pareto-efficient designs rather than a single "best" answer.

The C++/Python split was deliberate: propagation is the performance-critical inner loop, while analysis and visualization benefit from Python's plotting and numerical tooling.

Implementation Details

Orbital elements for each satellite are generated from Walker constellation notation (i:T/P/F), then propagated using a J2-perturbed model to keep secular drift (nodal regression, apsidal rotation) physically consistent over the simulation window. Ground coverage is computed by discretizing the Earth's surface into a grid and, at each timestep, checking satellite-to-grid-point visibility against a minimum elevation-angle constraint.

Sunlight exposure is computed with a cylindrical shadow model to flag eclipse periods per satellite, which feeds into power-system sizing discussions even though power modeling itself was out of scope for this tool.

Challenges

The main challenge was performance: naive nested loops over satellites, time steps, and ground points scale poorly. Vectorizing the coverage computation and keeping the hot propagation loop in C++ (rather than Python) were both necessary to make full parameter sweeps interactively usable rather than an overnight batch job.

The second challenge was presentation — raw coverage numbers don't communicate tradeoffs well on their own. Framing results as comparative plots (coverage vs. altitude, coverage vs. satellite count) made the tradeoffs legible to both technical and non-technical reviewers.

Results

Coverage vs. altitude sweepmedia pending — graph

Revisit time distributionmedia pending — graph

The framework successfully reproduced expected coverage trends (e.g., diminishing coverage returns per added satellite at a fixed altitude) and made it possible to compare multiple candidate constellations side-by-side in minutes rather than days of manual analysis.

Lessons Learned

Keeping the performance-critical propagation code separate from the analysis/visualization code paid off — it made the system easier to reason about and let each layer use the right tool for the job. It also reinforced how much of "simulation work" is actually about designing legible outputs, not just correct physics.

Future Work

• Add J4 and drag perturbation terms for longer-duration simulations
• Extend the optimizer to jointly consider ground-station downlink windows
• Add inter-satellite link (ISL) feasibility analysis for mesh-networked constellations