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.

SLB Monitoring

A Monitor process collects flashlists whose collection triggers the saving of the SLB histograms directly in the CondDB.

These histograms are produced in the ROOT format by the SLBMonitoringProducer.

The GUI then interfaces the CondDB retrieving the latest histograms.

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 each 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 a posteriori 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 USC55 level S2, row D:

  • ECAL = 4 partitions: E{B,E}{+,-}
  • EE{+,-} = 6 VME crates
  • EB{+,-} = 12 VME crates
  • VME E{B,E} crate = 3 {tri,hex}plets
  • 1 {tri,hex}plet = DCC + CCS + {1,4} TCC {68,48} (w/ SLBs)

  • 18 Readout PCs

Electronics in USC level S1:

  • TTC crate
  • 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.

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


This topic: Main > TWikiUsers > AndreDavid > CmsEcalMonitorables
Topic revision: r5 - 2006-09-19 - AndreDavid
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback