DCS Strategy Draft (In preparation)

This is the early draft of the PANDA DCS Strategy Document which will be released in PDF (from LaTeX) once finalised.

Contributors: Dan Protopopescu

Background

The detector control system's main task is to provide safe and correct operation of the PANDA experiment. The DCS must manage the magnet, target and the detector itself, possibly some of the HESR beam parameters. It must control HV and LV supplies (currents, voltages, trips, ramps and other procedures that must be implemented), the gas system (mixtures and flow) and the cooling system (coolant flow, temperature regulation, dew point monitoring).

DCS, which we would envisage rather as an Experiment Control System (ECS), can be seen as the cerebral cortex of the whole experiment since it controls vital processes as machine state, run start/stop, must handle critical conditions and at the same time supervise the data acquisition parameters and data quality.

DCS_small.png DIAGRAM: DCS Interrelations

At the other end, DCS must provide an ergonomic and easy to master user interface to control the whole experiment from a single workplace (the control room) as well as remote control components (for emergency expert intervention from off-site). Restricted access control must be implemented for remote operation and for expert tasks. The DCS must handle alarms: quickly display critical conditions and provide access to rectify them.

DCS must come with its own archiving mechanism (database or alternatives) to store a history of run conditions, firmware, versioning, readout settings (thresholds etc.), hardware settings (HV, LV etc.) and alignment information as well as calibration constants (RT, E) and circumstantial information.

The building blocks of such a DCS system, which we will refer to in the following sections, are: 1) Control units (CU) are higher level control modules, actual software implementations, 2) Logical units (LU) are omponents that model and control the units below them and 3) Device units (DU) are the low-level units that 'drive' the devices. This conceptualization allows for distributed and decentralised decision making and autonomous actions being possible even when controlled centrally.

Input from other PANDA subgroups

Information from the other subgroups (detectors, magner, target, DAQ) is important from the start, as they should provide the 'requirements' for the DCS. AFECS will be an 'umbrella' framework that will integrate physics data (from online analysis) with detector parameters (from native and custom DCS components) into a unified user interface (UUI).

Tasks

The detector control system must provide safe and correct operation of the PANDA experiment. Subject to a complete requirements analysis, the aim aim is to have a linux-based system built mainly from free software components. The best candidate framework is UNICOS (based on PVSS II which is a commercial product), adopted by the FAIR accelerator controls group, since this choice guarantees sharing expertise and also mutual support between PANDA and FAIR. Manpower and expertise will be needed for the implementation of EPICS and AFECS into a coherent solution across all components of the detector, target and accelerator interface and then coordinate the deployment, benchmarking and on-site testing of the complete system, with FAIR assistance.

Output

The final product of the DCS effort will be be a complete monitoring and control software system installed and running well ahead of the first tests of the fully assembled PANDA detector. PANDA must provide expertise and essential components of the computing infrastructure needed for running this system and will provide FAIR with specifications for the procurement of the other hardware components.

Justification

There are many detector control systems out there. Well established frameworks as EPICS, PVSS, used for large experiments, LabVIEW for smaller scale experiments or independent detector subsystems (such as target), as well as full implementations developed in-house. Which is the best choice depends a lot on the size of the experiment, the management of the subparts (many independent group might build subdetectors off-site and they must be all integrated at a later stage), costs (free versus commercial frameworks) and the expertise available within the collaboration (members with previous experience from other experiments).

For PANDA the candidates would be: 1) EPICS because our group's experience from Jlab where it is used as a slow control system both by accelerator and experiments. A disadvantage of EPICS is the lack of an embedded archival mechanism, but this can be provided by the upper layer component. 2) PVSS/UNICOS (from LHC) used by FAIR accelerator division with whom we could pool the knowledge and have easy interfacing 3) MonALISA was considered because it high abstractization level, robustness, portability and scalability, embedded database, browser and/or Java/GUI based user interface. 4) AFECS, a very sophisticated system developed by JLAB for future experiments like GlueX and CLAS12 5) LabVIEW, although promoted by some GSI colleagues for its simplicity is not considered feasible for such a large experimental setup and is not free software. However, LabVIEW could be used for subsystems like Target and integrated at either EPICS or AFECS level.

From within the frameworks enumerated above, EPICS comes as the best choice by far. EPICS is an established open-source system that presently benefits of support at GSI (within the HADES group). EPICS could be implemented and tested at FAIR by the time PANDA (possibly CBM and NuSTAR) needs it, benefit from the provision of in-house expertise at FAIR, technical support and possibly manpower.

Cost

Costs divide in three categories: 1) know-how management (organizing workshops where DCS group members meet experts from UNICOS and MonALISA, AFECS, inviting experts from JLAB, FAIR or CERN), 2) hardware for testing 3) in the long term, providing the mission critical components for the final on-site setup.

Project Timeline

The DCS subgroup in PANDA has been established during the September 2007 PANDA collaboration meeting at GSI [1]. The aim is to decide (and have some preliminary trials of) the framework for the PANDA DCS by the end of 2008. The architecture of the PANDA DCS and the individual components will be then ready for implementation and deployment, respectively, by the end of 2009. Actual testing, benchmarking, component development and streamlining will happen along with the completion of the detector until commissioning date [2].

Risk assessment

Implementation of EPICS with the support of GSI is the one of the least risky strategies. If PANDA DCS will contain core slow controls components from AFECS, then the success of the enterprise will depend on development of AFECS by the JLAB group and the development of custom interfaces (like LabVIEW-AFECS) by ourselves (PANDA/GSI). Successful tests of EPICS-MonALISA interfacing EPICS and MonALISA for example have been carried out at GSI.
Topic attachments
I Attachment ActionSorted ascending Size Date Who Comment
DCS_small.pngpng DCS_small.png manage 62.3 K 24 Apr 2008 - 13:53 DanProtopopescu DCS Interrelations
Topic revision: r6 - 17 Jun 2009, DanProtopopescu
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding PANDA Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)