Building Controls Software around an Object Oriented Database
Kris Kostro
CERN, SL Division, CH-1112 Geneva 23, Switzerland
Abstract
The use of Object Oriented (OO) techniques has become
popular in all areas of software technology and HEP
control systems have not been excluded from this trend. In
the course of modernisation of the CERN SPS
Experimental Areas control software we designed andimplemented an OO database to hold the configuration
data for equipment and beams. With the beam lines andequipment defined in the new database, control facilities
are being added by incrementally enhancing the classesand adding new methods to the database schema. Using theOO database helps to design the new system in atransparent way. Real-world objects such as beam lines orcrates are uniquely mapped to the corresponding objects inthe database. The new database allows seamlessintegration of data into programs written in OO languages
such as C++ and Java. The WWW interface to the databasegives a familiar look and feel and has been provided withrelatively little effort.
In this paper we present an overview of the project andthe employed methods. The choice of the databasemanagement system, the implementation of the Beam
Instrumentation (BI) database and its use in controls aswell as the benefits of the approach will be discussed insome detail.

the “ standard model”. NORD machines were replaced by
HP-UX workstations at the control room layer and by PCs
running the LynxOS operating system on the front-end
layer, leaving the equipment control layer unchanged. The
large investment in hardware at the level of CAMAC andbelow makes the replacement costs prohibitive so that new
low-level equipment control is introduced on case-by-casebasis. To avoid rewriting the large suite of application
programs written in NODAL over the preceding 20 years
the NODAL programming environment was recreated for
the HP-UX operating system. This approach has helped toreplace the obsolete NORD computers, but the many, often
little understood NODAL programs were left in place andthis constitutes now the biggest problem for theExperimental Areas controls. The software interconnections of this system are represented at the left-hand side ofFigure 1. The right-hand side represents the new softwareconnectivity and will be discussed later.
NODAL
application

Capplication

SL-EQUIP

SL-EQUIPO2Webserver

SL-EQUIP

The secondary beam lines of the SPS at CERN are
located downstream of the SPS primary targets: T1 in theWest Area and T2, T4 and T6 in the North Area. Thesebeam lines serve a variety of experiments and test facilities
often installed for several years or just for a few weeks.
The beam lines have therefore to be adapted continuously
to the changing needs. To accommodate for this, thecontrol system has to contain facilities for an easy
installation of new equipment even during operation.
The control system for experimental areas provides
facilities for controlling the beamline equipment byexperiments in an individual manner. Experiments havetheir individual permissions, which restrict equipment
access to their beam line, and other beam lines are notvisible to them. Another important function of the EA
controls is surveying the access doors in the zone andverifying the position of some critical equipment such as
the wobbling magnets.
The original control system of the Experimental Areas
dates from 1976, and it was based on NODAL programs
running on NORD computers with CAMAC for equipment
interface. In 1994/95 the control system was upgraded anda new system architecture, similar to the one used in LEP
was introduced [1]. This architecture is often referred to as

Class Library

SL-EQUIP
NC/RPCTCP/IP

1 Experimental areas of SPS and their controlsC++application

O2Shell

HP-UX

MMH

Data Modules

CORBA
serverLynxOS

MMH

VME
CAMAC

Equipment

MMH

O2
ServerEquipment

Figure 12 Evolution of the EA controls
The large number of programs written in an obsolete
language, the little knowledge we have about them and thelimited manpower make it impossible to replace all the EAcontrols in one big project. Since the NODAL programs
use their own data structure to store data and interact
between themselves heavily, it is also difficult to replacethem in an incremental way. Fortunately the project toreplace the Beam Instrumentation (BI) database ofconnections and addresses has offered us the opportunity
to slowly migrate the control system to a new environment.
OO techniques employed in this project provide a
infrastructure on which the new controls software can bebuilt.
2.1 The Beam Instrumentation database
The database of the electronics modules and theirconnections has been one of the most complicated piecesof software ever written in NODAL, and it represented aneffort of several man-years. This database fulfils several
functions in the current system. The obvious one is to keep
track of used racks, crates and modules and theirinterconnections. There are about 5000 physical items inthe database. It is also used for creating new equipment
according to equipment templates. The system scans thedatabase searching for free channels and allocates them tothe new equipment. Calculating addresses of equipment isanother capability of this system. Every equipment typehas its own addressing program. Modules can be wired
together to create a common facility, called system andsystem channels can be used in equipment and othersystems. With about 60 equipment and 30 system types(and almost as many addressing variants) the complexityof this database was obvious. With maintenance becoming
more and more difficult, the replacement of this database,responsible for the equipment address generation, became
an absolute necessity but it has also been taken as achallenge and opportunity to introduce new techniques.
3 New software system for the Experimental Areas
3.1 The new database choice
From the beginning we wanted, if possible, to use an
Object Oriented database. The main reason was that, being
interested in OO techniques, we wanted a database, which
is well integrated into this environment. The ODMG –Object Database Management Group defines language
bindings to allow the database to be accessed in atransparent way from OO languages such as C++ or Java.
Another reason is that an OO DBMS is inherently better
suited to represent complex data structures than a relational
DBMS. It is often stated that the performance of an
OODBMS is superior for complex data. Recent
investigation in the HEP community [2] showed 4-50
times better performance for typical physicist queries. At
CERN the Objectivity OODBMS was chosen by the RD45
project for performance reasons and for support for very
big databases in the order of terabytes. Our choice criteria
were different: we were looking for connectivity,
compliance to standards to protect our investment and fordevelopment tools.
The system which meets these requirements the best, isO2 from O2 Technology. The offered connectivity isO2Web to access the database from a WWW browser, aCORBA server to access the database from OO
applications distributed over the network, and a bridge torelational systems such as Oracle. C++ and Java bindings

provide a transparent access to database objects and a Cinterface exists as well. The database can be queried with
the OQL query language from any of these languages orfrom the O2Shell. OQL allows using class methods in thequery (among other features) and is part of the ODMG
standard.
The market for OODBMS, although rapidly growing, isstill relatively small, compared with the one for RDBMS.
Because of this, the price for such systems is still
relatively high and there is no well-established market
leader. This should change in the near future given that theOO technology will continue to gain ground.
3.2 Implementation of the new database
After installing O2 in November 1996 we started theimplementation by defining the classes of the database
schema. Some of the classes such as Rack, Crate, Module
correspond to real-world objects and are obvious to define.
Other classes such as equipment template represent anabstract idea and the relation between the BI equipment
and it'template is less obvious. Flexibility was thehighest priority in designing the classes of the schema andmuch effort was invested there. We anticipate that thedatabase schema will evolve in the future and it will be
used by other applications so that we tried to separate out
different views of objects. For instance we separated out
the physical, and the control aspects of experimental
equipment, which was not necessarily the case before.
About 50 classes have been defined of which 20 are keyclasses, such as BeamSegment, ExpEquip or Crate, andrepresent key ideas or real-world entities. Other classes arehelper classes or are used merely as data types.
A substantial effort went to the population of the new
database and several C ++ programs were written to
generate objects based on data extracted from the NODAL
database. Another laborious task was understanding andimplementing the numerous addressing algorithms.
When implementing a database, the user interface is oneof the most time-consuming components. Initially weplanned to implement a Motif-based interface for which
there is some support from O2 tools. Feeling that Webbased interfaces are gaining on importance, we decided
adopt a WWW approach. This is supported by the O2Web
tool, which provides the first, rudimentary interface to thedatabase at no development cost. Some customisation isthen needed and can be done on a class-by-class basis in an
incremental way. With the default interface the objects areidentified by their class name which is obviously not very
convenient for navigation. A small, one-line method
returning the name of the object is normally sufficient toovercome this limitation. Another problem with the defaultinterface is that when navigating from object to object, theURL is extended every time with the object reference. Forsome databases, where navigating in circles is possible (itis enough to have a back-reference) this can lead to very
long URL, hampering the performance. To overcome this aget_query() method, with the OQL query leading to thisobject, can be provided, which will break the circle. On atypical Web page 1 attributes andreferences arerepresented as a list with square bullets. Lists of objects arebulleted with circles. All references are clickable.
Another case of HTML generation occurs whencustomising the default page is not sufficient, i.e. when wewant to personalise the look of the object page, point toanother Web page or make input to the database withforms. This can be done by customising the html_header()method. This way buttons can be easily added to invoke anaction on the object or to spawn a form to submit data tothe database.
When using forms two methods are necessary: one
method to display the form, and a second method toanalyse the content of the form and perform an adequate
action such as doing a transaction on the database toupdate it. All this leads to very straightforward, butmonotonous programming. The customising of Web pages
probably needs some improvements so that this rather
easy, but still time-consuming task, can be simplified.
One of the big advantages of the Web interface is that it
is easy to sell to the users. Everybody knows how tonavigate with a browser so that the look-and-feel isfamiliar. It is also easy to insert references to the databaseobjects into other documents by simply grabbing the URL.
One of our users started immediately to write scripts to getsurveying information out of the database.
To resume, even if the Web interface is basically limited
to one-level interaction, other advantages outweigh it whencompared with X-based interfaces. With the WWW
technology evolving rapidly and being integrated withother products it is also an interesting investment into thefuture.

this case only the type and addressing information is storedin the database. A special case is when an attribute fromthe equipment has a setting and maybe tolerance as well,and it is often interesting to use them together. Finally thedatabase can be used as a cache for attributes which arefrequently used or expensive to obtain. A partial
equipment class and equipment type class hierarchy ispresented in Figure 2.
Offset corresponds to the offset in the attribute list anddmProperty is the Data Module property.
This definition can be used to produce a configurable,generic status display. Objects of class EquipAttrType can
ExpEqGroup
1*ExpEquip

1An example page was foreseen in this place but it could not be
produced on this space in an acceptable quality.

ExpEquipType

name
getAttrByName*
EquipCompType

*Attr

*
EquipAttrType

AttrInt

type
units.

AttrDouble

DbAttrType

DmAttrTypedmProperty

offsethtml_td_str

html_td_str

DmSetAttrTypedmProperty
offset3.3 Using O2 in controlling beam lines
Having implemented the BI database, the beam line
configuration and the equipment information are readily
available. Equipment is seen by experiments under
different names (in fact an equipment such as a bending
magnet can be seen as BEND1 by one experiment and as
BEND3 by another one) which is easily solved by creatinga named equipment reference. Beam lines are built frombeam segments, which are already in the database.
What we need is an interface to the physical equipment
to be able to read and set attributes such as magnet current
or the position of collimator jaws. In fact there is nodifficulty in calling equipment access functions, via theSL-EQUIP package[3], from equipment object methods.
The corresponding O2 clients have to be linked with theSL-EQUIP library as it is shown in Figure 1.
The idea of equipment having properties (or attributes inother words), which can be read and/or set is a goodparadigm for the equipment status and for the equipment
control. The NODAL-based SPS control system used it
extensively. The database is an excellent place to store
some static attributes such as equipment settings andlimits. Other attributes can change very frequently so that
we have to access them directly from the equipment. In1*

html_td_str

Figure 2
be added to the equipment type, describing where theequipment attribute has to be taken from. This approachhas been implemented in our database. The method
html_td_set() returns an HTML table cell so that status
display in the form of a table can be generated.
3.4 Future work
The generic status display, which has been presented in
the previous chapter, can be extended to setting equipment
attributes to change current, position etc. There are notechnical difficulties, but the problem of write permissionshas to be carefully evaluated. The current permission
schema is based on Unix user/group protection, whichcannot be adopted. The HTML password schema currently
used in our WWW interface has probably to be augmented
with checking of the IP address of the request originator to
make sure that the person setting attributes is actually on
the CERN site.
Another typical operation for beam equipment is making
a beam scan. This is a case where use of Java seems
interesting given all the display facilities already available.

Scans could be stored in the database and compared withother scans.
As mentioned briefly before, the database could be used
to cache equipment access. Performance determines
whether it is interesting or not, so that detailed
investigation of the response time and scalability arenecessary.
To eradicate NODAL from our control system we will
have to rewrite the access system, the surveillance
programs and the distribution of the target data toexperiments. In all cases the use of the new OO database
seems to be promising.
4 Benefits from using object-oriented DBMS system
Programs written in an OO language such as C++ orJava often have to deal with persistent objects i.e. objects
which remain the same beyond the lifetime of the program.
In the accelerator area these objects can correspond to anabstraction of a physical component of the system such asa beam line or a beam device. Without an OO database
these objects have to be explicitly created when theprogram starts or when it needs to use the object. For
instance to find all collimators of the “H2” beam line wewrite:
d_OQL_Query q_eq( “select e from b inTheBeamlineSegm, e in b->devices whereb->name=$1 and e->type->name like $2)’)
q_eq << “ H2” <<“Coll”;
d_eql_execute(q_eq, eq_list);

This syntax complies with the ODMG C++ binding
standard and is portable between different ODMGcompliant systems. The query statement in quotes iswritten in OQL query language, which is part of ODMG
standard as well. All this leads to programs which areshorter, and more comprehensive than programs which use
other types of permanent storage for objects. Anotheradvantage is that such storage is flexible. When the classevolves, the program does not need to be changed in mostcases. On the database level, any class of the schema canbe easily modified without affecting objects of this classalready stored in the database because new attributes will

be initialised with default values for existing objects. In
consequence software can be built in an incrementalmanner and this is exactly what we need to move from theold to the new control system.
Other benefits are the obvious benefits from using acommercial database system such as CASE tools fordevelopment, data security and optimisation of data access.
5 Conclusions
The new Object Oriented database has been a successful
approach to the modernisation of the Experimental Areassoftware. The implementation of the BI database has
allowed us to upgrade an important part of the NODALbased system and introduce numerous improvements.
More important, this approach is a good starting position toupgrade the whole system step-by-step. The use of an
object-oriented DBMS and of the World-Wide-Web puts
us in an excellent position to successively introduce objectoriented technology and Web tools. It is an innovative
approach and could become a pilot project for other areasof controls in our group.
Acknowledgements
I would like to thank Dafydd Thomas for his help inimporting the data to the database and understanding theequipment addressing. John Fullerton helped me tounderstand the old database and has provided most of therequirements.
References[1] The New Controls Infrastructure for the SPS, M.J.
Clayton and P. Charrue, Proceedings of the 1995
ICALEPCS conference, Chicago, 1995.
[2] PASS project at SSCL, PASS Note 93-1, also in
IADBG Newsletter no. 9, http://www.cern.ch/IADBG/Welcome.html[3] The Equipment Access Software for a Distributed
UNIX-based Accelerator Control System, P. Charrue et al.,ICALEPCS, Berlin, 1993