Process Types

The DAQ system distinguishes four different process categories as shown in Fig. A.2. The Controllersdirectly interact with the hardware and read out the data. Each hardware component is controlled by one Controller process. The Controllers push the data to intermediateReceivers, which perform further processing and store the data. The Receivers also provide an interface that allows other processes to sample processed data. Readersactively request data from the Receivers at a rate different from the actual data-taking rate. The data or derived quantities are then available for display and monitoring purposes. Managerprocesses are not involved in the

data transport but control the data-taking.

Manager

Display

Reader Controller

Hardware Receiver

DataControl

File

Figure A.2: Types of processes in the DAQ system.

Controllers

Each controller has an associated piece of hardware for which the states and transitions are implemented. Furthermore, most of the controllers produce data which have to be sent to one or more receivers. The data is filled into an object of a particular event class. Any external process which wants to receive this data has to SubscribeandUnsubscribeitself to the controller as a data receiver. For each subscriber, one or more data objects are packed intoFolderswhich are written into a buffer on the controllers host machine. Each buffer is connected to the respective subscriber by a CORBA connection and the sending of the data occurs asynchronously in a separate thread.

Table A.1 lists some example controllers in the H.E.S.S. DAQ system with their function, states, and data types they produce together with their approximate event rates.

Receivers

The main data stream is produced by the cameras which generate events with a size of 1.5 kB.

At the maximum system trigger rate of 400 Hz, this yields a maximum data rate of 2.4 MB/s for four telescopes, resulting in roughly 50 GB of data per observation night. The data rates from the other subsystems are significantly smaller.

The data Receivers have to store the data sent by Controllers in the local memory in order to allow other processes to fetch the data at a slower rate for monitoring purposes, and write the data to a file for archiving. This mechanism is implemented in a single generic process – theReceiver – which is able to receive and process any given H.E.S.S. data event. In the Configuretransition, theReceiverreads its assigned Controller from the database, subscribes itself as a data receiver at the controller, and establishes a buffered CORBA connection. When Starting, the receiver opens a file and sequentially processes all events in its input buffer until it isStopped and the files are being closed. This mechanism works well for all data with an input rate up to 100 Hz.

Since the camera data is sent as an unbuffered raw byte stream at a high data rate, there is a dedicated Receiver for this data – the CameraReader. This process has to provide an event buffer for the data of each telescope camera. The individual telescope events have to be merged into a single shower event using a unique event number provided by the central trigger. This event-building is performed online and the data is directly stored in the ROOT-format which is

Controller Name

Function Data Types Safe Ready Running 1 process per telescope

Tracking Drive system Tracking 3 Hz, Monitoring 1 Hz

Monitoring disabled 400 V 1 kV

CameraLid Camera lid closed open open

Flatfield Flatfield LED

Temperature 1 Hz off connected measuring unique process

CentralTrigger Central trigger Trigger bunch 0.2 Hz Meteo Meteo station Meteo event 1 Hz off connected measuring Table A.1: Examples of hardwareControllersin the DAQ system with a brief description of their types and rates of data output, and the meaning of their states.

used for later offline analysis. Since the rate at which the data is processed is lower than the data rate coming from the telescope cameras, many instances of the CameraReader– Nodes – distributed over different machines are required. The cameras send the data to one Node for a period of 5 s and then switch to another Node. The states RunningandPaused are used to indicate the status of each Node, busy with data processing or available to receive new data, respectively. For observations with the full array of four telescopes, 20 Nodes are used routinely, providing a sufficient safety margin in order to avoid data loss in case of an unexpected increase of the data rate from the cameras.

Readers

Data readers fetch the data objects inFoldersfrom the receivers for either duplicating a data stream, e.g. in order to store meteo data associated to an observation run, or for displaying purposes in the slow control of the array status. The first case is implemented by copying the object and writing it to a file.

The task of displaying the data is performed by a generic process using the ROOT graphics engine. This process – the Displayer – is solely configured by a database entry containing the type of the event which it has to fetch from a Receiver, the type of quantity contained in the event, the refresh rate, and the way in which the quantity should be displayed. During the Configurestep, theDisplayerreads its assigned database entries and opens dedicated graphics canvases. In the Running state it fetches the data from the assigned Receiver and draws the

relevant quantities. Figure A.3 shows some examples of the various possibilities to configure theDisplayer.

An intuitive and functional visualisation of the current state of the drive system cannot be easily implemented with the genericDisplayersince it involves many different quantities in a rather complex interplay. Therefore, a dedicatedTracking Displaywas developed, conceptually similar to the other Reader processes with respect to the underlying data transfer and at the same time providing a compact display of the relevant status information of all telescopes in the array. Figure A.4 shows the tracking display during an observation run.

Managers

Managers are used for the state control of groups of processes in the central DAQ system.

Furthermore, they serve as cross points in the message passing system. The functionality of Managers will be discussed in the next section.