2. CDEV: A Framework for Object Oriented Control Applications Chip Watson Thomas Jefferson National Accelerator Facility Acknowledgments Walt Akers & Jie Chen, Jefferson Lab EPICS Collaboration

3. 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 ABC

4. CDEV is … Distributed Components CDEV includes a set of components for developing distributed applications, either in C / C++, Java, or tcl Application C++ cdev EPICSclip java cdev name server C++ / Java server shell custom server applet / application clipPS-EQP

5. 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.

6. 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”

7. 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)

8. 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)

9. 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}

10. C++ Collection Example #include 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 results int length = arc1.length(); double field[length]; result.get(“value”,&field, length); int status[length]; result.get(“status”,&status,length);

11. 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();

12. 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)

13. 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, …)

14. 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)

15. 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 …)

16. Mapping & Portability Challenges While EPICS is primarily channel oriented, channels have a lot of “related data”: –units (EGU) –control limits (HOPR, LOPR) –warning limits (HIGH, LOW) –alarm limits (HIHI, LOLO) –graphing limits –resolution (DEL) –formatting (PREC)

17. Naming of Associated Values

18. 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 EPICSCODA other control systems RDBMS service layer

19. 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

20. Mix and Match Components MEDM EPICS ComputeOrbitParamsDatabase Reuse GUI for EPICS, Application data, and Database values

21. 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

22. 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)

23. 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)

24. 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 callback dev.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()); }

25. JDM : Java Display Manager Synoptic 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

26. 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)

27. 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

28. 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.

29. 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

30. 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)

31. 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.