1. The Detector Control System – FERO related issues
Peter Chochula
On behalf of DCS team

2. The DCS sub-systems
Main role of the DCS is to assure safe operation of ALICE. To fulfill this task, it has to communicate with a large number of devices
The DCS devices are logically grouped into several sub-systems which are operated separately and synchronized via FSM tools implemented in the SMI++ package
Main DCS sub-systems are:
High Voltage (HV)
Low voltage (LV)
Front-End and Readout Electronics (FERO)
Gas
Cooling
Some detectors implement additional sub-systems such as laser control, etc.
On top of this, the DCS communicates with LHC, Detector Safety System, external services …
In this talk only issues related directly to FEE will be discussed
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

3. The DCS Architecture and its Place in ALICE Online Hierarchy
The DCS is a strictly hierarchical online system, its synchronization with DAQ, TRG and HLT is achieved via the ECS
There are no horizontal connections between online systems
Efficient operation of ALICE sub-detectors depends on communication between online systems and this is strongly influenced by the FERO design
ECS
DCS
DAQ/RC
TRG
HLT
SPD
SPD
TPC …
TPC .
SPD
TPC … LV LV HV HV
FERO
FERO
Gas
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

4. The (simplified) DCS operation of a device
Configuration
Database
Device
Configuration
Device
Control
(Regulation, switching, handling
of alarms and exceptions…)
Device
Monitoring
Archive
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

5. Two main groups of questions related to FERO need to be solved:
How to access the electronics?
How to operate the electronics?
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

6. How to access the devices
Unlike the other online systems, the DCS communicates with wide range of different devices
The nature as well as handling of acquired data differs from sub-system to sub-system
There is no unique and standardized mechanism for accessing the DCS devices
Profibus
Ethernet
JTAG
EasyNet
RS 232
VME
CANbus
Custom solutions…
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

7. Access to the DCS hardware
The main operation tool of the DCS is a commercial SCADA system : PVSS-II
The PVSS-II offers a limited set of tools for accessing the hardware.
Native PVSS-II drivers are used where appropriate (e.g. for RS-232)
The aim is to use a set of software interfaces, which will hide the complexity of the underlying hardware
The ALICE DCS profits from (and contributes to) common developments between four LHC experiments – the JCOP project. The JCOP framework software package provides solutions for most standard devices (power supplies, ELMB based monitors, etc.)
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

8. The hardware access standards in the DCS – the OPC
Most commercial devices are shipped with software based on the OPC industrial standard
OPC client is integrated in PVSS
The DCS team is testing OPC servers and provides feedback to manufacturers if needed
Reports are regularly given at DCS workshops organized during the ALICE weeks
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

9. The main problem related to the FERO control in ALICE is caused by the fact, that different detectors are using different access strategies.
The FERO of some sub-detectors is accessed exclusively via the DDL which belongs to the DAQ domain and is handled by the DAQ/RC
Other architectures use a wide variety of access paths, which are handled by the DCS
In principle we can group all ALICE sub-detectors into four architectural classes shown on the next slide
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

10. FERO Access Architectures
Class B
Control
Monitoring
FERO
DDL
Non-DDL
Class A
Control
Monitoring
DDL
FERO
Class C
Class D
Control
Monitoring
Control
Monitoring
Non-DDL
Non-DDL
FERO
FERO
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

11. The hardware access standards in the DCS – the FED
The ALICE FERO (and some additional devices like Arem-Pro power supplies) are not covered by JCOP developments
Unfortunately the operation of this group of devices proves to be a very complicated one
The Front-End Device (FED) concept for accessing this group of devices has been elaborated (see presentations on DCS workshops and TB in May 2004)
The corresponding software architecture (called the FED Server) is based on DIM protocol, which is also integrated in the PVSS-II
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

12. Monitoring of all classes
FED Architecture
ECS
Class B,C,D Control
DAQ/RC
DCS
Class A+B Control
DDL SW
FED Client
Monitoring of all classes
FED
DDL SW
FED Server
Control CPU
Control CPU
Profibus, JTAG, etc.
DDL
FERO Hardware Layer
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

13. Architecture of the FED Server
(PVSS) DIM Client
DIM Interface layer
allows for communication with higher levels of software
Software
Client
Commands
& Data
Services
DIM server
FED
Server
Application layer contains detector control and monitoring code (agents)
Database
CA1
CAi
MA1
MAi
Device driver(s)
Hardware
Hardware access layer contains device drivers
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

14. How to operate the FED
The architecture of the FED server covers also some basic operational aspects
Implemented commands allow for integration with the DCS
The DCS handles cross-dependencies between sub-systems
e.g. FERO configuration is pending until the LV becomes operational, this is dependent on cooling status etc.
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

15. Standard FED Operation
Running
Stop
Run
Configured
Re - Configure
Switch-Off
Configuring
Configure
OFF
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

16. Additional (detector-specific) FED commands
A number of FED Server commands is unique for sub-detectors
E.g. JTAG chain verification in SPD
Autocalibration…
In close collaboration with DCS contact persons we try to identify these commands and propose solutions. In some cases only a very limited feedback is provided – this is mostly given by the fact that the software design has not reached the implementation phase yet.
FED Server prototyping is very well advanced for some detectors (SPD, TPC, TRD, PHOS) and we are profiting very much from a very good collaboration with detector groups
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

17. FERO Device Monitoring Principle in DCS
Sampling
interval
PVSS Alarm Limit
Publishing
deadband
Value recorded
In DCS
Published
value
Acquired
values
PVSS Alarm Limit
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

18. FERO operation A number of questions still needs to be answered:
What detector specific commands need to be implemented?
How do we monitor and treat SEU ?
What are the sub-system and system dependencies? (switching order….)
What parameters need to be monitored and at what frequencies?
What are the expected actions if some parameters are out of range? (sometimes is sufficient to record the anomaly in the archive, sometimes we can recover the settings, in some cases the run must be stopped…)
In some cases the DCS is expected to monitor for example local trigger counters – what happens if these are out of range ?
WHO and WHEN will starts the software developments on detector side, HOW and WHERE do we test the prototypes?
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

19. Typical problem requiring synchronization between online systems (Example – Class A device)
VR Failure
(e.g. due to SEU)
ECS
As a consequence
the FERO gets
mis-configured
DCS
TRG
DAQ
Recovery Action by DCS
DCS informs the DAQ
and TRG via ECS VR
FERO
DAQ reloads the FERO
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

20. Device Configuration and Archiving
All configuration data is stored in online database
Present implementation is based on Oracle
Monitoring and alarm limits are read by PVSS and sent to the FED Servers
FEE parameters (thresholds, mask matrices etc.) are read directly by FED Servers in order to minimize the amount of data passed through the PVSS-I
All acquired data, alarms and errors are stored in DCS archive (Oracle) and displayed in PVSS panels
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

21. DCS Configuration Database
System Static Configuration
Configuration DB
Device Static Configuration
Common Solutions
(FW devices only)
Device Dynamic Configuration
PVSS-II &
underlying software
FERO Static Configuration
Alice Specific
FERO Dynamic Configuration
Hardware
ALICE FERO Configuration will be shared between TRG,DAQ, DCS and ECS
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

22. DCS Archiving
PVSS
Present scheme
Archive
Archive
Condition DB
New scheme
Archive
Archive
New archiving model will be introduced in PVSS-II v release is scheduled for September Depending on its performance, the CondDB model could be dropped
PVSS
Archive
ORACLE
Database
Condition DB
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

23. Configuration and Archiving Related Questions
Again, there are questions to be answered:
What are the configuration parameters and how are they used? (data size, loading sequence…)
What are the requirements for data archival?
Interface to offline, analysis procedures …?
How are the configuration parameters obtained?
Calibration procedures
Data analysis
Configuration database updates
Who, when, where, how?
The DCS team is presently testing the prototypes based on ORACLE. First results will be presented at coming DCS workshop
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004

24. Conclusions FERO access strategy has been developed
Prototyping is proceeding well for SPD, HPMID, TPC, TRD and PHOS
Operational requirements are being studied
Feedback is essential: please make sure that the DCS-URD’s are updated
DCS team is happy to help you
DCS lab and its infrastructure are ready for testing the prototypes
Many questions are still open, please inform us about the progress of developments and your plans
Peter Chochula, ALICE workshop on radiation hard electronics, August 30, 2004