PhD Research Themes: From Orbit Optimization to Software-Defined Space Systems

This is the companion to my PhD plan. There I described the *strategy* — the roles, the layers of abstraction, the program, and the five criteria I use to filter a theme. Here I go deep on the themes themselves: every candidate idea gets a description, the methods it pulls in, and a figure, so I can see at a glance where each one sits relative to the contribution I actually want to make.

The exploration came in three waves. It started concrete and algorithmic — \*optimize an orbit* — drifted toward a richer domain — *lunar infrastructure\* — and finally reframed itself around what fits my profile best: designing complex, autonomous, distributed systems, with space as the demanding application domain.

Wave 1 — Optimizing satellite constellations

The first instinct was optimization: mega-constellations (Starlink, Kuiper, OneWeb) create thousands of open problems, and "optimize orbits" sounds like a thesis. The key realization was that *optimizing orbits* is too broad — you have to pick a specific optimization problem, not a vague goal. These are the sub-problems I mapped, each interesting in its own right.

Autonomous debris avoidance

With thousands of satellites in orbit, new collision risks appear every day, and most avoidance maneuvers are still computed by human operators reacting one conjunction at a time. The research question is: \*how do you change an orbit minimally while preserving the mission and saving fuel?\* It's a textbook multi-objective problem — you're not optimizing one number, you're trading off several at once, and the interesting output is the whole Pareto front of acceptable maneuvers rather than a single answer. Natural methods: NSGA-II, MOEA/D, reinforcement learning for the sequential decision, and model predictive control for the close-loop maneuver.

Earth coverage optimization

A constellation must cover specific regions — the Amazon, the Atlantic, the poles — and the design question is \*which orbital configuration covers the targets with the fewest satellites?\* The decision variables are geometric (altitude, inclination, RAAN, number of orbital planes, spacing), and the objectives pull against each other: more coverage and lower latency usually mean more satellites and more cost. It's a clean, high-dimensional design problem where the geometry maps directly onto a multi-objective search.

Inter-satellite optical networks

Modern constellations link satellites with optical (laser) crosslinks, which turns the constellation into a dynamic network whose topology changes continuously as satellites move. The problem stops being pure orbital mechanics and becomes routing: minimize latency and congestion, reduce energy, and keep the network connected as links form and break. This is where graph theory, dynamic routing, and network optimization come in — and it is, not coincidentally, very close to distributed-systems thinking.

Dynamic reconfiguration after failures

Constellations are disturbed constantly — satellites fail, new ones launch, and events (disasters, conflicts) shift where coverage is needed. The question is \*how does the constellation redistribute itself to maximize coverage after a disruption?\* — ideally on its own, without waiting for a ground operator. This leans on distributed control and multi-agent coordination: each satellite decides locally, and the fleet re-optimizes globally.

AI-driven maintenance and digital twins

My favorite of the optimization group: an AI that continuously decides when to maneuver, when to avoid a collision, when to shift coverage, and when to conserve fuel — backed by a full digital twin of the constellation running thousands of simulations to choose the best action before it's committed. This is very aligned with where the industry is heading (cyber-physical systems, digital engineering), and it turns "optimization" into a closed-loop, always-on system rather than a one-shot calculation.

Beyond these, there's a long tail of related optimization problems I noted but won't detail here: month-scale maneuver planning, energy budgets to maximize constellation lifetime, launch sequencing for hundreds of satellites, space-weather-aware adaptation during solar storms, and even quantum formulations (QAOA, quantum annealing) for the combinatorial parts. The shared toolbox across all of them is deep and reusable: multi-objective evolutionary algorithms (NSGA-II, SPEA2, MOEA/D), mathematical programming (MILP, NLP), metaheuristics (GA, differential evolution, PSO, ACO), Bayesian optimization, (multi-agent / deep) reinforcement learning, model predictive control, graph theory, and operations research.

Wave 2 — Lunar mission infrastructure

The optimization framing got much more interesting once I moved the domain to the Moon. Lunar exploration is shifting from isolated missions to *permanent infrastructure* — satellites, landers, rovers, bases, and communication systems — which opens a large space of problems that are simultaneously novel and well-motivated by real programs (NASA Artemis, LunaNet, the Lunar Gateway).

Lunar communication constellation

This is the most natural problem for someone who likes optimization. The Moon has a hard constraint: roughly half of it can't see Earth at any given time, and the south pole has deep craters with no line of sight at all. The research question is \*what is the smallest constellation that provides continuous Earth ↔ lunar-orbit ↔ surface communication?\* You optimize the number of satellites, the orbit families (elliptical, polar, halo, NRHO), fuel, coverage, redundancy, and latency — a problem that blends orbital mechanics, graph theory, and multi-objective optimization.

Lunar network reconfiguration

A mature lunar presence is a highly dynamic network of bases, rovers, drones, satellites, and orbital stations. Nodes drop out constantly — a satellite fails, a rover rolls behind a mountain, a base loses power for a while. The question is \*how does the network reorganize itself automatically when a node disappears?\* This is essentially fault-tolerant networking in an environment where you can't just dispatch a technician.

Logistics of a permanent base

Once there's a permanent base, everything is scarce: energy, fuel, water, oxygen, spare parts. Distributing those resources while minimizing risk is, in essence, a supply-chain problem on the Moon — with launch windows, an orbital depot, on-surface storage, and many consumers competing for the same limited stock. It maps cleanly onto operations-research and optimization-under-uncertainty techniques.

Infrastructure placement

Where do you put antennas, repeaters, power stations, bases, and observatories? Each candidate site has to be scored against competing objectives — line-of-sight coverage, solar illumination (critical near the pole), access to water ice, safety of the terrain, and cost. It's urban planning, but lunar, and it's a facility-location problem with an unusually rich set of constraints.

Autonomous mission planning

Picture dozens of simultaneous activities — several rovers, drones, astronauts, science modules — all contending for a handful of shared resources: who gets the antenna, who gets power, who transmits data first. This is a scheduling and arbitration problem that can be optimized automatically, and it scales badly with human operators, which is exactly why it's worth automating. Beyond it lie a few more lunar problems I'll only mention: a lunar PNT / GPS (none exists operationally yet), energy management, landing-window deconfliction for multiple landers, and a digital twin of the whole infrastructure.

Wave 3 — The pivot: from algorithms to systems

Here's the turn. My real interest isn't inventing a new optimization algorithm — it's software engineering, architecture, distributed systems, modeling complex systems, and using AI as a *tool*, not an end. So instead of *"optimize this orbit,"* the central question becomes:

How do you design complex, autonomous systems for space operations — where the scientific contribution is in software and systems, and space is the application domain?

That reframing produced a set of directions that fit me far better. Nine of them, each with its own description and figure.

Reference architecture for autonomous space systems

Today, satellites, rovers, drones, stations, and bases are each built almost as separate systems, with integration handled case by case. The question is \*what should a reference architecture for distributed, autonomous, resilient space systems look like?\* — the components, their responsibilities, the protocols between them, service discovery, synchronization, fault tolerance, and governance. This is enterprise architecture applied to space, and the result is highly transferable to any large distributed system on Earth.

Distributed systems for space missions

This is the direction that overlaps most directly with my day job. Treat a mission as one big cluster: every satellite, rover, and station is a node. The question is \*how do you build distributed systems that keep working under high latency, frequent disconnections, and scarce resources?\* — consensus, leader election, replication, eventual consistency, partition tolerance, message queues, asynchronous processing, distributed workflows. It's software engineering applied to space, and almost every concept transfers back to terrestrial systems.

Software-based mission engineering

A space mission today is thousands of documents. What if it were modeled as software instead? This direction explores domain-specific languages, model-driven engineering, digital engineering, and digital twins to answer *how do you specify missions as executable models?* — models you can compile, simulate, and formally verify rather than review by hand. It connects closely to domain-driven design and modeling languages, which I already care about.

A framework for autonomous planning

Rather than developing one specific algorithm, this direction builds a platform: a mission model feeds an optimization engine, whose plans are validated in simulation, executed, monitored, and — when reality diverges — replanned. The scientific contribution is the framework and its architecture, not any single solver, which means it can host many algorithms and outlive all of them.

Multi-agent systems

Model every satellite, rover, drone, and station as an autonomous agent that negotiates with the others: who performs a task, who transmits, who collects data, who conserves energy, who helps a struggling neighbor. It's distributed AI, but it's also squarely software engineering — the interesting parts are the negotiation protocols, the coordination guarantees, and how the collective behavior stays correct even when individual agents fail.

Software engineering for space infrastructure

Think of something like Kubernetes, but for space missions: a control plane that handles deployment, discovery, health checks, remote updates, rollback, observability, telemetry, and configuration management across dozens or hundreds of autonomous assets. It sounds futuristic, but it's exactly the abstraction that becomes necessary once a "mission" is really a fleet of independently operating systems that must be managed as one.

Mission Operating System

My favorite idea, because it organizes most of the others into one layered contribution. Instead of thinking about "a satellite," think about an operating system for missions: a layer that sits above the embedded systems and coordinates resources, communication, synchronization, workflows, events, planning, AI, monitoring, and failure recovery. It is a conceptually rich abstraction that could generate a whole series of contributions on its own.

Event-driven space systems

I already build asynchronous, workflow-oriented systems (with tools like Temporal), so an event-driven mission is a shape I recognize immediately: the mission reacts to the world as a stream of events, using event sourcing, CQRS, the saga pattern, and workflow engines to stay consistent. The figure below traces a single event — a new piece of debris — as it ripples through the whole system.

Self-healing space systems

The core question here is *how does a mission keep running when parts of it fail?* It's autonomic computing in an extremely constrained environment: the system observes itself, detects a fault, diagnoses it, reconfigures around it, recovers or degrades gracefully, and learns from the episode so it handles the next one better. The loop closes with no human in the middle.

Where the themes sit — and where I want to be

Mapping the theme families on two axes makes the decision obvious. One axis is *how general* the contribution is (specific to one system vs. broadly applicable); the other is *what level* it lives at (a point algorithm vs. systems and architecture). My sweet spot is the top-right: general and systems-level.

This is why the identity I'm converging on is Software-Defined Space Systems: see a space mission as a distributed, programmable, reconfigurable platform. It lets me study reference architectures, delay- and disconnection-tolerant distributed systems, coordination and orchestration frameworks, modeling languages for missions, the integration of simulation / planning / operation, and AI for runtime decision-making — while the contribution stays in software and systems.

Crucially, none of it is trapped in the space sector. A resilient distributed architecture that operates with intermittent communication and high autonomy applies just as well to industrial networks, autonomous vehicles, robotics, IoT, defense, undersea exploration, and critical systems in general. Space is the hardest, most compelling place to *validate* the ideas — not the boundary of where they're useful.

What's next for these themes

The next step is exactly the filter from the planning note: take two or three of the strongest directions here — reference architecture, the Mission Operating System, distributed systems for missions — run each through the five criteria, do a mini systematic review of the open gaps, connect them to real problems from my job, and take the filtered shortlist to my advisor. This page will grow as that shortlist sharpens into a single research question.