Skip to content

A Standard for Heterogeneous Telescope Networks

Skynet’s Astronomical Instrumentation & Linking Architecture (AILA) is a standard created to enable interoperability across the vast diversity of astronomical instrumentation and observation types.

Rather than defining a single, monolithic system for robotic telescope networks, AILA provides a common language for describing astronomical data requests, instruments, and observations. By standardizing how these elements are defined, AILA makes it possible for many different kinds of telescopes and instruments—each varying greatly in design, capability, and control system—to work together seamlessly.

The result is that a highly heterogeneous collection of telescopes can be treated as a single agile instrument. Observations can be automatically matched to suitable hardware anywhere in the world, enabling a coordinated and efficient response to scientific needs.

Without a shared standard like AILA, this kind of interoperability simply wouldn’t be possible—each system would remain isolated, unable to exchange requests or interpret data in a common format. AILA bridges that gap, transforming disconnected observatories into a unified, globally distributed observing capability.

Target Definitions: Specifying Astronomical Objects

Observations require precise definitions of targets, which are represented in a unified model applicable to all observation types.

Each target includes a position that can be one of several forms:

  • Fixed Position – Defined by equatorial (RA/Dec) or galactic coordinates.
  • Catalog Position – Retrieved from an astronomical catalog.
  • Ephemeral Position – Time-dependent coordinates for moving objects (e.g., asteroids, comets).
  • Orbital Position – Derived from Keplerian elements for solar system objects.

Targets may also include models describing the target’s photometric and dynamic properties:

  • Brightness Model – Defines the target’s brightness and is referenced when calculating exposure times from an optical imaging data request’s target signal-to-noise ratio (SNR). Brightness models can optionally include temporal and spectral components that describe how the target’s brightness evolves as a function of time and frequency.
  • Saturation Model – Sets upper limits on exposure times to help prevent overexposure and saturation of sources during optical imaging.

Observation Configurations

Observation configurations define environmental and operational constraints that apply to specific types of data requests.

Optical Imaging Configuration

The optical imaging configuration specifies environmental and field constraints used for all optical imaging data requests. It includes:

  • Field of View (FOV) constraints
  • Moon phase and moon separation requirements
  • Sun elevation and target elevation limits
  • Tiling and coverage strategy

These parameters ensure that optical imaging observations are scheduled under suitable conditions and maintain consistent image quality across the network.

Radio Tracking Configuration

The radio tracking configuration defines parameters for tracking observations, including:

  • Whether data should be collected on-source and off-source
  • The separation distance between on- and off-source positions

Radio tracking data requests consist of the following properties:

  • Spectroscopy windows
  • Minimum spectral resolution
  • Polarization requirements
  • Maximum integration time
  • Observation duration
  • Continuum requirement

Radio Mapping Configuration

The radio mapping configuration defines how data are collected across multiple pointings to construct a map of a sky region. It includes properties describing the offset pattern used during observation:

  • Daisy Pattern – Optimized for compact or point-like sources.
  • Raster Map – Used for larger or extended regions of the sky.

Radio mapping data requests include:

  • Spectroscopy windows
  • Minimum spectral resolution
  • Polarization requirements

These configurations ensure that both optical and radio observations can be defined consistently while remaining flexible enough to accommodate the unique requirements of each observation type.

Observation Requests: A Unified Way to Define Data Needs

AILA defines a standardized data request format that allows users to specify what kind of data they need rather than how to obtain it.
This separation allows Skynet’s scheduling system to determine which instruments and configurations can fulfill the request, no matter how different those instruments may be.

Optical Imaging Data Requests

  • Can be defined by fixed exposure time or target signal-to-noise ratio (SNR).
  • When using SNR-based exposure, a brightness model is required.

Radio Tracking Data Requests

  • Include band selection, number of channels, frequency range, and integration time.
  • Support both high-resolution and low-resolution spectral observations.
  • Provide configurable options for auto-peaking and auto-focusing.

Observation Results: Consistent, Interoperable Data Output

Once an observation is completed, AILA defines a consistent structure for storing and retrieving results, ensuring data interoperability across instruments and observatories.

Observation results may include:

  • Captured exposures – Raw and processed image files for optical observations.
  • Spectral data – Spectrograms and calibrated data for radio spectroscopy.
  • Final result files – Combined or stacked data products after post-processing.

By adhering to shared result definitions, AILA ensures that data collected from one observatory can be compared, combined, or analyzed alongside data from another—without translation or reformatting.

Why AILA Matters

AILA exists to solve one of the most fundamental challenges in modern astronomy: how to make a globally distributed, diverse set of instruments behave as a single coherent observatory.

Without a common standard, every telescope and control system would remain siloed—each speaking its own language, with its own data structures and observation formats. This would make it impossible to automatically coordinate or distribute observations across a network.

By defining a shared vocabulary for how observations, instruments, and data requests are described, AILA provides the foundation that allows a network of heterogeneous observatories to act as one agile, adaptive, and globally aware instrument.

This document provides an overview of the AILA standard. For a detailed breakdown of the schema models, observation types, and data formats, refer to the individual sections.

Auto-Generated Schema Documentation

The files under core_concepts/schemas in this documentation are produced automatically from the SQLAlchemy models in
packages/py/skynet_db/models. This keeps the reference material synchronized with the code used by the Skynet API and ensures that new fields or tables immediately appear in the docs.