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 ServerCA ServerRecordRecord

Event Queue

Legacy Fixed Event

Parameter Set

Scalar ValueTime StampAlarm Status

Legacy Fixed Event

Parameter Set

Scalar ValueTime StampAlarm Status

Upgraded Record Specific Event Parameter Set

Scalar or Vector Value

Time 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

Upgraded Device Specific Event Parameter Set

LANSCE Beam Gate Specification

Event Filter Upgrade

RecordRecord

Event Queue

Event Filter

Discard

Event Filter Expression

value < 10.0 and

value > log ( currentMonitor0007.current ) and

requireFlavor ( beamGateA | beamGateB ) and

excludeFlavor ( beamGateC )

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 users

class 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 client

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