DOOCS: an Object Oriented Control System as the Integrating Partfor the TTF Linac
S. Goloborodko*, G. Grygiel, O. Hensler, V. Kocharyan**, K. Rehlich, P. Shevtsov
DESY, Hamburg; *IHEP, Protvino; **YerPhI, Armenia
Abstract
DOOCS is a distributed control system that wasdeveloped for the HERA and TESLA Test Facility TTF
applications. It is an object oriented system design from thedevice server level up to the operator console. Classlibraries were developed as building blocks for device
server, communication objects and display components.
The whole system is written in the programming language
C++. DOOCS has been designed as a stand-alone control
system and was extended to allow uniform access to all
TTF control systems. The architecture is based on an object
oriented application programming interface (API) on theclient side that provides multiple protocols. A so called
Equipment Name Server (ENS) consists of a central database with all names and protocols in the system and isconsulted by the client programs before the first datatransfer to the device. This paper describes the objectoriented architecture of the system and the integration ofthe subsystems.
1 Introduction
The TESLA Test Facility (TTF) [1] at DESY, Hamburg
consists of a linac and associated infrastructure to study
acceleration structures based on superconducting cavities.
Currently the machine operates with the first prototype
acceleration section exceeding the design energy of 125
MeV. The final linac will produce more than 1 GeV andwill include a Free Electron Laser (FEL) facility. Aninternational collaboration designs and builds this machine.
The components for the accelerator and the control system
are supplied by different institutes and therefore demanding
the integration of the several different software protocols.
The integration technics used to access the data of thesubsystems are a multi-protocol application programinterface and different types of gateway servers. Bothmethods which create a homogeneous system are implemented in the Distributed Object Oriented Control System(DOOCS) [2]. This system is a new development that wasstarted with the design of TTF. The multi-protocol clientinterface is described in chapter 3, the different gateway
methods are described in chapter 6.

whole system is programmed in C++ and makes use of thereusable objects provided by the language.
An important design goal was the implementation of adevice server as an independent program that completelycontrols a number of devices and provides the device data
to the network and receives messages from the clients. The
architecture consists of device servers with hardware
connections on the lowest level, middle layer servers to
implement gateways, special calculations or sequencers
and client application programs at the top level.
DOOCS is a distributed system because the device
definition is done on the server side only and is transparent
to the clients. Whenever a server is started, new device
instances are created or new properties added, thesechanges are immediately available on the network; there isno central server database to hold these items. Clientprograms may request an actual on-line list of all devices
and properties by means of a query request.
Many different servers can run on the same hardware orthese servers can run on different CPUs. Even the same
type of a device server with different locations is able torun on many CPUs. The system is really distributed
without a single point of failure.
The DOOCS client Application Programming Interface(API) is able to handle different network protocols inaddition to the DOOCS-RPC protocol transparent to theuser. So far the EPICS calls are also supported from within
the API. Other systems are connected through gateway
servers.
The names (IP-Address) of servers are resolved by an
Equipment Name Server (ENS) which again can run on
multiple computers. A name query service, which is
missing in EPICS, is also provided by the ENS. The
communication separates the client programs completelyfrom the device servers. All device specific information is2 DOOCS Architecture
The design of DOOCS is based on device objects thatreflect the real world hardware devices. This leads to aconcept of device servers which handle all properties of aparticular device and a single software unit controls acomplete device instance. Further devices are then createdwith the powerful methods of object oriented languages.
The same object oriented design concepts are also used in
the network communication and in client programs. The

Fig. 1 DOOCS Architecturehold in the servers. A modification in the layout of a server
program has no impact on the client program because of
the symbolic access of data.
3 Client Interface (API)The client part consists of a communication class, anaddress class and a data class as the client interface plus
some internal classes. The data class library has a lot of
methods to access, change and convert data and othercontrol parameters. The transferred data also contains type,error and length information. A data item can be a simple
integer, float, string or a complex structure of archived
spectra or histories or error messages or a list of available
services.
With the address class the client program specifies afacility, a location, a device and a property of a device. The
4 parts are ASCII names with up to 16 characters each, theproperty part can be up to 32 characters long. The
addressing of the servers and the handling of the server
links is done in the library. A server could run on any
computer in the internet. Killing and restarting services arehandled in the communication libraries by the automatic
creation or recreation of links to these services. The
implementation of our communication protocol also allows
for reading the parameters of all objects of a certain device
server class with just one call. This feature reduces thenetwork traffic significantly and gives the program achance to read all error flags of one server, for instance,
without knowing the actual names or number of objects.
There is also provision in the protocol for generalized
programs to get the names and properties of all objects inthe net. The client communication interface requires only a
few calls. These are: two different calls to read data, one tosend data and another one to query the actual list of devices
and properties. One type of read call implements a
blocking, synchronous read with optional data send to theserver. The other read call implements a non-blocking
monitor call.
The API has access to an Equipment Name Server(ENS), which resolves the necessary information of theservers. These data are stored in a table of the client,
therefore the first call to a device server needs a nameresolve request to the name server.
Because of the object oriented structure of DOOCS, thegeneral interface is implemented in C++. To incorporate Cand LabVIEW applications a C interface was designed on
top of the C++ interface. This C interface is used in a set of
Virtual Instruments needed for LabVIEW to access all data.
A Fortran interface and a library for MATLAB/SIMULINK
is also provided.
4 Client Applications
On the client application side DOOCS provides a set ofgeneric and specialized programs and incorporates
commercial products. All of these programs use the same
API calls to access device data.
rpc_test is a generic program to display and modify all
available device data. It reads the actual list of device
servers from a name server and the available properties of acertain server from the process itself. Because the program
gets all information from the network, all parameters in thesystem can be read and written without any change in the
rpc_test program.
plot_test is a further generic program to display from all
devices all data which is plotable. Since it reads the names
from the network, as rpc_test does, it allows to show allavailable data types with historical data or snapshots fromscopes for instance. This data may come from actual
readings or from an archive.
LabVIEW from National Instruments is used for
applications which need to display and control device data.
It is useful for measurements including data processing andall kinds of sequencing programs. A Virtual Instrument(VI) library to access device data was created[4].
MATLAB/SIMULINK is a commercial tool which isused to integrate complex RF models with real data fromthe linac and to control and optimize feedback loops online for instance.
DOOCS Data Display program (ddd) [3] which is agraphical editor to create and run control panels. ddd
allows to create component libraries in a hierarchical way.
The synoptic displays are animated by the status of thedevices, subwindows with detailed information or plots areactivated by mouse clicks.
save&restore is a tool to read, modify and save groupsof device parameters on one page. The tool is configured
from files and stores device data in files.
xerror is a tool to display all errors/alarms of device
servers including the logfiles of the devices. It continuously
scans a list of device servers and displays any error. xerror
is configured from a file.
doocsget and doocsput are command-line interfaces toread or write device data and may be used in shell scripts.
knobbox is a hardware device as a user interface to steer
any parameter in the system e.g. magnets or RFphase/amplitude by four rotating knobs with a display toshow the parameter name and actual setting.
5 Device Server
Device server processes are build from a modular libraryof C++ classes. An actual server consists of several entries
of a device type at different locations in the system. It may
contain different device types also. Every instance of adevice defines a set of properties. These named properties
are the access points on the communication network andare implemented as data objects.
The server library defines a basic class for device servers.
This basic class provides the common communication
objects like the name, the error status and on/off-lineinformation. The device server inherits this information
and adds device specific code and data objects to thestandard objects. Data objects are also a part of the library
and are defined for status words and bits, correction
polynomials, errors, float values, filters, archiver andspectra readings etc. By declaring a data object in a device
server it is automatically inserted into the list of named
device properties and becomes accessible on the network.
In order to be independent from the Ethernet, a harddisk
is attached to every server station. This allows to boot andFig. 2 Integration of the Subsystems.
run individual servers without the network. Because of thelocal harddisk, archiving history data is done in the server
as well. This reduces the network load and allows toanalyze problems that happened during network breakdown without loosing data. Every device server keeps andpermanently updates a local database of its actual
configuration and state in order to restore the previous
system state after a power failure. Since this data base ismaintained locally a server does not depend on thenetwork.
The device servers and middle layer servers in thesystem are located on SPARCstations, VME-SPARC
processors running Solaris 2 and PC's with the LINUX
operating system. Most server processes are running onembedded SPARC CPUs in VME crates and talk to various
VME - cards via memory mapping or UNIX device
drivers. As fieldbuses we support the DESY standard
SEDAC, Profibus and CAN.
6 TTF Subsystems Integration
Due to the fact that TTF is build by a multinational
collaboration different stand-alone controls were deliveredfrom the other institutes. These subsystems are integrated
in different ways. Some examples of integration arepresented here:• The injector is controlled by EPICS [5], which is
integrated through our multiprotocol client API. Inaddition a middle layer DOOCS server is used to archive
injector channels.
• OTR screens are supplied with Macintosh computers
running LabVIEW. The communication is done through ashared memory in VME with two MACs and one SUN
accessing the same data. Commands are transferred via
mailboxes.
• The klystrons run a PSOS system and the so called
CLASSIC protocol. A gateway server is translating thisservice into the DOOCS environment. This server alsoprovides archiving.
• The wire alignment system consists of OS-9 front-ends
and a Linux data server. A SUN group server is NFS
mounting this disk and provides the communication andarchiving for this system.
7 Conclusion
Although the DOOCS system was newly developed withvery limited manpower, the TTF linac could becommissioned with a full set of software tools in very shorttime. It took three days to deliver the beam from theinjector up to the end of the linac with full design energy.
The TTF control system was developed by five differentinstitutes and five different communication protocols areused. All these subsystems demonstrated successfuloperation. By means of DOOCS all devices in thesubsystems can be accessed from a single program in atransparent way. An operator or a programmer does nothave to care about the different protocols and finds thecontrols to be an integrated system.
REFERENCES[1] D.A.Edwards et al, "TESLA Test Facility Linac Design Report", DESY-Print, March 1995.
[2] G. Grygiel, et al. "DOOCS: A Distributed ObjectOriented Control System on PC's and Workstations",
PCaPAC conference, 1996[3] K.Rehlich, "An Object-Oriented Data Display for theTESLA Test Facility", ICALEPCS 97, Beijing[4] S. Goloborodko, et al., "Integration of LabVIEW into
TTF Control System", Proc. of the XV Workshop on
charged particle accelerators, Protvino 1996
[5] F. Gougnaud, et al., The Tesla Test Facility InjectorControls, ICALEPCS 95, Chicago