ECS – Experiment Control System

1. ECS – Experiment Control System Burkhard Kolb, GSI CBM collaboration meeting Darmstadt, March 9 - 12, 2005

2. Main Goal • The ExperimentControl system (ECS) has to ensure the coherent and safe operation of the CBM experiment. • One main requirement is the easy integration of independently developed components. Burkhard Kolb, GSI – CBM collaboration meeting

3. What it does - and what not • The Experiment Control System is used to supervise and operate all detector hardware, the common experimental infrastructure, it provides the status of detector components for the CBM DAQ, it interfaces to the GSI infrastructure and to the SIS accelerator. • The ECS does not deal with the safety of personnel. Burkhard Kolb, GSI – CBM collaboration meeting

4. Client - Server Model • The clients are the distributed user interfaces (GUI), archiving stations, alarm handlers, and other high-level interfaces. • The servers are agents running either in the DCS boards or workstations or single board computers which interface to the specific detector or infrastructure hardware. • Clients and servers communicate overIP networks with protocols like channel access (CA), DIM or similar. Burkhard Kolb, GSI – CBM collaboration meeting

5. Standalone operation • The ECS has to be capable of operating the detector hardware without the DAQ system. Therefore it should wherever possible use its own control path to the hardware. Burkhard Kolb, GSI – CBM collaboration meeting

6. Partitioning • The ECS can be partitioned in sub-detectors for development and separate testing on a per agent basis. • GUI panels, archiving, and alarm handling also can be built accordingly. Burkhard Kolb, GSI – CBM collaboration meeting

7. Integration • The ECS has to integrate independently developed components by providing interoperability between a small number of allowed standards (field busses, SCADA systems, common hardware) Burkhard Kolb, GSI – CBM collaboration meeting

8. Functionality 1 - Setting • The ECS sets the detector system into RUN status by loading parameters and configuration files from the database to detector and trigger hardware. This includes the loading of programmable logic (FPGAs,...) • For speed of operation the database will be distributed and local caches in agents or intermediate management layers will be used (LAM and WAM). Burkhard Kolb, GSI – CBM collaboration meeting

9. Functionality 2 - Monitoring • The ECS monitors operational parameters from detectors, trigger hardware, high and low voltage supplies, gas systems, position measurement systems, and environment and provides a GUI to these process variables (PV) to the user. • All relevant process variables are archived to the database. • Historical views and trending is provided to the user and via APIs to the analysis software. Burkhard Kolb, GSI – CBM collaboration meeting

10. Functionality 3 - Archiving • All relevant process variables are archived to the database (ORACLE) • Historical views and trending is provided to the user and via APIs to the analysis software. Burkhard Kolb, GSI – CBM collaboration meeting

11. Functionality 4 - Alarms • The state of critical process variables is constantly monitored and compared against predefined boundaries (on server). • The alarm handling client alerts the operator and logs alarm states and acknowledgments to log files (or database). • Interlocks and detector safety are provided with dedicated hardware (i.e. PLCs), but the ECS monitors this hardware and the interlock status. Burkhard Kolb, GSI – CBM collaboration meeting

12. Functionality 5 - Access • Access Control for modification of parameters in the ECS and in the database are provided through user accounts and passwords. Burkhard Kolb, GSI – CBM collaboration meeting

13. Software • Open source software • For the reason of maintainability and licensing costs we want to use wherever possible open source software. There are several packages which are used with good experience in the HEP community, like EPICS and DIM. • Commercial SCADA • On the other hand there are many laboratory style hardware setups like gas systems, high voltage supplies, connections to PLCs, which are build around commercial SCADA packages like LabView. We will try to interconnect these sub systems to the general ECS by writing gateways. Burkhard Kolb, GSI – CBM collaboration meeting

14. Hardware • Early on a set of standardized hardware components which can be reused in the different detector sections has to be identified, as there are: • High Voltage • Low voltage power supplies • Crates and racks • Temperature sensors • Position sensors • Gas supply systems, valves, flow meters • Through standardization we will have fewer different components and need less spares. Burkhard Kolb, GSI – CBM collaboration meeting

15. DCS system • The detector control system (DCS) is an agent unit for many detector front-end components. • It acts as a status and event server for the ECS system as well as a client for controlling all front-end electronics. • The DCS will be implemented as a single board computer. • It consists of DCS hardware (DCS board), an operating system and the DCS application. Burkhard Kolb, GSI – CBM collaboration meeting

16. DCS functionality • The main tasks of DCS are to securely switch on and off front-end electronics, to configure all components (including FPGAs), and to set and monitor all software and hardware parameters. • Additionally the DCS should implement the runtime refresh for all FPGAs exposed to high radiation. • DCS acts as an agent to the experiment control system (ECS). Burkhard Kolb, GSI – CBM collaboration meeting

17. URD • An user requirements document (URD) template is being prepared. • It will be send to all detector group coordinators to collect the information about the to be controlled hardware. Burkhard Kolb, GSI – CBM collaboration meeting

18. Next steps • Constitute ECS group. • Collect URD and identify common hardware. • Work on gateways for existing software frameworks: • EPICS • DIM • Labview • OPC Burkhard Kolb, GSI – CBM collaboration meeting