On-Orbit Space AI: Federated, Multi-Agent, and Collaborative Algorithms for Satellite Constellations

Abstract

Satellite constellations are transforming space systems from isolated spacecraft into networked, software-defined platforms capable of on-orbit perception, decision making, and adaptation. Yet many of the existing AI studies remain centered on single-satellite inference, while constellation-scale autonomy introduces fundamentally new algorithmic requirements: learning and coordination under dynamic inter-satellite connectivity, strict SWaP-C limits, radiation-induced faults, non-IID data, concept drift, and safety-critical operational constraints. This survey consolidates the emerging field of on-orbit space AI through three complementary paradigms: (i) federated learning for cross-satellite training, personalization, and secure aggregation; (ii) multi-agent algorithms for cooperative planning, resource allocation, scheduling, formation control, and collision avoidance; and (iii) collaborative sensing and distributed inference for multi-satellite fusion, tracking, split/early-exit inference, and cross-layer co-design with constellation networking. We provide a system-level view and a taxonomy that unifies collaboration architectures, temporal mechanisms, and trust models.

1. Introduction

Satellite constellations are increasingly operated as networked, software-defined space systems rather than isolated spacecraft, enabled by platform miniaturization, inter-satellite links (ISLs), and programmable space networking and payload architectures [1,2,3,4,5]. In parallel, on-orbit/edge computing and onboard AI have moved from conceptual studies to flight demonstrations, making it practical to execute parts of the perception–analysis–action loop in orbit (e.g., cloud masking, event detection, and product prioritization) to reduce downlink volume and shorten the response cycle for time-critical applications [6,7,8,9,10,11,12]. Practical flight demonstrations already illustrate this trend at the single-spacecraft level. For example, onboard cloud screening and data prioritization have been demonstrated in orbit, while in-orbit experimentation platforms have provided a testbed for autonomous onboard software; together, these efforts motivate the next step from single-satellite intelligence toward constellation-level distributed collaboration. A brief illustration of satellite constellations (Source: Our World in Data, Jonathan’s Space Report) is illustrated in Figure 1.

Figure 1. A Brief Introduction of Satellite Constellations. (a) Satellite Constellations, (b) Global Orbital Launches Reaching Orbit (1957–2025), (c) Active Satellites in Orbit (1957–2025).

Within the broader theme of Space AI [13], these developments raise a central algorithmic question: how can multiple satellites learn, infer, and decide collaboratively under time-varying connectivity, strict SWaP-C budgets, radiation-induced faults, non-IID and drifting data streams, and safety-/security-critical operational constraints [14,15,16,17,18]? This survey focuses on on-orbit space AI, i.e., methods that treat a constellation as a distributed system for learning, inference, and autonomy. Compared with single-satellite onboard intelligence, constellation-scale methods must explicitly reason about dynamic contact graphs and intermittent/long-delay links [3,19], heterogeneous sensing/compute/energy capabilities, and stronger trust requirements: systems should be robust to benign faults and, where relevant, to adversarial or compromised participants while supporting controlled, auditable model updates [20,21].

1.1. Motivation and Scope

We consider distributed satellite systems and constellations in which each spacecraft can sense, compute, and communicate with neighboring satellites via inter-satellite links (ISLs) and/or with ground stations [3,19,22,23]. Collaboration is valuable because many core mission functions are inherently distributed: (i) coverage, tasking, and observation scheduling across many platforms [24,25]; (ii) cooperative observation, fusion, and tracking where multi-sensor or multi-view aggregation improves estimation quality and robustness [26,27,28]; and (iii) resilient networking and resource sharing where routing, contact utilization, and opportunistic coalitions determine end-to-end latency and throughput [29,30]. These capabilities are also tightly coupled with safety- and operations-critical constraints (e.g., maneuver conflicts, risk management, and supervisory autonomy), motivating coordination mechanisms that remain effective under partial observability and intermittent connectivity [31,32].

The scope of this review is algorithmic. We emphasize methods intended to run on orbit, either fully onboard or jointly with the ground segment, but with the constellation itself playing an active role in computation and coordination [12]. We organize the review around three paradigms. The first is federated learning for cross-satellite training and adaptation without centralizing raw data [16,33]. The second is multi-agent algorithms for cooperative autonomy, planning, scheduling, and resource allocation under constraints [24,34,35]. The third is collaborative sensing and distributed inference for multi-satellite fusion, tracking, and partitioned/split inference [26,28,36,37]. We do not attempt to comprehensively survey single-satellite onboard vision models, purely hardware-focused studies, or ground-only analytics, except when they directly affect the design and evaluation of distributed on-orbit algorithms [10].

1.2. Key Definitions: Federated vs. Multi-Agent vs. Collaborative

To keep terminology consistent, we use the following definitions.

Distributed on-orbit space AI refers to methods in which multiple satellites (optionally with ground nodes) jointly perform learning, inference, and/or decision-making, and where computation and communication are distributed under orbital contact graphs, DTN-like intermittency, and space operational constraints [3,19,22,32].

Federated learning (FL) refers to collaborative training or adaptation where each satellite keeps its raw data locally and exchanges model-related information (e.g., parameters, gradients, updates, or distilled knowledge). Aggregation may happen on the ground, through a hierarchical structure (e.g., cluster-head satellites), or via decentralized protocols [16,33]. In constellation settings, FL must address intermittent participation, asynchronous communication, non-IID data, and safe/secure update mechanisms (e.g., secure aggregation and robust aggregation under unreliable participants) [20].

Multi-agent algorithms model each satellite as an agent that selects actions (e.g., sensing schedules, pointing commands, routing decisions, maneuvering plans, or compute allocations) to optimize mission objectives under constraints. Cooperation can be achieved through multi-agent reinforcement learning, distributed planning, auction/market-based task allocation, or distributed control [24,25,34,38]. Communication is usually limited, delayed, and topology-dependent, so when and what to share becomes part of the algorithm design.

Collaborative sensing and distributed inference focus on sharing and fusing information for perception and estimation, and on distributing inference computation across nodes. Examples include distributed filtering and tracking, multi-view fusion, feature-level exchange, and split/early-exit inference [26,27,28,36,37]. This paradigm often requires joint design with networking and orbital edge computing because communication choices directly affect inference quality, latency, and energy [11,30].

These paradigms are not mutually exclusive. Federated learning can train perception models used by multi-agent autonomy; multi-agent coordination can determine which satellites participate in learning; and collaborative inference can be combined with federated updates to sustain performance under drift and changing contact patterns [11,32]. A brief line chart of the number of publications in the Web of Science database based on federated learning and multi-agent systems is illustrated in Figure 2. Table 1 provides a qualitative comparison of representative AI architectures for orbital space systems, highlighting their trade-offs in communication burden, inter-satellite link dependence, latency, privacy, onboard resource pressure, scalability, resilience, deployment complexity, autonomy, and current feasibility.

Figure 2. The Publication Trend of AI. (a) Federated learning. (b) Multi-agent systems.

Table 1. Qualitative Comparison of AI Architectures for Orbital Space Systems.

Property	Ground-Centric Centralized AI	Single-Satellite Onboard AI	Federated Learning	Collaborative Sensing	Distributed Inference	Multi-Agent Autonomous Constellation
Communication burden	Very high	Low	Moderate	High	Moderate	Moderate
Inter-satellite link dependence	Low	Low	Moderate	Moderate	High	High
End-to-end latency	Very high	Low	Moderate	Moderate	Low	Low
Privacy/data sovereignty	Very low	High	High	Moderate	High	High
Onboard compute & energy pressure	Low	Very high	High	Moderate	Moderate	Moderate
Scalability to large constellations	Moderate	Moderate	High	High	High	High
Fault tolerance/resilience	Low	Moderate	Moderate–High	High	High	Very high
Deployment & verification complexity	Low	Moderate	High	High	High	Very high
Autonomy level	Very low	High	Moderate	Moderate	High	Very high
Current feasibility/ maturity	Very high	High	Moderate	Moderate	Moderate	Moderate

1.3. Related Surveys & Our Positioning

A growing body of surveys has examined adjacent aspects of “AI + satellite constellations,” but often from a single-layer perspective. In satellite networking and non-terrestrial networks (NTNs), surveys largely focus on AI/ML as a tool for communications, routing, resource management, and integration with terrestrial systems [23,39,40,41,42]. In orbital/space edge computing, the emphasis is typically on system architectures and computation offloading/scheduling under time-varying connectivity [11,12,43]. A separate line of work reviews onboard AI from a device/software viewpoint (accelerators, compression, deployment constraints), mostly at the single-satellite level [44]. Finally, constellation-specific federated learning surveys concentrate on distributed training protocols under intermittent contacts and non-IID data, but do not aim to cover constellation-scale decision-making and collaborative inference as a unified algorithmic stack [16].

Table 2 summarizes representative related surveys and highlights the gap this paper addresses. In contrast to prior work, we take a constellation-as-a-distributed-system view and unify three algorithmic pillars—federated learning, multi-agent coordination, and collaborative sensing/distributed inference—under a shared taxonomy of architecture (centralized/hierarchical/decentralized), timing (synchronous/asynchronous/event-driven), and trust (benign faults to Byzantine/adversarial). This positioning is intended to make methods comparable across communities (distributed optimization, multi-agent systems, and distributed estimation/inference) and to provide evaluation guidance that reflects realistic on-orbit constraints.

Table 2. Comparison with representative related surveys. Y: explicit focus; P: partial/adjacent coverage; –: not a focus.

Survey	Year	Primary Scope	On-Orbit/Edge	FL	Multi-Agent	Collab. Inf./Fusion	Trust/Safety	Bench./Twin
Liu et al. [39]	2018	SAGIN architecture, resource mgmt., integration	P	–	–	–	P	–
Shen et al. [43]	2023	Computing tech in SAGIN (cloud/edge synergy, enabling tools)	Y	P	–	–	P	P
Mahboob & Liu [40]	2024	AI-enabled satellite-based NTN for 6G (networking-centric)	P	P	–	–	P	–
Fontanesi et al. [41]	2025	AI/ML for SATCOM (use cases, architectures, hardware notes)	P	–	–	–	P	–
Yin et al. [11] (Wu et al. [12])	2025 (2023)	Orbital edge computing: systems, offloading, scheduling	Y	P	P	P	P	P
Matthiesen et al. [16]	2024	Federated learning in satellite constellations	P	Y	–	–	P	P
Duggan et al. [44]	2025	AI-powered onboard EO image processing (deployment constraints)	Y	–	–	P	P	P
Thangavel et al. [32]	2024	Trusted autonomous satellite operations (DSS/TASO perspective)	P	–	P	P	Y	P
This survey (ours)	2026	Distributed on-orbit AI for constellations: learning + decision + inference	Y	Y	Y	Y	Y	Y

1.4. Contributions and Paper Organization

This survey makes the following contributions:

• System-oriented problem framing. We provide a constellation-centric view of distributed on-orbit AI, highlighting how orbital motion, intermittent contacts, SWaP-C limits, radiation-related faults, and safety constraints shape algorithm design.
• Unified taxonomy across learning, decision, and inference. We introduce a taxonomy and shared formulations that connect (i) distributed optimization for learning, (ii) multi-agent decision-making for coordination, and (iii) distributed inference for collaborative sensing, and we categorize methods by architecture, timing, and trust assumptions.
• Structured synthesis of three paradigms. We review representative methods in federated and privacy-preserving learning, multi-agent coordination, and collaborative sensing/distributed inference, emphasizing constellation-specific issues such as non-IID data, drift, bandwidth/energy budgets, faults, and safe update governance.
• Online Repository. To support community development and keep this review actionable over time, we continuously curate relevant papers and resources at https://github.com/ziyangwang007/AI4Space, accessed on 8 March 2026.

The remainder of this paper is organized as follows. Section 2 describes the constellation system model and presents a taxonomy of distributed on-orbit AI settings. Section 3 reviews federated and privacy-preserving learning for satellite constellations. Section 4 covers multi-agent coordination algorithms for constellation autonomy. Section 5 discusses collaborative sensing and distributed inference. Section 6 discusses the open challenges and future directions for academics and industry, and Section 7 concludes the survey.

2. System Model and Taxonomy

This section introduces a generic system model for distributed on-orbit AI in satellite constellations and then proposes a taxonomy to organize the design space. The goal is to make later algorithm sections comparable under shared assumptions about networking, onboard resources, and data properties.

2.1. Constellation Setting: Missions, Nodes, and Communication (ISLs, Dynamic Topology)

We model a constellation as a set of satellites $\mathcal{S}=\{1,\dots ,N\}$ and (optionally) a set of ground nodes $\mathcal{G}=\{1,\dots ,M\}$. Each satellite is equipped with one or more payloads (e.g., optical, SAR, infrared, GNSS, AIS, RF sensing), an onboard computing unit, local storage, and communication terminals for space-to-space and space-to-ground links. Inter-satellite links (ISLs) and scheduled space networking make the constellation topology time-dependent and operationally constrained [3,4,45].

Mission and task abstraction. Constellation operations can be viewed as selecting and executing a stream of tasks $\mathcal{T}$, such as observation requests, onboard processing, cooperative tracking, and communication/routing actions. Following the standard abstraction in satellite scheduling and mission planning, we represent each task $k\in \mathcal{T}$ by a feasible opportunity window and constraints, a resource-cost vector, and a utility value [46,47]:

$$k=\left(w_k, r_k, u_k\right),$$

(1)

where $w_k$ specifies the valid time window (and associated geometric/pointing constraints), $r_k$ summarizes the required resources (e.g., compute cycles, energy, storage, and communication volume), and $u_k$ denotes the mission utility or priority. This abstraction provides a common language for later sections on scheduling, resource allocation, and contact-aware learning/inference.

Time-varying connectivity and contact windows. ISLs induce a time-varying communication graph

$$\mathcal{G}\left(t\right)=\left(\mathcal{V}, \mathcal{E}\left(t\right)\right),\hspace{1em}\mathcal{V}=\mathcal{S}\cup \mathcal{G},$$

(2)

where an edge $(i,j)\in \mathcal{E}\left(t\right)$ exists when a communication opportunity is available between nodes i and j at time t (line-of-sight, pointing constraints, link scheduling). For an active link, we characterize its time-dependent capacity $B_{ij}\left(t\right)$, latency $D_{ij}\left(t\right)$, and reliability $P_{ij}\left(t\right)$; these vary across RF/optical ISLs and relay/direct-to-ground modes [3,45].

In many constellations, connectivity is intermittent and naturally modeled via a delay-/disruption-tolerant networking (DTN) perspective, where routing and aggregation are planned around contact windows rather than assuming persistent end-to-end paths [19,48]. A common operational abstraction is a contact plan (or contact schedule),

$$\mathcal{C}=\left\{\left(i,j,t^{\mathrm{start}},t^{\mathrm{end}},B_{ij},D_{ij}\right)\right\},$$

(3)

which encodes predictable communication opportunities and enables contact-graph based routing and collaboration scheduling [49,50,51]. This same contact-plan abstraction is also useful for designing contact-aware learning rounds, hierarchical aggregation, and cooperative inference pipelines in later sections.

Constellation geometry and communication patterns. Constellation geometry also affects the communication strategy. In Walker-Delta constellations, orbital planes are distributed across 360°, whereas Walker-Star constellations distribute planes across 180°; as a result, inter-plane connectivity patterns and handover behavior differ between the two. In near-polar Walker-Star systems, cross-seam inter-plane links may connect satellites moving in opposite directions, which increases relative velocity and Doppler and makes persistent inter-plane communication more challenging.

Onboard compute, energy, and storage constraints. Each satellite i operates under time-varying budgets of compute $C_i\left(t\right)$, energy $E_i\left(t\right)$, and storage $S_i\left(t\right)$, shaped by duty cycling, thermal constraints, payload operations, and link schedules. These constraints directly influence what can be trained or inferred onboard, how often models can be updated, and what intermediate information can be shared [10,11].

Where collaboration happens. Depending on mission design and governance, collaboration may be primarily (i) space-to-ground (ground-coordinated learning/planning), (ii) space-to-space (ISL-enabled peer/cluster cooperation with limited ground contact), or (iii) hybrid (local autonomy with periodic ground synchronization/validation). The remainder of this survey uses the above graph-and-contact view to compare algorithmic assumptions and feasibility under intermittent connectivity.

2.2. On-Orbit Constraints and Data Properties (SWaP-C, Radiation, Non-IID, Drift)

Distributed AI in orbit is governed by coupled constraints across computation, communication, reliability, operations, and data—many of which are weaker or absent in terrestrial settings.

SWaP-C limits and communication cost. Satellites operate under strict size, weight, power, and cost (SWaP-C) budgets that bound compute throughput, memory, and available energy, and impose strong thermal and duty-cycle constraints on sustained onboard workloads [10,44,52,53]. Communication is similarly expensive and often availability-limited: downlink/ISL sessions are time-windowed, and transmission can incur non-trivial power draw during high-rate engagements, which motivates selective sharing (e.g., compact features or model deltas rather than raw data) and event-driven messaging [11,54].

Intermittent connectivity and long-delay networking. Unlike stable terrestrial networks, constellation connectivity is dictated by orbital dynamics and link scheduling, yielding time-varying topologies, long/variable delays, and frequent partitions. Many constellations are therefore well described by delay-/disruption-tolerant networking (DTN) abstractions, where routing and coordination must tolerate intermittent contacts and partial participation [19,45,48,50]. Practically, this pushes distributed learning and coordination toward asynchronous, contact-aware protocols that explicitly handle staleness and missing updates.

Radiation-induced faults and unreliable computation. The space environment introduces radiation-induced faults (e.g., single-event upsets and latchup-related anomalies) that may manifest as bit flips, crashes, and silent data corruption, even when the network is functioning normally [15,55,56,57]. As a result, distributed methods must be robust not only to communication loss but also to transient compute/memory faults and intermittent node resets, motivating update sanity checks, redundancy, and conservative fusion/aggregation.

Safety-critical operations and update governance. Many constellation decisions are safety- and operations-critical, including collision avoidance, maneuver planning, and actions that affect attitude control, power budgets, and mission safety envelopes. Learning-enabled autonomy must respect hard constraints, support runtime monitoring and conservative fallbacks, and treat model updates as governed, auditable artifacts (e.g., staged rollout and rollback) rather than unconstrained online adaptation [32,58,59]. In other words, radiation-induced faults mean that abnormal outputs cannot be treated as ordinary statistical noise alone. They must instead be anticipated as a system-design constraint, motivating redundancy, sanity checks, robust aggregation or fusion, and conservative update admission throughout the learning and inference pipeline.

Non-IID and drifting data streams. Data collected by different satellites are typically non-identically distributed due to orbit geometry (latitude coverage, local time), payload diversity and calibration, operational modes, and regional weather/illumination patterns; distributions also evolve over time. Let ${\mathcal{D}}_i\left(t\right)$ denote the local data stream at satellite i with underlying distribution $p_i(x,y,t)$. Constellations commonly exhibit both cross-satellite heterogeneity and temporal drift:

$$\forall i\ne j: p_i(x,y,t)\ne p_j(x,y,t),\hspace{1em}\mathrm{and}\hspace{1em}\exists t\ne t^{\prime }: p_i(x,y,t)\ne p_i(x,y,t^{\prime }).$$

(4)

These properties affect convergence, aggregation bias, and fairness, and motivate personalization and heterogeneity-aware objectives in federated and distributed learning [16,60]. More broadly, the resulting concept drift and domain shift in high-dimensional imagery streams motivate continual adaptation and drift-aware evaluation protocols [18]. Table 3 summarizes how major on-orbit constraints, including SWaP-C limits, intermittent connectivity, bandwidth restrictions, radiation-induced faults, safety-critical operations, non-IID data, and concept drift, translate into corresponding algorithmic design levers and practical evaluation signals.

Table 3. Mapping from on-orbit constraints to algorithmic design levers and evaluation signals.

Constraint	Algorithmic Implications	Typical Design Levers	Evaluation Signals
SWaP-C (compute/energy/ memory) [10,11]	Limits model size, training frequency, and allowable on-orbit optimization; training competes with payload ops and comm sessions	Lightweight updates (adapters/heads), mixed precision, early-exit, split inference, sparse/quantized updates	Energy (J/orbit), FLOPs, memory, latency, duty cycle
Intermittent connectivity/long delay [45,48]	No persistent end-to-end paths; partial participation; stale information	Async protocols, staleness-aware weighting, contact-plan scheduling, DTN-aware routing/aggregation	Staleness, participation rate, time-to-update, timeliness
Limited bandwidth/short contact windows [11,48]	Update payload size dominates feasibility; large models hard to synchronize	Quantization/sparsification, low-rank deltas, distillation/logits, feature/tracklet sharing	Bytes/contact, throughput, accuracy-vs-bytes curve
Radiation-induced faults/ SDC [15,55,56,57]	Corrupted updates/messages; node resets; unreliable compute	Sanity checks, redundancy, robust aggregation/fusion, conservative filters (e.g., CI)	Fault-injection robustness, recovery time, consistency
Safety-critical operations [32,61]	Hard constraints must never be violated; updates must be governed	Safety filters/RTA, staged rollout/rollback, audit logs, conservative fallbacks	Constraint violations, intervention rate, rollback triggers
Non-IID across satellites [16,60]	Global model bias; slower convergence; fairness issues	Personalization, clustering, heterogeneity-aware objectives (FedProx/SCAFFOLD/FedNova)	Per-node accuracy, fairness, convergence speed
Concept drift over time [18]	Model aging/regression; delayed labels	Drift-aware evaluation, periodic re-sync, controlled continual learning + validation gates	Accuracy over time, drift detection delay, stability

2.3. Taxonomy of Distributed On-Orbit AI (Architectures, Timing, Trust)

To compare methods across federated learning, multi-agent coordination, and collaborative sensing/inference, we organize distributed on-orbit AI along three primary dimensions: collaboration architecture, timing mechanism, and trust model. For practical feasibility comparisons, we also track what is shared (data/features/models/decisions), since message semantics and size often dominate SWaP-C and contact-window budgets.

A compact summary is provided in Table 4. In brief, collaboration architecture describes where orchestration/aggregation happens: centralized (typically ground-orchestrated), hierarchical (e.g., cluster-head satellites or multi-tier aggregators), and decentralized (peer-to-peer consensus/gossip), often in hybrid combinations [16,62,63]. Timing mechanisms capture how updates are triggered under intermittent contacts: synchronous rounds (simple but fragile), asynchronous updates (staleness-aware), event-triggered communication/coordination (uncertainty- or value-driven), and orbit-periodic schedules aligned with predictable contact patterns [33,64,65]. Trust models distinguish benign unreliability from adversarial behavior, ranging from benign faults to honest-but-curious participants (privacy threats) and Byzantine/compromised nodes (poisoning or misinformation), which motivates secure and robust aggregation/fusion [20,21].

Table 4. Taxonomy for distributed on-orbit AI in satellite constellations.

Dimension	Categories	Implications for Design and Evaluation
Architecture	Centralized; Hierarchical; Decentralized (often hybrid)	Determines orchestration/aggregation points, failure modes, governance, and communication hotspots; affects latency and resilience under ground outages [16,62,63].
Timing	Synchronous; Asynchronous; Event-triggered; Orbit-periodic	Controls tolerance to intermittency and staleness; enables contact-aware scheduling (orbit-periodic) and value-driven messaging (event-triggered) [33,64,65].
Trust	Benign faults; Honest-but-curious; Byzantine/compromised	Dictates whether privacy-preserving and robust aggregation/fusion are required; impacts update validation, authentication, and anomaly filtering [20,21].
What is shared	Raw data; Features/statistics; Model updates; Decisions/intents	Directly determines message size and feasibility under SWaP-C/contact windows; links to split/early-exit inference, distributed tracking, and coordination messaging [28,35,36,37].

2.4. Practical Communication Constraints for On-Orbit Collaboration

A defining difference between terrestrial distributed AI and constellation-scale on-orbit collaboration is that communication cannot be treated as a transparent background service. In satellite constellations, latency, bandwidth, and connectivity are all strongly shaped by orbital motion, scheduled contacts, and link switching, so communication becomes a first-order algorithmic constraint rather than merely an implementation detail [4,30,45,48]. In practice, this means that the performance of federated learning, multi-agent coordination, and collaborative sensing is often limited less by nominal model quality than by when information can be exchanged, how much can be exchanged, and how stale that information becomes before it is used.

Latency and staleness. Even when communication is available, propagation delay, queueing, store-and-forward routing, and deferred contact opportunities can make shared information stale by the time it is consumed. In federated learning, this appears as stale model updates and delayed aggregation, which can slow convergence or bias the global model toward recently connected participants [66,67,68,69]. In multi-agent coordination, delayed messages can cause inconsistent local beliefs, outdated task allocations, and conflicting actions, especially when satellites coordinate under rapidly changing mission contexts or time-critical events [45,65]. In collaborative inference and tracking, latency reduces the value of exchanged features, tracklets, or state estimates because the underlying scene or network state may already have evolved by the time those messages arrive [11,30,48]. As a result, practical algorithms must explicitly account for staleness, for example through asynchronous updates, confidence decay, bounded-delay fusion, or value-aware message selection.

Bandwidth limitations and message design. Bandwidth in on-orbit networks is scarce, time-varying, and mission-dependent. Short contact windows and competing demands from payload downlink, control traffic, and crosslink exchange make it infeasible to share large models, raw imagery, or dense intermediate tensors at high frequency [11,45,48]. This has direct implications for algorithm design. Federated learning is pushed toward compressed or structured updates, sparse communication, partial model sharing, or split/federated hybrids [64,69]. Multi-agent coordination must often communicate compact intents, bids, or summarized states rather than rich internal representations [35,65]. Collaborative sensing and distributed inference likewise benefit from tracklets, embeddings, early-exit decisions, or uncertainty summaries instead of raw measurements, since the latter quickly exceed realistic contact budgets [36,37,70]. In this sense, message semantics matter as much as message size: the most useful shared artifact is often not the most detailed one, but the one that delivers the highest mission value per transmitted bit.

Intermittent connectivity and partial participation. Unlike terrestrial distributed systems, constellations cannot assume persistent end-to-end connectivity. The DTN literature explicitly models such environments as occasionally connected, frequently partitioned, and dependent on scheduled or opportunistic contacts [48,71,72]. For collaborative algorithms, this means that participation is inherently partial and topology-dependent. In FL, only a subset of satellites may contribute updates during a given synchronization opportunity, making partial participation and contact-aware scheduling unavoidable rather than exceptional [66,69]. In multi-agent settings, communication graphs may fragment into local neighborhoods, so coordination policies must remain effective under missing messages and changing adjacency relations [30,45]. In collaborative inference, intermittent connectivity limits the number of consensus rounds, fusion opportunities, or offloading choices available within a useful time horizon [11,70]. Consequently, algorithms that rely on frequent global synchronization or stable all-to-all communication are often mismatched to realistic on-orbit conditions.

Implications for practical algorithm design. These constraints suggest several design principles that recur across the three paradigms studied in this survey. First, asynchrony is usually more realistic than strict synchrony, because waiting for all nodes to participate often wastes scarce contacts and increases staleness [67,68]. Second, locality-aware collaboration is often preferable to constellation-wide coordination, since neighborhood- or cluster-level exchange better matches dynamic ISL topologies and bounded message budgets [11,30]. Third, event-driven communication is often more effective than periodic communication, because it transmits only when the expected utility of sharing exceeds the communication cost [36,65]. Fourth, graceful degradation is essential: algorithms should continue to operate safely under missing, delayed, or low-confidence communication rather than assuming ideal connectivity.

Overall, latency, bandwidth limits, and intermittent connectivity are not peripheral engineering concerns; they shape the feasible design space of distributed on-orbit AI. Any collaborative method that ignores these factors risks overestimating achievable performance and underestimating operational complexity. For this reason, the following sections discuss federated learning, multi-agent coordination, and collaborative inference not only as algorithmic paradigms, but also as communication-constrained processes whose practical success depends on contact-aware, bandwidth-aware, and delay-tolerant design.

3. Federated Learning for On-Orbit Intelligence

Federated learning (FL) enables multiple satellites to collaboratively train or adapt models while keeping raw data onboard [33,60]. In satellite constellations, FL is particularly attractive when downlink capacity is limited, when raw sensing data are sensitive, or when onboard models must adapt to changing conditions (illumination, seasons, sensor aging, evolving targets) without relying on continuous ground connectivity [16,66,69]. Compared with terrestrial FL, on-orbit FL is shaped by intermittent contacts and time-varying topology, heterogeneous compute/energy budgets, and stricter operational requirements for safety, validation, and update governance [32,66]. Table 5 provides a systematic overview of representative federated learning methods for on-orbit intelligence in satellite constellations, comparing them in terms of architecture, timing, main on-orbit focus, trust or privacy assumptions, and the model-related information exchanged.

Table 5. Systematic overview of FL for on-orbit intelligence in satellite constellations. The table maps representative constellation-oriented FL works to the taxonomy dimensions (architecture/timing/trust) and highlights the primary on-orbit constraints addressed.

Work	Arch.	Timing	Main On-Orbit Focus	Trust/Privacy Model	Shared Artifact
Ground-assisted FL [66]	Centralized (GS)	Async (staleness-aware)	Designs an asynchronous procedure based on FedAvg to cope with sporadic satellite–GS visibility and heterogeneous system conditions; improves convergence under partial participation.	Benign faults/intermittency (no explicit adversary model).	Model updates/deltas
Energy-aware scheduling for satellite FL [73]	Centralized/ Hybrid	Orbit-/schedule-aware	Schedules local computation time to minimize battery usage (e.g., eclipse periods) while preserving convergence speed; targets long mission lifetime and SWaP-C constraints.	Benign (resource reliability and aging).	Model updates (standard FL payload)
FedSN [69]	Centralized (GS)	Pseudo-sync (staleness compensation)	Addresses three LEO-specific bottlenecks: heterogeneous compute/memory, limited uplink rate, and model staleness; uses sub-structure scheme for heterogeneous local training and pseudo-synchronous aggregation.	Benign (system heterogeneity/staleness).	Structured/partial model updates
FedLEO [74]	Decentralized (ISL/P2P)	Async/contact-driven	Offloading-assisted decentralized FL to mitigate central-server bottlenecks; targets straggler effects and statistical heterogeneity under LEO topology and intermittent contacts.	Benign (no explicit adversary).	Neighbor model mixing + local updates
HiSatFL [62]	Hierarchical	Contact-/cluster-aware	Hierarchical FL tailored to dynamic satellite networks; emphasizes cross-domain adaptation and privacy-preserving collaboration under resource constraints.	Privacy-preserving (honest-but-curious assumptions are typical).	Privacy-protected model updates
RAFL [75]	Hierarchical	Contact-aware (reduces GS interaction)	Uses aerial networking + hierarchical aggregation to reduce satellite–GS communication; introduces self-adaptive reputation evaluation for leader selection and robustness; improves convergence and resists poisoning.	Byzantine/compromised nodes considered (poisoning defense via reputation).	Aggregated regional updates + global update
FedSecure (decentralized key generation + on-orbit aggregation) [76]	Hybrid (on-orbit forwarding/aggregation + GS)	Orbit-periodic/ async bridging	Reduces convergence delay by partial global aggregation per orbit; protects against insecure channels via decentralized key generation and functional-encryption-based privacy.	Honest-but-curious + eavesdroppers (privacy/integrity threats).	Encrypted/secure model updates
SFL-LEO (split + federated) [64]	Hybrid (Sat–GS split + FL aggregation)	Async local training during disconnection	Combines split learning with FL to accommodate constrained onboard compute and high dynamics; enables local training while disconnected; aggregates client-side sub-models at GS.	Benign (resource constraints/intermittency).	Client-side sub-model parameters

3.1. Topologies and Protocols (Ground-Aggregated, Hierarchical, Decentralized)

Basic formulation. Let satellite i maintain a local dataset/stream ${\mathcal{D}}_i$ and a local objective $F_i\left(\theta \right)$ over model parameters $\theta$. A standard global objective is

$$\underset{\theta }{\min } F\left(\theta \right)=\sum _{i=1}^N{w}_i{F}_i\left(\theta \right),\hspace{1em}\mathrm{where} w_i\ge 0, \sum _{i=1}^N{w}_i=1,$$

(5)

with $w_i$ typically proportional to local data volume and optionally reflecting sensing quality or mission priority [33,60]. Satellites perform local training and exchange model-related information (parameters, gradients, deltas, or distilled predictions), while the central design choice is where aggregation/coordination happens and how updates propagate under a dynamic contact graph.

Ground-aggregated FL. A ground station (or ground cloud) acts as the aggregator: it distributes a reference model, satellites train locally, and updates are uploaded during downlink windows; the ground then aggregates the received updates and releases the next model version. This topology naturally supports centralized governance and validation, and is widely adopted in satellite FL studies to accommodate limited onboard resources [16,66]. Its limitations are long update latency, restricted contact windows, downlink bottlenecks, and persistent partial participation (only satellites with timely contacts contribute to a given cycle), which can amplify staleness and bias [66,69].

Hierarchical FL. Hierarchical FL introduces intermediate aggregators (e.g., cluster-head satellites or region leaders). Satellites first aggregate within local groups via ISLs, then forward summarized updates upward (to a higher-tier satellite or the ground), reducing downlink load and exploiting more frequent ISL opportunities [62,75]. Hierarchical designs are particularly relevant when satellite–ground visibility is sparse and when leader selection and trust must be managed explicitly [75]. Key trade-offs include additional compute/energy burden at leaders, sensitivity to leader failures, and the need for robust/secure intra-cluster aggregation.

Decentralized FL. Decentralized FL removes the assumption of an always-available central aggregator. Each satellite maintains a local model ${\theta }_i$ and exchanges information with neighbors when contacts occur, often through consensus/gossip mixing combined with local SGD [63,74]. One common abstraction is a “mix-then-train” update:

$${\tilde{\theta }}_i^{\left(t\right)}=\sum _{j\in {\mathcal{N}}_i\left(t\right)\cup \left\{i\right\}}{a}_{ij}\left(t\right) {\theta }_j^{\left(t\right)},\hspace{1em} {\theta }_i^{(t+1)}={\tilde{\theta }}_i^{\left(t\right)}-\eta g_i\left({\tilde{\theta }}_i^{\left(t\right)}\right),$$

(6)

where ${\mathcal{N}}_i\left(t\right)$ is the set of neighbors reachable at time t, $a_{ij}\left(t\right)$ are mixing weights (row-stochastic over the available neighborhood), and $g_i(·)$ denotes a stochastic gradient computed from ${\mathcal{D}}_i$ [63]. Decentralized FL can improve resilience when ground contact is sparse, and has been explored for LEO settings with computation/communication offloading and dynamic topology [74]. However, it is more sensitive to topology changes, staleness, and trust assumptions, and typically requires additional mechanisms for stability and quality control.

What to transmit. On-orbit FL rarely transmits raw data; the communication budget often motivates exchanging compact model information: parameter differences, low-rank/structured updates, quantized or sparsified updates, and (in some cases) distilled predictions such as logits on shared proxy inputs [77,78,79,80,81,82,83]. These choices trade accuracy and convergence against bandwidth/energy, and interact with intermittency because short contact windows favor small, quickly verifiable payloads.

Hybrid and split protocols. Many constellation designs are hybrid: satellites may aggregate locally via ISLs most of the time, while the ground periodically synchronizes, validates, and authorizes releases [66,75]. Another increasingly relevant pattern is to combine FL with model splitting or on-orbit forwarding/partial aggregation to cope with constrained satellite compute and sporadic satellite–ground connectivity [64,76].

3.2. Intermittency and Efficiency (Asynchrony, Partial Participation, Compression/Scheduling)

Asynchrony and stale updates. Strictly synchronous rounds are difficult in constellations because contact opportunities are intermittent and topology changes with orbital motion. Asynchronous FL allows satellites to send updates whenever contacts occur, while the coordinator incorporates updates upon arrival, typically with staleness-aware weighting or bounded-delay rules [66,67]. Buffered asynchronous aggregation (e.g., aggregating a buffer of K updates before a server step) can reduce straggler sensitivity while remaining compatible with privacy primitives such as secure aggregation [68]. In satellite settings, pseudo-synchronous or staleness-compensated aggregation has been proposed to better match periodic visibility patterns and mitigate stale contributions [69].

Partial participation and participant selection. Only a subset of satellites can participate in any interval due to contact availability, duty cycling, and resource constraints. Participant selection can be treated as a constrained optimization problem balancing utility, timeliness, and resource cost. Terrestrial FL has developed resource-aware selection strategies (e.g., FedCS) and utility-aware selection (e.g., Oort), which are conceptually aligned with contact- and energy-limited satellite participation [84,85]. In constellations, selection policies should additionally incorporate predicted contact windows, remaining energy, compute load, and mission priority, and should avoid systematic bias across orbital planes/shells over long time horizons [69,73].

Communication reduction. Communication is often the dominant bottleneck. Classic techniques include structured/sketched updates, quantization, sparsification (e.g., top-k), and error feedback [77,79,80]. FL-specific schemes such as periodic averaging with quantization (FedPAQ) formalize the computation–communication trade-off [78]. In highly non-IID regimes, compression must be designed carefully because aggressive sparsification/quantization can amplify client drift; FL-tailored compression such as STC explicitly targets non-IID + partial participation regimes [81].

Scheduling with contact plans. Orbital dynamics and network schedules provide predictable contact windows. FL can exploit this structure by aligning aggregation opportunities with expected satellite–ground/ISL contacts, allocating more local computation when the next contact is far, and reducing compute load near imminent synchronization [64,66]. Energy-aware schedulers further highlight that “when to train” can be as important as “how to aggregate” for long mission lifetimes [73].

Energy- and compute-aware training. Training competes with payload operations, attitude control, routing, and housekeeping. Practical designs adapt local training frequency, batch size, and precision to available power and compute, and may restrict training to designated duty-cycle windows [69,73]. Model structuring (e.g., updating only small adapters/heads) can also reduce both compute and communication while lowering operational risk.

Local sanity checks before upload. Before transmitting updates, satellites can apply lightweight checks to reduce the probability of propagating corrupted or unstable updates (e.g., norm clipping, divergence detection, simple statistical consistency tests). These checks complement robust aggregation methods designed to tolerate abnormal or adversarial updates [21,86].

3.3. Robustness, Security, and Safe Updates (Non-IID, Poisoning, Rollback/Governance)

Non-IID data and heterogeneity. Cross-satellite data heterogeneity can slow convergence and bias global models. Beyond FedAvg [33], widely used heterogeneity mitigation approaches include proximal regularization (FedProx), variance reduction against client drift (SCAFFOLD), and normalization to correct objective inconsistency (FedNova) [87,88,89]. Personalization is often more appropriate than a single global model in constellations with persistent domain differences; representative strategies include global-base + local-head (FedPer), bilevel personalization (pFedMe), and personalization for fairness/robustness (Ditto) [90,91,92]. Constellation-focused surveys and systems similarly emphasize that non-IID and system heterogeneity are first-order design constraints for satellite FL [16,69].

Concept drift and continual adaptation. On-orbit data streams exhibit drift due to seasonality, illumination changes, sensor aging, and evolving targets, often with sparse or delayed labels. This motivates drift-aware evaluation, periodic re-synchronization, and controlled continual learning, but with stronger validation gates for safety-critical tasks [18,32].

Robustness to faults and unreliable participants. Radiation-induced transient faults and compute/memory errors can surface as abnormal or inconsistent updates. Robust aggregation rules (e.g., Krum/trimmed-mean/median families) and consistency filtering help even under benign faults, and become essential under stronger threat models [15,21,86]. Satellite-focused designs also incorporate leader selection/reputation mechanisms to mitigate unreliable or compromised participants in hierarchical settings [75].

Threats and poisoning. If a satellite is compromised, it may attempt model poisoning or backdoor insertion. Model replacement style backdoors demonstrate that a single malicious participant can implant hidden behaviors while maintaining apparent task accuracy, underscoring the need for explicit threat modeling and robust defenses [21,86,93].

Privacy and confidentiality. Although raw data are not shared, model updates can leak information. Secure aggregation hides individual updates from the aggregator, while differential privacy bounds information leakage at the cost of accuracy and additional compute/communication overhead [20,94]. In satellite networks, privacy/security concerns also include eavesdropping over insecure links and curious relays, motivating cryptography-assisted designs and on-orbit aggregation variants [76]. In practice, secure on-orbit FL requires confidentiality and integrity to be handled jointly rather than separately. Protecting update contents through secure aggregation or cryptographic mechanisms is insufficient unless paired with integrity checks, robust aggregation, authenticated model versions, and rollback-capable release governance.

Safe deployment, versioning, and rollback. In-orbit model updates should be treated as controlled, signed, and versioned artifacts. A practical approach is staged rollout (pilot satellites first), telemetry-based monitoring, and automatic rollback to a known-safe baseline upon detected regressions [32]. These mechanisms are critical for maintaining mission safety envelopes when models adapt under non-IID drift and intermittent connectivity.

Operational integration. Finally, on-orbit FL must fit within mission operations: coordinating training with payload schedules and network policies, logging for auditing/debugging, and explicitly defining when adaptation is permitted (and when it is prohibited). In practice, these operational constraints often determine feasibility and the acceptable aggressiveness of in-orbit adaptation [32,66].

Table 6 summarizes the major technical challenges in on-orbit federated learning, together with representative solution families and their satellite-oriented adaptations, including mechanisms for handling intermittency, communication bottlenecks, system and statistical heterogeneity, personalization, robustness, privacy, and poisoning resilience.

Table 6. Technique-level index for on-orbit federated learning: challenges, representative methods, and satellite-oriented adaptations.

Challenge	Representative Techniques	Satellite-Oriented Instantiation	Key Refs.
Intermittency/staleness	Async FL; buffered async; staleness-aware weighting	Contact-driven uploads; pseudo-synchrony aligned with visibility; bounded-delay update admission	[66,67,68,69]
Communication bottleneck	Quantization; sparsification; periodic averaging + quantization; non-IID-aware compression	Transmit deltas/partial modules; quick-to-verify payloads for short windows	[77,78,79,80,81]
System heterogeneity (compute/memory)	Partial/structured training; split/federated hybrids	Train client-side sub-models; aggregate only trainable subsets; match onboard capability	[64,69]
Statistical heterogeneity (non-IID)	Proximal regularization; control variates; normalized aggregation	Stabilize local drift when long gaps exist; improve fairness across orbital planes/domains	[87,88,89]
Personalization	Global-base + local layers; bilevel personalization; robust personalization	Per-orbit/plane local specialization with safe baselines and limited adaptation scope	[90,91,92]
Robustness to faulty/Byzantine updates	Byzantine-robust aggregation; outlier filtering	Fault-induced abnormal updates treated similarly to malicious outliers; hierarchical reputation	[21,75,86]
Privacy/confidentiality	Secure aggregation; differential privacy; crypto-assisted designs	Secure on-orbit aggregation/forwarding under insecure channels; privacy-budget-aware scheduling	[20,76,94]
Poisoning/backdoors	Threat modeling; robust aggregation; governance	Staged rollout + telemetry + rollback; reputation/attestation where feasible	[21,32,93]

4. Multi-Agent Coordination for Constellation Autonomy

Multi-agent coordination treats each satellite as an autonomous decision-maker that acts under local constraints while contributing to constellation-level objectives. Relative to single-spacecraft autonomy, constellations introduce strong coupling through shared resources (coverage, downlink, spectrum, compute, and power), time-varying communication graphs, and system-level safety requirements (e.g., collision avoidance and coordinated maneuvering) [32,95,96]. These properties naturally induce decentralized decision-making under partial observability and intermittent communication, where both the content and timing of information exchange become part of the control policy [45,48]. Accordingly, coordination methods must address non-stationarity, heterogeneous capabilities, delayed and missing messages, and the need for robust long-term operation over multi-year mission lifetimes [34,38]. The transition from single-satellite AI to constellation-scale multi-agent autonomy is not merely a matter of scaling up node count. It introduces distributed partial observability, coupled decision spaces, dynamic communication graphs, and safety-critical interdependence among satellites, all of which fundamentally reshape the algorithm design problem.

4.1. Core Tasks (Coverage, Scheduling, Formation, Collision Avoidance)

Coverage and persistent monitoring. A central objective is to maximize spatiotemporal coverage and revisit performance for regions of interest under viewing geometry, duty-cycle limits, and energy constraints. In Earth observation and related missions, coverage objectives are typically realized through time-windowed opportunities and priority changes (e.g., disaster response), making coordination necessary to reduce redundant sensing and avoid missed opportunities across orbital planes [46,47].

Tasking and observation scheduling. Constellation scheduling assigns observation tasks to satellites and selects sensing modes, pointing commands, and time allocations subject to slew limits, storage, and downlink constraints. This remains a core operations problem with many variants (imaging and communication tasks; uncertainty; multiple objectives), and is tightly coupled to onboard processing and product delivery latency [46,47]. Decentralized or auction-based scheduling is especially relevant when operators seek scalable, interpretable coordination under intermittent connectivity [24,35].

Resource allocation and network-aware coordination. Autonomous constellations must allocate shared resources such as ISL time, downlink windows, onboard compute slots, and power. Network-aware coordination further includes routing and store-and-forward decisions in DTN-like settings, and value-aware prioritization of which products to transmit when contacts appear [45,48,50]. These decisions become more complex under heterogeneous payloads and roles, and are increasingly studied in the context of large LEO networks and scalable contact-aware planning [30].

Formation flying and reconfiguration. For missions involving distributed apertures or coordinated sensing geometry, satellites must maintain relative configurations and may need to reconfigure or retask under fuel and safety constraints. Formation flying introduces coupled dynamics, relative navigation uncertainty, and communication delays, motivating distributed control and consensus-style coordination [97,98,99,100].

Collision avoidance and risk management. Collision avoidance (COLA) is safety-critical and increasingly central as the orbital environment becomes more congested. At constellation scale, maneuvers affect coverage, scheduling, and network topology, and coordination can be required to avoid conflicting maneuvers and to manage risk under uncertain conjunction data and delayed updates [61,101,102]. Recent studies also highlight the need for operationally viable decision-planning and coordination protocols for autonomous mitigation [58,59].

4.2. Algorithms (MARL, Distributed Planning/Allocation)

Formal decision models and CTDE. Many coordination problems can be formalized as decentralized decision-making under partial observability (e.g., Dec-POMDP-style settings), where each satellite observes locally and must act with limited communication [95]. In practice, multi-agent reinforcement learning (MARL) is frequently adopted when environment models are incomplete and objectives are long-horizon. A common paradigm is centralized training with decentralized execution (CTDE), enabling the use of global information and simulation during training while restricting policies to local observations (and limited messages) at runtime [34,38]. Representative CTDE families include actor–critic methods (e.g., MADDPG; COMA) and value decomposition/value factorization (e.g., VDN; QMIX) [103,104,105,106]. For constellation settings with a variable neighborhood structure, graph-based policy representations are a natural choice to generalize across changing connectivity [107].

Communication-aware coordination. Because communication is constrained and intermittent, coordination policies must account for delays, packet loss, and topology changes. A substantial amount of the MARL literature treats communication as a learnable component—deciding what to communicate, to whom, and when. Representative mechanisms include continuous message passing (CommNet), differentiable inter-agent learning (DIAL), gating/when-to-communicate models (IC3Net), targeted communication (TarMAC), and graph-attention scheduling of communication edges (MAGIC) [108,109,110,111,112]. Event-triggered communication policies provide an additional lens that aligns well with contact- and bandwidth-limited satellite settings [65]. When links are unavailable, robust coordination benefits from explicit uncertainty tracking, conservative rules, and policies that degrade gracefully under missing information.

Distributed planning and task allocation. Many constellation problems can be expressed as distributed planning with explicit constraints and interpretable objectives. Market-based and auction-based allocation, including consensus-based bundle assignment, can be implemented with limited message exchange (bids/utilities) while naturally handling heterogeneous capabilities [24,35]. Distributed constraint optimization (DCOP) provides a general coordination abstraction with both complete and approximate algorithms, and has been widely surveyed [113,114]. These methods are attractive for operations because constraints are explicit, decision logic is auditable, and integration with mission rules (e.g., priority policies) is straightforward.

Distributed control and optimization. For formation flying, networked control, and some allocation problems, distributed control and optimization can offer predictable behavior with explicit constraints. Consensus and cooperative control foundations are well established for dynamic graphs and delays [100]. Distributed and hierarchical model predictive control (MPC/DMPC) provides a powerful framework for explicitly enforcing state/input constraints and coordinating coupled subsystems, with several foundational surveys and roadmaps [115,116,117]. In constellation contexts, these approaches are often combined with contact-aware scheduling and simplified models to remain feasible under onboard resource limits.

Hybrid approaches. Operational systems are often hybrid: learning-based modules provide fast heuristics, prioritization, or policy initialization, while optimization-based layers enforce hard constraints and safety envelopes. Hybrid designs can also separate timescales—slow planning/allocation via optimization and fast reaction via learned policies—while retaining runtime monitors and conservative fallbacks [32].

4.3. Safety and Operations (Constraints, Runtime Assurance, Human-on-the-Loop)

Hard constraints and safe decision-making. Constellation autonomy must respect hard constraints (collision avoidance, attitude and slew limits, thermal/power budgets, link schedules, fuel usage). Rather than treating constraints as soft penalties, many approaches incorporate constrained RL formulations and safety layers/filters that modify proposed actions to remain within admissible sets [118,119,120,121]. These ideas are directly relevant to maneuver planning and risk-limited autonomy, where unsafe actions may be mission-ending.

Runtime assurance and monitoring. Even when policies are learned or adaptive, on-orbit operation typically requires runtime assurance (RTA): monitors that check safety-relevant properties online and switch to verified fallback behaviors when risk thresholds are exceeded [122,123]. In satellite operations, this mindset aligns with conservative fault protection and staged autonomy, and complements conjunction assessment best practices and operator coordination protocols [32,61].

Validation, staging, and operational governance. Constellation autonomy is commonly introduced gradually: simulation validation (including digital twins), hardware-in-the-loop tests when available, and staged rollout from advisory modes to supervised autonomy and finally to higher autonomy under well-defined envelopes [32]. Governance also includes versioning, audit trails, and rollback policies to maintain predictable behavior under drift and evolving conditions.

Human-on-the-loop coordination. Many missions require human operators to inspect, approve, or veto safety-relevant actions (especially maneuvers). Human-on-the-loop designs emphasize transparency of intent and uncertainty, appropriate levels of automation, and interfaces that summarize fleet-level decisions because operators cannot track each satellite in detail [124,125,126]. In constellation settings, this often motivates explainable summaries, conservative defaults, and mechanisms to reconcile local autonomy with centralized operational policies.

Long-term robustness. Constellations operate for years while payloads degrade, orbits evolve, and the operational environment changes. Multi-agent autonomy therefore benefits from conservative adaptation, strong telemetry for auditing, and clear separation between components that may adapt and those that must remain stable and certifiable [32].

Table 7 provides a systematic overview of representative multi-agent coordination methods for constellation autonomy, comparing their algorithm families, typical tasks, communication content, suitability under orbital constraints, and key references.

Table 7. Systematic overview of multi-agent coordination methods for constellation autonomy.

Method Family	Representative Algorithms	Typical Constellation Tasks	What Is Shared	Fit to Orbital Constraints	Key Refs.
CTDE MARL (value/actor-critic)	MADDPG; COMA; VDN/QMIX	Scheduling/coverage; routing policies; reactive tasking	Learned messages/local obs summaries	Strong in simulation; execution decentralized; needs robustness to delay and non-stationarity	[103,104,105,106]
Learned communication in MARL	CommNet; DIAL; IC3Net; TarMAC; MAGIC	Distributed coordination under partial observability	Differentiable messages; gated communication	Enables “what/when/to whom” policies; aligns with bandwidth limits (event-trigger)	[65,108,109,110,111,112]
Auction/market-based allocation	CBBA; distributed auction scheduling	Observation tasking; downlink allocation	Bids/utilities; local plans	Interpretable; works with sparse comm; good for heterogeneity and auditable ops	[24,35]
DCOP (distributed constraint optimization)	ADOPT; DCOP frameworks	Constraint-heavy scheduling/resource allocation	Constraint messages/cost tables	Explicit constraints; can trade optimality for comm; supports auditability	[113,114]
Distributed control/consensus/ DMPC	Consensus control; (D)MPC surveys	Formation flying; reconfiguration	State/trajectory/ constraints	Predictable + constraint handling; sensitive to delays; may need simplified models	[100,115,116,117]
Safety layers & runtime assurance	Safe RL; CPO; shielding; predictive safety filters; RTA	Maneuver planning; risk-limited autonomy	Safety monitors/filters	Enforces hard constraints; supports staged autonomy and fallbacks	[118,119,120,121,122,123]
COLA/conjunction operations (governance)	Best practices; autonomous COLA concepts	Collision avoidance and risk management	Risk thresholds; maneuver intents	Mission-critical; human-on-the-loop common; requires conservative governance	[58,59,61,101,102]

5. Collaborative Sensing and Distributed Inference

Collaborative sensing and distributed inference focus on constellation-level perception and estimation by sharing information across satellites and distributing parts of the inference pipeline. This differs from federated learning (training/adaptation) and multi-agent coordination (action selection): here the emphasis is on inference-time collaboration—fusing observations, exchanging intermediate results, and exploiting the constellation as a distributed computing fabric to obtain a faster or more reliable situational understanding. In orbit, this collaboration is constrained by intermittent ISLs, time-varying topology, heterogeneous sensors and compute, and strict latency requirements for time-critical tasks (e.g., conjunction risk, event detection) [11,45,48].

5.1. Multi-Satellite Fusion and Tracking (Consensus/Information Filters)

Multi-satellite fusion becomes essential when a single observation is insufficient, ambiguous, or too noisy, and when combining multiple views improves uncertainty reduction and robustness. Representative use cases include cooperative target tracking and orbit determination, conjunction assessment and SSA, and multi-view Earth observation products [127,128].

Distributed filtering and track-to-track fusion. A common approach maintains a local posterior/track on each satellite and exchanges compact sufficient statistics (rather than raw measurements) [127]. For Gaussian track fusion, it is convenient to use the information form, where each node i represents its estimate with an information matrix/vector $({\mathbf{Y}}_i,{\mathbf{y}}_i)=({\mathbf{P}}_i^{-1},{\mathbf{P}}_i^{-1}{\widehat{\mathbf{x}}}_i)$. Under conditional independence assumptions, information pairs add; however, in peer-to-peer settings, cross-correlations are often unknown, and naive fusion can lead to overconfident estimates (“data incest”) [129]. A classical conservative remedy is covariance intersection (CI), which fuses two information pairs via a convex combination

$$(\mathbf{Y},\mathbf{y})=\omega ({\mathbf{Y}}_1,{\mathbf{y}}_1)+(1-\omega )({\mathbf{Y}}_2,{\mathbf{y}}_2),\hspace{1em}\omega \in [0,1],$$

(7)

guaranteeing consistency without requiring the cross-correlation [130,131]. This CI/KL-average viewpoint connects naturally to distributed Bayesian fusion based on information-theoretic averaging (e.g., Kullback–Leibler averaging and consensus on posteriors) [129].

Consensus-based distributed estimators. Consensus filters provide a generic mechanism for distributed averaging on time-varying graphs and are widely used to build distributed Kalman/information filters. Early influential work decomposed centralized filtering into local micro-filters driven by consensus over measurements and inverse covariances [132,133]. Subsequent developments include information-consensus filters that combine information filtering with consensus iterations and explicitly analyze track-to-track statistics [134]. More recent work also connects distributed Kalman filtering to consensus optimization viewpoints with stability/performance guarantees [135]. In constellation settings, these methods must additionally confront intermittent contacts and limited consensus iterations per window, motivating bounded-round consensus, timeouts, and staleness-aware weighting [45,48].

Multi-object tracking and data association. For multi-target tracking, fusion must handle data association, false alarms, and track management. When bandwidth is limited, satellites typically exchange compact tracklets (state, covariance, quality flags) or compressed descriptors rather than full sensor data [127]. Random finite set (RFS) formulations provide a principled Bayesian framework for multi-object tracking and have also been adapted to consensus/distributed settings, including consensus labeled RFS filters [26,28,136]. These approaches are attractive for SSA-like scenarios where reporting track uncertainty and avoiding double counting are critical.

Multi-view and heterogeneous sensing. Fusion is not limited to identical sensors: constellations may combine optical, SAR, infrared, GNSS reflectometry, and RF sensing. Examples images are illustrated in Figure 3. Heterogeneous fusion requires calibration and temporal alignment and benefits from explicit uncertainty modeling so that contributions can be weighted by geometry and sensor quality [128]. In practice, heterogeneity also influences what is shared (raw measurements vs. features vs. tracks), because the latter determines both the achievable latency and the robustness to intermittent links.

Figure 3. Example Remote Sensing Images from Satellites with Different Sensors.

5.2. Collaborative Representation and Inference (Self-Supervised, Split/Early-Exit)

Representation sharing under scarce labels. When labels are sparse or delayed, collaborative representation learning can improve generalization by aligning features across satellites without transmitting raw imagery. Self-supervised learning (SSL) is particularly relevant for remote sensing because it exploits abundant unlabeled data and has been comprehensively reviewed and benchmarked in the EO domain [137,138]. In constellation settings, satellites may exchange compact prototypes, reference embeddings, or statistics to encourage cross-node consistency under non-IID conditions while keeping bandwidth low.

Collaborative self-supervision under non-IID data. Non-IID distributions can cause representations to drift apart across orbital planes, seasons, and sensor conditions. Alignment can be encouraged using contrastive or representation-regularization objectives across participants (e.g., model-contrastive or federated contrastive schemes), which conceptually match “share representations, not raw data” designs [139,140]. In orbit, such collaboration is often opportunistic (only during contact windows) and must be robust to partial participation.

Split inference and partitioned computation. Distributed inference can split a model across satellites or between the satellite and ground, executing early layers to generate an intermediate representation that is transmitted for completion elsewhere. A minimal abstraction is

$$\mathbf{z}=f_{1:k}\left(\mathbf{x}\right),\hspace{1em} \widehat{\mathbf{y}}=f_{k+1:L}\left(\mathbf{z}\right),$$

(8)

where $\mathbf{z}$ can be quantized/compressed to match link budgets. Dynamic partitioning between the edge and cloud has been studied extensively in terrestrial edge systems (e.g., layer-wise partitioning to minimize end-to-end latency/energy) [141]. In satellite edge computing, recent works explicitly study multi-satellite collaborative inference, including pipeline-style model splitting and satellite selection under LEO topology [70], as well as gain-aware scheduling for multi-exit models in resource-constrained in-orbit settings [142].

Early-exit inference and adaptive depth. Early-exit models attach intermediate classifiers so that “easy” samples exit early, reducing compute and often enabling event-driven communication (only uncertain cases are forwarded for deeper inference or collaborative verification) [36,37]. A comprehensive survey of early-exit DNNs further systematizes design and training choices, which are increasingly relevant for latency-critical on-orbit analytics [143]. In the satellite context, multi-exit DNNs have also been explored for cooperative inference where exit-point selection interacts with offloading and link states [142].

Collaborative ensembles and expert selection. Another practical pattern is to distribute specialists (experts) across the constellation (e.g., day/night, land/ocean, latitude bands) and query the most suitable expert based on metadata and uncertainty. This can improve robustness under persistent domain shift while avoiding a single monolithic model, but requires careful control of communication frequency and validation of received outputs under intermittent contacts [11].

5.3. Fault Tolerance and Cross-Layer Co-Design (Offloading, AI-for-Networking)

Fault tolerance under transient failures. Space environments introduce transient faults, resets, and silent corruptions. Collaborative inference should degrade gracefully when nodes disappear or messages are corrupted, using bounded trust in received messages, redundancy (multi-satellite confirmation), consistency checks on shared statistics, and conservative fusion when correlations are uncertain [15,57,130,131]. For split pipelines, practical safeguards include checkpointing and the ability to revert to local-only inference if collaboration becomes unavailable.

Compute offloading and scheduling. Collaborative inference is tightly linked to offloading decisions: process locally, forward to a neighbor, or downlink to the ground. Orbital edge computing surveys emphasize that feasibility depends on contact windows, hop delays, and the energy trade-off between compute and transmission [11,12]. Recent satellite-focused studies formulate and evaluate collaborative inference policies that jointly decide satellite selection, partitioning, and scheduling under LEO network constraints [70,142].

Cross-layer co-design: AI-for-networking and networking-for-AI. Networking determines which collaboration patterns are feasible, while AI workloads shape network demand. AI-for-networking uses learning/optimization to improve routing, contact utilization, and planning in large LEO networks [30,45]. Networking-for-AI, conversely, prioritizes messages that maximize inference utility (e.g., uncertainty reduction, consensus completion, or timely alerts), rather than treating all packets equally. This co-design view is central when contact windows are short and when system-level objectives (latency, energy, reliability) dominate raw model accuracy [11,48].

Event-driven communication. Event-driven policies transmit only when the value of communication is high, such as when confidence exceeds a threshold (triggering alerts) or when uncertainty is high (requesting collaborative verification). Early-exit and multi-exit architectures naturally support such designs by activating deeper or distributed computation only when needed [36,37,142]. Similar principles appear in event-triggered communication for multi-agent learning/control, aligning well with intermittency-limited ISLs [65].

End-to-end reliability and operational integration. Finally, collaborative inference should be evaluated end-to-end, including delays, drops, partial participation, and fault injection, because idealized networking can overestimate real mission benefit. Operational integration requires explicit latency targets, defined fallback behaviors, and auditable logging of shared outputs (tracks, alerts, fused estimates) for post-event analysis and safety review [11,48].

Table 8 provides a systematic overview of collaborative sensing and distributed inference methods in satellite constellations, comparing their core ideas, exchanged information, sensitivity to contact and timing constraints, representative use cases, and key references.

Table 8. Systematic overview of collaborative sensing and distributed inference in constellations.

Method Family	Core Idea	What Is Shared	Contact/Timing Sensitivity	Typical Use Cases	Key Refs.
Conservative fusion (CI)	Fuse without cross-correlation knowledge; ensure consistency	Information pairs/covariances	Low iteration; robust under intermittent contacts	SSA track fusion; reliable estimation under uncertain correlation	[130,131]
Information-theoretic averaging (KL-average)	Consensus on probability densities with stability guarantees	Density/summary statistics	Needs exchanges but can be bounded; stable under partial graphs	Distributed state estimation/tracking	[129]
Consensus Kalman/ information filters	Distributed filtering via consensus iterations	Measurements/ information vectors	Sensitive to rounds per contact window; requires bounded-round design	Cooperative tracking; orbit estimation	[132,133,134,135]
RFS-based distributed multi-object tracking	Bayesian multi-object tracking; consensus variants	Tracklets/labeled RFS representations	Exchange compact track summaries; handles association uncertainty	Debris/RSO tracking; SSA multi-target tracking	[26,28,136]
Split inference/partitioned computation	Compute early layers onboard; transmit embeddings	Intermediate features/embeddings	Very contact-aware; choose split point based on latency/bandwidth	EO event detection; cooperative analytics	[70,141]
Early-exit/multi-exit inference	Exit early for easy samples; trigger collaboration on uncertainty	Decisions + optional features for hard cases	Naturally event-driven; reduces comm and compute	Time-critical detection; bandwidth-limited verification	[36,37,142,143]
Cross-layer co-design (networking-for-AI)	Route/schedule messages by inference utility	Utility-weighted messages/alerts	Requires DTN/contact-plan awareness	Low-latency alerting; uncertainty reduction per bit	[11,30,45,48]

5.4. Representative Datasets and Benchmark Resources

A practical challenge in distributed on-orbit space AI is the lack of unified benchmarks that jointly capture constellation networking, onboard compute limits, non-IID sensing, and operational constraints. Nevertheless, several public datasets and benchmark resources are already useful for evaluating important subproblems, especially in remote-sensing perception and spacecraft telemetry analysis. These resources do not yet constitute a complete constellation-scale benchmark suite, but they provide an important experimental foundation for reproducible comparison.

For remote-sensing vision tasks, representative datasets include EuroSAT for land-use and land-cover classification from Sentinel-2 imagery [144], BigEarthNet for large-scale multi-label Sentinel benchmarking [145], SEN12MS for Sentinel-1/Sentinel-2 multimodal learning and data fusion [146], and So2Sat LCZ42 for global local-climate-zone classification [147]. High-resolution scene understanding is further supported by AID and RESISC45 for scene classification [148,149], PatternNet for remote-sensing image retrieval [150], fMoW for large-scale overhead imagery understanding with metadata [151], SpaceNet 6 for SAR–optical all-weather mapping [152], and MLRSNet for multi-label high-resolution semantic scene understanding [153]. Although these datasets were not originally designed for constellation-scale collaboration, they are highly relevant for studying distributed perception, multimodal fusion, split inference, and communication-efficient feature sharing.

For spacecraft health monitoring and anomaly detection, fewer public resources are available. The OPS-SAT anomaly-detection benchmark is particularly important because it provides real in-orbit telemetry, curated anomaly labels, suggested evaluation metrics, and baseline results, making it one of the most operationally relevant resources currently available for on-orbit AI benchmarking [154]. Earlier work on spacecraft anomaly detection with sequence models also provides a useful benchmark perspective for telemetry-driven AI methods [155]. More broadly, benchmark design in time-series anomaly detection deserves caution, since flawed benchmark construction can create misleading impressions of progress [156]. This warning is especially relevant for space AI, where distribution shift, missing data, and sparse labels are common rather than exceptional.

Overall, the current benchmark landscape is richer for perception than for constellation-scale collaboration itself. This imbalance suggests an important future direction: building benchmark suites that combine sensing tasks with time-varying contact graphs, onboard resource limits, delayed labels, and fault injection so that distributed on-orbit AI methods can be compared under more realistic mission conditions. Table 9 summarizes representative datasets and benchmark resources relevant to distributed on-orbit space AI, including their modality, primary task, and specific relevance to collaborative sensing, distributed inference, federated perception, and telemetry-based anomaly detection.

Table 9. Representative datasets and benchmark resources relevant to distributed on-orbit space AI.

Resource	Modality	Primary Task	Relevance to This Survey
EuroSAT [144]	Sentinel-2 optical	Land-use/land-cover classification	Lightweight EO perception benchmarks for onboard or distributed classification
BigEarthNet [145]	Sentinel-2 (and later Sentinel-1/2 variants)	Large-scale multi-label scene understanding	Useful for non-IID remote-sensing splits and federated perception studies
SEN12MS [146]	Sentinel-1 + Sentinel-2	Multimodal classification/fusion	Natural benchmark for collaborative sensing and multimodal distributed inference
So2Sat LCZ42 [147]	Sentinel-1 + Sentinel-2	Urban/local climate zone classification	Representative benchmark for multimodal global-scale classification under domain variation
AID [148]/ RESISC45 [149]	High-resolution optical	Scene classification	Standard remote-sensing vision benchmarks for onboard perception baselines
PatternNet [150]	High-resolution optical	Image retrieval	Useful for communication-efficient representation learning and retrieval tasks
fMoW [151]	Overhead imagery + metadata	Functional scene understanding	Relevant for metadata-aware collaborative inference and multi-source learning
SpaceNet 6 [152]	SAR + optical	All-weather building mapping	Strong benchmark for cross-modal fusion under adverse imaging conditions
MLRSNet [153]	High-resolution optical	Multi-label semantic scene understanding	Relevant for richer scene semantics than single-label classification
OPS-SAT benchmark [154]	Real satellite telemetry	Anomaly detection	One of the few public on-orbit telemetry benchmarks with operational relevance
Hundman et al. [155]	Spacecraft telemetry	Sequence-based anomaly detection	Early benchmark reference for telemetry-driven anomaly detection methods

6. Open Challenges and Future Directions

Distributed on-orbit space AI is no longer limited by whether collaboration in orbit is conceptually possible; rather, the main question is which problems are mature enough for near-term progress, which ones still block deployment, and which ones require community-level coordination beyond individual algorithmic advances. To make this section more actionable, we group the open problems into three priority classes. First, some directions are technically tractable in the near term because they can build on existing distributed optimization, edge inference, and space networking tools. Second, some challenges are blocking deployment because they directly affect mission assurance, safety, and operational acceptance. Third, some problems are community-level priorities whose solution depends on shared benchmarks, standards, and open ecosystems rather than on isolated methodological progress. This perspective helps distinguish research opportunities from engineering bottlenecks and coordination needs [32,45,48,157]. Beyond nominal algorithmic performance, real mission deployment is constrained by verification and validation burden, flight-software integration, contact-plan uncertainty, and the need for conservative fallback modes when distributed collaboration becomes unavailable. These factors often determine practical feasibility as strongly as model accuracy itself.

6.1. Near-Term Technically Tractable Directions

Communication-efficient collaboration. Among the most tractable near-term directions are methods that reduce the communication burden of distributed learning and inference. In large constellations, frequent global synchronization is rarely realistic, and practical progress is more likely to come from locality-aware collaboration, asynchronous aggregation, event-triggered communication, and utility-aware message selection [11,30,45,48,65]. These directions are attractive because they improve performance under constraints that are already well understood—limited contact windows, message budgets, and intermittent connectivity—without requiring a full solution to the hardest certification problems.

Cross-layer co-design of networking and AI. A second near-term opportunity lies in cross-layer co-design. Learning, inference, and tracking generate bursty traffic in the form of model updates, features, and tracklets, while routing and contact scheduling determine when such traffic can actually be delivered. Designing networking-for-AI policies that prioritize information value, and AI-for-networking policies that improve contact utilization and routing, is both practically useful and experimentally accessible with existing DTN abstractions and simulation tools [11,30,45,48,71,72]. Compared with end-to-end autonomous decision making, these problems are often easier to evaluate quantitatively through latency, throughput, and utility-per-bit metrics.

Benchmarkable collaborative perception and inference. A third tractable area is collaborative sensing and distributed inference for perception-heavy workloads, especially in vision and tracking. Split inference, early-exit models, feature sharing, and uncertainty-aware fusion can already be studied with current onboard AI pipelines and realistic networking assumptions. These problems are particularly suitable for short-term progress because they can often be benchmarked before full flight qualification, and because performance trade-offs can be reported in terms of communication, energy, and latency rather than only abstract model accuracy [11,32]. In other words, these directions are research-ready because they can be iterated in simulation and hardware-in-the-loop environments without immediately facing the full burden of mission-critical certification.

6.2. Current Blockers to Deployment

Verification, validation, and runtime assurance. The clearest blocker to deployment is not raw algorithmic capability but assurance. Learning-enabled multi-agent policies, adaptive models, and collaborative inference pipelines remain difficult to validate across the full space of operating conditions, especially when connectivity is intermittent and data distributions drift over time. For deployment, the key requirement is not only good nominal performance, but defensible evidence that unsafe or unstable behaviors will be detected and bounded. This makes runtime assurance, regression testing, fault injection, staged rollout, and conservative fallback policies central bottlenecks for constellation-scale autonomy [32,122,123,157]. In practice, these issues often determine whether a system can be allowed to close a control or operations loop at all.

Fault tolerance and silent corruption. A second deployment blocker is robustness to the space environment. Radiation-induced faults, transient resets, silent data corruption, and degraded sensors can invalidate both distributed learning and distributed inference, even if the communication network itself is functioning correctly [15,56,57]. While robust aggregation and conservative fusion can mitigate some failures, truly dependable deployment requires fault-aware update validation, uncertainty-aware collaboration, and graceful degradation policies that revert to local-only or conservative modes when trust signals deteriorate. This is a harder problem than ordinary packet-loss robustness, because the system must reason about when received information is merely delayed and when it is unsafe.

Safe model lifecycle management. Model updates in orbit are another major blocker. Continual adaptation is attractive under drift and non-IID data, but operationally it creates risk: a poorly validated update may degrade performance in a way that is hard to recover from during the mission. For this reason, constellation-scale space AI needs explicit lifecycle controls, including versioning, signing, validation gates, staged deployment, rollback, and continuous monitoring after release [32,158,159]. This is less a pure machine learning problem than an engineering-governance problem. Until update governance becomes routine, many learning-enabled capabilities will remain limited to advisory roles rather than mission-authoritative ones.

Security and adversarial resilience. Security is also deployment-blocking in settings where nodes may be compromised or links may be contested. Poisoning, backdoors, and malicious track/model updates are particularly serious in distributed settings because local corruption can propagate through aggregation and fusion [21,93]. Existing DTN and CCSDS security mechanisms such as BPSec provide an important foundation for integrity and confidentiality, but integrating these protections with learning-enabled workflows, update pipelines, and collaborative decision systems remains underdeveloped [72,160,161,162]. From a deployment perspective, this makes security not a secondary enhancement but part of the core safety case.

6.3. Community-Level Coordination Priorities

Benchmarks, datasets, and reproducible digital twins. Some of the most important gaps cannot be closed by a single research group. Chief among them is the lack of shared evaluation substrates that reflect constellation reality: dynamic contact graphs, non-IID data, concept drift, delayed labels, energy budgets, and fault injection. The field needs benchmarks and digital twins that combine orbit propagation, communications, onboard compute, and AI workloads in a reproducible way. Existing open tools such as Basilisk, GMAT, and Orekit provide strong building blocks, but they must be connected to common tasks, shared data splits, and standardized reporting protocols to become true community benchmarks [163,164,165]. This is a coordination problem as much as a technical one.

Standards and interoperable interfaces. Another community priority is standardization. Distributed on-orbit AI will remain difficult to compare and hard to integrate unless researchers converge on practical interfaces for exchanging model updates, feature tensors, uncertainty-aware tracklets, and mission metadata. CCSDS and DTN standards already define realistic communication and security baselines, but they do not yet provide a mature common layer for learning-enabled collaboration [71,72,160,166,167,168]. Progress here requires coordination among AI researchers, flight-software developers, mission operators, and standards bodies, rather than algorithmic innovation alone.

Open ecosystems and transparent reporting. Finally, the field needs open-source ecosystems and transparent documentation practices. Curated repositories of papers, code, datasets, and reproducible baselines can reduce fragmentation and accelerate research-to-deployment transfer. Similarly, documentation frameworks such as datasheets and model cards are important because they make assumptions, limitations, and intended use explicit, which is especially valuable in safety- and mission-critical settings [169,170]. In this sense, open ecosystems are not merely a convenience; they are part of the infrastructure required for comparability, accountability, and community growth.

Overall, the most tractable near-term opportunities lie in communication-efficient collaboration, cross-layer AI/network co-design, and benchmarkable collaborative perception. By contrast, the main blockers to real deployment are assurance, fault tolerance, security, and safe update governance, because these determine whether learning-enabled autonomy can be trusted operationally. Finally, shared benchmarks, interoperable standards, and open ecosystems are community-level priorities that no single paper or laboratory can solve alone. For constellation-scale on-orbit AI to mature beyond promising prototypes, progress on all three levels will be necessary, but the order matters: practical short-term advances should be pursued in parallel with assurance-driven engineering while the community collectively builds the common infrastructure needed for long-term field maturity. Table 10 presents a priority-based roadmap for constellation-scale distributed on-orbit AI, summarizing near-term technically tractable directions, current blockers to deployment, and broader community-level coordination priorities, together with their motivations, key actors, and suggested evaluation signals.

Table 10. Priority-based roadmap for constellation-scale distributed on-orbit AI.

Direction	Priority Class	Why It Matters Now	Main Actors	Suggested Evaluation Signals
Communication-efficient collaboration	Near-term tractable	Directly improves feasibility under limited contacts and message budgets; can be tested with existing simulators and prototypes	Individual research groups + mission AI teams	Bytes/contact, staleness, utility per bit, energy/latency trade-off
Cross-layer AI/network co-design	Near-term tractable	Networking already constrains collaboration; utility-aware scheduling can deliver immediate system gains	AI + networking researchers	End-to-end latency, throughput, delivery timeliness, uncertainty reduction per bit
Collaborative perception and distributed inference	Near-term tractable	Supports practical EO/SSA workloads and can be benchmarked before full autonomy certification	AI/vision groups + onboard computing teams	Accuracy vs latency/energy, early-exit rate, feature-sharing cost, robustness under drops
Verification, validation, and runtime assurance	Deployment blocker	Determines whether learning-enabled autonomy can be trusted in safety- or mission-critical loops	Flight software, assurance, autonomy teams	Constraint violations avoided, intervention rate, regression coverage, fault-injection robustness
Fault tolerance and silent-corruption resilience	Deployment blocker	Radiation and transient failures can invalidate distributed updates and fusion results	Hardware/software reliability + autonomy teams	Recovery time, safe fallback rate, consistency under injected faults
Safe model lifecycle management	Deployment blocker	In-orbit updates require governance, rollback, and monitoring before operational adoption	Mission operators + MLOps/flight software teams	Update success/failure rate, rollback triggers, post-update regression signals
Security and adversarial resilience	Deployment blocker	Compromised nodes or links can undermine learning, fusion, and coordination at system scale	Cybersecurity + autonomy teams	Attack success rate, poisoned-update robustness, integrity-check effectiveness
Benchmarks and digital twins	Community coordination	No shared basis yet exists for fair comparison under constellation realities	Research community + agencies + industry	Public tasks, common splits, fault/contact models, reproducibility of reported results
Standards and interoperable interfaces	Community coordination	Needed for cross-mission reuse, comparability, and integration with space networking stacks	Standards bodies + agencies + industry	Protocol compliance, interoperability demonstrations, reusable schemas/interfaces
Open ecosystems and transparent reporting	Community coordination	Reduces fragmentation and supports accountable, cumulative progress	Entire community	Availability of code/data, documentation quality, reuse across studies

7. Conclusions & Discussion

This survey reviewed distributed on-orbit space AI for satellite constellations, focusing on how multiple satellites can collaborate to learn, infer, and act under realistic space constraints. We introduced a constellation-centric system model that captures dynamic connectivity, heterogeneous onboard resources, and non-IID drifting data streams, and proposed a taxonomy that organizes methods by collaboration architecture, timing mechanism, and trust assumptions.

We synthesized the literature through three complementary algorithmic pillars. Federated learning enables cross-satellite training and adaptation without centralizing raw data, but demands contact-aware protocols that tolerate intermittent participation, limit communication overhead, and support safe, auditable update workflows. Multi-agent coordination addresses constellation-level autonomy for coverage, scheduling, formation, and collision avoidance, where partial observability and delayed communication are intrinsic and hard constraints must be enforced throughout planning and execution. Collaborative sensing and distributed inference improve constellation-level perception via multi-satellite fusion, tracking, and partitioned inference, and underscore the importance of cross-layer co-design with networking and compute offloading.

We further summarized representative applications in Earth observation, space situational awareness, autonomous constellation networking, and on-orbit servicing, and emphasized evaluation practices that jointly measure task performance and system-level costs using end-to-end simulation and reproducible benchmarks. Looking ahead, the main barriers to deployment are scalability to mega-constellations, trustworthiness under faults and adversaries, and operational integration across the mission lifecycle. Progress will depend on methods that remain effective under limited and intermittent communication, degrade gracefully under uncertainty and failures, and provide conservative governance for in-orbit model updates. We hope this review clarifies the design space and supports the development of practical, verifiable, and scalable approaches to constellation-scale on-orbit space AI.