1. André Augustinus 17 June 2002 Technology Overview What is out there to fulfil our requirements? (with thanks to Tarek)

2. André Augustinus 17 June 2002DCS Workshop 2 DCS parameters  Parameters can be obtained from: Individual sensors or actuators (e.g. PT100, relay) Complex devices (e.g. V mon or V set of a HV channel in a CAEN crate)  The majority of DCS parameters are only used for monitoring or “write-once” (Simple I/O) To be archived in a database To be shown on a display To be written (set) only infrequently (e.g. start of run or on operator request)  Only small subset is used in control/feedback loops (intelligent I/O) Adjust an output parameter based on the value of an input parameter

3. André Augustinus 17 June 2002DCS Workshop 3 DCS parameters database sensor display Supervisory tool (PVSS II) device I/O device actuatorsensoractuator I/O device Intelligent Dumb Intelligent I/O Simple I/O

4. André Augustinus 17 June 2002DCS Workshop 4 DCS parameters  The use of a parameter determines the architecture of the detector’s control system and the choice of the technology: “fast” and/or reliable feedback requires intelligent I/O devices such as PLC or PLC-like devices Monitored parameters only require “dumb” I/O devices  “loose” feedback can be done at supervisory level HV adjustment for muon chambers Automation of operation

5. André Augustinus 17 June 2002DCS Workshop 5 Intelligent I/O Where will intelligent I/O be needed?  Most intelligent I/O will be needed in systems “external” to the detectors Gas systems Cooling systems Magnet systems Safety systems  Very few detector sub-systems have been identified that will need feedback loops e.g. HMPID liquid circulation system Based on the information (URD, discussions) so far

6. André Augustinus 17 June 2002DCS Workshop 6 Intelligent I/O, technology Possible technologies:  PLC (e.g. Siemens, Schneider) Gas and cooling systems  Schneider HMPID liquid system  Siemens Prototype rack control  Siemens  Programmable devices (WAGO, SAIA) Prototype TPC cooling  WAGO  Connection to supervisory layer via OPC  Potential problems when used in cavern (radiation)

7. André Augustinus 17 June 2002DCS Workshop 7 Intelligent I/O, technology PLC versus “PLC-like” device:  PLC is more powerful (CPU, memory)  PLC is more “robust” (error recovery)  PLC’s have a larger installed base  PLC needs more expertise to program PLC programming environment is more elaborate  Interface PLC to supervisory level (e.g. OPC) by PLC vendor  PLC is more expensive  PLC is officially CERN supported  Engineering tools are available for PLC

8. André Augustinus 17 June 2002DCS Workshop 8 Intelligent I/O, PLC  Tendency in PLC is towards Schneider gas, cooling, electricity, magnets  Siemens versus Schneider Functionality is comparable but code is not interchangeable, minor differences in languages Siemens has larger user community many “ready to go” examples available Framework for PLC applications under development UNICOS, currently Schneider only Hardware setup is easier for Schneider less wiring, more complex backplane

9. André Augustinus 17 June 2002DCS Workshop 9 Intelligent I/O, PLC  Siemens versus Schneider (continued) Better structuring of code for Siemens operation and function blocks Development environment for Schneider is lighter Need less mouse clicks to get where you want Depending largely on preference of developer Development environment for Schneider is free Relatively expensive for Siemens Support for fieldbus is different Siemens: profibus Schneider: CAN, fip, profibus Note by IT/CO: This is incorrect, Siemens and Schneider are about the same price

10. André Augustinus 17 June 2002DCS Workshop 10 Intelligent I/O, other  Experience (ALICE and IT/CO) with WAGO Positive for small applications ALICE TPC cooling prototype NA60 gas system (flow meter)  Will start investigating SAIA products Same programming environment as Siemens  Can be a relatively cheap alternative to “full” PLC Bearing in mind the limitations

11. André Augustinus 17 June 2002DCS Workshop 11 Simple I/O  The detector sub-systems mainly require only “simple I/O” from individual sensors through dumb I/O devices from more complex devices (e.g. HV power supply) from detector specific devices (e.g. Front-End card)  Access through network or fieldbus but connection to supervisory level might be less straightforward

12. André Augustinus 17 June 2002DCS Workshop 12 Dumb I/O, technology Possible technologies:  Dumb bus coupler with I/O modules available from Siemens and Schneider, but also from e.g. WAGO access via ethernet or fieldbus  ELMB access via CANbus radiation resistant  PC based (ADC, DAC, Digital I/O) PCI cards Private bus (e.g. NI fieldpoint)

13. André Augustinus 17 June 2002DCS Workshop 13 Communication  Via fieldbus Only CAN and Profibus identified so far CANbus mainly driven by manufacturers (ISEG, Wiener), not so much by detectors Ethernet need to be studied case by case for detector specific applications  Aim for commercial interface (OPC) to supervisory level (from interface or device manufacturer)  Other means of communication RS232, GPIB Technically feasible, but need to be studied case by case JTAG (to be seen if directly interfaced to DCS)

14. André Augustinus 17 June 2002DCS Workshop 14 Conclusions  Requirements have major impact on technology choices  Solutions exist today to meet most requirements  DCS team (and detectors) are gaining experience with different technologies IT/CO has lot of expertise in the field  Radiation is a serious concern for equipment in the cavern  Too early to make definite global choices Please do come to us if you need to make a choice !!! We can help you for test or prototype solutions