André Augustinus 10 September 2001 Common Applications to Prototype A two way learning process

André Augustinus10 September 2001

Common Applications to Prototype

A two way learning process

10 September 2001DCS workshop 2André Augustinus

Introduction

Why seeking common solutions?• Avoid duplication of work in the detectors• More efficient support from experts• Bulk purchase may reduce hardware costs• Spares can be shared; thus less spares• Easier maintenance, very important in the longer

term future• Aim for a coherent, homogeneous DCS


Common Solutions

Try to find communalities across detectors• Need requirements

Look what solutions already exist or are proposed• In ALICE• In other experiments (JCOP)• In the accelerator and services


Common Solutions

Currently we concentrate on the process level of DCS

For solutions we concentrate on:• CERN accepted commercial solutions• CERN supported solutions (IT/CO, JCOP, …)


Prototyping

We would like to participate actively in the prototyping:• To learn the problems one might encounter• To learn and test current technologies


Prototyping

How will we proceed• Participate actively in getting clear requirements

• This usually involves several iterations

• Based on the requirements, propose a solution that would fulfill the requirements (with help of experts in e.g. IT/CO)

• If accepted, provide support for the implementation and commissioning

• Collect feedback


Objectives

The objectives of prototyping• Validate current ideas

• Ease of implementation and maintenance• Evaluate performance and reliability issues• Evaluate scalability

• Validate possible “final solutions” on “real systems”


Objectives

The objectives of prototyping• Compose a “catalogue” of tested and supported

solutions, easy to implement and maintain• Guidelines• Framework, examples

Inconveniences: • To start it might be heavy on resources (manpower,

money and time), but it’s not a waste, it is an investment

• System might at first be “over-dimensioned”


Current status

Currently concentrating mainly on the process level of DCS

Two pilots:• TPC

• High Voltage• Low Voltage• Cooling• Fieldcage (drift field)

• HMPID• High Voltage• Low Voltage• Fluid system


Current status (HMPID)

Started well before the central team existed Gained a lot of experience with hardware

and software that is most likely to be used more generally in ALICE

• CAEN HV, PLC (Siemens), PVSS, DIM, SMI

Should make this expertise available to a wider public (even outside ALICE)

We learn more from them then they from us


Current status (TPC)

Established first contacts with the various sub-systems: HV, LV, cooling and Fieldcage

High and Low Voltage:• Based on tests and surveys the TPC found a

devices that satisfied their needs: ISEG for HV and Wiener for LV

• We are currently investigating how these devices can fit in the global DCS picture (mainly a communication issue)



Cooling:• A test system has been built and is in principle

running. But might not be the most optimal choice to apply to the “final system”

• In the process of gathering more detailed requirements

• Based on this we should be able to propose a solution applicable to the “final system”; and adaptable to other detector needs



Fieldcage:• HV Power Supply, Current monitor, Cooling, Internal safety

• Most advanced as far as our involvement is concerned.

• Currently refining the user requirements for the system. We are preparing a third iteration.

• Close to proposing a solution that in principle should be a “final solution”.

• The prototype control system should be running by the end of the year.


Current status (Testlab)

Announced in May, but little progress during summer• Siemens PLC is installed

Foreseen in the near future:• More “typical” hardware to be installed• Develop simple demo-applications

Goals:• Get acquainted with hardware and software• Use as a development platform for prototypes


Future developments

Continue work on pilots Start work on a “vertical slice” of ALICE

• Build a control system from the hardware up to the highest level

• Validate the proposed architecture of the DCS (see a later talk)


Conclusions

Inform us on what you are doing We need your requirements

• You’ll be getting more questionnaires• You’ll be invited for meetings• You’ll get examples/instructions to prepare your URD

The ideal DCS would have for all systems standard solutions, no “special cases”.


Conclusions

We will not force you into a solution that will not match your requirements

We might be annoying you now, but you will profit from it in the long run

We are a collaboration

Documents

André Augustinus 10 September 2001 Common Applications to Prototype A two way learning process