Transcript Next generation EPICS Communications Protocols

Next Generation EPICS
Communications Protocols
Jeffrey O. Hill
LANL
Motivation
EPICS protocols essentially unchanged
since 1993
expanding EPICS user community
new supporting role: dissimilar system
integration
substantial improvements are possible
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 multilaboratory collaborations have complex
new requirements
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
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
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
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
WAN Guaranteed Quality 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
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
Controlled Degradation
Under Load
clients specify quality of service
adjustment of network data stream’s qualityof-service in IP kernel
adjustment of dispatch priority in the server
embed time stamp in server state-ofhealth-beacon
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”
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
Benefits
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