Calibration data provided by the DCS Peter Chochula Calibration Workshop February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 Yesterday I learned a lot. For example, that there is almost no need for the DCS data But – this must be a misunderstanding Some DCS data is expected to appear in the analysis, it is just not clear where one could get it from In this talk I would like to clarify some topics related to the DCS role in the calibration and a little bit beyond this Yes, some data is acquired and provided by the DCS And yes, we will even need to get some data back Many questions are still open and I appreciate very much this opportunity to mention them I would like also encourage the information exchange within the detector groups Peter Chochula Calibration Workshop, February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 The DCS Architecture The DCS is a strictly hierarchical system Device control and monitoring is split into several sub-systems such as: High Voltage (HV) Low Voltage (LV) FERO – Front-End and ReadOut electronics Cooling Etc. All subsystems need to work together, in this talk I will focus a little bit more on the FERO Peter Chochula Calibration Workshop, February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 Some definitions Device Control – set of tasks ranging from downloading of parameters to complex actions (calibration etc.). The DCS is involved in control of FERO for some (not all) sub-detectors – this has big impact on calibration procedures Device monitoring - reading of parameters provided by the device. The DCS is directly or indirectly involved in monitoring of FERO for all detectors Peter Chochula Calibration Workshop, February 23, 2005

Monitoring Principle in DCS Sampling interval PVSS Alarm Limit Publishing deadband Value recorded In DCS archive Published value Acquired values PVSS Alarm Limit Peter Chochula Calibration Workshop, February 23, 2005

The ALICE Front-End Device (FED) There are many different FERO architectures implemented in ALICE FED provides hardware abstraction layer the DCS is using this concept to filter unnecessary implementation details FED allows for hardware access unification The concept of FED was originally developed for SPD, now it became ALICE standard FED responds to standard commands and provides standard services which allows for easy integration with online systems The software interface layer leaves freedom for implementing detector specific functionality Peter Chochula Calibration Workshop, February 23, 2005

Monitoring of all classes FED Architecture ECS Class B,C,D Control DAQ/RC DCS Class A+B Control DDL SW FED Client Monitoring of all classes FED DDL SW FED Server Control CPU Control CPU Profibus, JTAG, etc. DDL FERO Hardware Layer Peter Chochula Calibration Workshop, February 23, 2005

Example - SPD Online Architecture TRG DAQ MXI-2 DCS The same path is used to download The chip parameters and to read the DCS data

Peter Chochula Calibration Workshop, February 23, 2005 The online hierarchy DCS Det x DCS DCS Det y DCS Det z HV LV FE Gas DCA-x DCA-y DCA-z DAQ x TRG x DAQ y TRG y DAQ z TRG z PCA-A TRG A DAQ A Services Infrastr. DCS Services Infrastr. DCS Det y DCS Det x DCS Det z HV FE HV FE HV FE LV Gas LV Gas LV Gas Slide borrowed from Andre Augustinus Peter Chochula Calibration Workshop, February 23, 2005

The DCS in the context of online network architecture (simplified) CERN Full DCS data Read access for everyone Application Gateways DCS data cache DCS “private” DCS DAQ The ECS transmits commands and states Restricted data flow between the DCS and online systems ECS TRI HLT Peter Chochula Calibration Workshop, February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 Some implications The DCS is designed to be able to operate even if the link to CERN is broken The DCS data might not appear in the database immediately For us is the simplest solution to keep the actual values ( for ~ 30 min) locally and then copy it to final destination We need to know the access patterns and we can then adopt to them Peter Chochula Calibration Workshop, February 23, 2005

Simplified DCS Data flow Configuration Database DCS DCS Archive HV, LV, Cooling, FERO Underlying technology for DCS databases is ORACLE We need to talk about the API Peter Chochula Calibration Workshop, February 23, 2005

What data is in the ConfDB? System Static Configuration Common Solution (FW devices only) Device Static Configuration Configuration DB PVSS-II & underlying software Hardware Device Dynamic Configuration FERO Static Configuration SPD Specific FERO Dynamic Configuration ALICE FERO Configuration will be shared between DAQ, and DCS ! Peter Chochula Calibration Workshop, February 23, 2005

What Data goes into Archive? Device settings (read back from devices), updated on change All monitored values updated on change FERO settings (only configuration version tag is written into archive) Commands sent to detector States published by subsystems Alarms, errors, warnings… Warning: The DCS does not depend on runs ! We provide only the timestamped data (arrival to DCS) Configuration Database DCS DCS Archive Peter Chochula Calibration Workshop, February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 Some basic facts Calibration is just another operation mode of ALICE online systems All actions are synchronized via the ECS (no role swapping – e.g. no LV control via DAQ, no borrowing of DDL to the DCS etc.) DCS might interfere with the calibration process even if it is not directly involved in it (e.g. interlocks due to high currents etc.) Peter Chochula Calibration Workshop, February 23, 2005

Preparing the DCS for the calibration Even if DCS is not directly involved in the calibration, it might need to prepare for it e.g. the monitored currents and voltages might deviate from normal (expected) values, DCS needs to change the alarm limits, otherwise interlocks will occur As already explained, the monitored values are archived only on change. Do we need to refresh some parameters during the calibration? You might need to have some measurements during the calibration process – maybe the deadbands should be changed? It can also happen that the monitoring intervals are bigger than the duration of the calibration process – hence no updated DCS data will be available Maybe you simply need to have a measurement timestamped during the calibration, even if the value did not change. We need to force the DCS to acquire the data In some cases the DCS will not be able to read some parameters during the calibration (for example the SPD temperatures and currents on the front-end) Peter Chochula Calibration Workshop, February 23, 2005

Example – the SPD calibration data flow Threshold / chip Mask matrix N Thr S-curve as measured by the DCS (per pixel) Almost 10 million curves stored in files passed to offline – we need to discuss this … Offline magic applied As a result the noise, thresholds distribution, dead and noisy pixels will be known This we need to get back and store in the configuration database Peter Chochula Calibration Workshop, February 23, 2005

Detector Calibration – Scenario 1 DCS prepares for calibration Calibration run recorded by DAQ DCS restores “normal” conditions No calibration data available from DCS In case of anomaly during the calibration the DCS will interrupt the process and take evasive actions in order to protect the equipment Peter Chochula Calibration Workshop, February 23, 2005

Detector Calibration – Scenario 2 DCS prepares for calibration DCS performs the calibration DCS restores “normal” conditions Calibration data available from DCS Data will be stored on DCS file server and copied to desired location This needs further clarifications Peter Chochula Calibration Workshop, February 23, 2005

Detector Calibration – Scenario 3 DCS prepares for calibration DAQ takes data DCS modifies operation parameters DCS restores “normal” conditions Calibration data available both from DCS and DAQ Peter Chochula Calibration Workshop, February 23, 2005

Detector Calibration – Scenario 3 The DCS data can be even “guessed” from the procedure The DCS will give a green light to the ECS only if the required settings were successfully applied – if we know the procedure, we know what parameters were set. But the data will also be stored in the DCS archive The procedure must be designed in a clever way Coordination between the DAQ, DCS, ECS and TRI There must be a way of how to describe the modifications in the procedure Number of steps, what parameter changes in each step and by how much … Peter Chochula Calibration Workshop, February 23, 2005

Peter Chochula Calibration Workshop, February 23, 2005 Conclusions There are many things to be discussed Database API Database access patterns How to pass the DCS data (which does not go to the database) to offline … There are many things which are still unknown Calibration procedures “parasitic” effects Time slots allocated to calibration There are many things which were not mentioned Data from alignment systems Data from CCD cameras… There is one thing which is sure The time is limited Peter Chochula Calibration Workshop, February 23, 2005