The Controls and Configuration Software of the Atlas Data Acquisition System for LHC Run 2. (April 2020)

• Record Type: Journal Article
• Authors: Kazarov, A; Aleksandrov, I; Avolio, G; Caprini, M; Chitan, A; Corso Radu, A; Kazymov, A; Lehmann Miotto, G; Mineev, M; Santos, A; Soloviev, I; Vasile, M; Unel, G
• Is Part Of: Journal of physics. Volume 1525(2020)
• Publication Date: 2020-04
• Subjects: Physics -- Congresses; 530.5
• DOI: 10.1088/1742-6596/1525/1/012036
• Languages: English
• ISSNs: 1742-6588

Abstract

Abstract: The ATLAS experiment at the Large Hadron Collider (LHC) operated very successfully in the years 2008 to 2013, a period identified as Run 1. ATLAS achieved an overall data-taking efficiency of 94%, largely constrained by the irreducible dead-time introduced to accommodate the limitations of the detector read-out electronics. Out of the 6% dead-time only about 15% could be attributed to the central trigger and DAQ system, and out of these, a negligible fraction was due to the Control and Configuration sub-system. Despite these achievements, and in order to improve the efficiency of the whole DAQ system in Run 2 (2015-2018), the first long LHC shutdown (2013-2014) was used to carry out a complete revision of the control and configuration software. The goals were three-fold: properly accommodate additional requirements that could not be seamlessly included during steady operation of the system; re-factor software that had been repeatedly modified to include new features, thus becoming less maintainable; and seize the opportunity of modernizing software written even before Run 1, thus profiting from the rapid evolution in IT technologies. This upgrade was carried out retaining the important constraint of minimally impacting the mode of operation of the system and public APIs, in order to maximize the acceptance of the changes by the large user community. This paper presents, using a few selected examples, how the work was approached and which new technologies were introduced into the ATLAS DAQ system, and how they were performing in course of Run 2. Despite these being specific to this system, many solutions can be considered and adapted to different distributed DAQ systems.