Jeffrey Hill

 LANSCE Requirements – a Review  EPICS Paradigm Shift – a Review  Status – What is Implemented  What is an Abstract Data Type?  Benefits of Abstract Types  A New EPICS Database Field Type for Abstract Data  LANSCE Schedule  Conclusion

LANSCE, a versatile machine – Originally producing H+, H-, and polarized H- Each with different intensities, duty factors, and even energies – depending on experimental and medical isotope production needs LANSCE timing and flavoring of data – Flavoring Selection based on - logical combinatorial of beam gates – Timing Selection based on - time window sampling Many permutations – Too many to, a-priori, install records for all of them – Subscription update filtering is needed

Distributed Control Data Acquisition Physics Control Open Source Vendor Neutral OS Neutral Small Footprint EPICS

 What is a Data Acquisition System? Replacing …

 What is a Distributed Data Acquisition System?  Must efficiently filter, and archive data  Selecting interesting occurrences  for future processing /evaluation  Flexible reconfigurable by clients at runtime ▪ Don’t expect to know initially, when designing/compiling runtime system, what experiments/filters might be devised later on ▪ Experiments/filters configured when client subscribes ▪ Don’t expect to know initially, when designing/compiling runtime system, what data aggregations will be on different data branches to different clients

 Current weaknesses deploying EPICS into Data Acquisition situations? Record processing provides good flexibility to create event filters, but …  Frequently, it isn't possible to know all of the experiments when the IOC’s database is designed  A distributed data acquisition system needs runtime reconfiguration, initiated by client side tools  Limited data model  No runtime aggregation, or user defined types

 Current weaknesses deploying EPICS into Data Acquisition situations? No support for site specific tagging of the data  If a site needs to filter for LANSCE H- beam, then forcing this to occur based on the time-stamp  Inflexible solution - from a LANSCE perspective  Our solution  Site specific parasitic PV attribute data can be filtered by the CA server

Alarm State PV ValueSignal Data Time Stamp Device Support Record Support DB Common CA Server Record Specific Values Device Specific Values

CA Client Multicast Enhancements CA Server Multicast Enhancements Implemented Mostly Implemented  Multicast Enhancements Simplified configuration of EPICS Systems with  Multiple IOCs on one host  Installations with multiple subnets

Device Support CA Server Event Queue Upgrade Database Enhancements Database CA Service Implemented Under Design LANSCE Specific CA Server Event Filtering Upgrade CA Server Service Interface Upgrade

 Subscription update event filtering >camonitor "fred$F $(PV:)>30 && $(PV)<40" fred$F $(PV:)>30 && $(PV)< :58: fred$F $(PV:)>30 && $(PV)< :58: fred$F $(PV:)>30 && $(PV)< :58: fred$F $(PV:)>30 && $(PV)< :58: fred$F $(PV:)>30 && $(PV)< :58: fred$F $(PV:)>30 && $(PV)< :58: >camonitor "fred$F $(PV:flavor)==30 " fred$F $(PV:flavor)== :58: fred$F $(PV:flavor)== :58: fred$F $(PV:flavor)== :58: fred$F $(PV:flavor)== :58: fred$F $(PV:flavor)== :58:

 An Abstract Data Type is defined by  Operations that may be performed on it  Some mathematical constraints on these operations  Our goal, always … Separation of interface from implementation  Isolate from each other …  The details of the internal encoding of the data structures of the implementation  The interface used to manipulate the implementation

 Defining Abstract Data Type’s Interface Specify Abstract Type’s name Specify Abstract Type’s N methods  Specify method’s name  Specify method’s I input, and O output, parameters  The parameter’s name  The parameter’s data type class  i.e. integer, real, string, enumerated  The parameter’s acceptable range  The parameter’s optional default

 Type Safety – user specified parameter must match with the specification of the interface All parameters passed by users must match  The parameter’s name  The parameter’s data type class  i.e. integer, real, string, enumerated  The parameter’s acceptable range Input Parameters  All input parameters must be supplied if the interface doesn't specify a default Output Parameters  All interface specified output parameters must be supplied  Additional optional output parameters may be present w/o violating interface specification  If properly qualified by a standardized path name – i.e. project/LANSCE/flavor

 Users can manipulate an entity more complex than a Process Variable  Implementation is free to evolve without impacting the users  We can pass in N parameters atomically Example, we can set the x, y, z coordinates together as a unit  We can pass out N parameters atomically Example, we can extend the set of parameters passed with a subscription update to include the LANSE flavor

 New field type Field size is sizeof ( pointer ) Field content  Reference counting C++ smart pointer  Smart pointer points to C++ pure virtual interface class  This is the C++ interface used to interface to an Abstract Data Type

 How do database links work? If the source is ordinary data and the destination is an Abstract Data Type instance  Not permitted unless the destination abstract type has value set method If the source is an Abstract Data Type instance and the destination is ordinary data  Not permitted unless the source abstract type has value get method If the source is an Abstract Data Type instance and and the destination is an Abstract Data Type instance  Not permitted unless  Both source and destination have same Abstract Data Type name  If permitted then smart pointer in the destination is simply changed to become a new reference to the source  Or there is a matching set/get

 Implementation issues Parameter interfacing  Presumably Data Access interface is used Parameter conversion and range checking  Presumably Data Access library is used

 Implementation issues Presumably these capabilities are evaluated first only in new record types  Therefore, minimal impact on existing installations

 Data Access, is it Easy CA? In the EPICS community we have – Application developers (well adjusted, etc) EPICS database, screens, matlab, python, tcl, etc – System programmers (geeks) Device drivers, EPICS internals, etc Implementing Data Access interface for particular data structure / class System programmer job

Data Access, is it Easy CA? Once interfaced with Data Access – A high level (i.e. easy ca interface is available) – DA is not the data manipulation interface used by application level users – Users use the public interface of the data structure / class which has been interfaced – Communities develop around the data structures / classes standardized by particular applications, industries, and instruments

 Orders for our new klystrons are in place  We will provide production subscription update filtering capabilities for the LANSCE upgraded RF system and the LANSCE upgraded diagnostic systems in 2013  Prototypes will need to function considerably before that time frame

 A significant upgrade for EPICS is in progress, significant milestones have been completed Multicasting – easier configuration Subscription update filtering – client specified filter expression Upgraded server event queue – optimal order preservation and transport of user defined types Upgraded server interface – user defined types  Others are in early design phases New Abstract Data EPICS database field types  A delivery schedule is in place at LANSCE