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

DCS Architecture Issues
Food for thoughts and discussion
André Augustinus
10 September 2001
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
DCS Workshop
10 September 2001
2
André’s ideas on DCS
A rather personal view
and probably somewhat DELPHI biased
André Augustinus
10 September 2001
Introduction
 From the ALICE Controls Coordination
mandate:
… 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 …
 The DCS should allow centralised operation
• By a single operator
• Not necessarily a DCS expert
• From a central control room
André Augustinus
DCS Workshop
10 September 2001
4
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
DCS Workshop
10 September 2001
5
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
DCS Workshop
10 September 2001
6
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
DCS Workshop
10 September 2001
7
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 preprogrammed operations (automated
operation)
André Augustinus
DCS Workshop
10 September 2001
8
The DCS, global view
 A Detector CS consists of a collection of subsystem 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
DCS Workshop
10 September 2001
9
The DCS, global view
Central
DCS
TPC Detector
DCS
T monitor
HV
HV
crate 1
HV
Crate 2
André Augustinus
LV
Cooling
LV
crate
Cooling
system
DCS Workshop
T
sensors
10 September 2001
10
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
DCS Workshop
10 September 2001
11
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
DCS Workshop
10 September 2001
12
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
DCS Workshop
10 September 2001
13
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
DCS Workshop
10 September 2001
14
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
DCS Workshop
10 September 2001
15
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
DCS Workshop
10 September 2001
16
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
DCS Workshop
10 September 2001
17
The DCS, global view
• Partitioning
Central
DCS
ITS
DCS
André Augustinus
TRD
DCS
TOF
DCS
DCS Workshop
HMPID
DCS
10 September 2001
18
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
DCS Workshop
10 September 2001
19
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
DCS Workshop
10 September 2001
20
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
DCS Workshop
10 September 2001
21
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
DCS Workshop
10 September 2001
22
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
André Augustinus
DCS Workshop
10 September 2001
23