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

André Augustinus10 September 2001

DCS Architecture Issues

Food for thoughts and discussion

10 September 2001DCS Workshop 2André Augustinus

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é Augustinus10 September 2001

André’s ideas on DCS

A rather personal view

and probably somewhat DELPHI biased


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 …


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


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.



Gas, Electricity, …Magnet, DAQ, LHC

ITS, TPC, TRD,TOF, Muon, …

ITS-SPD, ITS-SDD, ITS-SSDMuon-Track, Muon-Trig



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)



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



CentralDCS

TPC DetectorDCS

HV LV Cooling

HVcrate 1

HVCrate 2

LVcrate

Coolingsystem

T monitor

Tsensors


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



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



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)



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


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”


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


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



CentralDCS

ITSDCS

TRDDCS

TOFDCS

HMPIDDCS

• Partitioning


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


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


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


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


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

Documents

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