Next Generation EPICS Communications Protocols

1. Next Generation EPICS Communications Protocols Jeffrey O. Hill LANL

2. Motivation • EPICS protocols essentially unchanged since 1993 • expanding EPICS user community • new supporting role: dissimilar system integration • substantial improvements are possible

3. Expanding EPICS Community • over 100 sites in collaboration • since Jan 1st 1998 • 20 sites added to the collaboration • > 75 new users have received EPICS training • large new projects based on multi-laboratory collaborations have complex new requirements

4. Significant Improvements Possible • comprehensive process entity paradigm • better support for data acquisition • wide area network transparency • protocol compression • controlled degradation under load • client side API upgrade

5. Comprehensive Process Entity Paradigm • Extensible Attribute Set • application expands set of named attributes • units, limits, process-passive, mesons per sec, etc • application defined container types • message passing to “process entities” • command completion • Generalized Matrix Data • client discovers N dimensional bounds of data • client addresses any hyper cube within bounds • eliminate string and vector size limits

6. Better Support for Data Acquisition • application defined event types • servers post RF arch down events • clients subscribe for RF arch down events when POWER>10KW • clients subscribe for periodic updates • consistent sample rate compared with periodic queries originating from client • clients adjust server’s event queue length

7. WAN Transparency • plug-compatible directory service interfaces • wildcard queries • resource location monitoring • detection of name space collisions during resource installation • simplified configuration • strengthened security • kerberos, SSH tunnel etc • replace IP broadcast with IP multicast

8. WAN GuaranteedQuality of Service • from the EPICS server • from next generation Internet protocols • of particular interest to projects on large geographic scale • complex and expensive WAN • desire to route feedback control and process control messages on the same network

9. Protocol Compression • increase information density of protocol • level 1 • simply reorganize the protocol • level 2 • adaptive Huffman coding of resource identifiers • fidelity controls for analog data streams (lossy compression) • client side “plug-ins” for compressed analog data • possible symbioses with EPICS archiving tools

10. Controlled Degradation Under Load • clients specify quality of service • adjustment of network data stream’s quality-of-service in IP kernel • adjustment of dispatch priority in the server • embed time stamp in server state-of-health-beacon

11. Improved Client Side API • simplified C++ client side API is easier to extend and use • client API exports full functionality currently in the server API • support multiple threads without requiring vxWorks “task variables”

12. Uneventful Upgrade • large installed base of EPICS users • Simultaneous upgrade to a new version results in too much risk • Backward compatibility must be maintained • initial minor version number exchange between client and server • replaceable protocol dispatch table

13. Benefits

14. Conclusions • proposed changes are crucial facilitators for certain applications • they are not trivial optimizations • EPICS is increasingly used to integrate dissimilar systems • careful attention to process entity paradigm is warranted • proposed changes can be accomplished without impacting backward compatibility • increasing size of the EPICS user community increases the practicality of devoting resource to this effort