Experience with the Integration of Transient Recorders
in the Daily HERA Machine Operation
R. Bacher, M. Clausen, P. Duval and L. Steffen, DESY, Hamburg, Germany
Abstract
Many parameters of HERA machine components likeRF systems or quench protection as well as important
beam parameters and major parameters from the DESY
utility installations are continuously measured by transientrecorders. In general, these recorders are not synchronizedamong one another and sample the data with very different
rates ranging from 200 Hz to 50 MHz. At present, work isgoing on to integrate the existing transient recorders into aglobal system.
The paper reviews the transient recorder hardware
operated at HERA and the problems related to theintegration of different types and systems. The proposed
trigger distribution based on the HERA Integrated Timing
system and a possible software trigger as well as thesoftware concept to archive, retrieve and display the data together with first results - will be described.

universally usable recorder is currently being developed.
2 Existing transient recorder systems
The existing transient recorders have been alreadydescribed in detail [1]. They consist of several independent
developments of individual groups at DESY. These
recorders vary in functionality as well as in performance.
About hundred channels of the RF system and HV power
supplies are read by PC-based fast ADC boards (BakkerBE 490). More than 1400 channels of the quench
production system are read by special electronics in theHERA tunnel, transported through the CAN field-bus and
VME CPU and stored on a file server. Other data originate
from the post-mortem memories of the beam loss monitors,
the beam orbit and the pulses of the kickers and septum
magnets.
3 Integration of data sources

1 Introduction
The HERA accelerator complex is a proton-electron
collider. A proton beam of more than 70 mA is injected at
an energy of 40 GeV into a ring of superconducting
magnets and accelerated to 820 GeV. Electrons aretransferred to HERA at 12 GeV and ramped to 27 GeV
using conventional magnets. Typical electron currents areabout 40 mA. A successful fill remains stored in HERA
about half a day. Less than 50 % of the time scheduled forphysics experiments can be used for data taking. The
remaining fraction is mainly dominated by the filling,
ramping and tuning processes. In particular, the filling ofprotons takes a long time. Therefore, the most unfavorable
situation in the daily operation of HERA is the loss of one
or even both circulating beams. If the origin of the beamloss can be uniquely identified improvements of themachine operation or the technical components can beperformed. However, a loss not understood contains therisk of a new loss during the following run. Besides a
reduction of the running efficiency, losses can generate
dangerous situations for the superconducting magnets andradiation-sensitive components close to the beam pipe of
the physics detectors.
To identify the reasons for beam losses, many
parameters of HERA machine components like RF systems
or quench protection as well as important beam parameters
are continuously measured using transient recorders. Ingeneral, these recorders are not synchronized among one
another and sample the data with very different rates
ranging from 200 Hz to 50 MHz. This lack ofsynchronization often does not allow us to disentangle thetemporal or causal development of a beam loss. At present,
work is going on to integrate the different existing transient
recorders into a global system. In addition, a new

While some of the data are already stored on generalaccessible file servers, other data i.e. from Bakker boards
typically are stored on the local disks of distributed PC's.
To integrate these type of PC's the software support for theI/O boards has been rewritten to run under anotheroperating system (here: VxWorks) to provide the necessary
networking capability. This way the boards can beremotely managed and the data can be stored on a general
file server. Additional transient recorders will be integrated
in the same manner as well as new recorders currently
under development.
4 Software architecture
Since the installed transient recorders are installed andsupported by several groups at DESY using different ways
to collect and to store the data, a mechanism had to beestablished to combine the freedom of independent datastores with the requirement to be able to read, plot andcorrelate the data by one (ore more) common application.
The resulting software architecture is based on the wellestablished PKTR/net protocol at DESY. This protocol
uses the TCP/IP transport and supports asynchronous
communications following the client server paradigm. (Fig.
1).
4.1 Central event server
To accomplish the main requirement of the transient
recorder system: data correlation, it is necessary to keep
track of timing information of the different data stored ondisk. The central event server is designed with thefollowing functionality:•
receive triggers from the HERA Integrated Timing(HIT) system•receive requests for event numbers from archiveservers•
generate event numbers (UNIX time stamp)•
after a trigger, or a request for an event number fromone archive server, the event server will distributethe event number to all registered archive servers(including the one originating the request)•
store event number on disk•
receive acknowledgements from archive servers
including information about stored device information•
add archive server-, device server- and commentinformation to each event number•
keeping event numbers valid for a predefined time
period (typically 4 sec)
In addition to the functions generating and storing event
informations the event server has to communicate with thedisplay applications to:•provide stored event numbers within a given time
period•provide information about archive servers and device
servers which stored data for a given event numberBesides these central functions the event servers keeps
track of the currently connected archive servers, theirnames and the adjacent device servers.
4.2 Archive server
Besides the basic functionality to store the data of atransient recorder the archive server has to store additional
information together with the data. These will allow
identifying timing information as well as the hardware
setup of the transient recorder itself. These informations
will be necessary to display data from different recorders
by means of a common display tool in the same diagram.
Archive servers support internal and external triggers tostart an archiving process. If the archiver will receive an

event number from the event server it will decideaccording to the additional event code whether this willcause a readout of the served devices. On the other handthe archive server will store data from auto-triggered
devices and send a request for an event number to theevent server, which in addition will inform the otherarchive servers by distributing the event number.
Similar to the support for client applications on the event
server, the archive server has to provide detailed
information for (display) clients:•the event numbers for which data have been stored(redundant information to event server)•the number and names of device servers•
the devices and their properties•
the setup data of the transient recorders•
the data itself
Some redundant functionality to the event server will be
implemented on the archive server to be able to store, findand access the archived data without a running event
server.
4.3 Client applications
Since the development of the transient recorder system
is carried out by several groups at DESY, the goal is, to beable not only to share the applications for the event server
and the archive server but also to use a common display
application even though the individual groups use different
platforms for their daily work. In this case the two major
platforms for operator applications are workstations
running MS-Windows and UNIX workstations with XWindow displays.
If PC-based X-Server are not applicable the obvious
way to share applications between these two operating
systems is to use a Web based application. It was agreed
that the interactive features of the client application should

Application 1

Event Server

Trigger Server

Application 2

Archive Server 1

Archive Server 2

Device Server 1

Device Server 1

Device Server 2

Device Server 2

Figure 1: Software Architecture•A display to be able to select a certain time period
in which the user is interested.
•Communication with the event server to retrieve
the event numbers registered within the given time
period including the informations about the archiveand the device server, which stored data for the event
numbers.
•A display for the resulting informations from theevent server and the possibility to select an individual
device server to get more detailed data about thechannels and their properties stored on the archiveserver.
•Communications to the archive server to extractdevice informations and to retrieve the stored data.
•A chart to display one or more data sets from one
or more different archive servers.
In addition to the possibility to display data from thearchive server it was found to be useful to display also
online data from the running equipment. This function
has also been implemented.
In the next step the settings of the chart including thechannel properties will be stored on a common disk to
be able to retrieve previous setting in a new session.
Fig 2: Client Application
be similar to a Visual Basic or Motif based program.
Driven by these requirements a test was carried out to findout whether Java applets running under a Web browser
would perform adequately. The proof of principle waspossible with the Java-Class library from KL-Group for thecharts and the Symantec Cafe development toolkit for Java.
Even though the functionality running a Java 1.1-applet
under different Web browsers and different versions
showed astonishing results the performance was promising.
Hoping for a reliable implementation of the fundamental
Java classes in all common Web browsers it was decided
to implement the client application completely in Java.
The data transport between the Java applet and the dataservers is initially implemented in a CGI on the Web
server from which the applet is loaded. In the final
implementation of this communication the CORBA
transport will be implemented. First test have alreadyshown that this will lead towards better performance andmore flexibility for the location of the data servers
The initial functionality of the client application can besummarize as follows ( Fig. 2):

5 Status and outlook
The software modules for the event server have been
implemented and tested. Several archive server havestarted operations shortly before the end of the 1997
HERA run and write their data to a central file server. Theinterface programs for the event server and the archive
server are implemented and need final testing.
The client display program has been implemented inJava and tested with the event server. The initial version of
the display program is running and collecting data througha CGI on the Web server. More functionality will be
implemented in the display program and tested against
more device and archive servers as they come online.
It is planned to use CORBA as a transport for the Java
applet before the next HERA run in April 1998.
References[1] R. Bacher, M. Clausen, P. Duval and L. Steffen: “TheUsage of Transient Recorders in the Daily HERA
Machine Operation” PAC-97 Vancouver