EPICS V4 Channel Provider Proposal

EPICS V4 Channel Provider Proposal

EPICS V4 Channel Provider Proposal, Editor's Draft, 30-Apr-2012

Latest version:
epicsv4_document.html
This version:
epicsv4_document_20120430.html
Previous version:
No previous version yet
Editor:
Dave Hickin, Diamond

Abstract

In EPICS 4, a client must supply a channel provider when connecting to data identified by a channel name.

The client will know the list of providers which are available for it to use, but will not know which provider it should use for a given channel name. In some cases more than one provider could be used.

This document describes how a client determines which provider is used for a given channel name.

For more information about EPICS, please refer to the home page of the Experimental Physics and Industrial Control System.

Status of this Document

This is the 30 April 2012 version of the EPICS 4 Channel Provider document. This is the first draft of the document

This is a first draft and has not received any comments/feedback It does not clearly state what behaviour is mandatory, what is recommended and what is optional. In particular, for a given implementation

  1. Which methods, if any, for determining the provider must be implemented?
  2. Must an implementation permit the application layer to create a channel by both specifying and not specifying the method to be used to determine the provider?
  3. In the reference implementation the default behaviour when no method of determining the provider is suplied will be pvAccess if there has been no configuration of the client or site-level configuration. Should this be mandated in other implementations, or should an implementer be allowed there own default?

This version is an editor's draft towards the First Public Working Draft. The First Public Working Draft will be intended for the EPICS community to review and comment. Resulting comments will drive subsequent revisions of the Normative Types specification and the EPICS V4 Working Group's reference implementations of software that helps create, populate and exchange Normative Type PVData.

Comments are welcome, though bear in mind this is a pre-public release version.

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, and MAY when highlighted (through style sheets, and in uppercase in the source) are used in accordance with RFC 2119 [RFC2119]. The term NOT REQUIRED (not defined in RFC 2119) indicates exemption.

Table of Contents


Introduction

EPICS 4 pvData provides structured data types bib:pvdata. A client can connect to data identified by a channel name and once connected to perform operations which access the data (get, put, rpc, etc.). A channel which connects to the data is created by a channel provider. The pvAccess channel provider provides access for pvData using the pvAccess protocol bib:pvaccess. The caV3 provider provides access using the EPICS base CAV3. Other providers are possible, e.g. TINI or TANGO.

In order to connect to data identified by a channel name an channel access client must know which provider to use. The client knows the list of providers available to it, however it does not know which provider to use for a given channel name. A client may broadcast on multiple provider ports to establish which provider to use, however multiple replies may be received, with each reply implying a different provider. Specifically, this will happen when a channel is hosted by an V3 IOC that has both a V3 and V4 server on it. In this case responses may be received on both the pvAccess and V3 channel access ports.

How to determine the provider

A number of methods exist for determinining which provider to use to connect to a channel.

  1. Connect using a specified provider.
  2. A name resolution request [UDP broadcast] is made on multiple provider ports. More than one reply may be received where each implies a different provider. The client would then connect on the provider which answered first. Other alternatives are possible, for example connecting to the first reply unless a preferred provider replies within a given time.
  3. The client gets the provider from the directory service before connecting to the channel using the provider given.
  4. Other methods are possible, e.g. use of prefixes to determine the provider.

The client application layer can:

  1. Specify one of the methods above for determining the provider. In particular it may request connection using a specified provider.
  2. Connect to a channel without specifying the provider or the method of determing the provider. The choice of method is determined in the client in a layer below the application layer.

In case 2 the choice of method is the determined in the library functions called by the client application by configuration using environmental variables or other similar mechanism.

The default configuration is pvAccess, but sites/installations can choose their own default behaviour or it can be set on a per client basis.

Bibliography

bib:epicsv4home
EPICS V4 Homepage, EPICS V4 Working Group, Sep 2011 and after, http://epics-pvdata.sourceforge.net/
bib:pvdata
EPICS pvDataJava, Marty Kraimer, BNL, Latest Version, http://epics-pvdata.sourceforge.net/docbuild/pvDataJava/tip/documentation/pvDataJava.html
bib:pvaccess
EPICS pvAccessJava, Marty Kraimer, BNL, Latest Version, http://epics-pvdata.sourceforge.net/docbuild/pvAccessJava/tip/documentation/pvAccessJava.html
bib:epicsrecref
EPICS Reference Manual, Philip Stanley, Janet Anderson, Marty Kraimer, APS, http://www.aps.anl.gov/epics/EpicsDocumentation/AppDevManuals/RecordRef/Recordref-1.html

Contact author: Dave Hickin, Diamond
Last modified: Mon Apr 30 22:54:03 CEST 2012