CA SERVER SUBSCRIPTION FILTERING IN EPICS R3.15

Jeffrey O. HillLANSCE / LANL

Outline Requirements, a review Design, a review Application Programming Interface (API) Status Benefits, a review

Requirements – LANSCE Needs LANSCE timing and flavoring of data

Flavoring Selection based on - logical combinatorial of

beam gates Timing

Selection based on - time sampling (single element) within a beam pulse

Many permutations Too many to, a-priori, install records for all of

them Need LANSCE timing and flavoring specific

subscription update filtering From general purpose IOC and client side tools

Requirements – LANSCE Needs LANSCE timed data requires Array Index

Metadata Magnitude of zero-eth element index

Floating point Magnitude of one index increment

Floating point Units of these magnitudes

String This requires presumably an extension to

existing DBR_XXX types, and changes to EPICS process control runtime database

Requirements – Client Decides Channel Access client must

specify LANSCE timing, flavoring needed when subscribing Channel Access service must

tag the data with LANSCE timing, flavoring attributes Channel Access server must

Appropriately filter subscription updates but …

This must be done in a generic way to allow parallel capabilities at other EPICS installations

Minimal to no impact on performance if the client does not request a filtered update stream

Within the IOC, record processing must not be disturbed by filtering activities in the server

Design Filtering expression specified, as a string, when

subscribing The client side remains general purpose Filter is specified as a CALC expression

Evaluates true, update sent to the client Evaluates false, update suppressed for this client

No revolutionary changes in wire protocol Only minor changes to client side tools Service specified data types

Parameter name to application specific datum bindings Parameter hierarchical sets Service data is introspected using a generic interface

The IOC can remain general purpose

Event Queue - Upgrade

CA ServerRecord

Event Queue

Legacy Fixed Event

Parameter Set

Scalar ValueTime StampAlarm Status

Upgraded Record Specific Event Parameter Set

Scalar or Vector Value

Time StampAlarm Status

…

Upgraded Device Specific Event Parameter Set

LANSCE Beam Gate Specification

Event Filter Upgrade

Record

Event Queue

Event Filter

Discard

Event Filter Expression

value < 10.0 and

value > log ( currentMonitor0007.current ) and

requireFlavor ( beamGateA | beamGateB ) and

excludeFlavor ( beamGateC )

TCP Circuit

API -Data Access

Catalog – implemented by users Subordinate class in c++ or an interface in Java

Introspector – called by usersclass CatalogTelesopeCoordinate :

public Catalog {public: CatalogTelesopeCoordinate ( MyData & ); void traverse ( Introspector & introspector ) const { introspector.reveal ( piRA, _refTC._rightAscension );

introspector.reveal ( piDecl, _refTC._declination ); }private: TelesopeCoordinate & _refTC;};

API Changes -Data Access

Clerk – called by users Library implements get

Throws an exception if source datum is out of range in destination datum’s primitive type

TelesopeCoordinate telescopeCoordinate;CatalogTelesopeCoordinate

catalogTelescopeCoordinate ( telescopeCoordinate );Clerk clerk ( catalogTelescopeCoordinate );Double rightAscension, declination;Clerk.get ( piRA, rightAscension );Clerk.get ( piRA, declination );

API Changes -Before, Guard Reference Passed Guard

Takes Mutex in its constructor, releases it its destructor

Benefits Exception safe Mutex release Avoids locking overhead, locked API calls locked API Mutable Guard can be temporarily released

Negatives Guard reference argument, every function in the API Not obvious, which Mutex used, which interface

Guard guard ( this->_mutex );caClient->createChannel ( Guard &, …);

API Changes -After, Locking Smart Pointer

After, locking smart pointer Smart pointer

Takes Mutex in its constructor, releases it its destructor Benefits - essentially same as Guard, but …

One less argument passed to every function Target tells us which Mutex is needed when it creates Ptr Ptr has embedded Guard – often built efficiently using

preexisting Guard reference (avoids recursive locking) Negatives

Must carefully limit access to raw pointers, synchronized interfaces

Ptr < Service > pService = createService ();pService->createChannel (…);

API Changes -Lifetime and Reference Counting Reference - used by the event queue to track

references to 3rd party Catalog used by each client’s event queue Destruction of last reference causes automatic release

notification to target Catalog All accesses to target Catalog are synchronized

Have to create a locking smart pointer to receive access

Ref < const Catalog > refCatalog;{ Ptr < const Catalog > pCatalog = createCatalog (); refCatalog = pCatalog;}Ptr < const Catalog > pCatalog = ref.release ();

API Changes -Lifetime and Reference Counting RefMgr < T > - implemented by the library

Maintains, contains The reference count A pointer to Handle < T > interface

One-to-one relation with instance of T Handle < T > interface

Implemented by author of T One-to-one relation with instance of T

template < class T >class Handle {public: virtual Ptr < T > createPtr ( const Guard & ) = 0; virtual void release ( Guard & ) = 0;};

API Changes, Client directly Invokes Service

Client directly invokes Service Client library and Service implementation interfaces are one

and the same This is a low level interface designed to allow efficient,

flexible implementations All requests are completed via callbacks Used only by programmers that prefer to have, need to have,

more control legacy, EZ, ultimate CA …

… this is layered value added With a flexible low level interface we always get what we want

First corollary of API design Its impossible to satisfy everyone’s needs with a simple, easiest-to-

use high level interface

Programming Interfaces -Channel Access

Service – called by clientPtr < Type > createType ( Ptr < const Catalog > & );Ptr < Channel > createChannel ( Ptr < const Catalog > & );

Programming Interfaces -Channel Access

Channel – called by client

Ptr < Request > = pChannel->createRequest ( Ident & method, Ptr <Type > & reqParmsType, Ptr < Type > & resParmsType );

Programming Interfaces -Channel Access

Request – called by client

pRequest->initiate ( Ptr < Responder > & responder, // callback interface Ptr < Catalog > & reqParms ); // request parameters

Programming Interfaces -Channel Access

Responder Callback interface – called by service

Ptr < Catalog > pCatalog ( guard, refMgr, myCatalogImpl );pResponder->successNotify ( pCatalog );pResponder->failNotify ( pCatalog );

Status, MAGVIZ, my Full Time Project Last Year + 2 Months Before MagViz

distinguishes potential-threat liquids from harmless shampoos and sodas screened at airport baggage checkpoints

Status, This Project I am working on this project again since

the start of the calendar year The server and event queue changes are

very close to completion The next step, a Service snap-in for

iocCore

Benefits for LANSCE LANSCE style dynamic on-the-fly ad-hoc

beam flavoring and beam timing experiments But, in homogenous EPICS system

Tool based approach to LANSCE applications Applications have abstract model of hardware Incremental upgrades hopefully easier

Multi-element “Timed” data COTS digitizer Window in time selected

Benefits for EPICS Community

Flexible event snapshots Parameters other than alarm status, time stamp,

scalar value correlated on event queue Array update bursts buffered on event queue

Subscription update filtering Expression (string) based means

Project and site independent – tool based approach Minimally invasive for existing client side tools

Array index meta data Expanding intersection of EPICS with data

acquisition systems