The Online Observation Quality System Implementation for the ASTRI Mini-Array Project

TL;DR

This paper presents the implementation of the Online Observation Quality System (OOQS) for the ASTRI Mini-Array, enabling real-time data quality checks and feedback for high-energy gamma-ray observations using Cherenkov telescopes.

Contribution

The paper introduces the OOQS as a novel real-time data quality monitoring system integrated into the ASTRI Mini-Array's SCADA software, utilizing distributed components for high data rate handling.

Findings

Real-time data quality checks improve observation efficiency.

Distributed architecture handles data rates up to 1.15 Gb/s.

Feedback system enables prompt corrective actions.

Abstract

The ASTRI Mini-Array project, led by the Italian National Institute for Astrophysics, aims to construct and operate nine Imaging Atmospheric Cherenkov Telescopes for high-energy gamma-ray source study and stellar intensity interferometry. Located at the Teide Astronomical Observatory in Tenerife, the project's software is essential for remote operation, emphasizing the need for prompt feedback on observations. This contribution introduces the Online Observation Quality System (OOQS) as part of the Supervisory Control And Data Acquisition (SCADA) software. OOQS performs real-time data quality checks on data from Cherenkov cameras and Intensity Interferometry instruments. It provides feedback to SCADA and operators, highlighting abnormal conditions and ensuring quick corrective actions for optimal observations. Results are archived for operator visualization and further analysis. The OOQS data quality pipeline prototype utilizes a distributed application with three main components to handle the maximum array data rate of 1.15 Gb/s. The first is a Kafka consumer that manages the data stream from the Array Data Acquisition System through Apache Kafka, handling the data serialization and deserialization involved in the transmission. The data stream is divided into batches of data written in files. The second component monitors new files and conducts analyses using the Slurm workload scheduler, leveraging its parallel processing capabilities and scalability. Finally, the process results are collected by the last component and stored in the Quality Archive.