Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 12 Dec 2000 17:29:05 -0700

>
> Thus, we are facing pressure to add more 'features' to CA, thereby
> further increasing its complexity. I don't believe that this is the
> right way to go.

The features you are asking for introduce additional flexibility for
clients and inevitably additional complexity in the client and server
libraries. For example the ability to send a monitor subscription update
for process variable xyz when some process variable pdq changes requires
additional infrastructure in the server library which does not exist
today. This is not to say that we don't find that this level of flexibility
would be useful. Instead, many of the features that you are asking for have already been placed on our list of long term upgrades
for CA. We are
left only with a decision about what to implement first.

>
> One of the main reason why epics is such a useful thing and so much fun
> to work with, is that it makes extending and specializing it relatively
> easy. Instead of building on top of this extendibility, we drop it as
> soon as we leave the ioc.
>
> The natural association between the fields' names and the context in
> which they have a specific meaning is completely lost outside the
> database (in a technoical way, that is). Instead of using it, CA
> introduces a separate kind of semantic, the application / dbr type,
> which is independent from the database definition.

This isolation was introduced to facilitate a tool
based approach. Our specific intent was that the client side tools
should not need to be modified when a new record type was added to
the system.

>
> What I propose for the next generation of CA is therefore to abandon
> both dbr types and event types, in order to extend the flexibility and
> semantical depth from the IOC into the client. I believe that this can
> be done if we proceed along the following lines:
>
> Eliminate the need (1) for dbr types:
>
> - If a client desires attributes to a pv, it must explicitly connect
>   to "related" pvs. How clients find out which pvs are related, is a
>   matter of taste. See additional remark (c) below.
> - Clients may force a strong coupling of related pvs by grouping
>   them into a single request, just as with the current dbr types, but
>   without the need to adhere to some predefined combination.
> - Clients will routinely do this for attributes such as status, severity
>   and timestamp. On the other hand it makes *no* sense to force such a
>   strong coupling for display or alarm limits: these tend to
>   change only occasionally, if at all. Instead clients will want to
>   monitor such pvs independently.
>
> Eliminate the need (2) for dbr types:
>
> - Server always sends the value of the pv in its native type.
> - Conversion is done, if desired, be the client. A powerfull library
>   for type conversion exists and should be used by clients whenever
>   necessary.

Moving primitive conversions from inside the server library to inside
the client library is a goal for future versions. We do not, however,
plan to place this burden on either the client or server side tools.

>
> Eliminate the need (3) for event types:
>
> - If a client monitors a strongly coupled group of related pvs,
>   it may specify which of these pvs shall be triggering an event
>   and which shall not. For instance, an alarm handler will specify
>   the corresponding STAT and SEVR as trigger pvs. A display manager
>   like the dm2k will also specify VAL.

It is a goal for future versions to allow triggering of monitor
subscription updates for channel xyz when channel pdq changes.
It is agreed that this sort of client side flexibility might be
generally useful, but currently we are embarking on a solution
that allows some degree of client and server side flexibility,
retains the high performance potential of the current system,
and can be implemented within a reasonable bounded effort.

In the current system the higher priority ( read more real time )
activities in the EPICS IOC post events to a monitor subscription
update queue. If the network is busy, some finite number of
subscriptions updates are saved before inevitably we must replace
the last event on the queue for a particular subscription. Since
these events are fixed in size it is easy to come up with an
efficient implementation of the queue that does not fragment the
IOC's memory. This implementation also has the desirable effect
that, as the network becomes busy, the server tends to send more
subscriptions updates in each network frame.

In the future we would like to allow the server tool to post
event types that are unknown to the server or client libraries
at compile time. These new event data structures will be shared
in the event queues of several clients. When the last client
dispatches its subscription update for a particular event type
the event data structure will be returned to the server tool's
storage management. Since the server tool knows about its event type at
compile time it is easy for it to come up with an efficient
storage management scheme for queued events (probably a free list).
Ralph Lange and I are current working on an efficient mechanism for
mapping between these server specified event data structures and the
client tool specified subscription update data structures.

With the approach that Ben suggests the set of associated attributes for a
particular event type is know only at runtime (not at compile time).
This makes it particularly challenging to come up with an efficient
run time solution. Likewise, the interface between the server tool
and the server library is further complicated because we must arrange
for a consistent set of attributes. That is, the {time stamp,
value, alarm status, alarm severity} set must all come form the same
instance of record processing. Since the server library is discovering
that an event trigger has occurred, and then at its own (probably lower)
thread priority deciding to go out and capture the necessary data it
also becomes more difficult to make certain that the data and the trigger
are consistent. Furthermore, opening independent channels
for each PV attribute might significantly increase memory and
CPU consumption by the system.

> - Clients are free to specify any desired value as the monitor deadband,
>   as long as the corresponding pv is triggering and its primitive type
>   is a number.
> - On successful connection to a pv, the server may suggest related pvs
>   that contain suitable deadbands such as the corresponding
>   MDEL and ADEL fields, if such fields exist.

Only the server tool can decide on its own when its data
has changed, and therefore an event should be posted. Otherwise,
we are forced to poll the data from the server and introduce
additional overhead and also propagation delays.

It is however desirable in future versions to allow the client to
specify a wider deadband than what is used by the server tool to decide
if its PV has changed. This is already on the list.

> (f) Writing server tools will be simplified drastically (this is one of
> the reasons I began to think about this).

Quite a bit of effort went into designing a server tool interface
which would be both easy to understand and sufficiently general
so that EPICS protocols could be grafted onto almost any system. You
need only implement a PV existence test, a PV factory, read and write
routines for each of your PV types, and then post events when your
PVs change. All data conversions are handled by the libraries. But
perhaps this over simplifies the task. If what you want is a perfect
emulation of the EPICS function block database, then there is of course
quite a bit that you must implement, and my feedback from users
has uniformly implicated GDD as a source of some confusion.

I suspect that you desire to eliminate PV attributes from the interface
may result from frustration with GDD. If so, then I should add that
Ralph and I are working on a new approach which should greatly
simplify the interface. This approach will be reviewed on tech-talk
before we commit to it.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System