The CUORE data acquisition and slow control software, called Apollo, is designed with an high level of modularity, to provide an easy way to scale the number of acquired channels, and to allow smooth integration with the various subsystems of the experi- mental apparatus.
Written in the C++ programming language, Apollo is almost completely a custom software, the only exceptions being the National Instruments drivers used to interface with the DAQ boards, and the ROOT2 software package, used for online data quality
monitoring and for data storage.
Apollois composed by several processes distributed over different computers running Scientific Linux, an operating system specifically developed at CERN and Fermilab for scientific purposes. Communication and data transfer between different processes occur via standard network connections. Besides providing flexibility and scalability, the choice of using a distributed system was dictated by the possibility to exploit standard and cheap computing resources.
All the Apollo processes can access the CUORE database, which is used to store the geometric description of the apparatus, the mappings and the settings of the various readout components, informations concerning the performed measurements, as well as relevant quantities evaluated in the off-line analysis. The purpose of the database is to provide a standard and unified interface where all the informations are stored homogeneously and can be easily correlated to each other.
In the following a description of the processes composing the Apollo system will be given. A sketch of its main components is shown in fig.6.7.
DataReader
this is the basic process in the data acquisition chain. It continuously reads data from the DAQ boards and writes it into shared memories. As shown in fig. 6.8, shared memories can be accessed by other components of the Apollo system for different purposes, such as applying trigger algorithms, dumping the continuous data stream into files or looking at the data with a software oscilloscope. One DataReader process, running on a separate computer, exists for each data ac- quisition chassis. The DataReader is also responsible for applying triggering and digital filtering. Since it is in charge of acquiring only a subset of the channels in the whole apparatus, it cannot have an overall knowledge of the status of the system. As a consequence, at this level the trigger algorithms only set a flag into the data stream, and the event building is demanded to a separate process, able to handle all the acquired channels in parallel. The DataReader also allows to save on file the continuous data streams form each acquired channel. Given the rather low sampling frequency necessary to record the signals from bolomet- ric detectors, the additional required storage space can be easily afforded. This 2
DAQ Crate #N
DataReader
DataReader SlowServer
and Bessel boards Electronics Front End PulserController DAQ Crate #1 Builder MsgLogger DaqServer GUI
Detectors Pulser Boards
optical link copper link TCP/IP or interprocess communication
Figure 6.7: Schematic representation of the data acquisition system architecture. The fundamental hard- ware components are depicted as rectangular boxes, while the main software components are represented as blue ellipses.
feature can be used to reprocess the data offline for any kind of purpose, such as investigating possible problems in the detector operation or searching for low energy events with an arbitrarily sophisticated trigger algorithm.
event building trigger shared memory from DAQ boards write to disk oscilloscope software
Figure 6.8: Sketch of the components accessing the shared memory containing the acquired data. One of such shared memories exists for each acquired channel. In case one of the components resides on a different computer the shared memory is mirrored over the network by mean of a couple of DataSender/DataReceiver processes.
EventBuilder
this process reads the continuous data written in the shared memories by the DataReader and searches for trigger flags. At this level cross channels informa- tions are available, as signals from all channels are processed in parallel. By accessing the database, the EventBuilder can identify group of channels based on the spatial distance of the crystals they come from, on the particular front-end board they belong to, or any other meaningful criterion. Using these informa- tions, events are built as synchronous groups of waveforms coming from several different detectors. The events are then stored on disk for offline processing us- ing a customized ROOT file format. The EventBuilder process is actually an instance of Diana, the CUORE offline analysis software, running with a particu- lar configuration. Diana has an highly modular structure that allows to plug-in specific analysis packages and event-based filters using a simple configuration file. Therefore, besides the basic event building and data storage operations, the EventBuilder has the possibility to perform a first level online analysis of the acquired data, which allows a prompt monitoring of the detector conditions. PulserController
this process is dedicated to the management of the pulser control system. As discussed in chapter 3, the purpose of this subsystem is to send fixed energy calibration pulses on the detectors to monitor their response on short time scales. The PulserController periodically fires heater pulses on the bolometers and also sends a synchronous signal to the DAQ boards that is used for flagging purposes
in the event building phase. The pulser control subsystem will be discussed in sec. 6.6.1.
DataSender and DataReceiver
these two optional processes are present in case the Builder and the DataReader do not reside in the same host. This will happen as soon as more than one DAQ chassis is present in the system. These processes are responsible to perform the mirroring of the shared memories containing the acquired data over the network. Despite their main purpose is to export the shared memories on the host where the EventBuilder resides, they can be used for any other purpose, for example for exporting the data on a remote machine where the detector timelines can be watched almost in real time with a software oscilloscope.
MsgLogger
this process accepts messages from all the components of the Apollo system, and writes them to log files. It also handles informations about the status of running processes. A process can inform the message logger about its status or ask for the status of any other running program.
DaqServer
this process has the control over the whole system. It performs all the operations that are needed to start or stop a measurement, and monitors the overall system status during data acquisition.
ApolloGUI
this is the Apollo graphical user interface. It communicates with the DaqServer via network to perform standard operations such as starting or stopping a mea- surement. It includes some basic monitoring tools, such as a software oscilloscope to look at continuous signals on the bolometers, and a display window containing several plots summarizing the status of the measurement.
SlowServer
this process is responsible for hiding the implementation details of the protocols used to communicate with various hardware components of the system, such as the front-end electronics, Bessel filters, power supplies and pulser control boards. It provides a simple network interface that can be used by any other Apollo pro- cess to query or modify the status of the electronics system. During standard measurements the interaction with this process is limited to the pulser boards, while it is massively involved in the measurements dedicated to the characteriza- tion of the detectors (see sec. 6.7).
6.4.1
The trigger
Given the low event rate and the slow sampling frequency of bolometric detectors, it was decided to implement a software trigger, which reduces the costs of the system and allows more customizable configurations. Because of the wide spread in the noise and pulse shape of different detectors, an optimal threshold can be achieved at low energy only if the trigger is tuned on the specific features of the signal of each bolometer.
The object-oriented architecture of the Apollo software allowed to build the trigger engine in a modular structure that is transparent to the particular algorithm that is implemented. This permits to easily plug-in different algorithms on different channels. Four independent triggers can search for events at the same time on each channel. They can be based on different algorithms, or even on the same algorithm run with different parameters. This feature could be used for several purposes: for example one trigger could be tuned for high energy 0νββ events, while another one could be optimized for the search of low energy events.
At present two distinct algorithms have been implemented that are usually run in parallel on each channel. The first one is a simple random trigger, which has the purpose of acquiring the baseline samples that are used to produce the noise power spectra required by the optimum filter technique, used for signal amplitude evaluation (see sec.3.7). The other algorithm has the purpose of triggering physical pulses. It is based on the simple concept sketched in the left plot of fig. 6.9: the difference in the signal amplitude of two samples at a fixed time distance (average) is compared with a reference value (threshold); if this quantity is bigger than the threshold for at least a given number of consecutive samplings, a trigger flag is set in the data stream on the first sample that exceeded the threshold.
time [s] threshold average 0.6 0.7 0.8 0.9 1 1.1 1.2 amplitude [mV] 0 50 100 150 200 250 300 350 400 Signal amplitude [mV] 0 2 4 6 8 10 12 14 16 18 20 Trigger efficiency 0 0.2 0.4 0.6 0.8 1
Figure 6.9: Simple trigger algorithm implemented in Apollo. The left plot sketches the basic concept of the trigger implementation: the difference in the amplitude of two samples at a fixed distance must be bigger than a certain reference threshold for the trigger to fire. The right plot shows an example of the achieved trigger threshold on a CUORICINO-like pulse obtained from a Monte Carlo simulation.
A Monte Carlo simulation specifically developed by the CUORE collaboration to reproduce the thermal pulses was used to check the performance of the trigger. As shown in the right plot of fig. 6.9, a threshold as low as few mV (corresponding to less than 50 keV) can be achieved with this simple algorithm.
Given the very naive approach of the trigger algorithm implemented so far, it is likely that a more sophisticated one will be developed for CUORE. In fact the main aim of this algorithm was to have the possibility to reproduce the whole data acquisition chain in the validation measurements performed on real detectors that will be discussed in the following sections. As will be shown, the implemented trigger revealed to be fairly adequate for this purpose.