Diagnostic System Using a Database for High Energy Accelerator
Components at the Photon Factory
Noriichi KANAYA, Seiji ASAOKA and Hideki MAEZAWA
Photon FactoryHigh Energy Accelerator Research Organization (KEK)
1-1, Oho, Tsukuba, 305, Japan
Abstract
A diagnostic system using a commercial database has
been designed and built for high energy accelerator
components at the Photon Factory, KEK. An operator canchoose one or more event items associated with theaccelerator components to be inspected. By retrieving any
combination of operational information to reproduce thephysical behaviors, the system allows diagnosis of thecause of a failure that has occurred at one of the numerous
accelerator components, particularly for the twenty-two
synchrotron radiation beam lines and the vacuum
components of the 2.5 GeV positron storage ring, where
X-ray/VUV synchrotron radiation experiments are
simultaneously carried out. The total number of items to
be inspected by the diagnostic system is over 40 million inorder to obtain a correlation between the faulty component
and other physical components that would suggest thecause of the failure. With the aid of the diagnostic system,
the operator at the control room can easily determine thefaulty component, and recover the accelerator component.
Experience with the diagnostic system is described.

at the 2.5-GeV positron storage ring, Photon Factory at theHigh Energy Accelerator Research Organization. Thesebeam lines feed synchrotron radiation to the experimental
hall where experiments, such as surface physics, x-ray
lithography, microscopy and crystal structure analysis, aresimultaneously carried out. These beam lines are simultaneously in operation, providing intense synchrotron
radiation beams. The pressures in the storage ring and thebeam lines are maintained at an ultra-high vacuum (UHV)of less than 10-10 Torr to achieve a long beam lifetime,
typically more than sixty hours.
2 System description
Figure 1 shows a block diagram of the diagnostic
System. The database management system employed isOracle 7. Operational information regarding the beamlines is automatically stored to the Database [2].
These beam lines are automatically controlled by a
distributed control system which comprises twenty-two
microcomputers and a VAXstation 4000/90, runningunder VAX/VMS through an optical-fiber network with astar configuration [3,4].

1 Introduction
High energy accelerators comprise a large number ofaccelerator components and sensors to be controlled,
including digital I/Os and analogue I/Os. The components
involve a number of actuators, vacuum valves, coolingwater flow sensors, vacuum sensors, pneumatic-pressuresensors, atmosphere sensors, radiation-safety interlocks,
vacuum-pressure gauges and valve-driving units.
A diagnostic system for such complex accelerator
components is a key to R&D for the accelerator, providing
important trace-back information regarding the physicalbehavior of its components.
In addition, from the view point of accelerator
operations, the diagnostic system must allow the operators
to easily diagnose the cause of a failure by retrieving
operational information to reproduce the physical behavior
that has occurred in the accelerator.
As a template for such components of accelerator
complexes, a diagnostic system employing a databasemanagement system has been designed and implemented,
particularly for synchrotron radiation beam lines. For alarge accelerator, a logging system using a database has
been also in operation [1].
There are twenty-two synchrotron radiation beam lines

Fig.1 Block diagram of the diagnostic system for highenergy accelerator components.
There are two categories of operational data available
from the accelerator components: asynchronous event dataand static data. The event data is obtained from pick-ups
as digital ON/OFF signals generated by vacuum valves,
shutters, driving signals for controlling the vacuum valves,and status signals of safety interlock signals. There areapproximately 2000 pick-ups in total. Event data isobtained at any instance of time when a component
changes its status.

Fig.2 Retrieval result generated by the diagnostic system to inspect whether two accelerator components
are functioning properly.
The maximum rate of event signals reaches ~300
events/sec, which occurs at 9AM just before and after theroutine procedures for beam injection. The event signals
are archived at an accuracy of 20 ms. This also happens
when one of the interlocks is triggered in the case that an
unexpected failure occurs.
The second category includes static data: static datacomprises analogue values that are periodically measuredat a specified interval of three seconds. The static data
involves a beam current and pressure signals of thestorage ring, measured at an interval of three seconds. Thetotal amount data to be stored into the database reaches
approximately 40 million items, consuming approximately
2 GB of disk space per year.
The configuration of an accelerator always tends to bemodified in accordance with the physics experiments.
This leads a new problem: how can we add a new categoryof a device/ component without adding a row to a table inthe database, and keeping compatibility for future
modifica-tions of the accelerator. If you add a new row
into a table, you must reorganize the data table, and greatcare must be taken to make it compatible with the existingarchived data.
All event data are mapped to a tree data structure with amaxim of seven branch levels, which correspond to thecategory of devices and components (for examples, a valve
category and radiation interlock category). The lowest
branch level has leaves, i.e., the status of the component
associated with a timestamp. Each level of the tree ismapped to a row of a table in the database, having aunique index, which allows efficient retrieval. This meansthat the table is normalized to have seven rows plus one
row for a timestamp. Adding a new tree (or branch) to theexisting tree is done by inserting a new column into thetable without the need of reconfiguring the table at all.
This does not violate the configuration of the table,indices, and the primary key.
The retrieval viewer is a Motif-based viewer, thatprovides a full set of menus to allow an operator to choose
any combinations of operational data of the components tobe retrieved. The retrieval viewer has a SQL querymanger that communicates with the Oracle Databaseusing stored-procedures through an SQL-Net driver.
Figure 2 shows an example of how a water-cooled
photon mask and an UHV valve are inspected using thediagnostic system, showing the retrieval result of a weekly
operation to interpret an unexpected pressure rise in thestorage ring. The upper window indicates traces of thebeam current and UHV pressures in the 2.5 GeV storagering and beam line. The lower window is correlated to theupper window area, showing trace-back information of thephoton-mask′s status and the vacuum valve, including thestatus of Open/Close signals and the driver′s signal. Anyregion on the screen can be panned by dragging the fourboxes on the both corners to scrutinize details concerning
how these are functioning properly, or to locate amalfunction part.
In addition to the MOTIF viewer, a web viewer isimplemented using Java Applet. When there is a failure ofan accelerator component during an accelerator operation,
the operators can inspect the faulty component of theaccelerator and the cause of the failure using an web
viewer in order to re-establish accelerator operation. Theweb viewer then fetches operational information andcontrol data from a remote host computer. Finally, it
displays the operational and control information on theWWW browser as the console screen.
3 Conclusion
The diagnostic system using the database for highenergy accelerators has been discussed. The system has
been shown to be reliable in operation. The system
permits failure diagnosis for the numerous accelerator
components. The diagnostic system provides valuable
information regarding a faulty component and related

physical components that would suggest the cause of afailure. By using the diagnostic system, the operator at thecontrol room can easily locate any faulty component, andrecover from the accelerator component quickly. Thissystem can be extended for various kinds of accelerator
components. The system will be ported to a UNIXplatform.
Acknowledgement
The authors wish to express their gratitude to the staffof the Photon Factory Light Source Division for operating
the beam liens and the storage ring.
References[1] R.Billen, “LEP Accelerator Logging System using
on-line database”, NIM, Sec. A, pp.296-299, 1994.
[2] N.Kanaya, S.Asaoka and H.Maezawa, “OperationalLogging System Using the Database for theSynchrotron Radiation Beam Lines at the PhotonFactory”, Proc. of Particle Accelerator Conference
1997, Vancouver, Canada, Mar. 1997 (to bepublished)[3] N.Kanaya, “Design of the Distributed Control
System for Beam Lines at the Photon Factory”, IEEE
Trans. Nucl. Sci.,Vol.NS-31, No.3, pp.957-962,
June, 1984.
[4] N.Kanaya, S.Sato, S.Asaoka, T.Koide, H.Maezawa,“Operational Experience with the DistributedControl System for Synchrotron Radiation BeamLines at the Photon Factory”, Particle Accelerators,Vol.29, pp.227-232, 1990.