Designing a HEP Experiment Control System, Lessons to be Learned From 10 Years Evolution and Operation of the DELPHI Experiment. André Augustinus 8 February 2000
CHEP February Overview l The DELPHI experiment control system l The evolution of the DELPHI ECS l Observations and lessons learned from over 10 years of operation l Conclusions
CHEP February What is an ECS ? What is an Experiment Control System ? l All systems controlling or monitoring (parts of) an experiment l ‘Classical’ controls Ø Power supplies, temperatures l Data-flow controls Ø Start/stop of a run l Interface with external systems Ø Accelerator, safety system
CHEP February The DELPHI ECS What is the DELPHI Experiment Control System ? l Two main components: l Slow Controls system (SC) l Data Acquisition System (DAS) l Other components: l Trigger system l Communication with LEP accelerator l Data quality monitoring
CHEP February The DELPHI ECS (SC) Slow Controls system l Several 1000 channels l Power supplies, temperatures, pressures l Independent per sub-detector l G64/G96 crates (~100), PLC l M6809, M68340 processors l OS9, RPC/OSI, TCP/IP
CHEP February The DELPHI ECS (SC) The ECS is used to l Prepare sub-detectors for data taking l Report (and correct) anomalies l Integrate ancillary systems Ø Gas, magnet, safety l Store detector status on database(s) l Control & monitor the hardware
CHEP February The DELPHI ECS (DAS) Data Acquisition System: l Over channels l 20 partitions + central partition l Can run independently l Fastbus (~180), OS9, TCP/IP The ECS is used to l Configure the readout l Initialise the partitions l Control and monitor the data flow
CHEP February The DELPHI ECS (Other) Trigger system l Decision and timing l Hierarchical: local and central ECS is used to l Configure and initialise the trigger system l Download look-up tables l Monitoring of counters
CHEP February The DELPHI ECS (Other) LEP communications l Bi-directional exchange of experiment and LEP machine parameters Ø Luminosity, background, machine settings Data quality monitoring l Several 100 histograms l Event processing farm
CHEP February The DELPHI ECS (Software) Two main packages: ¶ SMI++ Models the behaviour of a system as a Finite State Machine in a dedicated language (SML) l Objects Ø Associated: represent concrete entities Ø Abstract: behaviour defined in SML l Objects are in a definite state l Objects can receive action requests l Logically related objects are grouped in domains
CHEP February The DELPHI ECS (Software) l User interface Ø State of objects are presented to the operator Ø Commands are given by sending action requests · DIM l Publish/Subscribe paradigm l Universal data exchange package Ø Refer to previous talk by Clara Gaspar
CHEP February The Evolution of the ECS l Started taking data in 1989 l No ‘real’ ECS yet l Only a rudimentary version of SMI l Line mode interfaces l ‘Human’ synchronisation
CHEP February The Evolution of the ECS l Taking advantage of SMI ( ) l Completion of SC and DAS domains l Centralised control of the experiment l Abstraction Ø Variety of hardware can be represented by one type of object Ø Logically related objects can be summarised in one single object l Uniformity across sub-detectors
CHEP February The Evolution of the ECS l Introduction of DIM (1993 onward) l Make use of user interfaces more flexible l Solve communication problems inside SMI l Evolved to a universal data exchange package in the experiment l DIM really started an integrated ECS : l Trigger, LEP communications became integrated part of ECS
CHEP February The Evolution of the ECS l Reengineering of SMI (1996) l Improve maintainability and portability l Using OO techniques l Smooth transition because of well defined interfaces (already in design phase) l Hardware and Software upgrades Ø New sub-detectors Ø New technologies Ø New versions of operating systems
CHEP February Automation in the ECS l Automation is unavoidable and imperative for efficient running of a complex experiment l Too complex for a non-expert operator l Gain in time, efficiency l Ensure consistency l Relatively easy to implement because of the use of SMI in all domains
CHEP February Automation in the ECS l Examples of automation l Trip recovery Ø Automatic reaction to trips l DAS auto-pilot Ø Automatic reaction to a variety of anomalies l SMI analyser Ø Analyse combination of SMI states l ‘Big Brother’ Ø Interconnection of various domains Ø ‘Hands-Free’ running of the experiment
CHEP February Future ECS l LEP experiments were probably the first generation that needed an ECS l One should take advantage of the expertise gained in running these big experiments
CHEP February Future ECS l Partitioning l Well thought out to allow stand-alone running (debugging, calibration) l Unhindered operation when part of the experiment is off l Central control l Small crew of operators l Well structured commands
CHEP February Future ECS l Uniformity across ECS subsystems l Will ease integration and automation l Will reduce maintenance efforts l Uniformity across sub-detectors l Common hardware and software Ø reduced costs and maintenance effort Ø reduced development efforts Ø easier operation l Use of commercial solutions
CHEP February Future ECS l Central support team l Strong central support is a great benefit l Provide guidelines and frameworks Ø enforce uniformity l Provide common solutions for common problems l Will ease maintenance over lifetime
CHEP February Future ECS l Flexibility l ECS is never ‘finished’ l Many changes will happen over the lifetime of an experiment, the ECS should cope with Ø Modification or addition of a sub-detector Ø Upgrades with new technology Ø Change of working points or operational procedures l Easy to modify or reconfigure Ø Good documentation
CHEP February Future ECS l Efficient day-to-day operation l Abstraction Ø Non-expert operators can run the experiment Ø Hide detailed information Ø Uniform representation and commands l Automation Ø Automatic error recovery Ø Automate ‘standard operations’ l Proper training and adequate documentation
CHEP February Summary l Designing an ECS Ø Strong central support Ø Partitioning Ø Uniformity Ø Flexibility Ø Abstraction Ø Automation