A ready-to-deploy MLOps software platform for satellite and NEO detection at meter-class ground-based observatories

1. Introduction

• Ground-based observations use streaks to detect and characterise NEOs for planetary defence and monitor satellites and orbital debris for Space Situational Awareness.Classical methods have been augmented by automated and machine-learning pipelines.Source: §1 · p. 1
• Prior work spans asteroid-detection suites, moving-object pipelines, deep learning, space-archive analysis, and hybrid image-processing methods.Examples include Umbrella (Stănescu and Văduvescu, 2021), TESS processing, DeepStreaks (Duev et al., 2019), and ASTA (Stoppa et al., 2024).Source: §1 · pp. 1–2
• StreakMind combines YOLO11 oriented-box detection with geometric refinement, inter-frame association, satellite cross-identification, and relational database storage.Carrillo et al. (2026) report 94% precision and 97% recall on an independent La Sagra test set.Source: §1 · p. 2
• The paper targets the operational-integration gap with a Workbench for executing, monitoring, inspecting, and managing existing detection pipelines, rather than developing new algorithms.It supports visual overlays, structured inspection of cross-identifications and tracks, and metadata export.Source: §1 · p. 2
• The implementation is intended for meter-class ground-based observatories and moderate-scale campaigns, not large high-throughput facilities with complex multi-detector focal planes.Source: §1 · p. 2

2.1. Design principles

• The Workbench is model-agnostic: users supply Ultralytics YOLO models in .pt files, while StreakMind post-processing functions load dynamically from the reference notebook.Source: §2.1 · p. 2

2. Software Architecture

• Figure 1 depicts the Workbench environment interacting with the StreakMind pipeline and the data products generated during routine workflows.Source: §2 · p. 2, Figure 1 · p. 3

2.1. Design principles

• Using standard FITS frames and embedded WCS information minimises observatory-specific configuration and supports portability to meter-class observatories with WCS-calibrated images.Source: §2.1 · pp. 2–3
• Processing is designed to match prototype or manual-workflow results, with inference, training, database exploration, and visualisation combined in one operational environment.Source: §2.1 · p. 3

2.2. Implementation and Pipeline Integration

• The Python and PyQt5 application uses a worker thread for intensive processing and database writes, keeping the graphical interface responsive during batch processing.The operational layer interacts with the underlying StreakMind pipeline.Source: §2.2 · p. 3
• At startup, jupyter-functions-exec extracts functions from the reference notebook so the Workbench calls the pipeline’s authoritative implementation rather than duplicating its logic.Source: §2.2 · pp. 3–4

2.3. Setup and Configuration

• The setup menu selects execution mode, configures the environment, and launches the application or notebook; project parameters are centralised in .env.Table 1 lists the environment variables exposed by .env.Source: §2.3 · p. 4, Table 1 · p. 4

2.4. Multi-Environment Deployment

• Host mode runs natively, while Docker mode provides an isolated environment; Windows use requires WSL2, and macOS Docker does not provide Metal GPU acceleration.Host mode is recommended for GPU inference on macOS; Docker remains functional on CPU.Source: §2.4 · p. 4

2.5. Device Selection

• Inference device selection prioritises CUDA, then Apple Metal Performance Shaders, and falls back to CPU, with manual override available.Source: §2.5 · p. 4

2.6. Container Architecture

• The container supports GPU acceleration when NVIDIA tooling is available and otherwise uses CPU; separate GUI and notebook virtual environments prevent dependency conflicts.The image includes required OpenCV and PyQt5 libraries and supports native-host and linux/amd64 builds.Source: §2.6 · p. 4

2.7. Testing Strategy

• Testing checks output consistency with the reference pipeline, not the scientific validity of its detection algorithms.Source: §2.7 · p. 4

2.7.1. Test Dataset

• The 20-image La Sagra test set captures varied observing conditions for rapid regression checks; full validation uses 273 images.Source: §2.7.1 · pp. 4–5

2.7.2. Inference Validation

• Inference validation compares detections, Gaia filtering, satellite identifications, and database records against the reference pipeline under identical parameters.Source: §2.7.2 · p. 5

2.7.3. Training Validation

• A lightweight two-epoch training run checks that logs, optimization curves, diagnostic plots, and exported weights match notebook-based training.Source: §2.7.3 · p. 5

2.7.4. Cross-Platform Verification

• The stable test dataset and configuration support reproducible validation in both Docker and Host modes across machines and software versions.Source: §2.7.4 · p. 5

2.8.1. Layer Organisation

• Four layers separate presentation, background workflow execution, reference-pipeline integration, and SQLite data access.Source: §2.8.1 · p. 5

2.8.2. Configuration Management

• Environment paths use a startup .env file, while interface preferences are persisted separately through Qt QSettings.Source: §2.8.2 · p. 5

2.8.3. Inter-Component Communication

• Qt signals and slots relay worker progress and refresh Database and Photometry tabs when inference completes.Source: §2.8.3 · p. 5

2.8.4. Multi-Threading Strategy

• Inference and photometry use QThread workers, while training runs in a separate process that can be terminated across compute backends.Source: §2.8.4 · p. 5

2.8.5. Internationalisation and Theming

• English and Spanish switching rebuilds the tabs; the QSS theming system offers eight schemes and a user-defined accent colour.Source: §2.8.5 · p. 6

• A runtime bridge extracts notebook functions as callable objects, keeping the reference notebook authoritative and avoiding duplicated pipeline code.Source: §2.9 · p. 6
• Training runs in a separate process because thread termination may not release GPU resources; the process boundary allows termination across backends.Source: §2.9 · p. 6
• Gaia queries are batched once per observing session rather than per image, with configurable retries after transient failures.Source: §2.9 · p. 6
• Photometric profiles extend under-sized detection boxes along the trail until signal falls below a locally estimated background threshold.Source: §2.9 · p. 6
• Lazy string lookup and rebuilding the tabs enables language changes without restarting the application or updating widgets individually.Source: §2.9 · p. 6

3.1. Image Ingestion

• Individual FITS files or directories are ingested, normalized for detection, and paired with retained source files and extracted instrumental metadata.Source: §3.1 · p. 6

3.2. Streak Detection

• Users supply an Ultralytics-compatible model and configure inference; the downstream pipeline is designed for satellite and debris trails.Source: §3.2 · pp. 6–7

3.3. Geometric Reconstruction and Astrometry

• Each detection receives pixel and equatorial trail geometry, completeness classification, and astrometry from the FITS header solution.Source: §3.3 · p. 7

3.4. Bright-Star Spike Filtering and Photometric Trail Refinement

• Gaia DR3 filtering flags detections within 450 arcseconds of sources brighter than GRP = 6.0; surviving trails receive photometric endpoint refinement.Source: §3.4 · p. 7

3.5. Satellite Cross-Identification and MPC Reporting

• Surviving detections generate MPC observation lines that are cross-matched through Project Pluto, with identification details stored alongside each record.Source: §3.5 · p. 7

3.6. Database Storage and Export

• A seven-table SQLite database uses MPC observation lines to prevent duplicate entries and supports JSON export for downstream use.Source: §3.6 · p. 7

4. Operational Workspaces

• The four workspaces cover inference, training, database exploration, and configuration management within a unified operational environment.Source: §4 · pp. 7–8

4.1. Inference Workspace

• The Inference workspace runs detection on individual FITS frames or image batches and displays processing progress, overlays, and navigable image previews.Users can configure detection parameters and output destinations; results include image visualisations, JSON summaries, and database records.Source: §4.1 · pp. 8–9

4.2. Training Workspace

• The Training workspace lets users configure and launch training, monitor progress, and interrupt a run through the interface.It creates an output directory with training configuration, metrics, diagnostic plots, example images, logs, and model weights.Source: §4.2 · p. 9

4.3. Database Workspace

• The Database workspace displays SQLite tables and records, supports switching or refreshing databases, and allows table export to JSON.Selecting a record displays its column values in an expanded preview.Source: §4.3 · p. 9

4.4. Settings Workspace

• The Settings workspace centralises interface preferences, the reference notebook path, and runtime-environment information.Users can also change the application theme and language; English and Spanish are supported with dynamic language changes.Source: §4.4 · p. 9

Validation Dataset

• 273 La Sagra Observatory images from routine asteroid observations formed the real-world validation dataset.The images span three asteroid-observation sets from 2019 and 2024, with 60 s and 100 s exposures, respectively.Source: §5 · p. 10

Training Validation

• Workbench-generated training logs, optimisation curves, evaluation plots, and model weights were compared with direct StreakMind pipeline outputs, and the experiment confirmed correct Workbench training-workflow execution.The reduced test used 2 epochs, batch size 1, 640-pixel inputs, zero data-loader workers, and the MPS backend; software and hardware differences and nondeterministic remote catalogue queries may cause minor variations, but these negligibly affect overall results.Source: §5 · p. 10

Validation Results

• The Workbench successfully executed inference, post-processing, database generation, satellite identification, MPC observation generation, and training management while maintaining consistency with the reference StreakMind methodology.Source: §5 · p. 10

Real-World Example

• A satellite streak appearing in five consecutive images yielded a consistent track, with reconstructed measurements and an MPC-formatted observation line stored in the database.The example identifies the object as INTELSAT 605 using satellite ephemerides, with a 0.0285° angular offset and 99.55% identification probability.Source: §5 · pp. 10–11, Table 2 · p. 11

Conclusions

• Validation demonstrated successful integration of image ingestion, streak detection, post-processing, database generation, satellite cross-identification, result inspection, and model-training workflows.The evaluation used an existing AI model and a representative dataset from La Sagra Observatory.Source: §6 · p. 11
• By combining automated processing, interactive visualisation, and structured data management, the Workbench facilitates dataset exploitation and real-time analysis, supporting SSA and planetary defence.It also enables observations originally acquired for other scientific objectives to be reused for detecting, characterising, and identifying artificial objects.Source: §6 · p. 11

Limitations

• Current limitations include no reconstruction of streaks spanning multiple detectors, possible ambiguous satellite matches, uncharacterised bright-star filtering in different fields, WCS error propagation, and MPC acceptance requirements external to the platform.Satellite cross-identification depends on orbital information; the current implementation does not use brightness to distinguish plausible candidates. The bright-star filter has only been validated under conditions represented in the current dataset.Source: §6 · p. 11
• The reference StreakMind model was trained and characterised using La Sagra Observatory data and has not been independently evaluated across multiple observatories.Consequently, the paper presents no multi-observatory confusion-matrix analysis.Source: §6 · p. 11

Future work

• Planned scientific extensions include calibrated trail photometry for object characterisation and resolving ambiguous satellite identifications, plus probabilistic associations with candidate asteroid trajectories.Small-body matching is being developed using schemes analogous to satellite identification.Source: §6 · pp. 11–12
• Future validation will investigate multiple observatories, model fine-tuning under different conditions, multi-detector support, and optional input astrometric-solution verification or refinement.Any direct MPC submission implementation will remain aligned with applicable MPC reporting requirements.Source: §6 · p. 12
• Operational development targets improved language support and computational performance for moderate-scale campaigns; a versioned Python package may better support automation and scalability while retaining a single authoritative source.The current strategy retains the reference Jupyter notebook as the authoritative implementation, which may be less suitable for highly automated or large-scale processing than a packaged backend.Source: §6 · pp. 11–12

CRediT authorship contribution statement

• Rafael Carrillo Navarro contributed across conceptualization, investigation, software, data curation, formal analysis, validation, visualization, project administration, and writing.He is credited with both the original draft and review and editing.Source: CRediT authorship contribution statement · p. 12
• Pablo García-Martín contributed supervision, project administration, methodology, and writing and editing.Source: CRediT authorship contribution statement · p. 12
• René Duffard contributed supervision, resources, project administration, funding acquisition, and writing and editing.Source: CRediT authorship contribution statement · p. 12
• Juan Luis Orellana Montes de Oca contributed software, methodology, investigation, and writing and editing.Source: CRediT authorship contribution statement · p. 12
• Oscar Ortega Ríos contributed software and writing and editing.Source: CRediT authorship contribution statement · p. 12