Channel Access Potential Upgrades and Essential Preexisting Features

Jeff Hill

Please send comments to johill_at_lanl.gov

Potential Upgrades

• Device Orientation
• Data Acquisition (expanded event set)
• Multi-Property synchronized reads, writes, events
• Multi-dimensional arrays
• Improved memory management
• Access Security
• Programming API
• Circuit priorities based on channel priority
• Multicasting allows tightly coupled control system domains to cross IP subnets
• Resolving resource names to server addresses
• Scaling and Isolation Upgrades
• Built-In Server Diagnostic PVs

Essential Preexisting Features

Existing Features that might not be Preserved

Potential Upgrades

Note that this is an attempt at a comprehensive list. Lists of this type will need to be pruned and prioritized. Which of these end up in the next, or any, release of EPICS will of course need to be carefully considered.

• Device Orientation
  • Browsible device hierarchy
    • Implies a name service upgrade for hierarchical names
    • Access security limited client browsing of public and private device components????
  • "Process Entity" is the message passing equivalent of a "Process Variable"
    • Device interface introspection
      • Public and private data
        • Application extensible meta-data
      • Public and private methods
        • Request data capsule
        • Response data capsule
        • Application extensible meta-data

• Data Acquisition (expanded event set)
  • New built-in event types
    • Limits change
    • Enumerated state set change
  • Client plug-in specified subscription
    • Application extensible event set
    • Application extensible subscription update meta-data set
  • Server plug-in specified event
    • Application extensible event set
    • Application extensible event capsule meta-data set
  • Client application specified trigger conditions for subscription updates
    • Time based
      • Maximum period
      • Minimum period
      • Fixed period
    • Triggered when a client specified "calc" _expression_ with channel mapped inputs changes from false to true
      • Trigger on % change
      • Trigger when a set of PVs change in some client specified way
    • Combinations of the above
  • Client application specifies event queue length
    • Allows GUI client to specify a queue length of one
    • Within limits of course
      • Limited by access security?
• Multi-Property synchronized reads, writes, events
  • Atomic multi-PV read and write
    • Multi-property write request
      • Application extensible meta-data
      • Mapping between property names and target field in the records
        • Such mappings might cross record boundaries
  • Synchronized read / write
    • Client application specified trigger
      • Triggered when a client specified "calc" _expression_ with channel mapped inputs changes from false to true
      • Absolute time occurs
      • Delay expires
• Multi-dimensional arrays
  • Requests specify starting position and size in each dimension
  • Storage specifies size in each dimension
• Improved memory management
  • Eliminate need for EPICS_CA_MAX_ARRAY configuration
  • Eliminate internal interfaces and implementations requiring that entire array fits in contiguous storage
• Access Security
  • "Confirmation Required" access modifier
    • Specified in the IOC's access security configuration
      • In addition to read and write access modifiers
    • This is a hint to interactive client application
      • Pop a "carefully consider this action before proceeding" dialog whenever a write is attempted
  • Kerberos (or some equivalent) based authentication
  • SSH tunneling
  • Access security integration with name server
    • Limited access to name space?????
• Programming API
  • Support for process passive and maximize severity
    • Implemented using application extensible meta-data and or channel naming convention
  • Application extensible meta-data
  • Unified server and client library programming interfaces
  • Client specifies caching or queuing behavior as an attribute of the channel or the channel naming convention?
• Circuit priorities based on channel priority
  • Specify TCP quality of service (QOS) parameters
    • Map client side application specified channel priority ranges to IP TOS field
      • IP Precedence based (legacy routers)
      • DiffServ Code Point based (modern DSCP routers)
• Multicasting allows tightly coupled control system domains to cross IP subnets
  • Environment variable specifying the multicast group identifier
  • Muticasted beacons
    • Cross subnets (reduced configuration labore)
    • Eliminates need for CA Repeater
  • Multicasted search requests
    • Cross subnets (reduced configuration labore)
    • Eliminates problems with unicasted searches being selectively received by multiple servers on the same host
• Resolving resource names to server addresses
  • Compatibility with industry standard naming service
    • Use of industry standard interfaces desirable
    • Industry standard (open source) name server implementation desirable
      • Site specific freedom to choose among several competing industry standard name server implemtations even better
  • Some applications will access many thousands of resources
    • Performance and efficiency are important
      • Transparent load balancing may be required for large systems
        • Incoming client circuit is routed to the name server with less load
        • Or possibly caching ala DNS
      • Does this imply a hierarchical implementation ala DNS
  • Name resolution is a critical component
    • Redundancy required
      • Zone transfers keep redundant name servers in sync?
  • Resource name hierarchies
    • For device orientation
    • Defines default mapping for incomplete names
      • Record name, but not field name, supplied
        • This implies "magnetCurrent.VAL"
      • Magnet name, but not magnet property name, supplied
        • This implies "magnet.current.VAL" ???
    • For specifying hierarchy root when a server (or a server plug-in) starts up
      • An application description might be instanciated several ways
        • /operations/linac/magnets/
        • /test/linac/magnets/
        • /simulation/linac/magnets
    • Hierarchies shall not impose address boundary rules
      • A magnet device instance may be hosted in more than one server
  • Auto Configuration - plug-and-play capabilities
    • Integrate servers developed off-site w/o configuring central authority
      • Name server contacts CA server and asks it for a list of all resource names
        • Possibly auto triggered when name server sees a new CA server beacon
      • Detect name space collisions during installation
    • No specialized configuration (no IP address entry)
      • For client to locate resource's server
      • For client to locate name resolution server
  • Client Queries
    • Query Request Specification
      • Clients can request a comprehensive list of resource names from a server
        • Request can specify a starting point in the hierarchy and a hierarchy depth
        • Response to this query is hierarchical
          • For example
            • List of all magnet device instances
            • List of all records names (and types) in a magnet device
            • List of all ai record instances
            • List of all fields in an ai record
      • Clients can request of course the address of only one named resource
      • Wildcarded queries
      • Clients can subscribe for resource address state change updates
    • Query Interface
      • Identical protocol
        • For querying names in a CA server?
        • For querying names in a name server?
        • This allows nested control system domains
          • This is thinking about architectural implications for scaling and isolation
            • Architectural implications for the CA gateway
      • Also identical programming API for the above?
  • Client side name resolution cache
• Scaling and Isolation Upgrades
  • Tightly coupled control system domains that cross subnets
    • Multicasting and or advanced name services
  • No single point of failure
    • Redundant gateways
  • Managed scaling with increasing outside load
    • Transparent multiple parallel gateway based load balancing
      • Incoming client circuit is routed to the gateway with less load
• Built-In Server Diagnostic PVs
  • number of clients
  • number of channels
  • events per second
  • beacon periodicity
  • state of health

Essential Preexisting Features

• Compatibility
  • Backwards compatibility
    • Client server architecture and internet transport
    • Past versions of the CA protocol
      • At large installations it will not be possible (or prudent) to migrate all IOCs to a new version during a maintenance period
  • Compatibility with commonly used 32 and 64 bit architectures
  • Compatibility with UNIX, RTEMS, vxWorks, and Windows
  • Channel Oriented Application Programmer Interface (API)
    • Backward compatible legacy CA client API
    • Thread safe interface
    • Support for single-threaded clients
      • Preemptive callback switch
      • File descriptor based scheduling
• Efficiency
  • Memory management
    • Small channel and subscription footprint size
    • Free list based memory management
  • Event based publish and subscribe
  • Streaming Process Variable IO
    • Message batching
    • Asynchronous response notification
  • Avoidance of centralized bottle necks
• Performance
  • Multiple channel create throughput
  • Multiple subscription create throughput
  • Multiple channel name to server address resolution throughput
  • Multiple channel connect throughput
  • Single read request round trip latency
  • Single write notify request round trip latency
  • Multiple read request throughput
  • Multiple write request throughput
  • Multiple write notify request throughput
  • Subscription update throughput
• Fault Tolerance
  • Proper server degradation under load
    • Prioritized request and event dispatch in the server
      • Client specified priority
    • Event queue decouples priority space of event poster from priority space of event dispatch
  • Connection management
    • Channel availability state change communication
    • API with features that encourage fault tolerant client applications
      • Connect / disconnect notification
    • Client library times out unresponsive channels, but does not timeout and disconnect unresponsive circuits
      • Burst of CPU or network saturation must not beget increasing load
  • Avoidance of single points of failure
  • Server shall not lock up if one of its clients is not reading from its TCP circuit
• Scaling and Isolation
  • Gateway based isolation interposed between tightly coupled control system domains
    • Gateway strictly controls (load limits) interactions
• Ease of use
  • Minimal (no) topology configuration required for simple systems
    • Off site developed components (IOCs) easily integrated

Existing Features that might not be Preserved

• Current version of the server side API employing GDD may be deprecated