230 likes | 388 Views
Detector DCS overview. Status and Progress. 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!
E N D
Detector DCS overview Status and Progress DCS Workshop
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 DCS Workshop
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) DCS Workshop
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 DCS Workshop
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! DCS Workshop
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… DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
Operational aspects • Capture, on each level, ‘normal operation’ in flow charts or state diagrams • Normal operation will probably follow ‘LHC cycle’ DCS Workshop
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’ DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 DCS Workshop
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 … DCS Workshop
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! DCS Workshop
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 DCS Workshop