Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 12 Dec 2000 22:08:08 +0100

Hi Everyone,

when I learned about epics a couple of years ago, the only reasonable
approach to Channel Access seemed to accept it as a fact of life and to
try to understand how to work with it. Now the situation is somewhat
different, since I hear that CA is going to enjoy a major revision, and
that the new portable ca server library is planned to be used in the ioc
as well, maybe already in R3.15.

If CA is indeed to be revised, I want to use the opportunity and present
my idea how this should be done and how not. To some of the "old guard"
all this is probably heresy, or maybe just stupid crab, I don't know. I
must admit that I never quite understood the rationale behind the design
of CA as opposed to the epics database and ioc core - it may well be
that I missed out important considerations that render all of the nice
proposals below completely obsolete.

However, let me begin with some general observations: As we all know,
the epics real-time database is structured along the notions of field,
record and recordtype. While the field is the atomic unit of data,
several related fields are grouped to form a close unit called record.
The definitions of the various recordtypes not only implicitly define
the field names and their data types; they also define a context in
which their these fields have an associated *meaning*.

Channel Access, on the other hand, is structured along the notions of pv
(process variable), dbr (database request) type, and event type (or
event mask). In principle, a pv corresponds to a certain field of a
certain record. That seems reasonable, since we want to be able to
address the smallest atoms of the epics db as an independent variable.

What are dbr and event types needed for?

(1) Composite dbr types are used to enrich the value of a pv (that is: a
certain field of a certain record) with a number of attributes, in
addition to the pv's value, such as status or timestamp or certain
limits on the value. The dbr types are the predefined combinations of
those attributes that the client may request. [In the more fashionable
terminology of the new portable cas, the attribute types are called
"application types".] On a closer look however, these attributes are
almost always the values of somehow related pvs, usually other fields of
the same record. The responsibility to decide which field contains the
appropriate attribute for some given field lies with the record support
(and the ioc core for dbCommon fields). (For an exception see remark (d)
below.)

(2) Dbr types specify a desired conversion from the primitive type of
the field (the so called native type) to the type the client wants. They
also implicitly define the requested primitive types of eventual
attributes. The necessary conversion between native and requested type
is done by the server before it sends the value.

(3) Event types are basically used to distinguish the triggering
attribute of a composite (with attributes enriched) pv. Thus, an alarm
event is triggered by a change in status or severity, a value or log
event by a change in value. The only difference between the log and
value events is that sometimes they use different deadbands (e.g. if the
primitive type of the pv is float or double).

Now, the need for additional event types, application types, and dbr
types arises naturally from the continuing process in which more
advanced client programms are developed (gateways, alarm handler,
archivers, display managers, etc.), each new sort of client colliding
with the limited supply of these types.

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.

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 extendability, 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.

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.

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.
- 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.

This is the general outline. I want to add a number of technical
considerations and general remarks.

(a) It may be useful or necessary to restrict the client's ability to
combine pvs into a closely coupled group. The first condition is of
course a successfull connection to these pvs. Further restrictions may
be that the pvs reside on the same server instance (decided by the
client library), or even in the same record (when the server is an epics
database on an ioc), or it may be left in the responsibility of the
server tool to restrict grouping as it sees fit.

(b) Requests for a closely coupled group of pvs will be packed into a
single data object before sending (on both sides). The client and the
server library therefore need to keep track of the composition of these
grouped requests, so they can dispatch incoming messages accordingly.

(c) Clients need to know which pv names are "related" to a given one. To
achieve this, it looks as though we either (i) still need the concept of
application type (pv attribute type) as a concept seperate from the pv
name, or (ii) define somewhat stricter conventions for the meaning of
record field names.

(i) If we follow the former approach, the application type should be
extendable at the database definition level (for databases, i.e. the
server onthe ioc), so that new record types may define new application
types. The server must then be required to *suggest* related pv names,
that the client may use in the sequel to obtain attributes (the ioc core
will delegate this in part to the record support, just as it is now).
The server will of course do so only if it has reasonable candidates to
offer. The information could be sent a part of the answer to a
connection request or it could be the answer to a special request.

(ii) If we follow the latter approach, we only have to care about fields
that do not belong to dbCommon (STAT, SEVR, TIME, etc. are the same for
each record type). It possibly makes sense, if the server still returns
a basename that the client can use to construct related pv names. I am
slightly in favor of this second method; the required changes at the
recordtype level are minor and some general overhaul of the standard
epics records is in order anyway - sooner or later.

(d) Some pv attributes do not correspond directly to a related field.
The only case I can think of at the moment is the enum string table for
fields which have type DBF_MENU. I'd say that in this case the server
should send the string itself - instead of sending a suggested pv name,
which the client may read to get the enum string - since this value can
never change during the life-time of the pv (even the server itself).
This will be indicated with a flag that is sent along with the string.
The method could be generalized to include any kind of attribute that is
guaranteed to remain constant over the life-time of a pv.

It will be necessary to add a field, containing all the enum strings in
a single array pv, to the enum type records such as bi, bo, mbbi and
mbbo.

(e) Restricting data type conversion to happen on the client side has a
lot of advantages: The client machines are usually more powerful than
IOCs. The IOC needs to perform real-time tasks, the clients usually
don't. Thus it makes sense to relieve the server of the task of
converting the data to the type desired by the client. Most existing
clients already request the native type in order to save bandwidth and
reduce IOC load.

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

(g) Last but not least: It should be a manageable task to provide a
compatibility layer that emulates the current CA client interface on top
of the new one, so existing clients need not be changed.

In the hope to inflame a hot discussion,

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System