Tracker monitoring in the control room with Iguana and in a Internet cafe' with a Java client

M.S.Mennea,A. Regano,G. Zito
Bari Cms Tracker Visualization Group
Why I don't use Powerpoint
Presentation done by Giuseppe Zito to the CMS WORKSHOP ON b/tau PHYSICS held in Bari 28.05 - 01.06 2004


The main use of Iguanacms for monitoring will be as an event display. Looking at the last events taken is one of the best ways to check that everything is ok. Taking for granted this use of Iguanacms, I will speak here about using it as something completely new: as a monitoring data display.

Tracker Visualisation: a nightmare

Build a map of the tracker

The tracker map

The final result with: overlayed, separated modules. This is a 1360x2800 image that can be saved on disk(ps format) or printed without losing information on a A1 sheet.To see this image now you need to scroll it but you can assume that in the control room we can afford a high resolution monitor that shows the complete image(in landscape format).(On my 21" monitor the maximum resolution is already 1920x1440)
This image is a kind of map of the tracker where you can display any information concerning the tracker. The simplest way to use it is to display the last few events overlayed:this will show immediately if there are holes or hot spots. The same display can be done plotting the signal in their position as a set of points(in this case the simhits). Other information that can be shown at this level: dead/busy strips, temperatures,results of periodic checks on all modules(for example comparison with a reference histogram for each module)...

Possible use of the tracker map in control room

Going to the level of the single channel

The tracker map needs some optimization.Your help for this is essential. There are some parts where the modules are not seen clearly. Using a triangle for stereo modules is the best solution?Which color is best?
Anyhow it can be thought as a scatter plot with an entry for each module. Up to now we have not implemented a zoom of this map (and we don't know if this is necessary). Instead if you want to go to the level of the single channel, you have to select a single layer:endcap; barrel . The layer will be zoomable in future and can represent the information down to the level of the single channel. At this level it should be possible to check for example the position of the signal with the position of faulty channels. At this level of detail we can introduce many different representations of informations: for example drawing fired strips ,writing the value of the information represented,... A popup menu' (not yet available) should allow the user to tailor the representation to his needs.At the module level it should be possible also to look directly at normal histograms using this map only as a convenient way to access the relevant histograms (you click on the module and get all module's histograms).

Accessing non event data in Iguanacms

We are implementing this software in Iguanacms integrating it with the normal 3D/2D event display. The tracker map is only one of the ways of representing the event. So you can compare the 2D view with the 3D view. My suggestion is that some monitoring data(non event data) could be feeded to Iguanacms presenting this data with the same format of event data: like "fake events". So you can think of a fake event with dead strips, another with temperatures , etc Also it is necessary to access histograms. Perhaps we can implement one or more data servers that could read the monitoring data from sensors and/or database and format them as event data.

And now ,out of the control room, in a Internet Cafe somewhere in the world...

The same 2D representation produced by a light Java client.
Light since it knows nothing about Cms software and hardware, it only implements the Gui. When this program needs the tracker description and the data to display, it sends the request to data servers using normal URI.
The data is transferred with XML+SOAP+WDSL : i.e. using Web services protocol.
We are working on this but we plan to have for Chep04 a working prototype. By now I can show you the schema of the tracker description and the full tracker description in xml
The program accepts any detector description that follows the schema: so it can be used also for test beam and to follow the construction tests.
I have used Castor to automatically generate the Java classes implementing the tracker model. The data server is created using Axis+Tomcat. We are planning to use the data in the Construction DB for a first test and then try with normal events.Data from the construction DB will be presented as "fake events". The events themselves are described by a schema and should travel in xml(!?).

Web Services in the control room?

(I don't know if what I say here makes sense:anyhow ...) Perhaps implementing web services access for monitoring is not our biggest priority, but I think that the "Web services approach" can be very helpful in planning the detector monitoring services. This means ,in my opinion, the following: each quantity to be monitored should have a unique URI .This should apply to any resource and also to collections of resources(events, etc). We define our interface to the monitoring resources as a web api.
This approach should have the following benefits:


Pagina curata da Giuseppe Zito:
ultimo aggiornamento: