Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 17 Oct 2005 13:23:32 -0600

> There was at one time a middle ground here, and it was called CDEV

Here is some background for those that don't know, or don't recall, the
history behind how we arrived at the Data Access approach.

Note that with CDEV a messaging interface was just an asynchronous
communication endpoint (dare I say channel) with an incoming CDevData and an
outgoing CDevData. Note that CDevData gave birth to GDD which was really not
functionally different from CDevData, and was intended to be a unifying
gateway between the two systems. We tried that in the portable server API
and were not happy with the result due to ease of use issues. In particular
ambiguities about who was responsible for what on either side of
communication interfaces became a big issue. Here is a paper on that.

http://www.elettra.trieste.it/icalepcs99/proceedings/papers/mc1p58.pdf

We were also concerned about performance issues in the performance critical
components of EPICS. In particular - I became very concerned about the
efficiency of the subscription update queue.

As a result Ralph and I created Data Access. As I recall, that approach was
reviewed and validated at two separate meetings (one at LANL and one at the
APS) at which all of the key players of that time were present. Here are the
resulting papers.

http://arxiv.org/ftp/cs/papers/0111/0111026.pdf
http://arxiv.org/ftp/cs/papers/0111/0111036.pdf

So the key difference between {DataAccess, CDevData, GDD} and CORBA based
systems is the potential for project portable tools that dynamically bind to
interfaces. Why is that? Because the purpose of the properties (the
parameters) passed in the communication system are known to the
communication system, and also to high level tools that use the
communication system.

Marty has asked how we would build a CA Gateway with DataAccess. My response
is that I wonder how we will build a gateway without DataAccess - without
dynamically learning the properties (the purposes of the parameters) in the
messages at runtime. I don't think we want to rebuild the gateway whenever a
new IDL snippet gets used. Admittedly, the Tango/ACS approach tends to
naturally include gateway like isolation as one moves up the device
hierarchy yet one worries that there is still a potential for scaling issues
if every graduate student in the facility pulls up applications attaching to
the lowest level interfaces.

I think that similar concerns apply to the archiver, display manager and
many other tools that we have come to assume will exist in an EPICS control
system.

Proper uniform definition of connection responsiveness notification
interfaces is also a very important issue that is often overlooked in a
first cut CORBA based approach. In any case that was what the reviewers
commented about initial efforts at NIF.

Finally, I must add at this point that I actually do have optimism for
project portable tools that bind to well defined (and designed) device
specific project portable programming interfaces (the CORBA approach). What
I like about Data Access is that it appears to accommodate both wide
interfaces and a generic approach to wide interfaces. We therefore can work
well in both worlds even if it, for example, takes a few years for CERN and
FERMI to agree on exactly what the proper programming interface is to a
LINAC. 

Jeff

> -----Original Message-----
> From: Claude Saunders [mailto:[email protected]]
> Sent: Monday, October 17, 2005 12:36 PM
> To: [email protected]
> Subject: Re: ICALEPCS and EPICS iocCore V4
> 
> Steve Lewis wrote:
> 
> > Marty Kraimer wrote:
> >
> >>
> >> 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.
> >
> >
> > Again, this is what the NIF architecture is like.  It is (was)
> > extremely frustrating under this architecture to bring some
> > functionality to bear on the hardware and to the operators.  What
> > would have taken 10 minutes with VDCT and 1 minute with MEDM in EPICS
> > took from 1 hour to 1 day from each of 1) the FEP programmer; 2) the
> > tier 2 programmer; 3) the IDL/SQL/RDB team; 4) the GUI programmer; 5)
> > the tier 3 team [sequencer-like "scripts"]; 6) the CM team to
> > "regenerate the IDL", do "make clean; make".  And then you test.
> > Elapsed calendar time: weeks to months.
> >
> > We called it "IDL hell" and employed the most devious strategies to
> > avoid items (2)-(6).
> >
> > </RANT>
> >
> There was at one time a middle ground here, and it was called CDEV. I'm
> not suggesting reviving that particular implementation, but it was a
> interesting idea, and there was a great deal of thought and design that
> went into it. There are quite a few similarities between the old CDEV
> discussions, and what I'm hearing now about the tension between
> channel-based and object-based access.
> 
> CDEV provided a device abstraction (sort of like objects with a dynamic
> invocation interface) while being readily re-configured. In short, no
> "make clean; make", or IDL hell.  So...
> 
> Is there anything wrong with supporting 2 namespaces for control? One
> would be the channel-based namespace EPICS currently offers, and the
> other would be a device abstraction ala CDEV. Before everyone recoils in
> horror, realize that most places wind up de-facto doing this anyways.
> SNS has EPICS, but yet all their applications are driven via an object
> model realized in a relational database, that in turn has the
> association with the underlying EPICS PVs. Here at APS, our OAG group is
> effectively doing a form of this using SDDS to group PVs into more
> useful abstractions. All this to make higher level operations and
> physics applications easier to understand and work with.
> 
> So keep the nimble applications like MEDM, which require a channel-based
> data layer, but explicitly support a device abstraction layer as well.
> Things like feedback loops would be left to the EPICS record level, not
> implemented at the device abstraction layer.
> 
> I guess this isn't too far from just dropping the upper levels of Tango
> on top of EPICS, but it is distinct from that approach in that I would
> suggest making it more configurable than the typical IDL based approach
> (which Steve correctly notes can be hell in a dynamic environment).
> These dynamic device abstractions could be presented as CORBA objects in
> an ORB possibly...
> 
> <disclaimer>
> Just talking out loud here, and please forgive me if I have
> misrepresented CDEV, Tango, or EPICS.
> </disclaimer>
> 
>   - Claude

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System