OrbitChain: Orchestrating In-orbit Real-time Analytics of Earth Observation Data

Earth observation analytics have the potential to transform many sectors. However, due to limited ground connections, it currently takes hours to days to download and analyze Earth observation data, diminishing the value of data for time-sensitive applications like disaster monitoring or search-and-rescue. To enable real-time analytics, we propose OrbitChain, an in-orbit multi-satellite Earth analytics framework. OrbitChain uses a pipelined design to decompose workflows into analytics functions, and orchestrates constellation-wide resources to finish real-time analytics tasks. It provides timely insights to Earth sensing applications and enables advanced workflows like in-orbit tip-and-cue. Hardware-in-the-loop experiments show that OrbitChain can deliver analytics results in minutes, supports up to 60% more analytics workload than existing frameworks, and reduces inter-satellite communication overhead by up to 45%.

💡 Research Summary

OrbitChain addresses the long‑standing latency problem in Earth observation (EO) systems, where data captured by low‑Earth‑orbit (LEO) satellites must be downlinked to ground stations before any sophisticated analytics can be performed. The authors observe that this “download‑then‑process” paradigm introduces delays ranging from several hours to days, rendering the data useless for time‑critical applications such as disaster response, maritime surveillance, or rapid agricultural monitoring. To eliminate this bottleneck, the paper proposes a multi‑satellite orbital edge computing (OEC) framework that executes the entire analytics pipeline in orbit.

The core idea is to exploit the overlapping ground‑track coverage of a leader‑follower constellation. Satellites are evenly spaced along the same orbital plane, so each ground location is observed sequentially by multiple satellites. This redundancy enables collaborative processing of a single “frame” (the area captured in one sensor sweep) across several nodes. The authors decompose any EO analytics workflow into atomic “analytics functions” (e.g., cloud detection, land‑use classification, water‑body monitoring, crop monitoring). These functions are represented as nodes in a directed acyclic graph (DAG), with edges indicating data dependencies. For each edge, a “distribution ratio” quantifies how many tiles are passed downstream on average (e.g., cloud detection may drop 50 % of tiles).

OrbitChain’s orchestration engine uses offline profiling of function runtimes, memory footprints, and energy consumption on representative hardware (NVIDIA Jetson, Raspberry Pi). With these profiles, a mixed‑integer linear program (MILP) decides: (1) which satellite hosts each function, (2) how much CPU/GPU, memory, and power to allocate, and (3) the routing of intermediate results over inter‑satellite links. The objective is to meet the frame deadline (Δf) while minimizing total inter‑satellite traffic, because each link consumes precious bandwidth and power (e.g., LoRa links at 5–50 kbps, S‑band up to 2 Mbps, with transmission power up to 18 W). The problem is NP‑hard; the authors therefore employ a heuristic that iteratively refines the placement based on bottleneck identification and load balancing.

Two traditional OEC approaches are contrasted. Data‑parallelism assigns disjoint tile subsets to each satellite but forces every satellite to run the full set of analytics models, leading to resource contention and inability to host complex pipelines. Compute‑parallelism distributes different functions across satellites, but requires transmitting raw tiles between nodes, incurring high bandwidth and energy costs, and suffers from pipeline stalls when slower models become bottlenecks. OrbitChain merges the strengths of both: by using distribution ratios it can prune low‑value data early, drastically reducing the amount of raw data that must travel between satellites, while still allowing functions to be placed on different nodes to balance compute load.

The prototype is evaluated on a hardware‑in‑the‑loop testbed that mimics a three‑satellite constellation. Realistic EO workloads (farmland flood monitoring) are run, with each function implemented as a lightweight deep‑learning model (e.g., YOLOv8n for object detection). Results show that OrbitChain completes the full DAG within the frame deadline for all tested workloads, whereas pure data‑parallel or compute‑parallel baselines miss the deadline in 70 % of cases. Overall throughput is increased by up to 60 % compared with the baselines, and total inter‑satellite traffic is reduced by an average of 45 %. Energy consumption on the communication subsystem follows the same trend, confirming the benefit of reduced data movement.

Beyond throughput, the paper demonstrates a “tip‑and‑cue” capability: once a satellite finishes a function (e.g., detects a flood‑affected region), it can immediately instruct the next satellite in the chain to prioritize re‑imaging that area or to downlink only the high‑value tiles, enabling near‑real‑time decision making without ground intervention.

In summary, OrbitChain provides a practical, end‑to‑end solution for fully in‑orbit real‑time EO analytics. By formalizing analytics workflows as DAGs, profiling function performance, and solving a joint placement‑allocation‑routing problem, it achieves high utilization of limited on‑board compute and energy resources while keeping inter‑satellite communication to a minimum. The work opens the door to truly autonomous satellite constellations that can deliver actionable insights within minutes of data capture, a capability essential for emerging time‑sensitive space‑based services. Future work should explore scaling to larger constellations, handling dynamic workload changes, and long‑duration on‑orbit validation.