EOS-Bench: Satellite Scheduling Benchmark

• EOS-Bench is an open-source benchmark framework that standardizes Earth observation satellite scheduling with realistic orbital and visibility constraints and supports both agile and non-agile satellites.
• It provides a solver-neutral, reproducible testbed with 1,390 scenarios and 13,900 benchmark instances to facilitate detailed comparisons across optimization, heuristic, meta-heuristic, and deep reinforcement learning methods.
• EOS-Bench integrates scenario generation, structural difficulty characterization, and a five-metric evaluation protocol to enable objective analysis of scheduling performance and trade-offs.

Searching arXiv for the benchmark paper and any directly relevant companion context. EOS-Bench is an open-source benchmark framework for the Earth Observation Satellite Scheduling Problem (EOSSP), introduced to provide a common, reproducible, solver-agnostic basis for comparing scheduling methods across exact optimization, heuristics, meta-heuristics, and deep reinforcement learning (Yin et al., 28 Apr 2026). It models Earth observation satellite imaging scheduling as a selection, assignment, and sequencing problem under visibility, timing, platform, and onboard-resource constraints, and combines realistic orbital/visibility generation with solver-neutral combinatorial instances, scenario characterization, and a multidimensional evaluation protocol. The framework spans both agile and non-agile satellites, includes 1,390 scenarios and 13,900 benchmark instances, and is intended as a unified and extensible open testbed for advancing research in Earth observation satellite scheduling (Yin et al., 28 Apr 2026).

1. Definition and benchmark scope

EOS-Bench is designed around the claim that Earth observation scheduling research has become methodologically diverse while remaining difficult to compare across studies because many results are obtained on private or idiosyncratic instance sets (Yin et al., 28 Apr 2026). The framework addresses this by standardizing scenario generation, instance construction, structural characterization, and evaluation metrics within a single benchmark ecosystem.

At the highest level, EOS-Bench formalizes the scenario space as

$$\Sigma = \mathcal{P}\times\mathcal{H}\times\mathcal{C}\times\mathcal{L}\times\mathcal{D}\times\mathcal{Z},$$

where $\mathcal{P}$ is platform type, $\mathcal{H}$ planning horizon, $\mathcal{C}$ constellation configuration, $\mathcal{L}$ mission load, $\mathcal{D}$ target-distribution pattern, and $\mathcal{Z}$ additional scenario-specific parameters. A scenario is one tuple

$\sigma=(p,h,c,\ell,d,z)\in\Sigma.$

Given a scenario $\sigma$ and random seed $\xi$, the instance generator outputs

$\mathcal{P}$0

where $\mathcal{P}$1 is the satellite set, $\mathcal{P}$2 the task set, $\mathcal{P}$3 the access-window family, and $\mathcal{P}$4 collect satellite-side and task-side parameters (Yin et al., 28 Apr 2026).

This formulation makes EOS-Bench a distribution over structured scheduling instances rather than a fixed dataset. A plausible implication is that benchmark conclusions can be separated into scenario-level effects and solver-level effects more cleanly than in single-instance comparisons.

2. Platform and task modeling

A central feature of EOS-Bench is explicit support for both non-agile and agile Earth observation satellites (Yin et al., 28 Apr 2026). Non-agile satellites are modeled as roll-only maneuverable platforms with pitch and yaw fixed at $\mathcal{P}$5, whereas agile satellites have full three-axis pointing flexibility and use roll, pitch, and yaw envelopes with time-dependent transition modeling. This distinction is structurally important because agile satellites enlarge the feasible observation set while increasing feasibility complexity.

The satellite model is defined by

$\mathcal{P}$6

where $\mathcal{P}$7 is orbital description, $\mathcal{P}$8 the admissible attitude envelope, $\mathcal{P}$9 onboard resource capacities, and $\mathcal{H}$0 payload-consumption parameters (Yin et al., 28 Apr 2026). Default platform agility bounds are max roll $\mathcal{H}$1, max pitch $\mathcal{H}$2, and max yaw $\mathcal{H}$3. Payload/resource modeling uses normalized units, with observation energy rate $\mathcal{H}$4 unit/s, observation memory rate $\mathcal{H}$5 unit/s, energy capacity per orbit $\mathcal{H}$6 units, storage capacity per orbit $\mathcal{H}$7 units, and attitude maneuver energy rate $\mathcal{H}$8 unit/deg (Yin et al., 28 Apr 2026).

Tasks are point targets in an offline deterministic setting, represented as

$\mathcal{H}$9

where $\mathcal{C}$0 is the target location, $\mathcal{C}$1 priority, $\mathcal{C}$2 profit, and $\mathcal{C}$3 required observation duration (Yin et al., 28 Apr 2026). The benchmark uses integer priorities 1–10, integer profits 1–10, and random durations 5–15 seconds. Target distributions include Global-Random, Region-Clustered, Hybrid, and a real-city target set derived from GeoNames (Yin et al., 28 Apr 2026).

The benchmark’s scheduling object is solver-neutral. Candidate assignments are

$\mathcal{C}$4

A feasible schedule $\mathcal{C}$5 must satisfy pairwise compatibility, task uniqueness, and resource limits: $\mathcal{C}$6

$\mathcal{C}$7

$\mathcal{C}$8

The feasible set is written

$\mathcal{C}$9

(Yin et al., 28 Apr 2026).

3. Orbital realism and visibility generation

EOS-Bench explicitly integrates orbital propagation with target visibility rather than treating scheduling as an abstract graph problem (Yin et al., 28 Apr 2026). Small-scale scenarios use 20 real Earth observation satellites drawn from CelesTrak’s “Earth Resources” category, including ALOS-2, AQUA, CARTOSAT-2C, DEIMOS-1, DEIMOS-2, GAOFEN_10R, GOKTURK_1A, GPM-CORE, KENT_RIDGE_1, SCD_1, SCD_2, SKYSAT-C2, SKYSAT-C9, SMOS, SRMSAT, TERRASAR-X, WORLDVIEW-1, YAOGAN_21, YAOGAN_4, and ZIYUAN_3-2 (Yin et al., 28 Apr 2026). Medium and large scales use Walker–Delta constellations seeded from ALOS-2’s sun-synchronous orbit.

The default synthetic constellations are 50 satellites in 10 planes × 5 per plane, 100 in 10 × 10, 200 in 20 × 10, 500 in 25 × 20, and 1000 in 50 × 20 (Yin et al., 28 Apr 2026). This gives a controlled and repeatable scaling ladder while retaining physically plausible orbit structure.

Visibility generation uses SGP4 and a deterministic geometric feasibility test: $\mathcal{L}$0 where line-of-sight, payload field of view, and platform attitude feasibility must all hold (Yin et al., 28 Apr 2026). Consecutive visible epochs are merged into access windows. For agile satellites, access windows store task ID, satellite ID, time window, and a discrete attitude sequence $\mathcal{L}$1; for non-agile satellites, they store a fixed roll angle $\mathcal{L}$2 with pitch and yaw fixed to zero (Yin et al., 28 Apr 2026).

For agile platforms, transition times are modeled by a piecewise function of total angular change $\mathcal{L}$3: $\mathcal{L}$4 with $\mathcal{L}$5, $\mathcal{L}$6, $\mathcal{L}$7, $\mathcal{L}$8, and in the Specific Scenarios $\mathcal{L}$9, $\mathcal{D}$0, $\mathcal{D}$1, $\mathcal{D}$2 (Yin et al., 28 Apr 2026). Non-agile satellites instead use a fixed 10-second transition time.

This suggests that EOS-Bench occupies an intermediate level between abstract combinatorial scheduling benchmarks and end-to-end operational simulators: it preserves realistic orbital and attitude constraints while exposing a solver-neutral schedule representation.

4. Scenario families, scale, and benchmark corpus

EOS-Bench contains 1,390 scenarios and 13,900 instances, consisting of 1,104 Standard Scenarios with 11,040 instances and 286 Specific Scenarios with 2,860 instances (Yin et al., 28 Apr 2026). Every scenario contains 10 instances. The benchmark spans 1–1000 satellites, 10–10,000 tasks, and planning horizons up to 168 hours according to the paper’s abstract and comparison material (Yin et al., 28 Apr 2026).

The Standard Scenario family varies platform type, planning horizon, constellation size, and mission load. Planning horizons are 0.5, 1, 3, and 7 days; constellation sizes are 1, 3, 5, 10, 20, 50, 100, 200, 500, and 1000; task counts depend on constellation size and range from 10 up to 10,000 (Yin et al., 28 Apr 2026). Combined with three target-distribution patterns and two platform types, this yields 1,104 Standard Scenarios.

The Specific Scenarios isolate single factors. The four families are summarized below.

Family	Main factor	Scenarios / instances
Resource-capacity variants	Low, high, and mixed capacities	120 / 1,200
Manoeuvrability profiles	Agile-only slew profiles	36 / 360
Constellation-configuration variants	Default, Few-Planes, Many-Planes	120 / 1,200
Realistic-target scenarios	Real city targets with real small constellations	10 / 100

Resource-capacity variants use baseline configurations $\mathcal{D}$3, $\mathcal{D}$4, $\mathcal{D}$5, and $\mathcal{D}$6, then apply Low-Capacity, High-Capacity, and Mixed A/B/C patterns (Yin et al., 28 Apr 2026). Manoeuvrability profiles compare High-Agility, Standard-Agility, Low-Agility, and Limited-Agility with explicitly specified angular velocities (Yin et al., 28 Apr 2026). Constellation-configuration variants compare different Walker–Delta plane allocations, such as 50 satellites in 10×5, 5×10, and 25×2 (Yin et al., 28 Apr 2026).

The benchmark’s experimental campaign in the paper uses a smaller but still broad subset: 250 scenarios and 2,500 instances, consisting of 96 Standard Scenarios and 154 Specific Scenarios (Yin et al., 28 Apr 2026). This is presented as evidence that EOS-Bench is discriminative, not as an exhaustive solver ranking over the full 13,900-instance corpus.

5. Structural difficulty characterization

A major contribution of EOS-Bench is its scenario characterization scheme, which describes structural difficulty independently of solver performance (Yin et al., 28 Apr 2026). If a scenario has $\mathcal{D}$7 instances and descriptor $\mathcal{D}$8 for instance $\mathcal{D}$9, the scenario-level estimate is

$\mathcal{Z}$0

Task-oriented descriptors include average available opportunities, opportunity constrained task ratio, task interference ratio, average task pair conflict ratio, and task elasticity ratio. Let $\mathcal{Z}$1 be the number of feasible opportunities for task $\mathcal{Z}$2, $\mathcal{Z}$3 the number of tasks, $\mathcal{Z}$4 the number of comparable window pairs, and $\mathcal{Z}$5 the number of conflicting ones. Then: $\mathcal{Z}$6

$\mathcal{Z}$7

$\mathcal{Z}$8

$\mathcal{Z}$9

with value 0 if $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$0, and

$\sigma=(p,h,c,\ell,d,z)\in\Sigma.$1

where $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$2 is the number of optional satellites for task $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$3 and $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$4 its number of feasible visible windows (Yin et al., 28 Apr 2026).

Satellite-oriented descriptors quantify congestion. Let $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$5 be the number of simultaneously active opportunities on satellite $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$6 at time $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$7. Then: $\sigma=(p,h,c,\ell,d,z)\in\Sigma.$8

$\sigma=(p,h,c,\ell,d,z)\in\Sigma.$9

$\sigma$0

$\sigma$1

and

$\sigma$2

with value 0 if there is no conflict segment (Yin et al., 28 Apr 2026).

The paper argues that these descriptors reveal latent structure not captured by nominal counts alone. For example, in a representative agile configuration with 100 satellites and 500 tasks, increasing horizon from 12h to 72h substantially raises $\sigma$3 and lowers $\sigma$4, while clustered targets sharply increase $\sigma$5 and $\sigma$6 relative to globally random targets (Yin et al., 28 Apr 2026). This suggests that EOS-Bench is intended not only as a scoreboard but also as a tool for separating task-scarcity regimes from satellite-congestion regimes.

6. Evaluation protocol and baseline methods

EOS-Bench evaluates solver outputs with five standardized metrics (Yin et al., 28 Apr 2026). Task Profit is

$\sigma$7

where $\sigma$8 is task profit and $\sigma$9 indicates execution. Task Completion Rate is

$\xi$0

Balance Degree is

$\xi$1

where $\xi$2 is the standard deviation of executed task counts per satellite and $\xi$3 is their mean over satellites executing at least one task. Timeliness is

$\xi$4

where completed tasks contribute normalized lateness and uncompleted tasks receive the maximum penalty 1. Runtime is per-instance wall-clock online solution time (Yin et al., 28 Apr 2026).

Benchmark evaluation over solver $\xi$5 is defined as

$\xi$6

that is, expected metric vectors over generated instances in a scenario, approximated by averaging over a fixed number of instances (Yin et al., 28 Apr 2026).

The paper’s baseline campaign covers 17 algorithms across four families. Exact optimization uses MIP-TP, MIP-TCR, and MIP-ALL, implemented in Python with PuLP and solved by CBC (Yin et al., 28 Apr 2026). Constructive heuristics include Greedy-TP, Greedy-TCR, Greedy-TM, and Greedy-BD (Yin et al., 28 Apr 2026). Meta-heuristics include GA, SA, and ACO, each with -TP, -TCR, and -ALL variants (Yin et al., 28 Apr 2026). The learning-based baseline is RL-TP, a PPO-based sequential constructive policy trained to maximize task profit (Yin et al., 28 Apr 2026).

The reported findings are intentionally benchmark-oriented rather than definitive solver rankings. On small agile scenarios, MIP provides exact or near-exact references, SA-based methods appear closest to MIP, and greedy methods lag (Yin et al., 28 Apr 2026). On large agile scenarios, greedy methods degrade more visibly, GA/SA/ACO form the leading quality group, and RL occupies a middle ground—better than weaker greedy baselines, but below the strongest meta-heuristics in those experiments (Yin et al., 28 Apr 2026). Runtime comparisons show that MIP scales poorly with horizon, population-based meta-heuristics incur heavy cost in large constellations, and RL inference and greedy construction remain comparatively fast (Yin et al., 28 Apr 2026).

A common misconception would be to treat EOS-Bench as a reinforcement-learning environment only. The paper explicitly frames it instead as a general combinatorial benchmark with solver-neutral interfaces and a multidimensional protocol, contrasting it with AEOS-Bench, which it describes as mainly a simulation/RL environment (Yin et al., 28 Apr 2026).

7. Significance, reproducibility, and limitations

EOS-Bench’s primary novelty lies in its benchmark ecosystem rather than in a new solver (Yin et al., 28 Apr 2026). The framework standardizes realistic orbital/visibility generation, supports both agile and non-agile platforms, provides structural descriptors that characterize scenario difficulty before optimization, and uses a five-metric protocol that exposes quality–efficiency trade-offs across heterogeneous solver families.

The framework is explicitly modular and algorithm-agnostic: solvers receive standardized inputs—planning horizon, satellites, tasks, and precomputed access windows—and must return a concrete plan specifying selected tasks, assigned satellites, chosen windows, and execution times (Yin et al., 28 Apr 2026). The paper also notes public code and data availability at

$\xi$7

and states that complete numerical results, logs, and visual outputs for the 2,500-instance campaign are included in the repository, especially in Scenario_Level_Results.xlsx (Yin et al., 28 Apr 2026).

The paper’s own scope also defines its limitations. It is a benchmark paper, not a final solver comparison for the EOS scheduling field. The main-text analysis concentrates on representative agile subsets for space reasons, while full agile and non-agile results are delegated to the repository (Yin et al., 28 Apr 2026). A plausible implication is that EOS-Bench should be understood as infrastructure for future comparative research rather than as a closed leaderboard.

In that sense, EOS-Bench establishes a common language for EOSSP evaluation: not just instance size, but opportunity density, flexibility, conflict intensity, satellite congestion, value, coverage, fairness, timeliness, and runtime. Within Earth observation scheduling research, its role is analogous to a benchmark suite that turns fragmented methodological comparisons into controlled, scenario-aware, and reproducible experiments (Yin et al., 28 Apr 2026).