Designing a HEP Experiment Control System, Lessons to be Learned From 10 Years Evolution and Operation of the DELPHI Experiment. André Augustinus 8 February.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Configuration management
André Augustinus 15 March 2003 DCS Workshop Safety Interlocks.
The Control System for the ATLAS Pixel Detector
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Clara Gaspar on behalf of the LHCb Collaboration, “Physics at the LHC and Beyond”, Quy Nhon, Vietnam, August 2014 Challenges and lessons learnt LHCb Operations.
André Augustinus ALICE Detector Control System  ALICE DCS is responsible for safe, stable and efficient operation of the experiment  Central monitoring.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Lecture 13 Revision IMS Systems Analysis and Design.
1 HLT – ECS, DCS and DAQ interfaces Sebastian Bablok UiB.
DAQ WS03 Sept 2006Jean-Sébastien GraulichSlide 1 Interface between Control & Monitoring and DDAQ o Introduction o Some background on DATE o Control Interface.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Clara Gaspar, May 2010 The LHCb Run Control System An Integrated and Homogeneous Control System.
The Origin of the VM/370 Time-sharing system Presented by Niranjan Soundararajan.
Database Administration Chapter 16. Need for Databases  Data is used by different people, in different departments, for different reasons  Interpretation.
Business Rules INFS 770 – KM for E-Business Professor L. Kerschberg Spring 2004.
Database Systems: Design, Implementation, and Management Ninth Edition
Benefits of Using AllFusion ERwin and Advantage Gen in the Same Project Lifecycle Steve Smith Jumar Solutions 28 th March 2007.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
CHEP2000 February 2000 Impact of Software Review and Inspection Doris Burckhart CERN ATLAS DAQ/EF-1 Back-end software.
CSE 303 – Software Design and Architecture
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Magnetic Field Measurement System as Part of a Software Family Jerzy M. Nogiec Joe DiMarco Fermilab.
Installation and Maintenance of Health IT Systems
RUP Design RUP Artifacts and Deliverables
JCOP Workshop September 8th 1999 H.J.Burckhart 1 ATLAS DCS Organization of Detector and Controls Architecture Connection to DAQ Front-end System Practical.
André Augustinus 10 September 2001 Common Applications to Prototype A two way learning process.
Clara Gaspar, October 2011 The LHCb Experiment Control System: On the path to full automation.
XXVI Workshop on Recent Developments in High Energy Physics and Cosmology Theodoros Argyropoulos NTUA DCS group Ancient Olympia 2008 ATLAS Cathode Strip.
Online Calibration of the D0 Vertex Detector Initialization Procedure and Database Usage Harald Fox D0 Experiment Northwestern University.
André Augustinus 10 September 2001 DCS Architecture Issues Food for thoughts and discussion.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Architectural Design Identifying system components and their interfaces.
André Augustinus 10 October 2005 ALICE Detector Control Status Report A. Augustinus, P. Chochula, G. De Cataldo, L. Jirdén, S. Popescu the DCS team, ALICE.
Control in ATLAS TDAQ Dietrich Liko on behalf of the ATLAS TDAQ Group.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Controls EN-ICE Finite States Machines An introduction Marco Boccioli FSM model(s) of detector control 26 th April 2011.
André Augustinus 21 June 2004 DCS Workshop Detector DCS overview Status and Progress.
Clara Gaspar, March 2005 LHCb Online & the Conditions DB.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Introduction CMS database workshop 23 rd to 25 th of February 2004 Frank Glege.
Module 4: Systems Development Chapter 14: Design And Implementation.
Database Administration
Chapter 5: Software Re-Engineering Omar Meqdadi SE 3860 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Controls EN-ICE FSM for dummies (…w/ all my respects) 15 th Jan 09.
Chapter 4 Automated Tools for Systems Development Modern Systems Analysis and Design Third Edition 4.1.
Configuration database status report Eric van Herwijnen September 29 th 2004 work done by: Lana Abadie Felix Schmidt-Eisenlohr.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Clara Gaspar, April 2006 LHCb Experiment Control System Scope, Status & Worries.
1 ECS CALO LED Control System CALO Piquet Training Session Anatoli Konoplyannikov /ITEP/ Outline  Introduction  Calorimeter ECS LED monitoring.
André Augustinus 18 March 2002 ALICE Detector Controls Requirements.
Maria del Carmen Barandela Pazos CERN CHEP 2-7 Sep 2007 Victoria LHCb Online Interface to the Conditions Database.
M. Caprini IFIN-HH Bucharest DAQ Control and Monitoring - A Software Component Model.
Online Software November 10, 2009 Infrastructure Overview Luciano Orsini, Roland Moser Invited Talk at SuperB ETD-Online Status Review.
CHEP 2010 – TAIPEI Robert Gomez-Reino on behalf of CMS DAQ group.
B. Franek, poster presented at Computing in High Energy and Nuclear Physics, Praha – Czech Republic, 21 – 27 March 2009 This framework provides: -A method.
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
ATLAS MDT HV – LV Detector Control System (DCS)
CMS – The Detector Control System
Controlling a large CPU farm using industrial tools
The LHCb Run Control System
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
Information Systems, Ninth Edition
Tools for the Automation of large distributed control systems
Modern Systems Analysis and Design Third Edition
Presentation transcript:

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