A CONTROL SYSTEM BASED ON WEB, JAVA, CORBA AND FIELDBUSTECHNOLOGIES
M. Dach*, S. Hunt*, B. Jeram, M. Juras, K. Kenda, I. Kriznar, B. Lesjak, K. Mele, T. Milharcic,M. Perko, M. Peternel, U. Platise, M. Plesko, R. Sabjan, H. Schieler+, M. Smolej, G. Tkacik, I.
Verstovsek, B. Zorko, K. Zagar, J. Stefan Institute, Ljubljana.
e-mail mark.plesko@ijs.si, http://kgb.ijs.si
exist. This comprises components, which are specific toaccelerators, such as API, data server and the I/O boards.

Abstract
We present the control system for the light source
ANKA, which builds on the three-tier standard modelarchitecture. Modern products based on standards indistributed objects and networking are applied inaddition to low-cost hardware including PCs. The
LonWorks field bus network with intelligent nodes andstandard I/O modules connect the individual devices
directly to PCs. Those PCs act as Web servers for datatransmission, application distribution and documentation
retrieval. Other PCs on the net run Web browsers withJava clients. The communication with the control systemdata servers is done through CORBA. CORBA objects
are wrapped into JavaBeans, which are connected withcommercial data-manipulation and visualisation Beans
using visual tools or programmatically. The CORBAobjects and JavaBeans are generic models of controlled
data that can be used at any other control system. The
Java applications are based on those objects only and canthus be run on any other accelerator.

1 INTRODUCTION
The control system uses existing intranet/internet
infrastructure and web technologies such as
HTML/HTTP, web browsers/servers with Java andCORBA to the maximum extent. This decision wasmade not only because nowadays a large proportion ofpeople are familiar with web browsers, but because there
are many Web-based commercial tools and libraries
available that can be used as building blocks of thecontrol system, thus reducing the development time.
As it is – as yet – too costly to have one Internet node
per controlled device, the LonWorks fieldbus is used tonetwork controlled devices. The gateway between thefieldbus and the Internet Protocol (IP) is done via
software (named device server) running on PCs.
Owing to the fact that many commercial components
exist, great care has been taken in using them as often as
possible, while keeping the number of different products
small. Table 1 gives an overview of products used. It canbe noted that only those components have beendeveloped in-house, for which no commercial alternative.

+*PSI, Villigen, Switzerland, FZK, Karlsruhe, Germany

Table: Products used in the control system.
usage

ProductSource

consolesoperating system
panelsvisual programming
widgets, plot/trend
accelerator API*PCs
Windows NT*Java
VisualAgeJava
JClass Beans
AbeansManyMicrosoftSunIBM
KLGroupin-house

process computer
operating systemInternetcommunicationfieldbus management
archive databaseconfig. databasedata server*PCs
Windows NT*CORBA
LCA/LNS*SQL
text-files
device server

manyMicrosoft
InpriseEchelonmany
in-house
in-housefieldbus
microcontroller
programming language
crossdeveloping tool
I/O boards*LonWorks*Neuron*Neuron C
LonBuilder
Zeus,Hera

EchelonEchelonEchelonEchelonin-house

2 ARCHITECTURE
2.1 Design Considerations
Some important design decisions are based on theparticularities of the ANKA project• small machine: 100 m circumference, 2.5 GeV,
medium emittance• low cost (15 M US$), short time-scale (3 years)• outsourced subsystems (injector, RF-system)• small staff, also for operation
The consequences for the control system are:• must avoid extensive development•needs to connect seamlessly to externally developedsubsystems• clean and simple concept for later maintenance
It was decided that performance can be sacrificed andinteroperability among components is sufficiently
important to tolerate overheads. Furthermore, generality
and flexibility, often requested because of missing or
insufficient advance specifications, have been limited.
Based on experiences from similar machines, a list ofsoftware and hardware interfaces has been established,which the designers of equipment had to follow. Shoulda custom implementation be inevitable, then it must behidden from the rest of the control system at the lowest
possible level, i.e. on the fieldbus node, be it in hardware
or software.

2.2 Design Simplifications
These directions worked very well so that a carefulanalysis revealed that only three different types offieldbus boards are necessary: DAC/ADC combo, 40
channel I/O and serial interface. More complex I/O, suchas image processing, PLC drivers and GPIB-Ethernet
converters, is handled directly by the PC.
Although the control system is designed to support all
primitive data types for controlled values, only double
and unsigned integer did suffice. In turn, the number ofnecessary GUI components is small. Not only were thetypes of values limited, also their properties weredefined and fixed in advance. This means that acontrolled value is either read-write or read-only and thatit has a name, a minimum, a maximum, etc. The list ofproperties was made large and configurable enough tocover .all cases, yet the sole fact that it is fixed inadvanced simplified the design of clients and servers anddatabases.
The only disadvantage of this approach is that thefieldbus programs are quite complex and different foreach device, i.e. not one program per board type but one
per device type. Also the device servers and the API isthen device specific, however due to the pre-definedvalue types and structures, all those components can bebuilt easily and fast. In fact, a wizard has been written
which generated device servers based on device interface
definitions. The Java API libraries, JavaBeans, need lessthan one page of extra code per device. So in total, theconcept proved to be advantageous.
This approach is of course by no means novel. EPICS
for example provides similar basic value types, yet isopen for user defined value types and properties. The
main differences of our approach with respect to EPICSare:• EPICS in principle assumes that nodes are notintelligent – EPICS does all the state processing andevent generation, while in our system this is done by
the fieldbus nodes•EPICS is based on channels, i.e. individual control
values, not on devices, while in our system devices
are implemented already on the fieldbus level.

2.3 General Layout
Technically, the control system follows the standard
model three-layer architecture. Conceptually, it iscomposed of two layers, connected through the device
server:• the fieldbus layer with asynchronous event-driven
data acquisition/control;• the object oriented layer with a model of devices
where the client talks to devices as if they werethere.
The device server adds little functionality apart fromserving as a gateway and multicasting events to manyclients. But due to its existence it hides all details of thefieldbus system to the client, although the event sources
reside actually on the fieldbus nodes.
The object-oriented layer, which is the only one that isseen by the user of the control system, is based on theWeb, Java and CORBA. The goal is that all user actions
can be done from a Web browser. This includes, apartfrom device control, also writing and reading thelogbook, checking alarms, searching the data log,
reading help and documentation, etc. Tasks that deal
with the management of the control system, however,will generally not be made available through a Webbrowser. The security implications are severe, not somuch because of external security breaches, which areunlikely, but because management should be kept in thehands of a small group of people.

3 COMPONENTS OF THE CONTROLSYSTEM
Separate contributions to this workshop describe theuse of the fundamental components LonWorks [1],CORBA [2], and Java [3] in great detail. Following areshort descriptions of control system components thatprovide the framework and services to the fundamentalcomponents.

3.1 Databases
Our design of the control system involves threedatabases, which accomplish completely different tasks.
The static database stores configuration parameterslike names, constants, calibration coefficients, attributes,
alarm levels, fieldbus addresses, etc.. Clients don’t
access the database directly but through the CORBA
server. Each object is responsible to provide data thatbelongs to it. The CORBA objects therefore implement
commands that return all data from the static database.
Since the properties of the controlled values have beendetermined in advance, each property is obtained
conveniently through a call to a CORBA method withthe same name as the property. The static data used by
the LonWorks nodes are stored in the static database,too. They are downloaded to the nodes at start-up of thedevice server with a generic procedure involving atemplate compiler and a LonWorks ftp-like protocol.
Data that are used both by the device server and thenodes are located only in one place of the database toensure consistency. Normal users of the control systemshould not modify the static database. The configurationclient runs therefore on the device server level only. As
it does not have to run in a Web browser, it has been
written in C++ for efficiency reasons. It provides handy
actions such as versioning, rollback, locking. The
database is hierarchically organised with directories andtext-files, benefiting from the Windows NT file system.
The client therefore uses MFC libraries of the Windows
Explorer and Notepad to display and edit the database
content.
The historic database logs data over long periods oftime. Long-term history data are stored into a relational
database and retrieved off-line. The device servers keepa short-term history for all controlled values in a ringbuffer during run-time. The length of the history is set in
the static database and comprises usually about 1000
seconds. The buffer is periodically sent to the historic
database. As the type of queries to the historic databasecan not be foreseen, a general SQL tool will be provided
to allow the user to construct any imaginable query.
The snapshot database stores the state (i.e. allsettings) of the machine. The snapshot database is usedand managed through a dedicated application. Thisdatabase uses a CORBA-based location service todiscover all devices during run-time. It then uses Java
introspection to determine all settable properties of adevice. Actions of the application include save/restore,view/edit/merge, etc. Due to the small amount of data atANKA, each entry in the snapshot database will be
stored as a text file. The application will provide means
to search the files in different ways. At a later stage amore powerful relational database could be used.

3.2 System ManagementThe management of the fieldbus is done partially withtools that form part of the developing environment ofLonWorks and partially through the device server.
The device server and the clients are managed with a
special CORBA client which can start/stop a server,
update static data on a running server disable/enable one
or several devices, disable/enable or stop monitors,monitor device server events (client connect/disconnect,errors, etc.). As in the case of the static database, themanagement client is written in C++.
The security of transactions will be very simple buteffective. Each client that wants to connect to a device
must first register with the management server. Only

clients with the correct password and host IP number
will be granted access to the device.

3.3 Using the Web
The Web acts as glue that helps the user see thecontrol system from a single application, namely a Web
browser. In addition to standard Java/CORBA clients of
the human machine interface, which include a Javavisualisation tool for AutoCAD files, standard Web
applications will be used for the help system and for thelogbook.
The help is simply a group of html files, withembedded PDF documents for technical drawings.
The logbook will be just another newsgroup, where
only the operators can post but anybody within thelaboratory can read. The current Web browser allow soconveniently to attach any electronic document type,including machine status printouts, that only a simple
Excel template is necessary to simplify operator input.
The machine status can be written to a file with a simple
Java application and then attached, too. As the law
requires keeping the logbook on hardcopy, the latest
mailings to the newsgroup will be printed once per shift.
An information service page with a small Java client
displaying the actual status of the light source, its
energy, current and lifetime history will be available
without security restrictions to everyone.

CONCLUSIONS
It is important that the concepts used will last over thelifetime of the ANKA project, which is long compared
to a typical lifecycle in the computer business. It is risky
to make predictions, but we believe that products thatare based on the technologies described in this paper canexperience a longer lifetime than usual.
Experiences with the running system for the ANKA
microtron show that the concept lives to its promises. A
successful port of the Java Beans to a test case at theSwiss Light Source, where the calls to CORBA werereplaced with calls to CDEV, is a proof that the strict
object oriented model of devices can be used toeffectively hide other types of communication channels.
This means that there is no limit to the reusability of theJava applets developed for ANKA at other accelerators.

REFERENCES[1] K. Kenda et al, I/O Control with PC and Fieldbus,
PCaPAC99 workshop, Tsukuba, January 1999.
[2] M. Plesko, Implementing Distributed Controlled
Objects with CORBA, PCaPAC99 workshop,Tsukuba, January 1999.
[3] G. Tkacik, Java Beans of Accelerator Devices forRapid Application Development, PCaPAC99
workshop, Tsukuba, January 1999.