Agenda of the BaBar Operations Workshop
At SLAC, Feb. 14 to 15
Detector Monitoring, Alarms and Interlocks
Friday 9:00 to 12:30 SCS 3rd floor conference rooms
Report from the Paris workshop George Vasileiadis
Description of the SIAM Perry Anthony
General Montioring Board Tom Meyer
Summaries of requirements from
the systems.
SVT David Kirkby
DCH David Coupal for Janice McKenna
DIRC George Vasileiadis
EMC Tom Meyer
IFR Pierluigi Paolucci
Discussion of common needs.
Database issues Gerry Abrams
Calibration
Friday 14:00 to 17:00 Orange Room
Machine operation Tom Mattison
Calibration software tools Gregory Dubois-Felsmann
Calibration questionnaire example David Brown
System calibration scenarios
SVT Natalie Roe
DCH Gabriella Sciolla
EMC John Dowdell
IFR Nicola Cavallo
Discussion of common requirements
Detector Downtime
Saturday Feb. 15th 9:00 to 12:00 Orange room
Detector access Harvey Lynch
Machine operation (macrostructure) Tom Mattison
Example data loss study (DCH) Walt Innes
Physics impact report Paul Harrison
CAN, design for reliability Tom Meyer
MTBF reports from systems
SVT Mark Nyman
DIRC Guy Wormser
EMC John Dowdell
IFR Nicola Cavallo
Reconstruction reports from systems
DCH Steve Wagner
DIRC Guy Wormser
EMC Helmut Marssike
IFR Nicola Cavallo
Discussion on how to proceed.
Goals of the workshop:
Detector Monitoring, Alarms, and Interlocks.
Monitoring is intended to mean keeping track of things like
temperatures, pressures, and voltages. It does not include
data monitoring. The goal is to establish what needs to be
monitored, how often, and how long the results need to be
remembered. In the case of alarms and interlocks we want
accumulate an inventory of what's needed. This information
will aid the database designers, and give the hardware
folks an idea of how much of everything is required.
This time will also be used to bring people up to date
on the descriptions reached in the Paris workshop.
The information needed from the system representatives
includes lists of how many of what needs to be monitored,
how often they need to be checked, what kind of alarms
(hardware) and software alerts are needed, how long and
how much needs to be remembered.
Calibration.
This means calibration in a broad sense. Any test or calibration
which involves the data acquisition system in a mode other
than standard data taking is included. The goal is to
establish the necessary and sufficient functionality
of the common calibration hardware and software, and
to estimate the data loss due to calibration activities.
The information needed from system representatives includes
scenarios for all anticipated calibrations and tests.
Estimates of their frequency. What are their requirements?
A revised version of the
calibration questionnaire is
now available. See also the
announcement. There is too much in the questionnaire for you
to complete before the meeting, but you can get a head start by
thinking out your calibration scenario in some detail.
How often do you need to calibrate (or test)? What conditions
are required? What is your signal source?
How many pulses per minor cycle?
What happens during a pulse? at the end of minor cycle? What needs to
change between minor cycles. How many minor cycles. Similarly
for major cycles. What happens at the end of a major cycle?
Please be prepared to walk us through your calibration(s).
If you have not already done so, you should join the
Calibration HyperNews forum.
Downtime.
The goal is to estimate the expected data loss due to
equipment failure. The effort should aid system
designers in their efforts to minimize
failure rates.
The information needed from system representatives includes:
MTBF reports with failure impacts, e.g., what channels die
if resistor X fails. The effects of the most likely failures
on reconstruction (at this time this will be from informed
guesses). Guesses on the impact of the reconstruction
degradation on physics.
The Reliability
page has links to Dave Nelson's analysis of the DCH. This can serve as
a guide to other efforts. This analysis does not group the failures
by the extent of the malfunction each would cause. This last step is
needed to evaluate their impact.
BaBar note 353
relates failures to data loss.
|