The data acquisition for the AURIGA RUN2
The data acquisition (daq) system for the AURIGA RUN2 has been re-designed from scratch, using the “state of the art” Object Oriented (OO) methodology for software engineering, the C++ programming language, the CORBA architecture, and the powerful development tools and libraries provided by the Linux software community (for instance, the QT framework package and the KDevelop integrated development environment (IDE)).
The daq architecture, sketched in fig. 1, consists of a set of processes, each specialized on a given task; the interprocess communications are implemented through the CORBA middleware while the interface code has been organized in a single shared library, the Process Control Library (PCL). Any exchanged information or data packet is encapsulated inside an IGWD frame. The frame has not originally designed for internal storage and processing; however, the IGWD format has demonstrated to be flexible enough for data acquisition applications with a tolerable overhead, thus simplifying the design and handling of the disk I/O subsystem. Each process has multithreaded functionalities, and the entire system can be modeled as the standard client/server architecture. Usually, the specific implementation of a process turns out to be very concise and simple as an uniform communication and control interface has been designed and entirely implemented inside the PCL library, both on client and server sides.
Each front-end process is devoted to a hardware device. For the current daq configuration we devise 3 processes:
The independence of the front-end processes contributes to avoid system blocking or deadlock situations in the case of device faults, providing meanwhile for a high flexibility. To give an example, the front-end processes can be distributed over different computers of a LAN.
The builder (BLD) process is the core of the acquisition system; it deals with the following main tasks: i) the request of the partial data acquired by the front-end processes; ii) the check of mutual consistency of data (e.g. the control of time stamping to get a synchronization with UTC within 1 μs); iii) the preliminary processing of data (e.g. the de-multiplexing of the auxiliary ADC channels); vi) the format of the complete frames, (i.e. ready for storage or for clients); v) the production of daq information (run number and current time); vi) the recording of on-line veto flags in the frames (to account for maintenance operations of the detector). In addition, the queue subsystem, provided by the PCL, adds an important buffering function to the BLD process, which takes care of the synchronization of the device-bound processes (front-end and disk).
The disk (DSK) process makes use of a special disk-based queue (the persistent queue provided by the PCL) to permanently store the frames on disks. To avoid data losses in the case of a disk crash, the permanent queue allows the mirroring of the frames. It should be noticed that the current hard disk technology is able to store up to one month of data in a single disk, and so we could not afford to overlook this eventuality. The DSK also provides a semi-automatic procedure to swap the acquisition disks without stopping the acquisition run. This feature allows for long periods of data taking, spanning data over many disks. The swapping of physical disks without halting the operating system can be safely done with the modern hot-swap technology.
The LOG process collects the log messages produced by daq processes, included itself; the log messages are first collected in a special multi-user queue and then stored on a disk. The LOG clients (running also on remote PCs) can access to the log messages queues at the same time and display the log history.
The Graphical User Interface (GUI) is the most complicate process of the daq system, although it is only a client and does not require the PCL server features. The GUI allows to enter commands which change the state of daq processes. The GUI also displays the status of any active daq process, its memorization subsystem and the recent log messages (obtained from the LOG process). The GUI allows the dispatching of the current veto flags to the BLD process. Finally, the GUI displays other information, such as acquisition run number and time, and provides a flexible sound alarm subsystem, which can react to specific log messages or conditions on the process status. The GUI has been developed in the QT framework  as fully multithreaded process. It is worth noticing that the PCL design allows many GUIs to be active at the same time.