Monitoring software for the ECAL OD Electronics and Hardware

This is a draft


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 XDaqApplication runs in each and every PC and should not be very intelligent nor take much memory.

Hence, it should provide only the basic infrastructure (drivers, etc) to access the different types of Monitorables that can conceivably exist.

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 Collectors this might be appropriate XDAQ monitor application

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

How to get these two together?

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


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 TypeSorted ascending Frequency Size Offset
  SyncHistos check trigger sync per minute 1 KiB 0xdeadbeef


If the ECAL DAQ software would also produce Monitorables that the Overseer could gather, it would be possible to re-use this framework for the monitoring of the ECAL DAQ software status.

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2006-07-19 - AndreDavid
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback