Monitoring software for the ECAL OD Electronics and Hardware

Purpose

To have a visual interface that allows rapid identification of abnormal conditions in the ECAL OD Electronics.

To keep up-to-date information concerning the synchronisation of the SLB cards in the trigger system.

To monitor the status of the ECAL TTC system.

To monitor the health of the PCs used in the the ECAL DAQ.

The Software side

The overall idea is to have local processes that gather data from hardware attached to its PC and return it to a global process. This global process provides an image of the whole system and provides a backend to the final piece: a user interface.

Monitorables Collector (MC)

This should be an addon to the Device Supervisors, and use them to access the Monitorables, perhaps using XDAQ monitor application.

Monitoring Overseer (MO)

This XDaqApplication runs in a single location and effectively centralises Monitorables asked from the Collectors.

It should read a configuration file specifying how which Monitorable should be handled (periodic collection, on demand, source, etc).

The Overseer will act as an image of the whole system (for the Displayer or other applications to query) and as a cache, so as to avoid that data is polled too often, particularly if it is voluminous.

This way applications should subscribe to Monitorables from the Overseer. If the Monitorable changes states, then subscribers are notified of changes. The Overseer should also accept requests to force a refresh of a certain Monitorable.

Monitoring Displayer (MD)

This is a GUI that processes and displays the Monitorables.

It should subscribe to Monitorables from the Overseer and, if requested by the user, force their update.

Monitoring Logger (ML)

Another application that subscribes Monitorables from the Overseer and writes them into some database or logging mechanism for posterior retrieval.

Available tools

For the Displayer we can use the Physics and Data Quality Monitoring infrastructure

How to get this together with XDAQ?

The Hardware side

Electronics in S2D:

• ECAL = 4 partitions: E{B,E}{+,-}
• EE{+,-} = 6 VME crates
• EB{+,-} = 12 VME crates
• VME crate = 3 triplets
• 1 triplet = DCC + TCC (w/ SLBs) + CCS (+ 3 TCC & SLBs for EE)

• Readout PCs

Electronics in S1:

• TTC
• TTC PC

Monitorables

These need to be defined per piece of hardware.

• Context refers to under which card this monitorable is defined
• ID is an unique string defining the name of the monitorable
• Type can be used to define how critical this particular Monitorable is in defining the state of its context, so as to prioritize display
• Frequency should specify if this Monitorable is to be polled on demand or regularly, and if so at what intervals
• Size specifies the amount of data that this Monitorable requires
• Offset refers to the location of this Monitorable's information inside the register/memory space of its context.

Context	ID	Type	Frequency	Size	Offset
?
Caen
CCS
DCC
DCC-TC
	SyncHistos	check trigger sync	per minute	1 KiB	0xdeadbeef
PC
SLB
TCC
TTC