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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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