The Implementation of an OO Control System API with CORBA
S. Hunt1, B. Jeram2, M. Plesko, C. Watson3,
1 Paul Scherrer Institute, Villigen, Switzerland
2J. Stefan Institute, Ljubljana, Slovenia
Thomas Jefferson National Accelerator Laboratory, Newport News, USA

3

Abstract
The trend in software development for accelerator
control systems, for both the client and server layers, istoward object oriented programming. Commercial
developments such as CORBA are now providing object
oriented environments for distributed systems which havesignificant advantages over older procedural libraries.
Object oriented client-server systems using C++ to C++,Java to C++ and Java to Java communications over
CORBA have been tested and compared to Java's remotemethod invocation (RMI) mechanism. Benchmark
performance measurements show that CORBA can be ofcomparable performance to many RPC or raw TCPsystems.
An object orient application programming interface(API) has been implemented in a prototype of the control
system for ANKA, a 2.5 GeV synchrotron radiation lightsource being built in Karlsruhe, Germany. This system isbased on TACO, a control system architecture with object
oriented servers developed at the ESRF and now used in awider collaboration. Use was made of CORBA and its IDL
to define first class objects both on the client and serverside. By using CORBA remote methods in both directions,asynchronous processing of events and call-backs are used
to provide efficient use of network resources. Static datasuch as calibration and other data that are stored indatabases are accessed directly through object serializationor synchronous client-server methods. Each object that isexported by CORBA has specified methods for its atomicactions, such as get(), set(), getStatus(), on(), off(), etc.
Alarm objects are always asynchronously sent to the alarm
handler application.
1. Background
ANKA and the SLS are two examples of the newgeneration of compact, high performance synchrotron lightsources that are at present under development. The key
parameters for the control system for these and othermodern machines are Performance, Functionality, andCost. Performance is needed to provide responsiveness tothe operator, such that no delay is noticed between thesetting and readback through the control system ofaccelerator parameters, and needed for programs that must
manipulate a large number of parameters (acquire beam
orbit at each step of a tuning algorithm). Functionality
includes the provision of now 'standard' features such asarchiving, synoptic displays and alarm handling. Cost is
becoming an even more important factor in determining

the technology to use for the implementation of a control
system, and can involve both the cost of control system
hardware as well as the cost of developing custom
software. To address these concerns, the ANKA control
system is based on TACO[1], an object-oriented control
system tool-kit that was developed at ESRF. TACO has
been upgraded to offer an object oriented API at the clientlevel, as well as at the real-time server level, and ismigrating from RPC to CORBA.
2. The evolution of accelerator control systems
The evolution of accelerator control systems has
occurred in clearly identifiable phases. Fromthemainframe era, the Mini-computer (VAX) era, theWorkstation era, to the present PC era, some common
trends can be discerned: from home-built to commercial
tools and standards; from being 'computer scientists' at theleadingedge of technology to becoming systems
integrators; from expensive (specialized) to cheap, mass
market components; and from working in isolation toworking in collaboration.
Developers of accelerator control systems have often
been slow to admit that their requirements might be met
by standard industrial products, services, and protocols.
For example, from building network hardware, one started
to use Ethernet, but with home-built protocols. Slowly theuse of UDP and TCP became common. Later still, higher
level protocols such as RPC have become widely used inaccelerators. And now, distributed component technology,
such as DCOM and CORBA have appeared in control
systems. Often in these cases, there is a trade-off between
functionality and performance. But the trend is clear: as
the performance of commercial products improves, and thecost of providing the desired functionality ‘ in house’
increases, relying on home built systems becomes even lessattractive.
3. What CORBA provides
In common with RPC, CORBA[2] provides the ability tobuild distributed applications, running on heterogeneous
systems, without knowledge of the underlying network. By
linking with 'stub' procedures that have the same signatureas the procedures on the remote system, the programmer
can be made (almost) unaware that some of his program isexecuting on a remote machine. However CORBA goesmuch further than RPC; it defines an object-oriented, rather
than a procedural interface. It also defines a very richlanguage (IDL) for describing the interface and behavior ofremote objects. CORBA also allows late binding, thediscovery of objects at run-time, allowing CORBA objects
to be self describing. CORBA objects can be serialized(archived) to and from a variety of persistent storage
devices, including files and databases. CORBA defines
many of the services needed in building distributed systems
such as accelerator control systems. CORBA services
include PERSISTENCE, CONCURENCY, NAMING,EVENTS, and SECURITY.
4. Arguments made against CORBA
4.1 CORBA is slow?
CORBA is a standard for implementing distributedsystems, it is not a product. The CORBA standards aredefined by the Object Management Group (OMG), anindustry consortium including the leading computercompanies. As such, CORBA is not inherently slow or fast,and one has to examine implementations of the standard.
There exists a large spread in performance between
different CORBA implementations. This is partly due toproducts focusing on different target markets. One of themarkets for CORBA, embedded systems, clearly identifies
real-time performance as a goal. Although some features ofCORBA, such as dynamic invocation interface, may cause
a performance penalty, one is not forced to use thosefeatures where they are inappropriate. Tests using one
CORBA implementation (DOME[5]) on low-end personal
computers, has shown sub-millisecond response time forsynchronous calls.
4.2 CORBA object resolution takes too long ?
CORBA defines a naming service, but it also supports
third party naming services. As in existing control systemarchitectures, in CORBA one must choose between acentralized naming service, a totally distributed naming
service, or a hybrid offering redundancy but without theoverhead of total distribution. Note that a CORBA
accelerator object can represent a device, such as a power
supply or beam position monitor, which can include many
low-level inputs and outputs. Therefore a CORBA system
has to bind to many fewer named items than a system thatdeals with low-level channels.
In one test, CORBA has been shown to resolvereferences to 1,000 objects within 4 ms per object, which
may be considered an acceptable overhead when starting anapplication program. If this is too slow (and is not brought
down fast enough by evolution of hardware and software),there is still the possibility of a custom naming service andbatching of name resolution (a technique used in a numberof control systems).
4.3 CORBA is too complex ?
Many users of control systems find the change from aprocedural to an object oriented program paradigm
difficult. Some of the reports that CORBA is complex
result from this general difficulty, and do not represent aproblem with CORBA itself. However, the language

bindings, particularly those that are non-standard, do seem
unnecessarily obtuse. One reasonable approach to handle
this is to hide the CORBA related calls from the end-user
in a well-designed control system API. CDEV is one
framework which could easily encapsulate CORBA calls(especially the difficult dynamic invocation calls) within aneasier to use API.
4.4 CORBA does not run on real-time systems ?
Vendors offer CORBA on a number of real-time
platforms, including OS-9, VxWorks, and Psos. CORBA
extensions for real-time have started the standardization
process. Some of the issues for CORBA on embedded realtime systems, such as
the suitability of dynamic
invocation, are being studied.
4.5 CORBA has no asynchronous calls and call-backs ?
OMG has not defined a standardized way to implement
call-backs, or asynchronous calls. However this does notmean that these features are not available. As often is thecase, some vendors are ahead of the standardization
process, and some behind it. Some CORBA vendors offer
non-blocking (asynchronous) calls and callbacks as aproprietary extension, while users are always free toimplement callbacks themselves.
4.6 CORBA does not scale to massive systems ?
OMG designed CORBA to encompass global networks,
with thousands of servers and millions of objects. Althoughmany existing implementations do not support the services,such as efficient name resolution, to support this, there are
no inherent bottlenecks to global CORBA networks.
Systems such as accelerators, with perhaps hundreds ofOrbs and tens of thousands of objects can use existing
CORBA implementations. As CORBA does not enforce asingle naming service, a 'real-time' naming service, perhaps
one already used for accelerator control, might beappropriate for these larger systems.
4.7 CORBA is not supported by Microsoft ?
DCOM, the distributed component architecture fromMicrosoft is a very strong contender for use in accelerator
control systems. It may be that DCOM becomes the defacto standard, with CORBA occupying only a nichemarket. If one decides to use only Windows as an operating
system, DCOM might be the best choice. However DCOM
is not yet as mature as CORBA, it is lacking many of theCORBA services, and many developers are not willing torun only Windows. If DCOM does come to dominate, itmight become necessary to port existing CORBA
applications. Given the architectural similarities, thisshould not be too daunting a task. Alternatively it might bebetter to rely on CORBA-DCOM inter-working products,
which are becoming available.
4.8 RMI will replace CORBA ?
Java Remote Method Invocation protocol (RMI)

provides a more 'natural' environment for distributed
applications written using only Java. However, Java does
not yet seem suitable for embedding in real-time systems.
This is mainly due to the much discussed issues involved ingarbage collection. At the moment there are examples Javaclients talking to servers on real time systems written in C
or C++, in which case one cannot use RMI.
4.9 CORBA is not easy to integrate with existing systems?
Many laboratories have a large installed base of software
which is not CORBA based, and must be preserved. Two
approaches allow integration with CORBA. First, agateway could be provided between the CORBA and nonCORBA parts of the system. Second, an object oriented
framework such as CDEV[3] could be used to integrate thesystems at a higher, wrapper layer.

Num. OfObjects
1101001000
10000

Table 2. Performance of DOME
AverageTime for
Time for
Time forstlastobject1 Object
Bind (ms)access (ms) access (ms)
1.01
0.85
0.85
1.40
0.86
0.88
1.54
0.88
1.14
2.75
0.89
3.40
14.32
0.88
32.71

5. CORBA performance

These results were achieved between two 133 MHzPentium PCs running Linux 2.0. As can be seen, DOME
does not behave as well when dealing with very large
numbers of objects on one server. This is because it uses alinear search algorithm to obtain the object reference. OOT
has announced that the new release of Dome has addressed
this problem. Dome licenses are free for educational users,
and they also offer free licensing for personal use on Linux.

5.1 Visigenic performance using Java

5.3 Other ORBS

Visigenic offers the most common CORBA ORB - notsurprisingly as every new copy of Netscape, said to be themost popular computer application program ever written,ships with a copy of the Visigenic Orb. Visigenic offers
Orbs with a native C++ binding for a number of systems,
including popular UNIX platforms and Windows.
Visigenic also offers an ORB with a Java binding, itself
written fully in Java, making it suitable for any platform
offering a Java Virtual Machine.

A number of other Orbs are worth considering. OMIBroker is also very fast, is free for non-commercial use,and source code is available. OmniORB is a fully threaded
Orb that is available under GNU licensing.

Table 1. Performance comparison of RMI and CORBA.
RMI
CORBA
(Visigenic)
first bind
70 ms
24 ms
remote redraw
5.8 - 6.3 ms
4.0 - 4.4 ms
fillCircle
Visigenic however has a relatively high cost for adevelopment licence, and does not run on real-time
platforms.
5.2 DOME performance using C++
DOME, from Object Oriented Technologies, is a realtime embeddable ORB. It is available for a number ofplatforms, including NT, Win95, Linux, Solaris, HPUX,OS-9, and Psos. DOME supports callbacks andasynchronous calls, and has a small footprint, but a
CORBA 2.0 compliant version is presently only available
under beta release. DOME achieves performance at thecost of some incompatibilities with other Orbs, but this isconfigurable in the new version, allowing either IIOP orproprietary transport. It is even possible to bypass byteorder conversion when systems are compatible, whichfurther increases performance.

6. Features of a CORBA OO - API
In order for common accelerator applications to be used
at more than one laboratory, a common API and basic
accelerator class hierarchy are needed. Devices such as
Power Supply (or Magnet), Position Monitor, and Vacuum
Gauge have to use a minimum set of common attributes.
Common attributes include: access control; engineering
units; device description; alarm limits; and time-stamp.
6.1 Wide or Narrow API
Accelerator Control system API's have traditionallyemployed a 'narrow' API - defining a few well-known calls,
which take device or channel name and value or commandas arguments. Such calls typically are get(), set(), etc.
•get(Booster_PS01,Status,result);
Object oriented languages more typically use a 'wide'
API - with each class of devices having its methods, andusing an instance of its class per device.
•result = BoosterPS01.Status;
Narrow interfaces are preferable when writing general
purpose applications such as save/restore or a synoptic
display program. Wide interfaces are more natural for
accelerator physics applications which “ know” what
attributes they will be dealing with. A control system using
CORBA could be implemented with either approach.
ANKA has chosen a wide interface, within a defined
accelerator class hierarchy.
6.2 Databases and serialization

Default device properties (such as engineering unit
conversions), Operational parameters (such as powersupply current), and archive data, can be kept local to theserver or in a database. CORBA serialization can make thetype of storage used transparent to the programmer.
6.3 Organization of Classes
Classes should be independent of the language used (forinstance, Java). Therefore there should be no reference tothe visualization or GUI for a given object or attribute.
Also there is a clear difference between accelerator control
objects (power supply, insertion device) and physics
objects (orbit). These differences should result in two classhierarchies that share a common root class.
6.4 Root class methods
Some root class methods would be defined in the rootclass, providing default behavior. Some methods would bevirtual, forcing each device class to implement thatfunctionality. All devices should support callbacks andmonitors (send data only when changes have exceededlimits). Methods should also be defined to get a list of alldevices of a specific type. Locks (mutexes) should beavailable to the programmer to ensure exclusive write
access to resources.
6.5 Standard Accelerator Objects
Standard classes should be defined for common
accelerator objects. These should include:• Power Supply• RF• Vacuum-Pump• Valve• Kicker• Septum• Position monitor• Profile monitor• Current monitor

able to be grouped together in logical arrangements (forexample SR group, or RF group, or orbit correction group).
Methods, including serialization, should operate on groups
as well as on individual devices. Another type ofaggregation used in CDEV allows a logical device to span
multiple servers, for example to have dynamic data in areal-time front end and static data in a commercialdatabase. The exact location of a piece of data is hiddenfrom the user, easing use and maintainability.
6.8 Object Naming
Although a device naming convention is outside thescope of this paper, the OO API should not put unnecessary
restrictions on the device naming scheme chosen. Many
existing accelerator naming conventions are a mixture oflocation and type (e.g. SR/PS/Q1 - SR and 1 refer to thelocation, PS and Q refer to the type of object). Software
sharing arguments (and the impossibility of having aninternational naming convention) implies that suchinformation should be held as an object attribute, orretrieved from a database.
7. Conclusions
CORBA is a rapidly maturing technology, that canprovide many of the components needed for building
accelerator control
systems. However in manylaboratories, legacy considerations will delay theintroduction of component software technologies.
Furthermore, many applications are available for existing
API's such as Channel Access, CDEV, and the existing
TACO interface. CDEV in particular offers a strong objectoriented environment in which to share software at theapplication level, independent of the underlying control
system and able to integrate with CORBA and nonCORBA API. It is hoped that these existing accelerator
software bus technologies, rather than try to compete withcommercial component software technologies, will migrate
in a controlled fashion to make use of the newopportunities offered.

6.6 Introspection

References

In order to be able to write generic applications, there
should be a method to find all attributes of an object. This
could be either part of the root class, or use CORBA
dynamic binding, or a set of helper objects as is done inCDEV.

[1]Taco, http://www.esrf.fr/computing/cs/taco/taco.html

6.7 Aggregation and Groups of Devices
Devices of the same or even different classes should be[2] CORBA: Architecture and specification, OMG, 1996.
[3] CDEV, http://www.jlab.org/cdev/[4] Client Server programming with Java and CORBA, R.
Orfali. & D. Harkey, Wiley computer publishing.
[5] DOME, http://www.oot.co.uk