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 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

The Software side

The overall idea is to have local processes gathering data from hardware attached to its PC and publishing it into some common space. Asynchronously a global process gathers that information and acts as a backend to the final piece: a user interface.

Monitorables Collector (MC)

This application 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 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 the GUI application 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.


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
  SyncHistos informative once per orbit 1 KiB 0x4329


If the ECAL DAQ software would also produce Monitorables, 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: r1 - 2006-07-18 - 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback