---
title: 'ACADA: Control & Data Acquisition Software'
url: https://www.emergentmind.com/topics/control-and-data-acquisition-software-acada
type: topic
---

# ACADA: Control & Data Acquisition Software

Searching arXiv for recent papers on CTAO ACADA and related subsystems.
arxiv_search(query="CTAO ACADA Array Control and Data Acquisition software SAG-SCI monitoring logging alarm", max_results=10, sort_by="relevance")
Control and Data Acquisition Software (ACADA) denotes the Cherenkov Telescope Array Observatory’s central on-site software system for control, supervision, data acquisition, real-time analysis, and transient response. In CTAO, ACADA controls and supervises telescopes and auxiliary instruments, handles the multi-gigabit-per-second data streams produced by the telescopes, drives the planning and execution of observations, and embeds the Science Alert Generation pipeline together with the Transients Handler so that ongoing observations can be modified on sub-minute timescales [2606.18798]. A plausible implication is that ACADA is both a specific CTAO software stack and a representative instance of a broader class of integrated control/DAQ architectures used in large scientific facilities, where run control, synchronized acquisition, monitoring, alerting, and operator tooling are treated as one system rather than as isolated services [2005.00219].

## 1. Scope, role, and architectural decomposition

ACADA is organized as a distributed system deployed separately at the CTAO North and South sites. At each site it manages telescopes, Raman LIDARs, all-sky cameras, photometers, weather stations, ceilometers, illuminators, and other auxiliary devices treated as array elements. It is built on the ALMA Common Software middleware and comprises subsystems including the Resource Manager, Central Control, Human-Machine Interface, Array Data Handler, Science Alert Generation pipeline, Transients Handler, Short-Term Scheduler, Monitoring and Logging, Array Alarm System, Array Configuration Database, Reporting System, and ancillary command-line and workload-management services [2606.18798].

| Subsystem | Primary function | Typical scope |
|---|---|---|
| RM | Supervision, restart, persistence | Core services |
| CC | Observation orchestration | SB/OB execution |
| STS | Dynamic scheduling | Subarrays and night plan |
| ADH | Data acquisition and reduction | R1 to DL0 path |
| SAG | Real-time reconstruction and alerts | DL0 to quick-look products |
| TH | Internal/external alert handling | Transient reaction |
| MON/AAS | Monitoring, logging, alarms | Health and fault management |

The architectural split between control and data handling is explicit. RM, CC, STS, HMI, MON, AAS, CDB, and REP form the control and supervision fabric; ADH and SAG form the low-latency acquisition and real-time processing path; DPPS, although outside ACADA, receives the reduced products for deeper processing and preservation. ACADA also supports up to eight simultaneously active subarrays, so the software must schedule and supervise several logically independent observation programs on a common hardware pool [2606.18798].

This decomposition is not merely organizational. It reflects the CTAO requirement that telescopes, high-rate camera streams, atmospheric devices, alert brokers, and operator interfaces remain coordinated under changing environmental and scientific conditions. Comparable separation of central run control, per-device front ends, and event-building or supervisory layers is also characteristic of other large detector and telescope DAQ systems, although under different names and middleware choices [1909.13725].

## 2. Observation control, scheduling, and transient response

Observation execution in ACADA is driven by the interaction of Central Control, the Short-Term Scheduler, the Resource Manager, and the Transients Handler. STS transforms the Mid-Term Schedule received from off-site systems into an executable nightly plan, using the STARS library to calculate observable windows, enforce constraints, group telescopes into subarrays, and create Observation Blocks appended to Scheduling Blocks. Central Control then requests resources from RM, configures telescopes and auxiliary instruments according to the SB parameters, starts and stops OB execution, and informs ADH and SAG about upcoming observations so that data handling and analysis can be prepared in advance [2606.18798].

The Transients Handler is the broker and policy engine for rapid reaction. It receives internal science alert candidates from SAG and external alerts from other facilities, performs validation and de-duplication, matches the alert against science configurations, determines a follow-up strategy, and creates a dedicated Scheduling Block for STS. Internal candidates are produced at the top of the SAG chain, where SAG-SCI consumes reconstructed gamma-ray events, performs high-level analysis, and passes candidate science alerts to the ACADA Transient Handler for confirmation or rejection [2509.18945].

Rapid response is a defining property of the architecture. ACADA is required to trigger observations within 4 s of receiving an external alert, while the fast slewing of CTAO telescopes and the direct STS–TH interaction enable sub-minute modifications of ongoing observations [2606.18798]. This makes alert handling part of routine array control rather than an external add-on. A plausible implication is that ACADA treats transient astrophysics as a first-class scheduling constraint, on the same footing as hardware availability, weather, and calibration state.

## 3. Data acquisition, reduction, and real-time science processing

The data path begins with telescope camera streams delivered in R1 format and continues through the Array Data Handler. Per-telescope approximate event data rates are about 24 Gb/s for an LST, about 12 Gb/s for an MST, and about 2 Gb/s for an SST. ACADA must reduce the total data rate toward DPPS to below about 5 Gb/s per site, which implies a strong on-site reduction step before archival transfer [2606.18798].

ADH implements that reduction. Its Science Data Handler receives R1, applies zero suppression and other Data Volume Reduction procedures through the DVR library, forwards reduced data to SAG, and writes compressed DL0 files to on-site storage. A Software Array Trigger reads event timestamps from camera servers, searches for cross-telescope coincidences, and rejects events that are only local to a single telescope except for a small fraction retained for calibration. High-rate auxiliary devices that exceed the few-hertz cadence of MON are handled by a separate Auxiliary Instrumentation Data Handler that formats their output as DL0 [2606.18798].

SAG is the real-time analysis chain operating on that reduced stream. SAG-RECO builds event images, performs image cleaning, extracts Hillas parameters, and applies Random Forest models trained on Monte Carlo simulations to estimate direction, energy, and gamma-ray-likeness. Image parameter extraction is implemented at more than 1000 events/s per CPU per telescope, and SAG-RECO targets a latency below 15 s, within a total SAG latency budget of 20 s [2606.18798].

At the high-level analysis stage, SAG-SCI receives reconstructed gamma-ray photon lists from multiple reconstruction lines, merges them, stores them in a database, and launches several parallel analyses on the latest data. Its internal organization is database-driven: a Data Source database stores input gamma-ray events, a Data Model database describes observations, instruments, targets, analysis types, and dynamically created jobs, and a Results database stores the products of analysis jobs and candidate science alerts. `DL3Merger`, `SubmitJob`, and `UpdateJobStatus` daemons coordinate ingestion and execution, while Slurm acts as the Task Manager and Gammapy plus RTAPH provide the analysis engines [2509.18945].

The supported analyses include target significance and flux estimation, sky maps, light curves, and blind searches for sources within the field of view. In simulated tests, SAG-SCI detected steady sources, gamma-ray flares, and serendipitous transients; it recovered flux values consistent with the simulated value within statistical uncertainties of about 35% in individual light-curve bins, and a 20% offset in the assumed spectral index produced a systematic flux error of about 30% [2509.18945]. This suggests that ACADA’s science-alert path is designed not only for speed but also for quantified uncertainty propagation at the alert-generation stage.

## 4. Monitoring, logging, alarms, and online data quality

ACADA’s operational awareness layer is implemented by MON, the Logging subsystem, the Array Alarm System, and online data-quality services in SAG. MON is responsible for monitoring and logging the overall array at each CTA site by acquiring monitoring points and logs from telescopes, calibration devices, environmental instruments, and ACADA processes. It makes monitoring and logging data immediately available for the operator interface and quick-look quality checks, and stores them for later inspection. CTA monitoring is treated explicitly as a big-data problem, with about 200,000 monitoring points sampled at 1 to 5 Hz, a maximum data rate for monitoring plus alarms of about 26 Mbps, and an additional logging data rate of about 1 Gbps [2109.05770].

The implementation reflects those rates. ACS provides the component framework, OPC UA is used for device access, Apache Avro defines schemas, Apache Kafka transports monitoring and log streams, Cassandra stores long-term monitoring data and alarms, Filebeat and Logstash ship and process logs, and Docker packages the services for deployment and scaling. MON contains a Monitoring System, Monitoring and Logging Supervisor, Environmental Conditions Inspector, Monitoring Value Inspector, Logging System, and Logs Analyzer; AAS contains Alarm Collector, Alarm Filter, Alarm Rules Database, Alarm Storage, and AAS Supervisor [2109.05770].

In the real-time science path, online data quality is handled inside SAG by a dedicated DQ engine. The rta-dq-lib library was proposed for CTA to perform online data-quality analysis on data arriving at event rates of tens of kHz. It is available in Python for rapid prototyping and in C++ for maximum performance, and it translates XML configuration files into a directed acyclic computational graph that encodes data sources, executor nodes, quality checks, and output nodes. The model supports thread-level parallelization and condition levels for each indicator—optimal, warning, and alarm—so that operators and support astronomers can be notified immediately and observations interrupted when critical conditions are met [2105.08648].

The coupling between monitoring, alarms, and science processing is deliberate. Monitoring Value Inspector raises alarms when a value remains above threshold for a predefined duration; Logs Analyzer derives alarms from log patterns; SAG-DQ provides data-quality status that can suppress or flag science alerts. A plausible implication is that ACADA is architected so that scientific significance is never interpreted independently of instrument state and environment.

## 5. Configuration, development tooling, and operator interfaces

Configuration in ACADA is centralized but multi-layered. The Array Configuration Database is implemented as a FastAPI plus SQLAlchemy OpenAPI service using JSON and JSON Schema, with XML support, versioning, validation, and transactions; it can generate type-safe clients in multiple languages. HMI provides the operator and support astronomer interface, while Central Control uses a scripting language to execute complex telescope and calibration procedures. Redis is used for RM persistence and as an HMI backend broker, and the broader implementation uses C++, Java, Python, and JavaScript according to subsystem needs [2606.18798].

Recent work has extended this configuration-centric view into development tooling. CTAgent, an LLM-based assistant for CTAO engineering, targets ACADA artifacts such as documents, specifications, and configuration structures. It is implemented as a narrow-waist agentic system that normalizes source files, invokes specialized LLM “experts,” validates generated code with `ast.parse` and structural checks, and emits strongly typed Python data models based on `pydantic.BaseModel`. A `ConfigurationWrapper` stub illustrates how these models could attach to ACADA connectors and configuration processors, and future work explicitly envisages connections to telemetry, configuration, and CI/CD APIs while preserving a natural-language interface for developers and operators [2510.01299].

From an encyclopedic perspective, this development tooling is significant because it shows that ACADA’s complexity is no longer confined to real-time control loops and data transport. The maintenance of schemas, configuration processors, and project conventions has itself become an infrastructure problem. This suggests a transition from handwritten glue code toward auditable, validation-first generation of data models and interface definitions, while leaving the live control loops outside the scope of direct LLM action.

## 6. Reliability, scalability, and comparative design patterns

ACADA’s reliability strategy is centered on supervision trees, restart isolation, persistent state, and distributed storage. RM implements supervisors inspired by Erlang/OTP: a Root Supervisor and subordinate supervisors initialize child components, poll their status, replace failed components, and restore state through a Persistence Service. Core functionality must be available for at least 99% of the scheduled observation time, core ACADA functionality must restart within 2 minutes, and full monitoring and alarms must be restored within 5 minutes [2606.18798].

Scalability is addressed by design choices at several layers. CTAO will operate more than 60 telescopes across two sites, with up to eight active subarrays, multi-gigabit-per-second telescope streams, and site-wide monitoring of approximately 200,000 data points. ACADA therefore combines ACS supervision with horizontally scalable tools such as Kafka, Cassandra, Slurm, Redis, Docker, and database-backed pipeline orchestration in SAG-SCI [2606.18798]. The first major release capable of operating a single LST was deployed in 2023, and integration work with LST-1 validated the overall architecture while exposing interface and performance issues that were addressed in later releases [2606.18798].

Comparable design patterns recur in other large scientific control/DAQ systems. Advanced LIGO’s real-time system uses model-based control generation, isolated real-time kernel execution, shared-memory data paths, and a distinct supervisory layer based on EPICS, illustrating the same separation between hard real-time loops and higher-level orchestration [2005.00219]. The South Pole Telescope’s Generic Control Program combines a control layer, a mediator layer, embedded readout boards, and synchronized frame-based archiving, showing an analogous division between autonomous front ends and a central monitoring and archive process [1210.4966]. EUDAQ generalizes global run control, central event building, synchronized recording, and plugin-style device integration for heterogeneous beam-test apparatus [1909.13725]. A SoC-FPGA control framework based on gRPC likewise shows how configuration, calibration, and external-bus access can be moved onto embedded processors while time-critical acquisition remains in programmable logic, a pattern that aligns closely with ACADA’s broader control/data split [2011.00112].

These comparisons do not imply identity of purpose or implementation. Rather, they indicate that ACADA exemplifies a mature architectural family in which deterministic acquisition, declarative configuration, distributed supervision, and rapid operator feedback are co-designed. What distinguishes CTAO’s ACADA within that family is the explicit fusion of observatory control, on-site data reduction, and science-alert generation into one operational stack, so that observing strategy itself can change on the basis of real-time scientific inference [2509.18945].

Source: https://www.emergentmind.com/topics/control-and-data-acquisition-software-acada