1. André Augustinus 21 June 2004 DCS Workshop Detector DCS overview Status and Progress

2. André Augustinus 21 June 2004DCS Workshop 2 Introduction  Since some time the ‘overview drawings’ for each detector form the basis of our understanding of the various sub-systems  From the end of last year, there are only very few modifications +Things are decided and stable… good! –You haven’t had time to update the drawings… … try to put in the small effort or, as a minimum, forward me your comments

3. André Augustinus 21 June 2004DCS Workshop 3 Feedback  Last workshop many points of general interest were presented and discussed; on which feedback was requested from the detectors  Detectors were reminded to give feedback on some of these points two weeks ago  Unfortunately we received very little input for this workshop…  So, I will not really summarize current status (as basically nothing changed since March)

4. André Augustinus 21 June 2004DCS Workshop 4 Feedback  I will try to explain again why and on what areas we would like you to provide us with feedback  Remember that: We are there to support you For that we need to know what you want! Pre-installation starts in a few months, installation in a year from now Things take time to prepare (properly), please allow us that time 16 or so detectors will have to be operated coherently Has to be designed, we need to know how you operate your detector

5. André Augustinus 21 June 2004DCS Workshop 5 URD’s  The URD is supposed to be the repository for your requirements Need to be updated when your requirements change  Currently ‘dormant’… We haven’t seen any updates for a year (or more) No URD at all for some detectors!

6. André Augustinus 21 June 2004DCS Workshop 6 URD’s  Need to be reviewed and put in EDMS Collection of URD’s is referred to in the TDR  Base this review around overview drawing, the URD… … allows to put more information (description) … allows to capture other information than ‘numbers’ … allows to cover operational aspects  We will get back to you on this…

7. André Augustinus 21 June 2004DCS Workshop 7 Operational aspects  During installation and commissioning you will operate your detector ‘stand alone’  An important ‘mission’ of the DCS team is to allow centralized and coherent operation (of the DCS) of the whole ALICE experiment  The design and prototyping for this is now starting Was already started with the ‘common solutions’  Therefore we need your input

8. André Augustinus 21 June 2004DCS Workshop 8 Operational aspects  Relevant on many levels in the DCS  Firstly, the operation or behaviour of each individual sub-system Aim is to describe behaviour in a state diagram Cover both ‘normal operation’ and ‘anomalies’ Inventory of all possible anomalous states Reaction on these anomalous states: recovery or reporting E.g. automatic recovery of a tripped HV channel  This will be covered in more detail by Giacinto

9. André Augustinus 21 June 2004DCS Workshop 9 Operational aspects  Secondly, the interaction between the various sub- systems in your detector What are the dependencies between the sub-systems E.g. a sub-system cannot be operated without another No LV without cooling, no HV without correct gas Operations on sub-systems need to be done in a defined order (some) LV need to be switched on before HV This also touches the subject of interlocks  Again state diagram or flow chart would be useful  Aim is to standardize as far as possible States, commands

10. André Augustinus 21 June 2004DCS Workshop 10 Operational aspects  Finally, the interaction between the DCS and ‘the rest of the world’  Rarely the DCS is operated in ‘isolation’  Need to understand relation to e.g. other online systems Makes no sense to start data-taking without HV and LV on HV can only be switched on when beam conditions allow For some calibration coordination between DAQ and DCS is needed  Important for the design of the ECS  Even further: what DCS information is needed offline

11. André Augustinus 21 June 2004DCS Workshop 11 Operational aspects  Capture, on each level, ‘normal operation’ in flow charts or state diagrams  Normal operation will probably follow ‘LHC cycle’

12. André Augustinus 21 June 2004DCS Workshop 12 Operational aspects  Clearly many aspects are still unclear will only become clear when you start understanding your detector  Some questions to trigger reflection What operations are needed before or at the start of a fill ramp voltages from off, or intermediate, special calibration or configuration to be done What recovery procedures are foreseen recovery of trips, recovery of SEU What operations are needed at the end of fill ramping down of voltages, switching off sub-systems, performing automatically some ‘post-fill calibration’

13. André Augustinus 21 June 2004DCS Workshop 13 Operational aspects What kind of calibration(s) will be needed when and how often will they be performed what are the conditions to do them can it be done with beam or should it be without beam what sub-systems or other online systems (DAQ, TRG etc.) are involved and how do they interact

14. André Augustinus 21 June 2004DCS Workshop 14 Operational aspects  Not limited to data taking periods, DCS will be operational (and essential) during ‘shutdown’ periods What will be the status of your detector during (prolonged) shutdowns e.g. for one or more days (LHC ‘machine development’) or some weeks or months (‘technical stop’ or ‘winter shutdown’) will all sub-systems be switched off or will some systems remain operational, and if so will this require operator surveillance What will be the startup procedure after a shutdown period e.g. gas purge, cool down period

15. André Augustinus 21 June 2004DCS Workshop 15 Databases  Last workshop(s) Peter presented the various databases related to DCS Configuration DB, conditions DB, PVSS archive  Need your feedback on the use of these databases To evaluate technology, access, performance, tools…  Some (most) of it comes with framework but some will be ALICE specific

16. André Augustinus 21 June 2004DCS Workshop 16 Databases - configuration  Configuration database holds all kind of information Static information (on processes, on devices) Dynamic information (settings, alarm limits, recipes) FERO configuration (information for FEE) ALICE specific  Static system information (processes) relatively straightforward What process is running where, what managers, what drivers… Will need to add your specific needs

17. André Augustinus 21 June 2004DCS Workshop 17 Databases - configuration  Static (device) information relatively well known for ‘common devices’, for specific devices we need your input  Dynamic information Again, for non-common devices we need to know what settings exist How are these settings defined (populating the database) “Manually” Automatically e.g. following a calibration run

18. André Augustinus 21 June 2004DCS Workshop 18 Databases - configuration  FERO configuration, strictly seen the same as device configuration (static and dynamic) Will be shared with other online systems (DAQ, ECS) You will have to define what need to be stored, and how database will be populated  Static configuration will be accessed only occasionally  Dynamic configuration more often Would like to know how often, when, amount of data to assess performance issues

19. André Augustinus 21 June 2004DCS Workshop 19 Databases - conditions  Conditions database: data needed for (physics) data analysis by offline  (PVSS) Archive: all data acquired by PVSS stored for use by DCS experts  Conditions database is a subset of data in archive or based on archive data  Depending on developments in PVSS, on performance etc. offline might have access to archive directly  Need your input on what data is needed for offline

20. André Augustinus 21 June 2004DCS Workshop 20 Interlocks  Last workshop I presented a draft document on ideas on interlocks Have not had any comments on its content  Would like to have your feedback with your needs  Closely related to operational aspects, especially ‘soft interlocks’  Would like to have for each detector an inventory of all aspects of all your interlocks

21. André Augustinus 21 June 2004DCS Workshop 21 Interlocks - Questions  What we would like to know from you (in principle for both hard and soft interlocks) Source, what system is generating the interlock On what conditions is the interlock generated At least in indication (gas mixture, pressure, temperature …) Will there be a delay between detection of condition and generation of interlock Destination, what system is receiving the interlock For hardwired interlocks, what will be the signal (both source and destination end) open/close contact, voltage level, current loop …

22. André Augustinus 21 June 2004DCS Workshop 22 Interlocks  We will get back to you with precise questions  And a proposal how to capture your needs table, drawing filled with what we already know with information on ‘external systems’ (how e.g. cooling and gas are generating interlocks)  Doesn’t prevent you from starting to think on the subject!

23. André Augustinus 21 June 2004DCS Workshop 23 Summary  Will continue to bother you with request for information  Shift our attention from ‘numbers’ to ‘operation’  Review URD’s  Feedback needed on operation, databases, interlocks