Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Mon, 17 Oct 2005 10:57:16 -0500

This is about some ICALEPCS talks (The meeting itself, the EPICS

meeting, and the ALMA/ACS workshop), which I thoughts were somehow

related to EPICS iocCore V4. I was at the tango workshop for only an

hour because it was the same day as the ALAMA workshop. I did not attend

any other workshops so I will not comment on them. Perhaps Kay can

comment more about the TANGO and ECLIPSE workshops.

The main commonality of the ICALEPCS meeting, the ALMA/ACS workshop, and

the Tango workshop is

1) A three tier model is common, i.e. a client layer communicates with

front end computers via services provided by a middle layer. The front

end implements device servers.

2) Frameworks are BIG.
3) Java is BIG.
4) Corba is being used but hidden via frameworks.

Let me speak first about ALMA/ACS. ALMA will be a large array of radio

telescopes in Chile.

ACS stands for ALMA Common Software. It looks like ACS is taking over

the radio astronomy community. Many sites are already adapting it. The

ESO (optical) also has a pilot project to investigate ACS.

ACS uses CORBA as its middleware but implements containers, i.e., a

framework on top of CORBA.

Clients can be implemented in Java, C++, or Python.

I think the following presentations are of particular interest.

http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/ACSWorkshop-ACSIntro.ppt
http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/ACSOverviewICALEPCS2005.ppt

These give a good overview of ACS

http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/beyondMiddleware.pdf

This talk by Steve Wampler gives a very good overview of what the

frameworks are trying to accomplish.

This is important for use to understand while developing V4.

http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/compareEPICSandACS.ppt

This gives a comparison of many existing systems. There are two things I

want to emphasize.

1) A slide shows that EPICS has a narrow interface and ALAMA/ACS has a

wide interface. Narrow means that epics just has well defined data types

and wide means that ACS has object to object communication.

2) It is not in the slides but at the presentation Mark said that it is

easy to allow ACS to talk to epics but hard to have epics talk to ACS. I

will go further and say that it will be hard to make any wide interface

talk to another wide interface unless they are very similar. A strength

of EPICS is that other systems can talk to it.

Since I was at the ALAMA/ACS workshop I was only able to be at the TANGO

workshop for about an hour.

I saw a presentation of ATK, which is a generic tool to create operator

interfaces. I assume it is the TANGO equivalent of an EPICS Display manager.

The ICALEPCS oral presentations including most of the workshop

presentations are already available on-line.

The ICALEPCS meeting itself was dominated by SERN/LHC talks. We heard

many papers about the LHC control system software. The work framework

appeared often. There are using PVSS from ETM which is object based

middleware for communicating with front end systems that access

hardware. See

http://www.gsi.de/onTEAM/dokumente/public/191069949690.ppt
For a description of PVSS.

There are a few papers I think are interesting because they described

things that are NOT handled by the common software framework.

http://icalepcs2005.web.cern.ch/Icalepcs2005/Presentations/13oct_Thursday/TH1/TH1.4-8O.ppt

This describes what the accelerator physicists are doing. Note that one

of the things they are using is SDDS!!

http://icalepcs2005.web.cern.ch/Icalepcs2005/Presentations/13oct_Thursday/TH1/TH1.5-8O.ppt

This describes JAPC (the Java API for Parameter Control) Since it is an

overview presentation it is hard to find out exactly what it is but

sounds interesting. It describes the basic functionality as:

1) set/get and subscribe
2) Obtain meta information about the parameter

It also talks about a narrow and wide interface but with the meaning is

1) narrow means passing all data via strings and 2) wide meaning passing

data the Java primitive data types.

One last paper is certainly of interest to EPICS V4 since it is talking

about EPICS V4. This is the talk by Matthais on EPICS Office which is

renamed to Control System Office

http://icalepcs2005.web.cern.ch/Icalepcs2005/Presentations/14oct_Friday/FR2/FR2.6-6O.ppt

Of particular interest to V4 core development is on slide 28

      Working on requirements and use-cases for the CSO-Data Access API

and slide 32

       Finish Control System Data Access API by Christmas this year.
           (We might also have a look at JAPC from CERN)

One last comment about something that is not available from any of the

presentations.

The following is the current plan for defining the CSO Data Access API

 1] Matthias and Ned will solicit "Use Cases for A Next Generation

Control System Data Access API" from some prominent EPICS Users (i.e.

application programmers who are application-driven rather than

protocol-driven). The basic question is "what would you expect from

EPICS V4?"

 2] These Use Cases, along with our current list of V4 features,

will be passed on to Cosylab (by Matthias). They will analyze, filter,

dissect and evaluate them and then define an API to accommodate as

many as reasonable. This will indeed get done, because Matthias has a

contract with them to do it!

 3] Once the API is defined, we will find the resources to develop

a Proof-of-Principle implementation of this API using ICE as the

network protocol.

Note that 3) does NOT mean that ICE will be the V4 middleware. It does

mean that it may be considered as one of the possible V4 middleware

components. Channel Access V4 will be another. The V4 client Data Access

API should be able to communicate via multiple protocals.

The remainder of this message is my current thoughts about what EPICS

iocCore V4 should be taking into consideration everything I heard at

ICALEPCS.

The following are the main features of EPICS IOCs

1) The IOC database is the heart of EPICS iocCore. It is what

distinguishes EPICS from the other control systems in use by the

accelerator and telescope control systems. Most of the others have the

concept of device servers in the front ends rather that an intelligent

runtime database, which means that the intelligence resides in the

workstations or else is implement in an ad-hoc way in the device servers

or in some other systems like PLCs.

2) The interface to the IOC database is narrow in the sense that

communication is done via data rather than a large set of objects. This

is what allows general purpose tools like display managers and what

makes it easy for other systems to talk to IOCs. In EPICS facilities it

is common for operators to create displays for MEDM or EDM. I suspect

that tools like the the tango gui builder would be used by programmers

rather than operators or hardware oriented engineers. Thus we must be

carefull about how much device orientation we introduce into IOCs.

Perhaps a power supply but not a high level physics abstraction.

3) EPICS can be either 2 tier or 3 tier. Thus for small systems

everything can be 2 tier. For large systems serves like name servers,

gateways, etc can introduce an additional tier.

4) High level device abstractions can and will be built on top of iocCore.

Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System