Pixel DSS Review Minutes - M. Votova, scribe

Meeting: April 3, 2008

Eileen Berman - moderator
Margaret Votava - scribe
Kevin Krause - reviewer
Jim Kowalkowski - reviewer
Chung Khim - guest
Joel Butler - guest
Gennady Lukhanin  - reviewer
Slawek Tkacyzk - guest
Charles Newsom - guest
Christian Veelken -author
Lalith Perera - guest
Piero Giorio Verdini - offline reviewer
Stefan  Lueders - offline reviewer
Jeronimo Vidal - offline reviewer
Umesh - offline guest

Charles Newsom has volunteered to organize getting reviewer documentation
web accessible. Since the meeting, it is now available at:


Reviewers should use the word document as a reference for the slide
presentation by Christian. It includes data structure descriptions. 
can go back to the code to look at details.

The author is more interested in reviewers looking at the design for
missing features rather than at the code itself. Have error conditions
been handled? The author feels good about the quality of the 
The code is highly configurable so that configuration changes can
be handled without modifying the source code. How robust is
it against downloading the wrong configuration?

There were strip DCS people attending this meeting as well.
Frank, Giorgio, and Andromachi Tsirou did strips safety sytsems.
Pixel was a growth after that. Reviewers should consider how to better
understand differences
between two systems. Strips will be reviewed next.

PVSS is used as user interface. The primary safety system
is on the PLC. PVSS is primarily used a
 monitoring system and will serve as one of several second level safety
 backups in case of PLC failurea.

PVSS runs under windows, system level servers under SLF4.
Interlocks will be deployed on CMS if operators ignore DCS
warning or the DCS fails. The only interaction with xdaq is in
ramping up power supplies are ramped up during intialization
as well as configuration and downloading.

Maintainable - can it be all handled with configuration changes
and not source code changes. Can new people to the source
be able to make changes? There are mass generation scripts
to generate the code (same as strips) to keep them the same.

Config parameters will be taken from Oracle (is now excel).
This is one of the differences between Strips and Pixels. Pixels
are rapidly  converging on Oracle and strips (or did use) Excel tables.

Limited simulation of the code by the manufacturers.

Code hasn't been changed much since the end of January.
Virtually complete now that PLC GUI is done.

Eileen will start a discussion this week of when the followup meeting
will be. Tentatively this is April 24th.

There was a decision to look at commonalities between the the Pixel
and Strips DCS systems and decide after the strip review whether an
additional meeting was needed to discuss these

Questions from the author slides:
The PVSS information is just background information, and not
part of the review.

Why is there a block move from DV400 to PVSS? Not there
anymore. (page 12)

Page 20. Is there a check if the heartbeat is lost? Interlocks
will go to low. Users manually turn things on/off when down
for maintenance. Don't want to turn off/on detector very

Is there are copy of the code somewhere? Charles will
get the information up.
Is the PLC code available at CERN? Yes.
Charles will send email when docs are updated.

How to we preserve integrity?
Should we have a joint review with strips for integration
purposes and verification. There is already too much
material in this first review. Let's no overload it.
Maybe that happens as phase II.
Maybe some issues can be tabled for phase II.

Are we looking at tracking code too? No just pixel.

Will we talk about how to split the workload? There are
different philosophies. This review will not split, this can
be revisited as reviewers start the process and they
should communicate that back to the review panel.
Will the reviewers meet among themselves? Typically
nothing formal. Feel free to touch base with each other
as needed.