André Augustinus 10 September 2001 DCS Architecture Issues Food for thoughts and discussion

André Augustinus 10 September 2001DCS Workshop 2 Disclaimer  What will be presented is not a proposal to be accepted or rejected.  It is merely a collection of (personal) ideas.  It is meant to make you start thinking and trigger discussions. With the outcome of these discussions we could start to design the full Detector Control System.  We are eager to hear your comments!

André Augustinus 10 September 2001 André’s ideas on DCS A rather personal view and probably somewhat DELPHI biased

André Augustinus 10 September 2001DCS Workshop 4 Introduction  From the ALICE Controls Coordination mandate:  The DCS should allow centralised operation By a single operator Not necessarily a DCS expert From a central control room … to have the Detector Controls System (DCS) ready for exploitation by the end of 2005, allowing to control and operate the experiment (from a central operator workplace) during all modes of operation …

André Augustinus 10 September 2001DCS Workshop 5 Introduction  A central (non-expert) operator should at all times be informed about anomalies in the experiment be able to give the necessary commands to run the experiment efficiently (minimal downtime)  A detector (expert) operator should have a detailed view of the detector/system be able to give any expert commands

André Augustinus 10 September 2001DCS Workshop 6 The DCS, global view  Hierarchical system Central DCS Detector CS’s and/or sub-detector CS’s  Connected to external systems Gas, Electricity etc. Magnet, DAQ, LHC Accelerator etc.

André Augustinus 10 September 2001DCS Workshop 7 The DCS, global view Gas, Electricity, … Magnet, DAQ, LHC ITS, TPC, TRD, TOF, Muon, … ITS-SPD, ITS-SDD, ITS-SSD Muon-Track, Muon-Trig

André Augustinus 10 September 2001DCS Workshop 8 The DCS, global view  Central DCS collects the status of all detectors and external systems  Through the Central DCS the operator will give generic commands to all or a set of detectors  The Central DCS can perform pre- programmed operations (automated operation)

André Augustinus 10 September 2001DCS Workshop 9 The DCS, global view  A Detector CS consists of a collection of sub- system controls  The sub-system controls is controlling a collection of equipment or devices that is logically grouped together HV, LV, Cooling, …  The sub-system controls is the interface to the hardware of the detector

André Augustinus 10 September 2001DCS Workshop 10 The DCS, global view Central DCS TPC Detector DCS HVLV Cooling HV crate 1 HV Crate 2 LV crate Cooling system T monitor T sensors

André Augustinus 10 September 2001DCS Workshop 11 Central operation, an example  Operator issues command “get ready for physics” Get ALICE ready for datataking Ramp up HV, switch on or off equipment, change operational parameters.  Command is issued through an operator interface (PVSS) to the Central DCS  Central DCS dispatches the command to Detector CS’s

André Augustinus 10 September 2001DCS Workshop 12 Central operation, an example  Upon receipt the Detector CS will issue commands to sub-system controls “Ramp up” to HV, “Switch on” to LV, “load physics” to temperature monitoring  The sub-system controls will perform the necessary action on the hardware Send a command to CAEN to initiate a ramp  At this moment the command execution has finished

André Augustinus 10 September 2001DCS Workshop 13 Central operation, an example  The operator should get feedback on the execution of the command Should know when command is finished (Has reached the hardware) Should get feedback from the hardware (The hardware is doing/has done something)

André Augustinus 10 September 2001DCS Workshop 14 Central operation, an example  CAEN received command and starts ramping  It reports this back to Detector CS: “I’m ramping up” and the Detector CS will detect a change from “off” to “ramping up”  Based on this new information it will recalculate its own state and change from “not ready” to “HV ramping up”  This state is seen by the Central DCS and shown to the operator

André Augustinus 10 September 2001DCS Workshop 15 Background  Detector CS: operations logic Programmed commands Generic devices Programmed logic, maybe templates/framework  Sub-system controls: hardware details One sub-system controls per type of device “device driver”

André Augustinus 10 September 2001DCS Workshop 16 External Systems  Information from external systems is essential For display to operator For archiving To trigger actions  In principle, all information from any external system is available, via software  Crucial events should be backed up by hardwired interlocks

André Augustinus 10 September 2001DCS Workshop 17 Dividing the system  Each detector should, if needed, be able to run independent from central operation Commissioning, debugging, calibration, …  Partitioning  Propagation of commands and events should be handled properly in case of partitioning  Who decides who has control

André Augustinus 10 September 2001DCS Workshop 18 The DCS, global view Central DCS ITS DCS TRD DCS TOF DCS HMPID DCS Partitioning

André Augustinus 10 September 2001DCS Workshop 19 Archiving and Logging  Archiving Store the value of a monitored parameter for later retrieval (time stamped) Performance Post Mortem analysis For use with offline data analysis  Logging Store all events that occurred in the system Commands given (what, by whom) Anomalies, errors, alarms

André Augustinus 10 September 2001DCS Workshop 20 Configuration  Aim for a uniform system, that only needs to be configured to the needs of the user Provide an ALICE DCS framework Configurable, nothing “hard coded” Configuration data should be stored in some database

André Augustinus 10 September 2001DCS Workshop 21 More ideas  Central DCS and Detector CS could be very conveniently implemented as Finite State Machines (will be (is) part of PVSS)  User interfaces (user defined) can be connected at any point in the system  Access control and access rights can be applied at any point in the system

André Augustinus 10 September 2001DCS Workshop 22 More ideas  One could envisage automated operation: Routine operation LHC declares stable beam conditions Prepare DCS and DAQ for physics Start datataking when DCS is ready Pause datataking when DCS detects serious problem Ramp down at beamdump Apply standard corrective actions Ramp up a tripped channel

André Augustinus 10 September 2001DCS Workshop 23 Summary  Meant to trigger reflection and discussion  We will produce a discussion document elaborating on the issues presented here  Come to a definition if the Alice DCS architecture