Integration of a Relational Database in the CERN PS Control System
J.H. Cuperus, M. Lelaizant,CERN, 1211 Geneve 23, Switzerland
Abstract
The control system for the CERN 26 Gev Proton
Synchrotron and its injectors is a generic system which canbe adapted to other accelerators. Most configuration data
are in a relational database. From these data we cangenerate object interfaces for equipment, configuration
files for front-end computers, a read-only database foraccelerator control interfacing, and full dynamic
documentation on the Web. The database is also used inreal time for runtime references and archives, and for theworking data of several programs.
1 Introduction
The control system for the CERN PS accelerator
complex (7 accelerators, not including SPS and LEP), is a
generic system which can be adapted to other accelerators.
It must steer the beams through the interconnected
accelerators with up to 5 particle types accelerated incycles grouped in a supercycle. This means thatthousands of parameters must be changed each cycle ofabout 1.2 seconds. Some help from a database is required.

VME, CAMAC, G64, and other module types. Someattributes, such as default VME base addresses andinterrupts, are only filled in when relevant.
An example of an instance description is table
MODULES which lists the location, function, addresses,
and exceptions of individual modules.
When the number of attributes is too large, or when thelist of attributes varies too much from class to class, we fallback on a structure like: INSTVAL = {CLASS +MEMBERNO + VARNAME + VALUE} which contains
values for all the static (read-only) attributes which aredefined in the class. These values can be of any type, evenarray, but are stored as strings.
2.4 Data input

2 The database
2.1 History of the database
The development started in 1980 when a file system
database made by us on a NORD computer was used
to support a data-driven alarm system. The data expanded
to cover other subsystems and, in 1986, the data weremoved to a Oracle-V5 database system on a central
mainframe. In 1991 they moved again to a local server,
dedicated to accelerator control.
2.2 The database server
The relational database management system (RDBMS)
is Oracle-V7.3, running on an IBM RS/6000 server with
256 MB of memory and 3 hard disks of 2.2 GB each.
Operation is continuous with on-line backup during thenight. In case of hardware malfunction, we can quickly
switch to a backup machine without loss of data, but there
has been no need for this in 6 years of operation on
two different servers. The mean load of the database is low
so that almost all requests can be serviced quickly.
2.3 Data structure
The hardware and software is described with about 100
core tables managed by the database section. Of these, 60
describe software classes or hardware types and the rest
stores the attributes for the instances of these types.
An example of a hardware type description is table
MODULETYPES, which lists the fixed attributes of

Fig1: An example of a data input screen
Input of static data is mainly through interactive forms(Fig.1), grouped in menu structures per application. Theforms are generated with the help of our templates on
top of the Oracle 4.5 Forms.
Some bulk loading from external data sources such asdata files, spreadsheets, or other databases is also done
and, occasionally, the data manager can transform the datawith SQL database language statements or withscripts. Dynamic on-line data, such as accelerator settings,measurements, and user actions, are mainly written to thedatabase by C procedures with embedded SQL.
And some of the data migrated over 17 years through 5
platform changes.
2.5 The real-time database DBRT
A subset of the data in the RDB can be downloaded in asimple real-time database called DBRT, which is based onNDBM, a commercial UNIX hash table system. This has
the following advantages :•••••

Each accelerator can have its own copy which makes
the system less dependent on the central database.
Access is through procedure calls and the application
programmer does not need a SQL precompiler.
Access time is better guaranteed.
Complex derived objects can be constructed off-line.
DBRT shows a consistent snapshot of the data at themoment it was generated.

A variant of DBRT is now experimentally used for
initialising Java objects through UDP network calls. This
may later be replaced by a direct RDB connection through
JDBC (Java Database Connectivity)or throughembedded SQL in Java..
2.6 Dynamic web documentation

including the structure and status of the database.
3 Application
The most important applications are described below.
Support for these applications goes from major
responsibility for the database section (2 persons) to merely
providing the database environment.
3.1 Object oriented equipment interface
Access to the accelerator equipment is with Control
Modules, which are seen by the application programmers
through a uniform object oriented interface [1].
A piece of equipment is identified by its name or,alternatively, by its class name and member number.
About 100 classes are defined in the database in ahierarchical structure with inheritance. All instanceread-only data (constants) are also defined in the database.
9 class and 2
instance description tables
ControlModule
Frame

Data Structure andMethod Template
Generation Program
Initialised
DataStructures

Templates
MethodLibrary

C -Compiler
Fully initialised Control Modules installed on
one of more than 100 front-end computers

Fig3: Control Module generation
When the data are filled in (and the method libraryupdated), a set of classes can be automatically compiledand installed in one of the 100 front-end computers(called Device Stub Controllers or DSC) each sitting in a
VME crate (Fig.3).
3.2 Automatic front-end computer configuration

Fig.2: An example of dynamic documentation on the Web
A Web page can reference a script in the server directory
cgi-bin which calls procedures in the databaseprogramming language PL/SQL. These procedures, stored
in the Oracle database, construct dynamic pages (Fig.2)
according to the parameters with which they are called.
These pages are typically also full of links which referto other dynamic pages and so on. At present, 113
procedures can generate tens of thousands of different
pages in 113 formats. They cover the whole control system,

From information about VME and other crates andmodules, equipment, and programs, a file named rc.local isgenerated for each DSC (Fig.4). This file contains all
information for starting up and initialising the drivers
and other
programs
whicharespecificto this DSC, in the proper order and with the rightpriority and arguments. The file contains also comments
which describe the configuration of the DSC and arereadable by a maintenance program [2].
3.3 Alarm system
Any control module (CM) class can inherit variables andmethods from the ALARMS class, on top of its normalinheritance. This inheritance includes the generic method
ALARM which depends for its execution on control and5 type description tables for computers, crates,modules, drivers, and programs.
7 instance description tables for installation,exceptions, and parameters.

via DBRT [4].

Initialisation-file Generation Program
DSC Initialisation-file rc.local
Fig.4: Generation of rc.local initialisation files
status word descriptions in its class and instance variables.
These values are derived from the database [3].
An active scan program acquires a list of equipment andperiodically scans the corresponding CM with the method
ALARM which responds with an alarm code (Fig.5).
The display program can display the corresponding
alarm messages and give details on request.

Real-Time
Database
DBRT

7 typedescriptiontables and 2
instance tables

All control
modules
implementing
alarmsActive alarm scanner and collector

Interactive alarm dispay(s)Fig.5: Data flow in the alarm system
3.4 Equipment archives and references
Each piece of equipment can have the values of several
attributes stored for each of 24 virtual accelerators. Thesereferences are set to the operational values on request of
the operator, individually or for any set of them. Later,
the operator can use these values to restore
normal operation after experiments or corruption.
Any set of reference values can be stored in a namedarchive.
A large number of archives is allowed.
These archives are used to come back to settings whichgave good results in the past.
3.5 Generic user interface
After the operator logs in, he is presented with a menu
interface which permits him to select the working
environment and the programs to be started.
Generic programs are available for controlling
equipment and for displaying values in the desired format,
for single pieces of equipment or for various ensembles(Fig.6). This is aided by meta-data which specify theimportant properties for each class.
All this is data-driven, with data coming from the RDB

Fig.6: Knobs for setting values of accelerator parameters.
3.6 Supercycle editor
An interactive program permits the operator to set up
the various beams and cycles which compose a supercycle.
All this is described with tables in the RDB which
also contains an archive of useful past cycles, beams andsupercycles [5].
3.7 Expert systems
A few expert systems have been built, using the databaseas a knowledge base:•
An experimental system relating beam data andalarms [6].
•A set-up system for initialising the equipment
interface and the equipment with a specially madeinference engine [7].
•A system converting rules to SQL statements forchecking the compatibility of cycles in asupercycle[8].
These systems work well but there is no unifiedapproach. We think it would be logical to put both facts andrules in a relational database. Some means of indexing therules would avoid linear searches through huge rule bases.
What is missing is an inference engine integrated in thedatabase, perhaps based on an extension of the SQLlanguage. This marriage
betweenRDBMS andexpert systems seems natural to us but database designers
have other priorities at the moment.
3.8 Data extraction from drawings
A lot of information about the control system iscontained in drawings made with the help of Computer
Aided Drawing systems. It would be useful to be able
to extract the geographical location of a component or thenumber of a cable between two connectors. There are
however no accepted data format standards and little
provision is made for extracting information beyond partlists. Some way to query the data with at least a subset of
SQL is desirable.
We tried automatic information extraction from lists that
could be generated but this was not implemented becausethe efforts were out of proportion to the benefits.
3.9 Other applications
Independently developed applications may use the coretables and add tables of their own, integrated with the coredata by agreeing on common identifiers. Examples are:•ABS [9] which describes beam paths, magnets, andmonitors in order to calculate operational settings
to steer the beam.
•NAOS [10] which controls a system for acquiring anddigitising signals for display and reference.
4 Why a relational database ?
We make considerable efforts to reconstruct
software objects from data in the database, so you may ask
why we do not use an object oriented database. The
advantages of a relational database for accelerator controls
are:•
The data are in a safe environment, well protectedfrom unintentional changes by faulty programs.
•Data access is with the standard SQL language andis not restricted to a set of closely related programs.
•
The rules for modelling complex structures in a
relational database are well known and rather easy
to apply with some experience.
•The resulting tables are well adapted for filling-in thedata through forms.
•Strong data relations are grouped in tables while
weaker relations can be left implicit, which keeps thestructure simple and versatile.
•Object views adapted to particular applications can bederived with SQL statements. This may be inefficient
but it is straightforward and fast enough for theapplications which are of interest here.
•Most large and complex control systems will grow,have frequent modifications, and often whole newsubsystems have to be integrated without disturbing
existing applications. All this is rather easy with arelational database.
Version 8 of Oracle, now becoming available, hasmany new object-oriented features, implemented on top ofthe RDBMS. It is not yet clear how we can use thesefeatures and whether they will make things simpler.
Of more immediate interest is support for storage,
display, and querying, of complex datatypes like text,images, video, and sound. Especially important for us
is support for collections such as arrays and lists.
Thesedevelopments fit perfectly in the relational model.
5 Conclusion

We have demonstrated that it is quite possible to store
almost all configuration data and many operational data ina relational database. These data can be used to generateinterface modules, install programs, and provide programswith data. The database is especially useful if the wholesystem is integrated and not just a number of unrelated
subsystems. This requires close collaboration between the
database section, responsible for the structure of the coretables, and the application programmers. An important side
effect of a central data store is the availability of theinformation on the Web, for local use and external
documentation.
References[1] L.Casalegno, J.Cuperus, C.H.Sicard, Processequipment data organisation in CERN PS controls,
ICALEPCS-89, Nucl. Instr. & Meth. A293 (1990)
412-415.
[2]J.Cuperus,A.Gagnaire, Automatic Generation ofconfiguration files for a distributed control system,ICALEPCS-95, Nucl. Instr. & Meth.
A352 (1996) 148-153.
[3] J-M. Bouche, J.Cuperus, M.Lelaizant, The data driven
alarm system for CERN PS accelerators, ICALEPCS93, Nucl. Instr. & Meth. A352 (1994) 196-198.
[4] J.Cuperus, F.Di Maio, C.H.Sicard, The operator
interface to the equipment of the CERN PSaccelerators, ICALEPCS-93, Nucl. Instr. and Meth.
A352 (1994) 346-349.
[5] J.Lewis, V.Sikolenko, The new CERN PS timingsystem, ICALEPCS-93, Nucl. Instr. & Meth.
A352 (1994) 91-93.
[6] P.Skarek, L.Varga, Multi-agent cooperation forparticle accelerator control, Expert Systems withapplications Vol.11 No.4 (1996) 481-487(Pergamon / Elsevier Science Ltd).
[7] G.Daems, V.Filimonov, V.Homutnikov,
F.Perriollat, Yu.Riabov, P.Skarek, A knowledge based
control method, ICALEPCS-93, Nucl. Instr. & Meth,
A352 (1994) 325-328.
[8] J.Lewis, P.Skarek, L.Varga, A rule-based consultantfor accelerator beam scheduling used in the CERN PS
complex, ICALEPCS-95, Nucl. Instr. & Meth.
A352 (1996) 703-706.
[9] B.Autin, F.di Maio, M.Gourber-Pace, M.Lindroos,J.Schinzel, Database for accelerator optics, thisconference.
[10] B.Dupuy, P.Fernier, B.Frammery, S.Pasinelli, A VXIsystem for observation of distributed analog signals.
RT93, Eight Conference on Real-Time Computer
Applications, June 8-11, 1993, Vancouver, Canada.