CDEV:A Framework for

Object Oriented Control Applications

Chip Watson

Thomas Jefferson National Accelerator Facility

Acknowledgments

Walt Akers & Jie Chen, Jefferson Lab

EPICS Collaboration

What is CDEV?

• A definition of an interface to a virtual control system with a simple device / property flavor.

• A framework for developing a common interface to multiple control systems (such as EPICS), or other distributed systems, through simple adapters.

Application

System

Application

cdev system

A B C

CDEV is … Distributed Components

CDEV includes a set of components for

developing distributed

applications, either in C / C++,

Java, or tcl

Application

C++ cdev

EPICS clip

java cdev

name serverC++ / Java server shell

custom server

applet / application

clip PS-EQP

Overview

• The CDEV (common device) C++ and java libraries provide an implementation of a standard application programming interface (API) to one or more underlying packages, typically control system interfaces like EPICS.

• CDEV provides a generic abstraction of these various systems, plus a number of features not provided by many control systems.

• It is now the standard interface to control systems at Jefferson Lab, BESSY, BNL and several HEP experiments (C++) and CERN (Java), and now at SLS, the new light source at PSI.

Device + Property + Message

• Virtual control system abstraction– All I/O is performed by getting or setting the value

of a property, or sending a message to a device.

• Information hiding– Client has no knowledge (location, etc.) of the

device’s implementation, only knows (or discovers at run time) the list of properties and messages to which the device responds.

• Organizing control points into devices– Client application views a collection of control

points (EPICS channels) as a set of properties of a device. Devices are in turn organized into types (classes) and collections (arrays).

device

get property1

reply

client

send “on”

High Performance Features

• Asynchronous I/O supported– allows server and client execution to be overlapped.

• Buffered protocols supported

– EPICS / CA and CLIP both put multiple operations into a single network packet for higher throughput.

• Collections / arrays supported

– Arrays of devices supported in API

– Array operations mapped onto underlying array calls, if supported (used at CERN, BNL); otherwise automatically unrolled into simple I/O calls (EPICS)

Asynchronous and Buffered I/O

CDEV was designed to support EPICS, and so these two features directly map onto EPICS/CA.

• CDEV supports two flavors of asynchronous I/O, callback and asynchronous filling of a user buffer. Each of these, when used with EPICS, uses channel access callbacks, wrapped to the standard API. (Synchronous calls also use CA callbacks so that other non-EPICS I/O is not blocked).

• CDEV also explicitly supports buffered I/O, in which the application issues many I/O calls, then explicitly does “flush”, “poll”, or “pend”, at which point buffered I/O is flushed (mapped onto CA flush)

High Performance Feature: Collections

A collection is a container for 1 or more devices. Sending a message to the device sends it to all contained devices.– supports same interface as cdev Device

– if the underlying system supports it, collections may be stored in the server, improving network performance (used at BNL, CERN)

– results are returned as array of values

– collections can be statically defined (in a file or database) or dynamically defined or modified

client

get xpos

value={a,b,c,d,e}

C++ Collection Example#include <cdev.h>main (int argc, char **argv) {

// attach to a pre-defined array of magnets cdevCollection & arc1 = cdevCollection::attachRef (“Arc1”);

// synchronously read the field (integral bdl at Jlab)   cdevData result;

arc1.send (“get bdl”, NULL, result);

// extract the resultsint length = arc1.length();double field[length];result.get(“value”,&field, length);

int status[length];result.get(“status”,&status,length);

Java DeviceArray example

import cdev.*;

import cdev.data.*;

. . .

String [] names = “Q1”,”Q3”,”Q5”,”Q6”,”Q8”,”Q9”;

DeviceArray magnets = new DeviceArray(“magnets”,names);

Data result = new Data();

magnets.get(“field”,result);

// extract field values as doubles (don’t worry what front end uses)

double [] fields = result.getDataEntry(“value”).doubleArray();

// get array of status values

int [] stats = result.getDataEntry(“status”).intArray();

Enhanced Capabilities

• Better organization– Control points (channels) organized into devices

– Devices are organized into classes with identical sets of properties (name mapping defined locally)

– Classes may be in a hierarchy (e.g. a QUAD is a MAGNET, a MAGNET has a current and a setpoint)

– A device may reference other devices by a relationship (e.g. which power supply drives this magnet?)

– Lists of devices may be defined (e.g. logical or geographical section of a machine)

Enhanced Capabilities . . .

• Greater support for generic applications– pre-defined lists of devices (e.g. Linac1 w/ magnets,

bpm’s, valves, rf cavities, cryomodules, etc.)

– discovery of device type, given a name

– create a table of all properties of a named device

– create a table of all devices in collection Linac1 of type Magnet showing a standard set of properties (setpoint, current, …)

Enhanced Capabilities . . .

• Transparent access to multiple services

– dynamic values in EPICS

– optics and/or other static values in a database

– dynamic (processed) data from a custom server

– experimental physics data acquisition system values in

a domain specific DAQ system (e.g. CODA at Jlab)

Enhanced Capabilities . . .

• Portability across control systems

– carefully written applications can run at EPICS sites

and non-EPICS sites: BNL, CERN, …

– example: BNL could use MEDM (but …)

CDEV Architecture

• All I/O operations are actually performed by an I/O service, which is a dynamically loaded library (C++) or class (Java)

• The system layer routes operations to the appropriate service

• Multiple services may be used concurrently (eases integration)

• (C++ only) a device may span services

Application

cdev system layer

EPICS CODAother

controlsystems

RDBMS

service layer

Network Components

• Network name server– location services (server name-> host and port),

query services (list of servers), and server monitoring (connection management)

• Re-useable server shell (C++ or Java)

– handles network protocol; developer provides routines to do the actual command processing

• Gateway program

– provides a control system proxy for java applications and applets

name server

server shell

server

C++ Gateway

application

EPICS IOC

Mix and Match Components

MEDM

EPICS

ComputeOrbitParamsDatabase

Reuse GUI for EPICS, Application data, and Database values

CDEV / CLIP Servers

• cdevGateway (C++)– Provides a proxy for the control system, useful for web access,

connection concentrator

• dbGateway (Java)– Uses JDBC to get / set device properties in an SQL database

(monitoring planned for future)

– Allows a device to partially reside in db, partially in EPICS

– accessible from C++ or Java

• custom servers (C++ or Java)– Many special servers at Jlab and BNL are used to aggregate and

pre-digest information from front end systems

EPICS support for CDEV

• CDEV versions for the following applications exist:– MEDM (synoptic display)

– ALH (alarm handler, GUI)

– StripTool (strip chart GUI)

– XTRACT (acquire device/property values as function of other device/property values)

• Additional CDEV applications used with EPICS– CMLOG (message logging server + GUI, used at many EPICS sites)

– braus (CDEV browser, Till Strauman at Bessy)

Using Java CDEV with EPICS

• Java CDEV can use native methods or socket connections. – The current implementation for EPICS uses the cdev

Gateway (clip protocol implemented in 100% java)

– java applets supported with no need for local libraries

• Devices may be defined in a ddl file, and Java clients will talk to the cdevDirectory in the Gateway

• CA “fallthrough” on the Gateway allows direct addressing of records as devices and fields as properties (can be disabled)

Java Example#import cdev.*;

class myClass implements DeviceListener {

myfunction () {ControlSystem sys = ControlSystem.getDefault();

sys.connect(host,port); // connect to the gateway

Device dev = new Device(“IPM3L01”); // a beam position monitor

dev.get (“X”,this); // second arg is object to receive callbackdev.get (“Y”,this); // same as dev.send(“get Y”,this);. . .

}

public void deviceChanged ( DeviceEvent evt) {System.out.println ( event.getDevice().getName() + " " +

event.getProperty() + " " +

event.getData().getDataEntry("value").stringValue());

}

JDM : Java Display ManagerSynoptic Display Package

• Emulates MEDM widgets (at 95% level)– Can parse existing .adl files

– Supports macro substitution

• Programmable– JDM widgets and custom code can be mixed, allowing higher

functionality interfaces than MEDM, and better programming language (personal taste) than tcl/tk

• Widget set includes:– primitives: line, rectangle, oval, arc, polygon, text, pixmap (can

dynamically change color, visibility)

– advanced: meter, strip chart, slider, bar chart, button, menu, text entry, x-y plot

CDEV Status

• C++ code fairly stable– a few new features each year for last 2 years

– port to NT and new HP-UX acc compiler improved code quality, now builds cleanly on Linux (poster)

• Java code gaining new features (now version 2.0)– CERN adding enhanced support for generic

applications (introspection) (two ICALEPCS talks)

– JDM synoptic library being improved and extended to Java Beans (~1 FTE)

CDEV Status

• CDEV used heavily in TCL scripts at Jefferson Lab and BNL

• CDEV servers (C++) also used heavily at Jefferson Lab and BNL, particularly for accelerator-aware code (optics)

– Example: BPM server at Jlab is a CDEV server

Current Developments

• Java CDEV 2.0 (collaboration with CERN)• Java Beans version of JDM (collaboration w/ PSI)• Performance enhancements for cdevGateway• Improvements in cdevDirectory to support Java

CDEV 2.0 for sites using CDEV C++

Current effort at Jefferson Lab + CERN > 3 FTE, mostly on Java developments.

How to Start (EPICS users)

1. http://www.jlab.org/cdev/

2. Download version 1.7 tar file, and follow readme instructions (it links to your version of CA lib)

3. C++ : – copy a makefile from a test directory, and start by using CA

fallthrough (device=record, property=field)

– create ddl file(s) to describe your devices (how a device maps to multiple records), & switch to device oriented I/O

– follow links from web site to get cdev applications

How to ...

4. Java : – Start the C++ name server, and set

CDEV_NAME_SERVER to that host name

– Grant CA read access to your web machine (for applets), and start cdevGateway on that machine

– Download Java CDEV 2.1 sources or jar file, and place in your CLASSPATH (applications) or reference on your web page (applets)

– Run test applications in …/java/cdev/test

– Run test applets in …/java/cdev/test (from Jlab web)

How to Obtain CDEV

• CDEV Home page is

http://www.jlab.org/cdev/

• Java CDEV main page

http://www.jlab.org/cdev/java/

You may download the current 2.1beta2 version of Java CDEV, and the 1.7 release of C++ code.