Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 18 Oct 2005 00:57:28 +0200

On Monday 17 October 2005 20:14, Kay-Uwe Kasemir wrote:
> On Oct 17, 2005, at 13:41 , Steve Lewis wrote:
> >> 1) 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.
> >
> > This is the key difference.  The NIF control system also has an
> > ALMA_like, wide, object-to-object interface.  My opinion is that
> > this nearly killed it.  A wide interface is a very subtle way of
> > replacing the benefits of encapsulation and data hiding with
> > (larger) problem of "interface coupling".
> >
> > You cannot effectively build tools; programmers need to be involved
> > at every level, forever. Even small changes require rebuilding
> > everything: it's "make clean; make" every night--hopefully you have
> > a full suite of regression tests with a lab filled with real
> > hardware. NIF has about $500K sunk in such a lab, and keeps its
> > test team staffed at 25% of the level of the developers.
>
> I believe that. On the other hand this talk listed by Marty:
> http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/
> beyondMiddleware.pdf
> .. which gives the example of replacing CORBA with ICE.
> Now: hard, requires recompile etc.
> Future: easy based on divine framework with interfaces to services in
> containers.
> Can replace the CORBA plugin with an ICE plugin, at run-time, going
> forth and back.
>
> So who's right?

Note that the talk you mention is mostly about the "future", IOW it's 
vapor-ware (like EPICS V4 at the moment, to be fair). It all sounds a 
bit too optimistic in favour of co-existence of quite different 
approaches, IMHO. Look at the internet and how (and why) it took off: a 
very small number of rather simple protocols, each dedicated to solve a 
dedicated problem; evolution eradicated all competitors to TCP/UDP/IP 
as the foundation layer; most commonly used higher level protocols dead 
simple (text and even line based), witness http, email, etc.

As Marty observed, it is easy to talk to EPICS/CA. This is because it is 
flat, low-level, simple and efficient.

Maybe the direction to go with EPICS V4 is to strive for a two-layered 
middle-ware: a low-level part, that will hopefully be even simpler 
(conceptually at least) than the current CA, but OTOH flexible enough 
to make it suitable as a foundation layer for more specialized 
protocols that build upon it. Getting rid of arbitrary size limits and 
of a fixed number of data structures and event types are the most 
important points here, I'd say. Maybe basic support for crossing 
network boundaries. Oh, I forgot a precise specification of the 
protocol, independent of any implementation.

We should take care that higher-level stuff such as name services, 
support for redundancy, device-priented abstractions, etc. /can/ be 
built on top of this, without compromising efficiency or 
interoperability, but I think it would be a mistake to try to include 
all these things into CA proper.

The decisive advantage of such a two-(or rather multi-)layered approach 
is that in case a higher level fails to provide enough flexibility (see 
Steve Lewis' sniding remarks ;) there is always the next lower level to 
fall back to. In an ideal world, I imagine standard high-level 
communication services to be appear as factored-out solutions to common 
problems.

[Note: I wrote this before reading the Claude Saunders' post. He argues 
in a similar way and I agree with most of it.]

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System